「コンテナジャーニー」〜明日から速攻始めるAWSでのコンテナ導入運用〜 #cmdevio2018

アプリケーションのコンテナ化には様々なメリットがありますが、実際に本番環境に導入するには従来のアプリケーションの考え方とは違う部分もあり、簡単にはいきません。その辛さを乗り越えて「もっと多くの人にコンテナを活用してもらいたい」という想いを、このセッションに込めました。

Developers.IO 2018

#イベントレポート

#Docker

#Amazon ECS

#AWS Fargate

#AWS

濱田孝治

2018.10.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「コンテナ導入ってどこからやったらいいんやろう…」

Amazon ECSがリリースされてから、早4年。Docker自体の進歩が目覚ましく、周辺のオーケストレーションツールや関連するOSSなども目を見張るような勢いで進化しています。以前は開発環境での利用が主流だったコンテナも、今では本番環境での採用事例も増えてきました。さらに、Fargateの東京リージョンリリースやEKSの一般公開など、話題には事欠きません。

AWSは利用しているがアプリケーションをコンテナ化するメリットがあまり感じられない人や、コンテナに関する情報量が多くどこから手を付ければよいのかわからない人向けの内容です。

コンテナジャーニーきたか…!!

　 ( ﾟдﾟ)　ｶﾞﾀｯ
　 /　　 ヾ
＿_L| /￣￣￣/＿
　 ＼/　　　/

記事内容について

この記事は、DevelopersIO 2018に登壇したときの資料を元に、話した内容や行間を埋めて再構成したものです。記事末に登壇資料へのリンクもいれています。

コンテナ導入で気をつけるべきこと

本日は、「これからコンテナ導入してみたいがなにから始めたらよいかわからない」「コンテナ導入のメリットがいまいちよくわからない」といった人に向けて、お話させていただきます。

最初に、コンテナ（Docker）についての認識合わせをさせてください。

Dockerとは、「コンテナ型仮想化技術を実現するためのプロダクト」です。

では、コンテナを導入するときに考えるべきことって、どんなことがありますかね？

技術用語っぽいのから、ポエムまでわらわら出てきました。四の五の言わずに、単純にこういうことです。

身も蓋もないですが事実です。ただ、そんなん言うてたらいつまでたっても始められないので、本日は「コンテナジャーニー」と銘打って、「こんな感じで始めたらコンテナ導入、うまく進むんじゃない？」というものを考えてみました。このスライドは十分味わってください。

おもいっきり適当な単語を作ってみた後、これを1段階ずつ説明していきます。

コンテナジャーニー、始まります！

コンテナジャーニー1「ひとりでDocker使ってみる」

最初にDocker使うためにやることは、当然みなさんのクライアントPCにDockerをインストールすることです。全てはここから始まります。

ほな、Docker試しにつかってみるわけですが、はっきり言ってHelloWordだしてもフーんで終わってしまうので、もっと実践的なツールをDockerで使ってみましょう。

オススメなのは、ドキュメントコンバーターのPandocです。

Pandoc - About pandoc

オープンソースのドキュメント・コンバータ
異なるドキュメント形式を相互に変換可能
- HTML,docx,XML,EPUB,OPML,LaTeX,PDF,Markdown
MarkdownをHTMLやdocx（Word）形式に変換できる
Haskell製

Dockerをインストールした状態で、以下のコマンドで速攻Pandocが使えます。これは、sample.md（Markdown形式）をsample.docx（Word形式）に変換する例です。

$ docker run -v `pwd`:/source jagregory/pandoc -f markdown -t docx sample.md -o sample.docx

pandocのインストールは何もやってないのに、docker runでpandocが動くんですよ。実際に後ろで動いている内容はこちら。

DockerってCLIっぽくつかえるんですよ。自分この使い方最初に見たとき、衝撃を受けました（参考：【環境構築10分】Markdown形式（md）のドキュメントを Word 形式（docx）に変換する）。

従来
- 最初にOSを起動する
- 起動したあとに、アプリケーションをいろいろ導入しておく
- 常駐させておいて外から使う
Docker
- イメージにOSとアプリケーションをあらかじめ全てまとめておく
- 使うときに呼んで、使い終わったら即捨てる

この、使うときに呼んで、使い終わったら即捨てるという感覚は、Dockerを使う上で非常に重要です。身体で感じ取っておいてください。

ここで、俺好みのDockerイメージが作りたくなってきた皆さんに、プロジェクトでよくあるツールを紹介します。こういうツール、いろんな現場にあると思います。

プロジェクトメンバーでいざ使おうとしたときに、よくある悲しいパターンがこちら。

それが、Dockerを使った場合、こんな素敵な未来が待っています。

つまりDockerを使うことで、いろんな環境の依存関係を超えることができ、インストールの手間が軽減されます。ぜひ、自分の現場を振り返って、Docker化すると幸せになるネタをさがしてみてください。

出来合いのイメージを探す場合はこちらが参考になります。

The Best Docker Repositories, Apps, and Images in Docker Hub in 2018

Dockerfileの書き方を極めたくなった場合は公式のこちらが参考になります。

Best practices for writing Dockerfiles | Docker Documentation

コンテナジャーニー2「チーム内でイメージを共有する」

先程、チーム内でイメージを共有するのに、Docker HUBを使っていることに気付きましたでしょうか。きっと、ドキドキした人もいるでしょう。

社内で使うツールをパブリックな場所に置いとくのは、さすがに嫌ですよね。そんなあなたに紹介するのが、Amazon ECRです。

Amazon EC2 Container Registry（Docker レジストリ） | AWS

AWSが提供する完全マネージド型のDockerコンテナレジストリ
自前のコンテナリポジトリの運用やインフラ管理が不要
AWSと完全に統合されているので、従来の方法（IAM）でアクセス権の管理が可能（逆にパブリック公開は不可）

使い方もとっても簡単、３ステップ。

ECRアクセス権ポリシーをIAMユーザーに付与
コンソールでECRを作
利用コマンドが表示されるので、そのとおりに利用

あとは、コンソール上に実際に使うコマンドが表示されるので、クライアントにAWS CLIとdockerがセットアップされていれば、いつでもこのECRを利用することができます。

1点注意事項として、長くリポジトリを使っていると容量が増大しがちです。ライフサイクルポリシーを設定して、古いイメージは自動的に削除するようにしましょう。

【設定10分】イメージが溜まりまくってストレージ圧迫しないようECRのライフサイクルを設定しましょ｜ DevelopersIO

ここまでで、チーム内のイメージ共有がはかどりだすと、きっとあなたはこういう気持ちになっているはずです。

コンテナジャーニー3「サーバーにコンテナをデプロイする」

開発環境でコンテナをデプロイする方法ですが、単純に以下の方法でもOKです。

適当なサーバーにDockerをインストール
アクセスするポートを決めてdocker run

でも、開発環境だからってこれで本当に使えますかね？

本命登場です。

Amazon EC2 Container Service (ECS - 高性能な Docker コンテナ管理) | AWS

Dockerコンテナアプリケーションを簡単に実行、スケール、保護可能
デプロイ時の配置場所（VPC）を指定
オートスケールによるコンテナの増減を管理
対抗馬はAmazon Elastic Container Service for Kubernetes（EKS）

AWS Fargate - サーバーやクラスターの管理が不要なコンテナの実行

サーバーやクラスターを管理することなくコンテナを実行
仮想マシンのクラスターのプロビジョニングが不要
コンソールからEC2が見えない！！

ここで、AWSのコンテナ関連サービスの関連を把握します。この図はむっちゃ重要なので、理解が曖昧な人はしっかりみてください。

ECSとEKSはいわゆるコントロールプレーンであり、コンテナを管理します。対して、FargateやEC2は実際にコンテナが稼働する場所です。EKSとFargateの間が点線になっているのは、現在、EKSはFargateをサポートしていないからです。

AWSのコンテナサービスの関連を把握した後、ECSの構造を解説します。はっきり言ってECSの構造は複雑です。

ただ、無駄に難しいわけではなくきちんと階層構造で役割付けられているので、その役割の違いを把握しておくことがECSを理解する上で重要です。

まず、タスク定義とコンテナ定義について。

最初、タスク定義を作るときに、「Fargate」or「EC2」を選択します。タスク定義には、そのタスクに割り当てるハードウェアリソース（CPU、メモリ）を定義。その中に、コンテナを複数含めることができ、それぞれの起動時の引数をコンテナ定義で指定します。コンテナ定義の中で定義できるコマンドは、docker runで指定できるコマンドとほぼ同じです。

次に、クラスタとサービスについて。

クラスターは、ECSで一番大きい単位ですね。単なる入れ物なんで、指定するパラメータはクラスター名のみ。

サービスでは、元ネタとするタスク定義を一つ指定し、そのタスクの動作に関わるパラメータを設定していきます。紐付けるALBやオートスケールの設定もここでやります。

ここまででECSの構造を理解すれば、あとは、コンソールとにらめっこしながら開発環境にコンテナデプロイし、その操作感覚を試してみてください。

Dockerアプリケーションの考慮点

設定は環境変数に格納する
- 開発、ステージング、本番で同一イメージを使うなら必須
- 他コンテナへの接続情報、DB接続情報、ログの出力レベルなども環境変数で設定できるようにする
廃棄容易性
- いつおちても支障がないように
- 永続化する必要のあるデータは、ステートフルなバックエンドサービスに格納
ログはすべてSTDOUTに
- バッファリングせずそのまま吐き出す
- 各コンテナのログドライバで受ける

さらに細かいポイントは、こちらの記事を参考に。12-factor Appsも紹介されています。

[AWS Black Belt Online Seminar] Docker on AWS レポート [12-factor App] ｜ DevelopersIO

AWS Fargateにしたときの代表的な罠

ホストインスタンスにSSHログインできない
- ホストインスタンスにSSHログインしてコンテナの状況を確認するコマンドが利用できない（docker ps、docker images、docker logs、docker execなど）
ホストインスタンスに導入する前提のセキュリティソフトが利用できない
- コンテナ単体でセキュリティをチェックする仕組みが必要
ログドライバがawslogsのみ
- 標準ではCloudWatch Logsのみに出力される

Fargateにしたときも、思わぬ「できないこと」が発生しうるので、本番適用前にかならず十分に開発環境で運用してみてください。