本記事について
既にコンテナを運用している方からしたら当たり前の事かもしれないです。
アプリケーションのデータの保存場所
結論
クラウド上のRDSなどのPaaSを使うのが良い。
理由
スケーラビリティの担保&管理がシンプル
詳細
コンテナは可搬性に優れているがデータを永続的に持つ事は苦手である。
docker runでコンテナが作られる段階では、真っさらなデータになってしまう。
既にあるコンテナからイメージ化する事は可能だが、コードでの管理を放棄してしまっており、中身があるべき状態=もとのDockerfileのままである事を保証できない。
なのでvolumeを使って永続化を行う方法がまずある。
しかしvolumeを使う場合もローカルpcに入れるとスケールしない(トラフィックの増加に対応できない)ので、クラウド上のrdsや、s3など、永続化に強いコンポーネントと組み合わせて使う方が良い。
クラウドのPaaSをデータベース基盤に据える前提ありきであれば、ローカルDBからの移行の手間もあるので最初から最後までPaaSで行う方が好ましい。
使用するコンテナオーケストレーター
結論
Amazon ECSを使用する
理由
AWSとの親和性がある&学習コストが比較的低い
詳細
ECSを採用するかKubernatesを採用するかEKSを採用するかで迷った。
私自身これらのいずれについても無知な状態から取り組み始めるにあたって、まずKubernatesの学習コストの高さについては気になって選択肢から外れた。
ECSとEKSの選択ではこちらの方のサイトが参考になった。
今回だと、サービスの複雑度が低い事と料金コスト、学習コスト等の面でECSの採用が適正であると判断。
ECSのネットワークモード
結論
awsvpcモードを使用する
理由
AWSリソースとの連携が容易
セキュリティグループの割り当てができることで柔軟な制御が可能であること
詳細
host,bridge,awsvpcのモードが存在する。
hostモードはその名の通りEC2ホストのENIを使うモード、
bridgeモードはdockerのデフォルトであるdefault0インターフェースを使うモード、
awsvpcはホストから独立したENIを使用するモード
になる。
デプロイ方式
結論
ブルーグリーンデプロイを使用する
理由
アプリケーションのテストを検証・本番で2回行うのではなく1回で済ませる為。
詳細
ローリングアップデート、ブルーグリーンデプロイ、外部デプロイの3つの方法がある。
外部デプロイはあまり一般的でなく、情報も少ない。また、Auto Scalingがサポートされないという制約がある。ローリングアップデートがECSのデフォルトであり、ブルーグリーンデプロイに比べるとデプロイに時間がかかるが、リソースに無駄がない、設定がシンプルというメリットがある。ブルーグリーンデプロイはそれなりの設定が必要であり、即時性と可用性を担保できるので、停止が許されないシステム向けである。このような観点からローリングアップデートを基準として選択すべきと考えた。
しかし、採用しようとしている環境が開発環境、検証環境、本番環境という区分けでかつ検証環境と本番環境は環境変数以外は同一の構成としたいという希望があった。
ここで問題になるのが検証・本番に関してほぼ同じ構成であっても結合テストは2回行わなければいけないということがあった。
これを回避できる方法として、そもそも検証環境と本番環境ではなく、ブルー環境とグリーン環境として定義し、いずれかを本番トラフィックの向き先とする。アップデート時は本番トラフィックの向き先ではない環境にデプロイを行い、結合テストを実施後にトラフィックのスワップを実施することで、テストを二重に行う必要がなくなるということから、ブルーグリーンを採用した。
Dockerfileを使うか、docker-composeを使うか
結論
Dockerfileをメインで使う
理由
バージョンや依存関係に直結する部分を管理しやすいから
詳細
Dockerを使う利点の一つはアプリケーションの実行環境の依存関係やバージョンをパッケージング出来ること。
Dockerfileとdocker-composeを比較すると、Dockerfileはミドルウェアのベースイメージ自体にバージョンが付与されており、イメージをカスタマイズする形でバージョン管理が実現できるのに対して、docker-composeを使ってバージョンや依存関係を管理するとそこからDockerfileが呼ばれるような形になるので階層が一つ深くなり管理の煩雑さが生まれたり、またそれにより厳密なコントロールがしづらくなる事が懸念された。
docker-composeの使途としてコンテナの起動順序の制御などもあるが、ECSにもこの機能はあり、こちらで実現可能であることを見込んでのこともあった。