【AWS Black Belt Online Seminar】Docker on AWS

Ryosuke Iwanaga

Solutions Architect, Amazon Web Services Japan

2017.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

内容についての注意点

• 本資料では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

Agenda

• Docker入門

• 12-factor App

• AWS上でDockerを動かす

4

Docker入門

5

Dockerとは？

• コンテナ技術– コンテナ＝OS上での仮想レイヤ (ハードウェア仮想化ではない)

• 最近ものすごい注目を集めている– なぜ？

– 体験してみましょう

6

Docker基本要素

7

CLI Engine Registry

docker build

docker push/pull

docker run Amazon EC2 Container Registry

8

Amazon LinuxのイメージをMac上にダウンロードして実行

docker runでコンテナ内のbashを起動して確認

9

yum update, yum install python27-pip,

pip install flaskを実行

10

サンプルアプリを作成して実行

コンテナを再度実行すると、今までの作業は残っていない

11

Dockerfileに手順を記述してdocker buildを実行

12

生成されたイメージから5000番ポートをlistenするコンテナを起動

コンテナの外から、コンテナ内のアプリにアクセスができた

13

アプリを書き換え、再度build=>runして変更を確認

14

タグをつけてbuild既に作業済なのでキャッシュが使われ高速

Amazon ECRのレポジトリにできたイメージをpush

誰でも簡単にコンテナは扱える

• 起動が高速– 実態はプロセスなので、OSのbootstrap不要

• ライブラリからアプリまで1つのイメージに– サーバ構築は不要、Dockerイメージをpullするだけ

• どんな言語・フレームワークでも同じ– 必要なモノはDockerfileで入れてしまえばよい

15

12-factor App

16

Dockerをサービスで利用するには？

• サクサクコマンドラインで使うには便利だが、、、– 本番サービスで運用すると、様々なハマりポイントが存在

• VMやサーバとは違う勘所が必要になる– インフラより、むしろアプリケーションの作りが異なってくる

• Transformationのベストプラクティスは？– 開発を変化させるときに、どこに向かうべきか？

– → 12-factor App

17

18

12-factor App

• Herokuのエンジニアが2011年に提唱– 当時からコンテナを使いこなしているPaaS (Docker登場は2013年)

• このドキュメントの対象者– "サービスとして動くアプリケーションを開発しているすべての開発者。およびそのようなアプリケーションをデプロイまたは管理しているインフラエンジニア"

– → すなわち全員(今時サービスに関わらないエンジニアはいない)

19

https://12factor.net/ja/

12-factor Appとは何か？

• サービスを開発する上で、従うべき12の要素– これらに従うことで、モダンな環境に最適なアプリになる

– 2011年の定義だが、今でも変わらないベストプラクティス

– 特に、コンテナでアプリを動かす上では必須となる要素

• Dockerが使いにくいと感じたら？– それはアプリが12-factor Appになっていないことがほとんど

– どうすればアプリを12-factor Appにできるかをまず考える

– 12-factor Appを逸脱するなら、明確な理由を

20

Twelve-Factor

I. コードベースバージョン管理される1つのコードベースと複数デプロイ

II. 依存関係依存関係を明示的に宣言し分離する

III.設定設定を環境変数に格納する

IV.バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う

V. ビルド、リリース、実行ビルド、リリース、実行の3つのステージを厳密に分離する

VI.プロセスアプリを1つ又は複数のステートレスなプロセスとして実行

VII.ポートバインディングポートバインディングを通してサービスを公開する

VIII.並行性プロセスモデルによってスケールアウトする

IX.廃棄容易性高速な起動とグレースフル停止で堅牢性を最大化する

X. 開発/本番一致開発、ステージング、本番環境をできるだけ一致させた状態を保つ

XI.ログログをイベントストリームとして扱う

XII.管理プロセス管理タスクを1回限りのプロセスとして実行する

I. コードベース バージョン管理される1つのコードベースと複数デプロイ

• コードベースとアプリケーションの間には、常に1対1の関係がある。– 複数のコードベースを持つ＝分散システム

– アプリ間でコードを共通に使いたいなら、ライブラリとして取り込む

• アプリケーションのデプロイは複数存在する。 デプロイはアプリケーションの実行中のインスタンスである。– 本番環境はもちろん、開発者のローカル環境さえも1つのデプロイ

22 https://12factor.net/ja/codebase

II. 依存関係 依存関係を明示的に宣言し分離する

• システム全体にインストールされるパッケージが暗黙的に存在することに決して依存しない。– すべての依存関係を依存関係宣言マニフェスト(RubyならGemfile)で完全かつ厳密に宣言する。

– 実行時には依存関係分離ツール(RubyならBundler)を使って、取り囲んでいるシステムから暗黙の依存関係が“漏れ出ない”ことを保証する。

• アプリケーションがシステムツールを必要とするならば、そのツールをアプリケーションに組み込むべきである。– 例えば、ImageMagickやcurlコマンド等

– Docker Imageが得意とするところ

23 https://12factor.net/ja/dependencies

III. 設定 設定を環境変数に格納する

• 設定をコードから厳密に分離することを要求する。設定はデプロイごとに大きく異なるが、コードはそうではない。– 設定の例:

• データベース、Memcached、他のバックエンドサービスなどのリソースへのハンドル

• Amazon S3やTwitterなどの外部サービスの認証情報

• デプロイされたホストの正規化されたホスト名など、デプロイごとの値

– 認証情報等を漏洩せずに、今すぐコードベースをオープンソースにできるか？

• 設定を 環境変数に格納する。 環境変数は、コードを変更することなくデプロイごとに簡単に変更できる。– 設定ファイルでは不十分。環境変数はどんな言語/OSでも扱える

– 環境変数は"環境"としてまとめることはなく、デプロイ毎に独立して管理される

24 https://12factor.net/ja/config

IV. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う

• バックエンドサービスはアプリケーションが通常の動作の中でネットワーク越しに利用するすべてのサービスを言う。– 例: DB、MQ、SMTP、Cache等

• バックエンドサービスは、ローカルサービスとサードパーティサービスを区別しない。– 自前管理のMySQLからAmazon RDSへの移行の際、コードの変更が不要であること

• リソースは自由にデプロイにアタッチしたり、デプロイからデタッチしたりできる。– ハードウェアの問題によってアプリケーションのデータベースの動作がおかしい場合、アプリケーションの管理者は最新のバックアップから新しいデータベースサーバーを立ち上げる。そして現在の本番データベースをデタッチし、新しいデータベースをアタッチする– コードを一切変更せずに。

25 https://12factor.net/ja/backing-services

V. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する

• ビルド、リリース、実行の3つのステージを厳密に分離する。– ビルド: コードベースを実行可能な塊 (Docker Image)へ– リリース: ビルド＋設定で、すぐに実行できる状態に– 実行: アプリケーションを実際に(1プロセス以上)実行する

• すべてのリリースは常に一意のリリースIDを持つべきである。

• 3つのステージのライフサイクルは異なる– ビルドは、開発者がコードを変更するたびに実行される– リリースは、デプロイのたびに実行される– 実行は、スケールや障害対応で任意のタイミングで実行される

• 実行ステージは可変部分を持たない様にすることが重要

26 https://12factor.net/ja/build-release-run

VI. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する

• プロセスはステートレスかつシェアードナッシング である。– 永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービス（典型的にはデータベース）に格納しなければならない。

• メモリやディスクにキャッシュされたものが将来のリクエストやジョブにおいて利用できることを決して仮定しない– それぞれのプロセスタイプのプロセスが多く実行されている場合、将来のリクエストやジョブが別のプロセスで処理される可能性が高い。

• アセットコンパイルはビルド時に実施 (Railsの様に)

• スティッキーセッションは使わず、セッションはバックエンドサービスに保管する

27 https://12factor.net/ja/processes

VII. ポートバインディング ポートバインディングを通してサービスを公開する

• ポートにバインドすることでHTTPをサービスとして公開し、そのポートにリクエストが来るのを待つ。– コンテナが実行環境にWebサーバーランタイムを注入することを頼りにしない。

(Apache moduleやTomcatを使うなら、それをアプリケーションが持つべき)

• Dockerであれば、ホストポートとコンテナポートのマッピングが可能– 例: ホストのポート32145 => コンテナのポート80で、32145ポートを公開する

• ポートバインディングの方法によって、あるアプリケーションが他のアプリケーションにとってのバックエンドサービスになれる。

28 https://12factor.net/ja/port-binding

VIII. 並行性 プロセスモデルによってスケールアウトする

• プロセスは第一級市民である。– HTTPリクエストはWebプロセスによって処理し、時間のかかるバックグラウンドタスクはワーカープロセスによって処理することができる。

– 個々のプロセスがプロセス内部で多重化することを禁止するわけではないが、スケールアップに限界があるので、プロセス分割できることが必要

• スケールアウトが必要になった時、並行性を高める操作が単純かつ確実– シェアードナッシングで水平分割可能だから

• プロセスは決してデーモン化するべきではないし、PIDファイルを書き出すべきではない。– 標準的な機能に頼り、出力ストリームを管理し、プロセスのクラッシュに対応し、ユーザーによる再起動やシャットダウンを処理すべきである。

29 https://12factor.net/ja/concurrency

IX. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する

• 12-facter Appのプロセスは廃棄容易である、すなわち即座に起動・終了することができる。

• 起動時間を最小化するよう努力するべきである。

• SIGTERMシグナルを受け取ったときに、グレースフルにシャットダウンする。– Webプロセスなら、リクエスト受付を中止し処理中のものが終わったら終了

– ワーカープロセスなら、処理中のジョブをキューに戻す

• 突然の死に対して堅牢であるべきである。– 予期しない死があってもうまく処理できること

– 例: クラッシュオンリー設計にする

30 https://12factor.net/ja/disposability

X. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ

• 継続的デプロイしやすいよう開発環境と本番環境のギャップを小さく保つ。– 時間のギャップを小さくする: 開発者が書いたコードは数時間後、さらには数分後にはデプロイされる。

– 人材のギャップを小さくする: コードを書いた開発者はそのコードのデプロイに深く関わり、そのコードの本番環境での挙動をモニタリングする。

– ツールのギャップを小さくする: 開発環境と本番環境をできるだけ一致させた状態を保つ。

• 開発者は、開発と本番の間で異なるバックエンドサービスを使いたくなる衝動に抵抗する。– 本番環境がMySQLなのに開発環境はSQLiteを使う様なことをしない

31 https://12factor.net/ja/dev-prod-parity

XI. ログ ログをイベントストリームとして扱う

• 12-factor Appはアプリケーションの出力ストリームの送り先やストレージについて一切関知しない。– ログファイルに書き込んだりする処理をアプリケーションに実装しない

• 全てSTDOUTにバッファリングせずに書き出すだけ– 開発中は、そのストリームをフォアグラウンドで見る

– 本番等では、実行環境によってそれが捕捉され、最終目的地に配送される

• アプリケーションからはそれを知る由もない

32 https://12factor.net/ja/logs

XII. 管理プロセス 管理タスクを1回限りのプロセスとして実行する

• 1回限りの管理プロセスは、アプリケーションの通常の長時間実行されるプロセスと全く同じ環境で実行されるべきである。– 例: DBマイグレーション、調査のためのREPL、スクリプト実行(例: rails runner)

• あるリリースに対して実行され、そのリリースに対して実行されるすべてのプロセスと同じコードベースと設定を使う。

• 管理用のコードは、同期の問題を避けるためにアプリケーションコードと一緒にデプロイされるべきである。

33 https://12factor.net/ja/admin-processes

12-factor Appに従うことで得られるメリット

• セットアップ自動化のために宣言的なフォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。

• 下層のOSへの依存関係を明確化し、実行環境間での移植性を最大化する。

• モダンなクラウドプラットフォーム上へのデプロイに適しており、サーバー管理やシステム管理を不要なものにする。

• 開発環境と本番環境の 差異を最小限にし、アジリティを最大化する継続的デプロイを可能にする。

• ツール、アーキテクチャ、開発プラクティスを大幅に変更することなくスケールアップできる。

34 https://12factor.net/ja/

12-factor AppとDocker

• 12-factor Appを実行する上で、Dockerは最適– 依存関係: Dockerfile、Docker Image

– 設定: 環境変数

– ビルド、リリース、実行: Docker Image, Registry

– プロセス: Docker Container

– ポートバインディング: Port Mapping

– ログ: Logging Driver

• 逆に言えば、12-factor Appでないものを動かす時には一苦労する

35

AWS上でDockerを動かす

36

本番環境でDockerを動かす

• Dockerを動かすだけなら簡単– $ docker run [ENTER]

• 問題は、どこでどうやってDockerを動かすか？– sshして実行？フロントからどうやってルーティングする？フェイルオーバーするには？スケールするには？

• クラスタ管理の仕組みが必要1. インスタンス群の状態を管理

2. どこでどのコンテナを動かすかを決めて実行

3. コンテナ群の状態を管理

37

Amazon EC2 Container Service (ECS)

• Amazon EC2インスタンス群をDocker実行環境に簡単に変身させる– ECS Agentをインストールするだけ、管理インスタンスは不要

– ECS自体の料金は無料 (EC2等、他の利用しているリソース課金)

• 1コンテナから数万コンテナ以上を管理– 開発環境から本番環境までこれ1つで十分

• AWSの他のサービスとの深い連携– 例: AWS CloudFormationでデプロイ可能、ALB連携、etc.

38

デモ: コマンドラインで簡単に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

40

インスタンス1台の環境を作成

裏ではAWS CloudFormationがテンプレートに従いリソース作成

41

Auto Scaling Groupでt2.micro 1台が作成された

42

新規アプリを作成最後の引数がURLのPath prefix

サンプルアプリはNode.jsPATH_PREFIXを環境変数で受取る

Node.jsの依存関係定義にnpmのpackage.jsonを利用

43

buildしてrunするラッパーが8080ポートをマッピングしてくれる

44

pushすると、Amazon ECRに保存されデプロイも実行される

45

Openで実際のアクセスURLを取得

まだコンテナの数が0なので503が返ってくる

46

タスク数(=コンテナ数)を1に更新

しばらくするとアクセス可能に

logsでログストリームも確認

47

今度はアプリをPythonに変えてみる

依存関係定義をrequirements.txtで

48

やることは同じで、build、run、push

49

しばらくするとBlue/Greenデプロイされる

デモの裏側

• 全てのコンポーネントはCloudFormationで定義– AWS CLIでCloudFormationのStackを作成・更新しているだけ

– ある程度ベストプラクティスな構成のテンプレートを準備

• 要件に応じてテンプレートを自由にカスタマイズ可能

• アプリ開発者はAWSを使っていることすら意識する必要がない– 自分専用のPaaSを持てる様なイメージ

50

その他のソリューション

• もちろん他にもソリューションはある– AWS Elastic Beanstalk

– Convox https://convox.com/

• いずれのソリューションであっても、12-factor Appで作られていれば後からの変更は容易

51

より深く学ぶには？

• 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

Docker始めてみませんか？

• 12-factor Appにすることが第一ステップ– 既存アプリは、まず12-factor App化することに注力する

– 新規アプリは、必ず12-factor Appとして作る

• 12-factor Appにさえできれば、基盤やコンポーネントの入れ替えは非常に容易– ECS, Elastic Beanstalk, etc.

– バックエンドサービスも、もちろん同様

– 現実的な意味でのロックイン回避ができる

54

Q&A

55

参考情報

• 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

オンラインセミナー資料の配置場所

• AWS クラウドサービス活用資料集– http://aws.amazon.com/jp/aws-jp-introduction/

• AWS Solutions Architect ブログ– 最新の情報、セミナー中のQ&A等が掲載されています

– http://aws.typepad.com/sajp/

57

公式Twitter/FacebookAWSの最新情報をお届けします

58

@awscloud_jp

検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！

もしくはhttp://on.fb.me/1vR8yWm

AWSの導入、お問い合わせのご相談

AWSクラウド導入に関するご質問、お見積り、資料請求をご希望のお客様は以下のリンクよりお気軽にご相談くださいhttps://aws.amazon.com/jp/contact-us/aws-sales/

※「AWS 問い合わせ」で検索してください

ご参加ありがとうございました

60

61