注目の記事

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

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

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

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

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

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

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

Amazon EC2 Container Registry(Docker レジストリ) | AWS

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

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

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

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

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

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

コンテナジャーニー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 Fargateにしたときの代表的な罠

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

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

コンテナジャーニー4「リポジトリから自動デプロイする」

開発環境へのデプロイができたら、もうどんどん開発していきたいですよね。そこで、自動デプロイ環境を作ってみましょう。Code3兄弟の登場です。

自動デプロイの導入にはいろんなメリットがあります。是非がんばって導入してみてください。

  • なんせ楽
    • 常にリポジトリの状態がサーバーに反映されている
  • 再現性がある
    • だれがやっても結果は一緒
  • 導入も楽
    • docker build一発でイメージ作成できるようになってれば、導入はほぼテンプレ

導入イメージはこんな感じです。うまくいけば、30分程度。ハマったら3時間程度の作業です。

なんでこの導入が簡単かといううと、Dockerfileにサーバーの作り込みとアプリケーションのインストールが全て記載されているからです。なので、フック元のリポジトリとデプロイ先のECSのクラスタ名とサービス名を指定するだけで、あっけなくCI/CDパイプラインが完成するんですよ。むっちゃ楽ちんです。

実施の導入方法は、こちらを参考にしてみてください。

CodePipeline で ECS にデプロイできるようになり、Docker 環境の継続的デリバリも簡単になりました | DevelopersIO

ここまでで、もう、コンテナイケイケどんどんな感じがしてきます。本番運用、やってしまいましょう!

コンテナジャーニー5「本番運用してみる」

本番運用で気をつけるべきこと、3点挙げます。

監視

基本はCloudWatchを活用します。

  • 取得できる主なメトリクス
    • Fargateの場合、取得できるメトリクスがサービス単位のメモリ使用率とCPU使用率
    • クラスター予約、クラスター使用率、サービス使用率、RUNNINGタスク数
    • 閾値を設定してSNS発砲、もしくはオートスケール

詳細は、公式ドキュメントを参考に。

SaaS系の監視ツールもあるので、ここらへんも検討対象になるかと思います。

トレーサビリティ

トレーサビリティをとるために、AWS X-Rayを使ってみるのも良いかと思います。

AWS X-Ray (製品や分散アプリケーションの分析とデバッグ) | AWS

  • 分散システム間処理をトレース
  • マイクロサービスだけではない
  • アプリケーションで発生したエラーや障害の原因特定に利用

セキュリティ

セキュリティの考慮も必要になってきます。

  • アプリケーションの安全性
    • 構築したアプリに脆弱性が含まれていないか?
  • イメージの安全性
    • 元にしたイメージがそもそも安全か?
    • あとから追加したパッケージに脆弱性がないか?
    • 本番運用しているイメージに脆弱性がないか定期的に確認しているか?

無料で簡単に静的に検査するツールとして、aqua社のmicroscannerなども利用できるかと思います。

無料で脆弱性検査!Dockerfileに4行追加で導入できるmicroscannerを試してみた | DevelopersIO

SaaS型で、コンテナセキュリティを検査するツール、各ベンダーが出しています。

こちらの記事もご参考ください。

中丸さんのこちらのスライド、コンテナのセキュリティ全般について、鬼のように詳しくまとめられているので合わせて参考にすると、捗ること間違いありません。

まとめ

アプリケーションのコンテナ化から運用〜導入には、考えたほうが良いことが非常に多いです。ただ、同時にコンテナの利用は技術者目線で非常にワクワクするものです。

このワクワク感を大事にしてもらいつつ、できるところから徐々にコンテナ化に取り組んで、無理のない、その組織にフィットしたDockerの使い方を模索してもらえればと思います。

DevelopersIO 2018後日談

この記事は、Developers.IO 2018 | シリーズ | DevelopersIOの登壇資料を、別途ブログ用にまとめたものです。

最初、DevelopersIO 2018のセッション一覧見たときに「コンテナないやんけ。AWSのお祭りとか言っときながら、コンテナ無いとかありえへんやろ〜」と、本部長にかけあいました。

3分後、社長から返信がありました。

いつもこんな感じで物事が決まる弊社です。

それでは、今日はこのへんで。濱田(@hamako9999)でした。