###導入のきっかけ
###・いわゆるWeb系の現場ではコンテナのデプロイ+ CI/CDパイプライン構築が当たり前に組まれている
主なメリットとしてはフックとなる箇所（masterブランチにpushしたときなど)を指定してテスト~デプロイ~DBマイグレーションなどを自動でやってくれるというところ。それにより
テスト~デプロイまでが一定の品質で自動でできる開発者は商品価値を生み出す部分（機能の差別化など）に全力を注ぐことができる。
###Web系のエンジニアとしてDevOpsの知見と後に出て来るような構成での構築スキルは武器になる最早必須であると考えた。
###参考文献
【AWS Black Belt Online Seminar】Amazon Container Service
#まずはザックリECSの構成について
- ※今回は実際に私が構築した構成を主に説明していこうと思います。
- Cluster（＝複数EC2インスタンスの集合）上で
- Dockerコンテナを起動・管理し
- Serviceを動作させたり停止させて減らしたりする
- 以下、渾身のイメージ。
※アプリケーションはRailsで、赤枠部は現状できてないけど実装予定
#コンテナを利用した開発に必要な技術要素
- 1.アプリのステートレス化
- 2.レジストリ
- 3.コントロールプレーン／データプレーン
- 4.CI／CDパイプライン
- 5.Cluster/Agent
この辺の説明。わかっている人はこの章は読み飛ばしてもらって大丈夫です。
#1.アプリのステートレス化(Amazon RDS,S3)
###※アプリがステートレスとはどういうことか。。
- APサーバは状態のデータを保持するべきではない（負荷分散する上で必要）
- APサーバはリクエストに応じたレスポンスを返すだけ
- 状態のデータが必要であればコンテナ外のDBサーバまたはElastiCache等のインメモリキャッシュへ保存する
###ディスポーザブル（可搬性）
imageからまたコンテナ作れるからいいや。っていうアーキテクトじゃないと、それが死んだ時にそこに保持していたデータも共に死んでしまう。
だからコンテナがステートフルだと、コンテナのいいところを殺している事になる。
#####-ステートを持っているものはコンテナの外へ置く
状態をDBに持っているとしたらRDSへオブジェクトの保存はS3へ。という設計にすべき。次！
#2.レジストリ(Amazon ECR)
コンテナの起動元となるimageの置き場所
アプリ＋実行環境をpush/実行時にpullして起動する
#3.コントロールプレーン(Amazon ECS ,EKS)／データプレーン(Amazon Fargate ,EC2)
###コントロールプレーン=コンテナの管理をする場所(Amazon ECS,EKS)
-
コンテナのライフサイクル
- どこでコンテナを動かす？
- いつ止める？
- デプロイ時にどういう配置にする？
- EKSについてはこれがわかりやすかった。
AWS コンテナサービス「Fargate」「ECS(EC2)」「EKS」の違いを解説
###データプレーン=実際にコンテナが稼働する場所(Amazon Fargate,EC2,EKS)
- コントロールプレーンからの指示に従って起動
- 各種の状態を監視しコントロールプレーンへ提供
#4.CI/CDパイプライン(AWS CodePipeline,CodeBuild)
- 継続的インテグレーション(CI)/継続的デリバリー(CD)
- アプリケーションを止めずに変更やデプロイをするってやつですね。
- ポイントは誰がやっても同じようにデプロイができる（ようにする）こと
- 品質の保証。アプリケーションの開発に専念できる。などいいこといっぱい。
#5.Cluster/Agent
#####・Cluster...コンテナが実行される場所を提供するリソース群実態はVPC 内の任意のEC2インスタンス
#####・Agent...EC2の様々な情報をECS側に送るマネージャー的存在
##２０１９年のAWSSummitにて株式会社アカツキ様がこんな発表をしています。
ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker 運用の知見 #AWSSummitで以下のようにEC2ベースのコンテナ管理に戻す結果になっています。
一部のプロダクション環境で使っていたがEC2/ECSに戻した
・ Pros（メリット）
・サーバーレス
・簡単にスケールする
・ Cons（デメリット）
・スケール時間があまり早くない
・EC2のスケール時間と変わらない
・ロギング
・当時はCloudWatch Logsのみサポートだった
今の所、要件に応じて使い分けるべき。という見解です。
これらを踏まえて実際の構築の手順を記事にします。
目標：2019/08/19まで
作成中のポートフォリオの機能面を充実させたいため8/31まで新機能の実装に注力します。