Presentation Title Here

Size: px

Start display at page:

Download "Presentation Title Here"

あつみねありの
5 years ago
Views:

1 AWS Black Belt Online Seminar Docker on AWS Ryosuke Iwanaga Solutions Architect, Amazon Web Services Japan

AWS Black Belt Online Seminar とは AWSJのTechメンバがAWSに関する様々な事を紹介するオンラインセミナーです火曜 12:00~13:00 主にAWSのソリューションや業界カットでの使いどころなどを紹介 (例 IoT 金融業界向け etc.

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.) 開催曜日と時間帯は変更となる場合がございます最新の情報は下記をご確認下さいオンラインセミナーのスケジュール&申し込みサイト 2

3 内容についての注意点本資料では 2017 年 2 月 1 日時点のサービス内容および価格についてご説明しています最新の情報は AWS 公式ウェブサイト ( にてご確認ください資料作成には十分注意しておりますが資料内の価格と 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 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 5 Docker 入門

6 Dockerとは? コンテナ技術コンテナ =OS 上での仮想レイヤ ( ハードウェア仮想化ではない ) 最近ものすごい注目を集めているなぜ? 体験してみましょう 6

7 Docker 基本要素 CLI Engine Registry docker build docker push/pull docker run Amazon EC2 Container Registry 7

8 Amazon Linux のイメージを Mac 上にダウンロードして実行 docker run でコンテナ内の bash を起動して確認 8

9 9 yum update, yum install python27-pip, pip install flask を実行

10 サンプルアプリを作成して実行コンテナを再度実行すると今までの作業は残っていない 10

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

12 コンテナの外からコンテナ内のアプリにアクセスができた生成されたイメージから 5000 番ポートを listen するコンテナを起動 12

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

14 タグをつけて build 既に作業済なのでキャッシュが使われ高速 Amazon ECR のレポジトリにできたイメージを push 14

15 誰でも簡単にコンテナは扱える起動が高速実態はプロセスなので OS の bootstrap 不要ライブラリからアプリまで 1 つのイメージにサーバ構築は不要 Docker イメージを pull するだけどんな言語フレームワークでも同じ必要なモノは Dockerfile で入れてしまえばよい 15

16 16 12-factor App

17 Dockerをサービスで利用するには? サクサクコマンドラインで使うには便利だが本番サービスで運用すると様々なハマりポイントが存在 VM やサーバとは違う勘所が必要になるインフラよりむしろアプリケーションの作りが異なってくる Transformation のベストプラクティスは? 開発を変化させるときにどこに向かうべきか? 12-factor App 17

18 18

19 12-factor App Heroku のエンジニアが 2011 年に提唱当時からコンテナを使いこなしている PaaS (Docker 登場は 2013 年 ) このドキュメントの対象者 " サービスとして動くアプリケーションを開発しているすべての開発者およびそのようなアプリケーションをデプロイまたは管理しているインフラエンジニア " すなわち全員 ( 今時サービスに関わらないエンジニアはいない ) 19

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

23 II. 依存関係依存関係を明示的に宣言し分離するシステム全体にインストールされるパッケージが暗黙的に存在することに決して依存しないすべての依存関係を依存関係宣言マニフェスト(RubyならGemfile)で完全かつ厳密に宣言する実行時には依存関係分離ツール(RubyならBundler)を使って取り囲んでいるシステムから暗黙の依存関係が漏れ出ないことを保証するアプリケーションがシステムツールを必要とするならばそのツールをアプリケーションに組み込むべきである例えば ImageMagickやcurlコマンド等 Docker Imageが得意とするところ 23

24 III. 設定設定を環境変数に格納する設定をコードから厳密に分離することを要求する設定はデプロイごとに大きく異なるがコードはそうではない設定の例: データベース Memcached 他のバックエンドサービスなどのリソースへのハンドル Amazon S3やTwitterなどの外部サービスの認証情報デプロイされたホストの正規化されたホスト名などデプロイごとの値認証情報等を漏洩せずに今すぐコードベースをオープンソースにできるか設定を環境変数に格納する環境変数はコードを変更することなくデプロイごとに簡単に変更できる設定ファイルでは不十分環境変数はどんな言語/OSでも扱える環境変数は"環境"としてまとめることはなくデプロイ毎に独立して管理される 24

25 IV. バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱うバックエンドサービスはアプリケーションが通常の動作の中でネットワーク越しに利用するすべてのサービスを言う例: DB MQ SMTP Cache等バックエンドサービスはローカルサービスとサードパーティサービスを区別しない自前管理のMySQLからAmazon RDSへの移行の際コードの変更が不要であることリソースは自由にデプロイにアタッチしたりデプロイからデタッチしたりできるハードウェアの問題によってアプリケーションのデータベースの動作がおかしい場合アプリケーションの管理者は最新のバックアップから新しいデータベースサーバーを立ち上げるそして現在の本番データベースをデタッチし新しいデータベースをアタッチするコードを一切変更せずに 25

26 V. ビルドリリース実行ビルドリリース実行の 3 つのステージを厳密に分離するビルドリリース実行の 3 つのステージを厳密に分離するビルド : コードベースを実行可能な塊 (Docker Image) へリリース : ビルド + 設定ですぐに実行できる状態に実行 : アプリケーションを実際に (1 プロセス以上 ) 実行するすべてのリリースは常に一意のリリース ID を持つべきである 3 つのステージのライフサイクルは異なるビルドは開発者がコードを変更するたびに実行されるリリースはデプロイのたびに実行される実行はスケールや障害対応で任意のタイミングで実行される実行ステージは可変部分を持たない様にすることが重要 26

27 VI. プロセスアプリケーションを 1 つもしくは複数のステートレスなプロセスとして実行するプロセスはステートレスかつシェアードナッシングである永続化する必要のあるすべてのデータはステートフルなバックエンドサービス ( 典型的にはデータベース ) に格納しなければならないメモリやディスクにキャッシュされたものが将来のリクエストやジョブにおいて利用できることを決して仮定しないそれぞれのプロセスタイプのプロセスが多く実行されている場合将来のリクエストやジョブが別のプロセスで処理される可能性が高いアセットコンパイルはビルド時に実施 (Rails の様に ) スティッキーセッションは使わずセッションはバックエンドサービスに保管する 27

28 VII. ポートバインディングポートバインディングを通してサービスを公開するポートにバインドすることで HTTP をサービスとして公開しそのポートにリクエストが来るのを待つコンテナが実行環境に Web サーバーランタイムを注入することを頼りにしない (Apache module や Tomcat を使うならそれをアプリケーションが持つべき ) Docker であればホストポートとコンテナポートのマッピングが可能例 : ホストのポート => コンテナのポート 80 でポートを公開するポートバインディングの方法によってあるアプリケーションが他のアプリケーションにとってのバックエンドサービスになれる 28

29 VIII. 並行性プロセスモデルによってスケールアウトするプロセスは第一級市民である HTTP リクエストは Web プロセスによって処理し時間のかかるバックグラウンドタスクはワーカープロセスによって処理することができる個々のプロセスがプロセス内部で多重化することを禁止するわけではないがスケールアップに限界があるのでプロセス分割できることが必要スケールアウトが必要になった時並行性を高める操作が単純かつ確実シェアードナッシングで水平分割可能だからプロセスは決してデーモン化するべきではないし PID ファイルを書き出すべきではない標準的な機能に頼り出力ストリームを管理しプロセスのクラッシュに対応しユーザーによる再起動やシャットダウンを処理すべきである 29

30 IX. 廃棄容易性高速な起動とグレースフルシャットダウンで堅牢性を最大化する 12-facter App のプロセスは廃棄容易であるすなわち即座に起動終了することができる起動時間を最小化するよう努力するべきである SIGTERM シグナルを受け取ったときにグレースフルにシャットダウンする Web プロセスならリクエスト受付を中止し処理中のものが終わったら終了ワーカープロセスなら処理中のジョブをキューに戻す突然の死に対して堅牢であるべきである予期しない死があってもうまく処理できること例 : クラッシュオンリー設計にする 30

31 X. 開発 / 本番一致開発ステージング本番環境をできるだけ一致させた状態を保つ継続的デプロイしやすいよう開発環境と本番環境のギャップを小さく保つ時間のギャップを小さくする : 開発者が書いたコードは数時間後さらには数分後にはデプロイされる人材のギャップを小さくする : コードを書いた開発者はそのコードのデプロイに深く関わりそのコードの本番環境での挙動をモニタリングするツールのギャップを小さくする : 開発環境と本番環境をできるだけ一致させた状態を保つ開発者は開発と本番の間で異なるバックエンドサービスを使いたくなる衝動に抵抗する本番環境が MySQL なのに開発環境は SQLite を使う様なことをしない 31

32 XI. ログログをイベントストリームとして扱う 12-factor App はアプリケーションの出力ストリームの送り先やストレージについて一切関知しないログファイルに書き込んだりする処理をアプリケーションに実装しない全て STDOUT にバッファリングせずに書き出すだけ開発中はそのストリームをフォアグラウンドで見る本番等では実行環境によってそれが捕捉され最終目的地に配送されるアプリケーションからはそれを知る由もない 32

33 XII. 管理プロセス管理タスクを 1 回限りのプロセスとして実行する 1 回限りの管理プロセスはアプリケーションの通常の長時間実行されるプロセスと全く同じ環境で実行されるべきである例 : DB マイグレーション調査のための REPL スクリプト実行 ( 例 : rails runner) あるリリースに対して実行されそのリリースに対して実行されるすべてのプロセスと同じコードベースと設定を使う管理用のコードは同期の問題を避けるためにアプリケーションコードと一緒にデプロイされるべきである 33

34 12-factor App に従うことで得られるメリットセットアップ自動化のために宣言的なフォーマットを使いプロジェクトに新しく加わった開発者が要する時間とコストを最小化する下層の OS への依存関係を明確化し実行環境間での移植性を最大化するモダンなクラウドプラットフォーム上へのデプロイに適しておりサーバー管理やシステム管理を不要なものにする開発環境と本番環境の差異を最小限にしアジリティを最大化する継続的デプロイを可能にするツールアーキテクチャ開発プラクティスを大幅に変更することなくスケールアップできる 34

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

36 36 AWS 上で Docker を動かす

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

40 インスタンス 1 台の環境を作成裏では AWS CloudFormation がテンプレートに従いリソース作成 40

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

42 新規アプリを作成最後の引数が URL の Path prefix サンプルアプリは Node.js PATH_PREFIX を環境変数で受取る Node.js の依存関係定義に npm の package.json を利用 42

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

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

45 Open で実際のアクセス URL を取得まだコンテナの数が 0 なので 503 が返ってくる 45

46 タスク数 (= コンテナ数 ) を 1 に更新 logs でログストリームも確認しばらくするとアクセス可能に 46

47 今度はアプリを Python に変えてみる依存関係定義を requirements.txt で 47

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

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

50 デモの裏側全てのコンポーネントは CloudFormation で定義 AWS CLI で CloudFormation の Stack を作成更新しているだけある程度ベストプラクティスな構成のテンプレートを準備要件に応じてテンプレートを自由にカスタマイズ可能アプリ開発者は AWS を使っていることすら意識する必要がない自分専用の PaaS を持てる様なイメージ 50

51 その他のソリューションもちろん他にもソリューションはある AWS Elastic Beanstalk Convox いずれのソリューションであっても 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 55 Q&A

56 参考情報 12-factor App Amazon EC2 Container Service (ECS)

オンラインセミナー資料の配置場所 AWS クラウドサービス活用資料集 http://aws.amazon.

57 オンラインセミナー資料の配置場所 AWS クラウドサービス活用資料集 AWS Solutions Architect ブログ最新の情報セミナー中のQ&A等が掲載されています 57

58 公式 Twitter/Facebook AWS 検索もしくは最新技術情報イベント情報お役立ち情報お得なキャンペーン情報などを日々更新しています! 58

59 AWS の導入お問い合わせのご相談 AWS クラウド導入に関するご質問お見積り資料請求をご希望のお客様は以下のリンクよりお気軽にご相談ください AWS 問い合わせで検索してください

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

61 61

Presentation Title Here

Presentation Title Here AWS Black Belt Online Seminar Amazon Pinpoint 2017.04.26 アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト清水崇之 0 自己紹介清水崇之ソリューションアーキテクト ( 西日本担当 ) 大阪から沖縄まで西日本のお客様にもプライム対応で参上します AWS 芸人 ( 詳しくは https://www.slideshare.net/shimy_net/)