この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、菊池です。
2017年2月9日（木）のAWS Black Belt Online Seminarを受講しましたので、レポートします。
今回は Docker on AWS という表題の通り、DockerをAWSで動かすことについてです。講師はAWSJソリューションアーキテクトの岩永亮介さんでした。
AWSでDockerといえば、コンテナ管理サービスのECSやコンテナレジストリであるECRがイメージされますが、今回のセミナーではそれらAWSサービスの説明はほどほどに、Dockerでアプリケーションを扱う上での重要な要素である、12-factor App にフォーカスされた内容でした。
セミナースライドは以下になります。
レポート
アジェンダは以下の通りでした。
- Docker入門
- 12-factor App
- AWS上でDockerを動かす
Docker入門
- Dockerとは
- コンテナ：OS上での仮想レイヤ
- 最近ものすごい注目されている
- 構成要素
- CLI（Dockerコマンド）
- Engine
- Registry（docker hub/Amazon ECR）
- デモ
- 基本的なDockerコマンド（docker pull/push/build/run）を使ってアプリケーションのデモを見せて頂きました
- 誰でも簡単にコンテナは扱える
- 起動が高速
- ライブラリからアプリまで1つのイメージに
- どんな言語、フレームワークでも同じ（必要なものは全てdockerfileに入れてしまえばいい）
12-factor App
- 12-factor Appとは
- Herokuのエンジニアが2011年に提唱（Docker登場以前）
- 対象者
- サービスとして稼働するアプリケーションを開発する全ての開発者、およびそれをデプロイ、管理するインフラエンジニア
- つまりは全てのエンジニア
- サービス開発で従うべき12の要素
- Dockerが使いにくと感じたら
- 12-factor Appに従っていないことがほとんど
- まずはアプリを12-factor Appにすること
- 12-factor Appを逸脱する場合には明確な理由を
- Dockerを本番サービスで利用するためには
- ハマりポイントの存在
- VM/サーバと違う勘所（インフラよりもむしろアプリケーション）
- Transformationのベストプラクティスは？ -> 12-factor App
- Twelve-Factor
- コードベース
- 依存関係
- 設定
- バックエンドサービス
- ビルド、リリース、実行
- プロセス
- ポートバインディング
- 並行性
- 廃棄容易性
- 開発/本番一致
- ログ
- 管理プロセス
- コードベース
- アプリケーションとコードベースは常に1:1であるべき
- アプリケーションに対してデプロイは複数存在（本番のほか、開発中環境も1つのデプロイである）
- 依存関係
- パッケージ/ライブラリは全て宣言する（システムにインストールされていることを前提にしない）
- ツールが必要ならばアプリケーションに組み込むべき -> Dockerが得意とするところ
- 設定
- コードと厳密に分離（変更タイミングが異なるから）
- 認証情報等を漏洩せずに、いますぐコードベースをオープンソースにできるか？
- 設定群（prod）としてまとめることもバッドノウハウ
- 環境変数を使うのがベストプラクティス
- バックエンドサービス
- ローカルとサードパーティを区別せずに使えること（例えば自前DBからRDSに移行する際にコード変更が不要であること）
- ビルド、リリース、実行
- 3つのステージを厳密に分離する
- 全てのリリースは常に一意のIDを持つべき
- 3つのステージでライフサイクルは異なる
- プロセス
- ステートレスでシェアードナッシング
- メモリ/ディスクにキャッシュされたものが将来のリクエストで利用できることを決して仮定しない
- スティッキーセッションはバッドプラクティス
- ポートバインディング
- ポートバインディングを通してサービスを公開する
- Apache module/Tomcatを使うならそのアプリケーションが持つべき
- ポートバインディングよってあるサービスのバックエンドサービスになる -> マイクロサービスが成立
- 並行性
- プロセス第一
- スケールが必要になったとき、並行性を高めることが簡単で確実
- プロセスはデーモン化するべきでない
- 廃棄容易性
- 即座に起動・停止できる
- 最小の起動時間
- グレースフルにシャットダウン
- 突然死に堅牢であること
- 開発/本番一致
- 開発環境と本番環境のギャップを小さく保つ
- 時間のギャップ（コードを書いてからデプロイされるまで）
- 人材：開発者がデプロイする
- ツール
- 本番と異なるバックエンドサービスを使わない
- 開発環境と本番環境のギャップを小さく保つ
- ログ
- 12-factor Appではログの送り先、ストレージには一切関知しない（ファイル出力をアプリケーションに実装しない）
- 全てSTDOUTにバッファリングせずに書き出すだけ（実行環境で配送する/アプリケーションでは知る由がない）
- 管理プロセス
- 管理プロセスもアプリケーションと同じ環境で実行されるべき
- 同じコードベースを使う/一緒にデプロイしておく
- 12-factor Appに従うことで得られるメリット
- 新しくプロジェクトに加わった開発者が要するコストの最小化
- クラウドへの最適化、サーバ管理/システム管理を不要に
- 開発環境と本番環境の差異を最小にし、継続的デプロイを可能に
- スケール
- 12-factor AppとDocker
- 12-factor Appの実現手段としてDockerは最適、逆に、12-factor AppでないものをDockerで動かすと苦労する
AWS上でDockerを動かす
- 本番サービスで動かす
- 動かすだけなら簡単
- 問題は、どこでどうやって？
- クラスタ管理の仕組みが必要 -> ECS
- Amazon EC2 Container Service (ECS)
- EC2群をコンテナ環境へ
- 1つから数万以上のコンテナに対応
- 他のAWSサービスとの連携
- デモ
- アプリ開発者からはAWSを意識させない
- その他のソリューション
- AWS Elastic Beanstalk
- Convox
- いずれの方法でも、12-factor Appであれば移行は容易
- 何より12-factor Appであることが重要
まとめ
- 12-factor Appにすることが第一ステップ
- 12-factor Appであれば基盤やコンポーネントの変更は容易
今後のオンラインセミナー
最後に
以上です。
まとめに集約されている通り、12-factor Appであることが重要ということがよくわかりました。便利そうなツールが注目されると、とにかく使うことが目的になってしまい、結果的に何がよくなったのかよくわからないといこともありがちです。そのツールが何を解決してくれるのか、前提として何が必要なのかをよく理解して導入していきたいですね。
18
