AWS Black Belt Online Seminar 2017 Docker on AWS
•
39 likes•67,867 views
AWS Black Belt Online Seminar 2017 Docker on AWS
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (11)
Similar to AWS Black Belt Online Seminar 2017 Docker on AWS
Similar to AWS Black Belt Online Seminar 2017 Docker on AWS (20)
More from Amazon Web Services Japan
More from Amazon Web Services Japan (20)
AWS Black Belt Online Seminar 2017 Docker on AWS
- 1. 【AWS Black Belt Online Seminar】 Docker on AWS Ryosuke Iwanaga Solutions Architect, Amazon Web Services Japan 2017.2
- 2. AWS Black Belt Online Seminar とは AWSJのTechメンバがAWSに関する様々な事を紹介するオンラインセミナーです 【火曜 12:00~13:00】 主にAWSのソリューションや 業界カットでの使いどころなどを紹介 (例：IoT、金融業界向け etc.) 【水曜 18:00~19:00】 主にAWSサービスの紹介や アップデートの解説 (例：EC2、RDS、Lambda etc.) ※開催曜日と時間帯は変更となる場合がございます。 最新の情報は下記をご確認下さい。 オンラインセミナーのスケジュール&申し込みサイト – https://aws.amazon.com/jp/about-aws/events/webinars/ 2
- 3. 内容についての注意点 • 本資料では2017年2月1日時点のサービス内容および価格についてご説明しています。最新の 情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。 • 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に 相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。 • 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途 消費税をご請求させていただきます。 • AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided. 3
- 4. Agenda • Docker入門 • 12-factor App • AWS上でDockerを動かす 4
- 5. Docker入門 5
- 6. Dockerとは？ • コンテナ技術 – コンテナ＝OS上での仮想レイヤ (ハードウェア仮想化ではない) • 最近ものすごい注目を集めている – なぜ？ – 体験してみましょう 6
- 7. Docker基本要素 7 CLI Engine Registry docker build docker push/pull docker run Amazon EC2 Container Registry
- 9. 9 yum update, yum install python27-pip, pip install flaskを実行
- 15. 誰でも簡単にコンテナは扱える • 起動が高速 – 実態はプロセスなので、OSのbootstrap不要 • ライブラリからアプリまで1つのイメージに – サーバ構築は不要、Dockerイメージをpullするだけ • どんな言語・フレームワークでも同じ – 必要なモノはDockerfileで入れてしまえばよい 15
- 16. 12-factor App 16
- 17. Dockerをサービスで利用するには？ • サクサクコマンドラインで使うには便利だが、、、 – 本番サービスで運用すると、様々なハマりポイントが存在 • VMやサーバとは違う勘所が必要になる – インフラより、むしろアプリケーションの作りが異なってくる • Transformationのベストプラクティスは？ – 開発を変化させるときに、どこに向かうべきか？ – → 12-factor App 17
- 18. 18
- 19. 12-factor App • Herokuのエンジニアが2011年に提唱 – 当時からコンテナを使いこなしているPaaS (Docker登場は2013年) • このドキュメントの対象者 – "サービスとして動くアプリケーションを開発しているすべての開発 者。およびそのようなアプリケーションをデプロイまたは管理して いるインフラエンジニア" – → すなわち全員(今時サービスに関わらないエンジニアはいない) 19 https://12factor.net/ja/
- 20. 12-factor Appとは何か？ • サービスを開発する上で、従うべき12の要素 – これらに従うことで、モダンな環境に最適なアプリになる – 2011年の定義だが、今でも変わらないベストプラクティス – 特に、コンテナでアプリを動かす上では必須となる要素 • Dockerが使いにくいと感じたら？ – それはアプリが12-factor Appになっていないことがほとんど – どうすればアプリを12-factor Appにできるかをまず考える – 12-factor Appを逸脱するなら、明確な理由を 20
- 21. Twelve-Factor I. コードベース バージョン管理される1つのコードベースと複数デプロイ II. 依存関係 依存関係を明示的に宣言し分離する III.設定 設定を環境変数に格納する IV.バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する VI.プロセス アプリを1つ又は複数のステートレスなプロセスとして実行 VII.ポートバインディング ポートバインディングを通してサービスを公開する VIII.並行性 プロセスモデルによってスケールアウトする IX. 廃棄容易性 高速な起動とグレースフル停止で堅牢性を最大化する X. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ XI. ログ ログをイベントストリームとして扱う XII.管理プロセス 管理タスクを1回限りのプロセスとして実行する
- 22. I. コードベース バージョン管理される1つのコードベースと複数デプロイ • コードベースとアプリケーションの間には、常に1対1の関 係がある。 – 複数のコードベースを持つ＝分散システム – アプリ間でコードを共通に使いたいなら、ライブラリとして取り込む • アプリケーションのデプロイは複数存在する。 デプロイは アプリケーションの実行中のインスタンスである。 – 本番環境はもちろん、開発者のローカル環境さえも1つのデプロイ 22 https://12factor.net/ja/codebase
- 23. II. 依存関係 依存関係を明示的に宣言し分離する • システム全体にインストールされるパッケージが暗黙的に 存在することに決して依存しない。 – すべての依存関係を依存関係宣言マニフェスト(RubyならGemfile)で完全 かつ厳密に宣言する。 – 実行時には依存関係分離ツール(RubyならBundler)を使って、取り囲んで いるシステムから暗黙の依存関係が“漏れ出ない”ことを保証する。 • アプリケーションがシステムツールを必要とするならば、 そのツールをアプリケーションに組み込むべきである。 – 例えば、ImageMagickやcurlコマンド等 – Docker Imageが得意とするところ 23 https://12factor.net/ja/dependencies
- 24. III. 設定 設定を環境変数に格納する • 設定をコードから厳密に分離することを要求する。設定は デプロイごとに大きく異なるが、コードはそうではない。 – 設定の例: • データベース、Memcached、他のバックエンドサービスなどのリソースへのハンドル • Amazon S3やTwitterなどの外部サービスの認証情報 • デプロイされたホストの正規化されたホスト名など、デプロイごとの値 – 認証情報等を漏洩せずに、今すぐコードベースをオープンソースにできるか？ • 設定を 環境変数に格納する。 環境変数は、コードを変更 することなくデプロイごとに簡単に変更できる。 – 設定ファイルでは不十分。環境変数はどんな言語/OSでも扱える – 環境変数は"環境"としてまとめることはなく、デプロイ毎に独立して管理される 24 https://12factor.net/ja/config
- 25. IV. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う • バックエンドサービスはアプリケーションが通常の動作の中で ネットワーク越しに利用するすべてのサービスを言う。 – 例: DB、MQ、SMTP、Cache等 • バックエンドサービスは、ローカルサービスとサードパーティ サービスを区別しない。 – 自前管理のMySQLからAmazon RDSへの移行の際、コードの変更が不要であること • リソースは自由にデプロイにアタッチしたり、デプロイからデ タッチしたりできる。 – ハードウェアの問題によってアプリケーションのデータベースの動作がおかしい場合、ア プリケーションの管理者は最新のバックアップから新しいデータベースサーバーを立ち上 げる。そして現在の本番データベースをデタッチし、新しいデータベースをアタッチする – コードを一切変更せずに。 25 https://12factor.net/ja/backing-services
- 26. V. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する • ビルド、リリース、実行の3つのステージを厳密に分離する。 – ビルド: コードベースを実行可能な塊 (Docker Image)へ – リリース: ビルド＋設定で、すぐに実行できる状態に – 実行: アプリケーションを実際に(1プロセス以上)実行する • すべてのリリースは常に一意のリリースIDを持つべきである。 • 3つのステージのライフサイクルは異なる – ビルドは、開発者がコードを変更するたびに実行される – リリースは、デプロイのたびに実行される – 実行は、スケールや障害対応で任意のタイミングで実行される • 実行ステージは可変部分を持たない様にすることが重要 26 https://12factor.net/ja/build-release-run
- 27. VI. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する • プロセスはステートレスかつシェアードナッシング である。 – 永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービス （典型的にはデータベース）に格納しなければならない。 • メモリやディスクにキャッシュされたものが将来のリクエ ストやジョブにおいて利用できることを決して仮定しない – それぞれのプロセスタイプのプロセスが多く実行されている場合、将来のリクエス トやジョブが別のプロセスで処理される可能性が高い。 • アセットコンパイルはビルド時に実施 (Railsの様に) • スティッキーセッションは使わず、セッションはバックエ ンドサービスに保管する 27 https://12factor.net/ja/processes
- 28. VII. ポートバインディング ポートバインディングを通してサービスを公開する • ポートにバインドすることでHTTPをサービスとして公開 し、そのポートにリクエストが来るのを待つ。 – コンテナが実行環境にWebサーバーランタイムを注入することを頼りにしない。 (Apache moduleやTomcatを使うなら、それをアプリケーションが持つべき) • Dockerであれば、ホストポートとコンテナポートのマッ ピングが可能 – 例: ホストのポート32145 => コンテナのポート80で、32145ポートを公開する • ポートバインディングの方法によって、あるアプリケー ションが他のアプリケーションにとってのバックエンド サービスになれる。 28 https://12factor.net/ja/port-binding
- 29. VIII. 並行性 プロセスモデルによってスケールアウトする • プロセスは第一級市民である。 – HTTPリクエストはWebプロセスによって処理し、時間のかかるバックグラウンドタスク はワーカープロセスによって処理することができる。 – 個々のプロセスがプロセス内部で多重化することを禁止するわけではないが、スケール アップに限界があるので、プロセス分割できることが必要 • スケールアウトが必要になった時、並行性を高める操作が単純 かつ確実 – シェアードナッシングで水平分割可能だから • プロセスは決してデーモン化するべきではないし、PIDファイル を書き出すべきではない。 – 標準的な機能に頼り、出力ストリームを管理し、プロセスのクラッシュに対応し、ユー ザーによる再起動やシャットダウンを処理すべきである。 29 https://12factor.net/ja/concurrency
- 30. IX. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する • 12-facter Appのプロセスは廃棄容易である、すなわち即座に起 動・終了することができる。 • 起動時間を最小化するよう努力するべきである。 • SIGTERMシグナルを受け取ったときに、グレースフルにシャッ トダウンする。 – Webプロセスなら、リクエスト受付を中止し処理中のものが終わったら終了 – ワーカープロセスなら、処理中のジョブをキューに戻す • 突然の死に対して堅牢であるべきである。 – 予期しない死があってもうまく処理できること – 例: クラッシュオンリー設計にする 30 https://12factor.net/ja/disposability
- 31. X. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ • 継続的デプロイしやすいよう開発環境と本番環境のギャッ プを小さく保つ。 – 時間のギャップを小さくする: 開発者が書いたコードは数時間後、さらには数分後 にはデプロイされる。 – 人材のギャップを小さくする: コードを書いた開発者はそのコードのデプロイに深 く関わり、そのコードの本番環境での挙動をモニタリングする。 – ツールのギャップを小さくする: 開発環境と本番環境をできるだけ一致させた状態 を保つ。 • 開発者は、開発と本番の間で異なるバックエンドサービス を使いたくなる衝動に抵抗する。 – 本番環境がMySQLなのに開発環境はSQLiteを使う様なことをしない 31 https://12factor.net/ja/dev-prod-parity
- 32. XI. ログ ログをイベントストリームとして扱う • 12-factor Appはアプリケーションの出力ストリームの送 り先やストレージについて一切関知しない。 – ログファイルに書き込んだりする処理をアプリケーションに実装しない • 全てSTDOUTにバッファリングせずに書き出すだけ – 開発中は、そのストリームをフォアグラウンドで見る – 本番等では、実行環境によってそれが捕捉され、最終目的地に配送される • アプリケーションからはそれを知る由もない 32 https://12factor.net/ja/logs
- 33. XII. 管理プロセス 管理タスクを1回限りのプロセスとして実行する • 1回限りの管理プロセスは、アプリケーションの通常の長 時間実行されるプロセスと全く同じ環境で実行されるべき である。 – 例: DBマイグレーション、調査のためのREPL、スクリプト実行(例: rails runner) • あるリリースに対して実行され、そのリリースに対して実 行されるすべてのプロセスと同じコードベースと設定を使 う。 • 管理用のコードは、同期の問題を避けるためにアプリケー ションコードと一緒にデプロイされるべきである。 33 https://12factor.net/ja/admin-processes
- 34. 12-factor Appに従うことで得られるメリット • セットアップ自動化のために宣言的なフォーマットを使い、 プロジェクトに新しく加わった開発者が要する時間とコス トを最小化する。 • 下層のOSへの依存関係を明確化し、実行環境間での移植 性を最大化する。 • モダンなクラウドプラットフォーム上へのデプロイに適し ており、サーバー管理やシステム管理を不要なものにする。 • 開発環境と本番環境の 差異を最小限にし、アジリティを最 大化する継続的デプロイを可能にする。 • ツール、アーキテクチャ、開発プラクティスを大幅に変更 することなくスケールアップできる。 34 https://12factor.net/ja/
- 35. 12-factor AppとDocker • 12-factor Appを実行する上で、Dockerは最適 – 依存関係: Dockerfile、Docker Image – 設定: 環境変数 – ビルド、リリース、実行: Docker Image, Registry – プロセス: Docker Container – ポートバインディング: Port Mapping – ログ: Logging Driver • 逆に言えば、12-factor Appでないものを動かす 時には一苦労する 35
- 37. 本番環境でDockerを動かす • Dockerを動かすだけなら簡単 – $ docker run [ENTER] • 問題は、どこでどうやってDockerを動かすか？ – sshして実行？フロントからどうやってルーティングする？フェイル オーバーするには？スケールするには？ • クラスタ管理の仕組みが必要 1. インスタンス群の状態を管理 2. どこでどのコンテナを動かすかを決めて実行 3. コンテナ群の状態を管理 37
- 38. Amazon EC2 Container Service (ECS) • Amazon EC2インスタンス群をDocker実行環境に 簡単に変身させる – ECS Agentをインストールするだけ、管理インスタンスは不要 – ECS自体の料金は無料 (EC2等、他の利用しているリソース課金) • 1コンテナから数万コンテナ以上を管理 – 開発環境から本番環境までこれ1つで十分 • AWSの他のサービスとの深い連携 – 例: AWS CloudFormationでデプロイ可能、ALB連携、etc. 38
- 39. デモ: コマンドラインで簡単にDocker開発スタート • aws-docker provision --instances 1 • aws-docker create myapp /myapp • aws-docker build • aws-docker push • aws-docker open • aws-docker logs • aws-docker update --tasks 1 39
- 41. 41 Auto Scaling Groupで t2.micro 1台が作成された
- 50. デモの裏側 • 全てのコンポーネントはCloudFormationで定義 – AWS CLIでCloudFormationのStackを作成・更新しているだけ – ある程度ベストプラクティスな構成のテンプレートを準備 • 要件に応じてテンプレートを自由にカスタマイズ可能 • アプリ開発者はAWSを使っていることすら意識す る必要がない – 自分専用のPaaSを持てる様なイメージ 50
- 51. その他のソリューション • もちろん他にもソリューションはある – AWS Elastic Beanstalk – Convox https://convox.com/ • いずれのソリューションであっても、12-factor Appで作られていれば後からの変更は容易 51
- 52. より深く学ぶには？ • AWSの他のサービスの学習をすることで更に発展 – Auto Scaling (Application Auto Scaling) – Elastic Load Balancing (Application Load Balancer) – AWS Identity and Access Management – AWS CloudWatch Logs – Amazon EC2 Container Registry – AWS CloudFormation – and more… • ただ、その前に12-factor Appであることが重要 52
- 53. まとめ 53
- 54. Docker始めてみませんか？ • 12-factor Appにすることが第一ステップ – 既存アプリは、まず12-factor App化することに注力する – 新規アプリは、必ず12-factor Appとして作る • 12-factor Appにさえできれば、基盤やコンポーネ ントの入れ替えは非常に容易 – ECS, Elastic Beanstalk, etc. – バックエンドサービスも、もちろん同様 – 現実的な意味でのロックイン回避ができる 54
- 55. Q&A 55
- 56. 参考情報 • 12-factor App – https://12factor.net/ja/ – https://www.infoq.com/presentations/12-Principles-Deploy-Apps • Amazon EC2 Container Service (ECS) – https://aws.amazon.com/ecs/ – http://www.slideshare.net/AmazonWebServicesJapan/aws-black- belt-online-seminar-2016-amazon-ec2-container-service 56
- 57. オンラインセミナー資料の配置場所 • AWS クラウドサービス活用資料集 – http://aws.amazon.com/jp/aws-jp-introduction/ • AWS Solutions Architect ブログ – 最新の情報、セミナー中のQ&A等が掲載されています – http://aws.typepad.com/sajp/ 57
- 61. 61