« AWS Black Belt Online Seminar「AWSで実現するDisaster Recovery」の資料およびQA公開 | メイン | 【AWS Database Blog】DynamoDB におけるパーティションキー設計の手引き »

AWS Black Belt Online Seminar「Docker on AWS」の資料およびQA公開

みなさんこんばんは。ソリューションアーキテクト小川です。

先日開催したBlackBeltオンラインセミナー「Docker on AWS」の資料が公開されております。当日みなさまから寄せられたQ&Aの回答と併せて、この記事でご紹介させて頂きます。

【Q&A】
Q1:Dockerイメージの作成単位ですが、グッドプラクティスはあるでしょうか?
A1:コンテナ内で複数のプロセスが動く様なデザインは、12-factor Appとしては良くないので避けるのがベストです。また、古典的なWEB+APの構成を取る必要があるかどうかというところから検討すると良いです。Dockerを使ったシステムではAPサーバのみの構成もよく見られます。

Q2:イメージは作成したOSに依存(そのOS上でしか動かないなど)しますか?
A2:イメージがどのOS(プラットフォーム)をベースにしているかは注意が必要です。元々DockerはLinuxのイメージのみで、Docker for Mac/WindowsではLinux Kernelをエミュレートする様な形を取って別OS上でもLinuxイメージが実行可能となっています。Linux Kernelのみをホストと共有する形になるので、ディストリビューションという意味でのOS(Ubuntu, CentOS, Amazon Linux等)はホストと揃っている必要はありません。
一方、最近Windows ServerもDockerコンテナが登場しましたが、こちらはイメージがLinuxではなくWindows Serverになり、現状はWindowsでのみ実行可能です。

Q3:実行ステージは可変部分を持たないようにする、とはどういう意味でしょうか?ビルド、リリースと分離されているため、実行フェーズで変更を加えない、という意味でしょうか?
A3:その通りです。実行ステージではリリースステージで組み合わせられたビルド+設定を実行するだけにすべきです。そうすることで、他のステージからライフサイクルを切り離して運用することが可能になります。

Q4:Githubと連動したCI/CD環境を作る際に組み合わせると良いサービスを教えてください。コードがGithubにpushされたら、docker imageをビルドし、ECRにpushされ、テスト環境にデプロイし、テストして、本番環境にデプロイし、・・・の流れ。
A4:デプロイ速度を安定して高速化するためにCI/CD環境は有用です。AWSでは、CI/CDのパイプライン管理のために利用できるAWS CodePipeline、Dockerイメージのbuild&pushに使えるAWS CodeBuild、Amazon ECSへのデプロイに使えるAWS CloudFormationを提供しており、これらを組み合わせたリファレンスアーキテクチャおよびCI/CDそのものの解説がこちらにありますのでご参照下さい。
https://aws.amazon.com/jp/blogs/news/continuous-deployment-to-amazon-ecs-using-aws-codepipeline-aws-codebuild-amazon-ecr-and-aws-cloudformation/

Q5:並行性で「プロセスは決してデーモン化するべきではないし、PIDファイルを書き出すべきではない。」と言っていた理由を詳しく補足いただけますか?
A5:12-factor Appのプロセスは自分自身でデーモン化するのではなく、実行環境に任せるべきという主張になります。Dockerの場合、docker run -dというオプションでデーモン実行が簡単にできますし、プロセス停止時の対処はAmazon ECSの様なクラスタ管理が面倒をみるべきです。

Q6:コンテナでは、ホストマシンのある領域を、コンテナ側でMountすることもできたと思いますが、ここにログ出力することはBadプラクティスでしょうか?Stdoutに書き出して、StreamをCatchすべき?
A6:Dockerの仕組みでホストOS側のディスクをコンテナにマウントすることは可能です。しかし、ファイルに書くということがもたらす制約(例: 複数コンテナのログを見たいときに各マシンからログを集めないといけない等)に引きずられて、実行環境が複雑になってしまいます。STDOUTに書き出してさえおけば、開発環境ではフォアグラウンドにすぐ出力されますし、本番環境ではLogging Driverの仕組みによって中央システムにリアルタイムに送ることが可能です。DockerのLogging Driverにはawslogsというものが既に入っていて、これはAmazon CloudWatch Logsというログの保管サービスに転送できるドライバになっています。CloudWatch Logsで集中的にログを扱うことができるので非常に便利です。

Q7:Docker(コンテナ)のデメリット(これは出来ないなど)はありますか?
A7:パフォーマンスという意味でディスクIOが弱いです。なので、データベース等を動かすのには向いていません。12-factor Appの原則に沿ったステートレスなアプリの設計を心がけると良いです。(ステートを持つのはバックエンドサービスで)

Q8:Dockerそのものの仕組みについての質問になりますが、OSのbootstrapが不要で、プロセスとして稼働するのに、なぜ異なるOSでもOKなのでしょうか?カーネルを下位互換として古いOSのみ対応なのでしょうか?古いOSをホストとして、新しいOSをコンテナとして利用しても問題ないのでしょうか?
A8:Linuxの場合ですが、Kernelをホストとコンテナで共有しています。なので、異なるKernelで動くことはできません。一方、それ以外のファイルを含んだディストリビューションのバージョンに関しては、chrootの様にルートファイルシステムを切り替えて実行されるので、ホストとコンテナの間に関連性はなく自由なOSが利用できます。そのイメージがどのバージョンのKernelを保証するかはイメージ次第になるかと思います。

Q9:cronの設定をlambdaとSSM(Amazon EC2 Simple Systems Manager agent)を使って行っているのですが、ベストプラクティスはありますか?
A9:いくつか方式があります。デプロイされているリリースと同じビルド+設定で、crondのみを実行するコンテナをアプリサーバとは別に起動しておくのも1つのやり方です。cronのキックをAWS Lambda (実際はAmazon CloudWatch EventsのScheduled events)に任せるなら、そこからAmazon ECSのようなクラスタ管理ツールに対して12-factor Appで言う管理アプリの実行を依頼するのが良いです(ECSならRun Task API等)。SSMで実行すると、クラスタ管理の外側で実行されることになるり、残リソースの計算がおかしくなってしまうので極力避けた方が良いです。

Q10:12-factor app の「設定を環境変数に格納する」について、環境依存の設定値をアプリケーションのコードから分離して環境変数で受け渡しするという話がありましたが、その環境変数自体はどう管理するのが良いのでしょうか。普通にChefやAnsibleなどでしょうか。
A10:Dockerでは実行時にコンテナに環境変数を渡すことができます。その渡す値自体の管理はクラスタ管理が行ってくれる場合が多いです。Amazon ECSではコンテナを実行する定義であるタスク定義の中に環境変数も指定できます。また、そこに秘匿情報を入れたい場合にはAmazon EC2 Systems ManagerのParameter Storeを使って安全に管理する方法もあります。詳しくはこちらのブログに情報がございます。(少しAWS的にアドバンスドな内容になります)
ChefやAnsibleでホストOSに環境変数(の元になる情報)を持たせると、ホストOSへの設定作業がデプロイ時に発生することになってしまい、実行環境の複雑化が発生します。可能な限りクラスタ管理自身が持っている機能に任せるのが良いデザインです 。
 
以上です。今後のBlackBeltオンラインセミナーの配信予定についてはこちらに掲載されております。
3月の配信についても確定して、3月分はこちらのAmazon Web Service ブログにも掲載させていただいております。引き続きみなさまのご参加をスピーカー&スタッフ一同お待ちしております。
 

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2017年5 月

  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31