More Related Content
Similar to AWS Black Belt Online Seminar 2017 Docker on AWS (20)
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
- 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
- 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
- 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
- 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
- 54. Docker始めてみませんか?
• 12-factor Appにすることが第一ステップ
– 既存アプリは、まず12-factor App化することに注力する
– 新規アプリは、必ず12-factor Appとして作る
• 12-factor Appにさえできれば、基盤やコンポーネ
ントの入れ替えは非常に容易
– ECS, Elastic Beanstalk, etc.
– バックエンドサービスも、もちろん同様
– 現実的な意味でのロックイン回避ができる
54
- 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