AWS （ECS + RDS）+ CircleciによるCI/CDの理解（初学者がインプットすべき情報）~用語と概念理解編~

###導入のきっかけ

###・いわゆるWeb系の現場ではコンテナのデプロイ+ CI/CDパイプライン構築が当たり前に組まれている


主なメリットとしてはフックとなる箇所（<font color="Salmon">masterブランチにpushしたときなど</font>)を指定してテスト~デプロイ~DBマイグレーションなどを自動でやってくれるというところ。それにより

- `テスト~デプロイまでが一定の品質で自動でできる`
- `開発者は商品価値を生み出す部分（機能の差別化など）に全力を注ぐことができる。`



###<font color="DarkOrange">Web系のエンジニアとしてDevOpsの知見と後に出て来るような構成での構築スキルは~~武器になる~~最早必須であると考えた。</font>

###参考文献
[【AWS Black Belt Online Seminar】Amazon Container Service](https://d1.awsstatic.com/webinars/jp/pdf/services/20180220_Amazoncontainerservices-blackbelt-180220131635.pdf)

[AWSのコンテナ管理入門](https://d1.awsstatic.com/events/jp/2017/summit/slide/D3T3-3.pdf)


#まずはザックリECSの構成について
- ※今回は実際に私が構築した構成を主に説明していこうと思います。
- <font color="red">Cluster（＝複数EC2インスタンスの集合）上で</font>
- <font color="red">Dockerコンテナを起動・管理し</font>
- <font color="red">Serviceを動作させたり停止させて減らしたりする</font>
- 以下、渾身のイメージ。
   ※アプリケーションはRailsで、赤枠部は現状できてないけど実装予定
![20190621システム構成図 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/303093/b6990f1d-9b29-da5c-aa14-e25234d63c39.png)





#コンテナを利用した開発に必要な技術要素
- 1.<font color="Blue">アプリのステートレス化</font>
- 2.<font color="Blue">レジストリ</font>
- 3.<font color="Blue">コントロールプレーン／データプレーン</font>
- 4.<font color="Blue">CI／CDパイプライン</font>
- 5.<font color="Blue">Cluster/Agent</font>

この辺の説明。わかっている人はこの章は読み飛ばしてもらって大丈夫です。

#1.<font color="red">アプリのステートレス化(Amazon RDS,S3)</font>
###※アプリがステートレスとはどういうことか。。
- <font color="Blue">APサーバは状態のデータを保持するべきではない（負荷分散する上で必要）</font>
- <font color="Blue">APサーバはリクエストに応じたレスポンスを返すだけ</font>
- 状態のデータが必要であればコンテナ外のDBサーバまたはElastiCache等のインメモリキャッシュへ保存する

<img width="847" alt="スクリーンショット 2019-06-17 23.37.05.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/303093/e5829518-9745-f875-49fe-c4eadc83e92f.jpeg">

<img width="691" alt="スクリーンショット 2019-06-17 23.34.40.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/303093/f09ed2cc-7fca-b0bb-1411-4efadd851aa7.jpeg">



###ディスポーザブル（可搬性）
`imageからまたコンテナ作れるからいいや。`っていうアーキテクトじゃないと、それが死んだ時にそこに保持していたデータも共に死んでしまう。
だからコンテナがステートフルだと、コンテナのいいところを殺している事になる。
#####-ステートを持っているものはコンテナの外へ置く
状態をDBに持っているとしたら`RDS`へオブジェクトの保存は`S3`へ。という設計にすべき。次！

#2.<font color="red">レジストリ(Amazon ECR)</font>
コンテナの起動元となるimageの置き場所
アプリ＋実行環境をpush/実行時にpullして起動する


#3.<font color="red">コントロールプレーン(Amazon ECS ,EKS)／データプレーン(Amazon Fargate ,EC2)</font>
###コントロールプレーン=`コンテナの管理をする場所(Amazon ECS,EKS)`
- **コンテナのライフサイクル**
  - どこでコンテナを動かす？
  - いつ止める？
  - デプロイ時にどういう配置にする？
  - EKSについてはこれがわかりやすかった。
[AWS コンテナサービス「Fargate」「ECS(EC2)」「EKS」の違いを解説](https://xn--o9j8h1c9hb5756dt0ua226amc1a.com/?p=2025)

###データプレーン=`実際にコンテナが稼働する場所(Amazon Fargate,EC2,EKS)`
- コントロールプレーンからの指示に従って起動
- 各種の状態を監視しコントロールプレーンへ提供




#4.<font color="red">CI/CDパイプライン(AWS CodePipeline,CodeBuild)</font>
- 継続的インテグレーション(CI)/継続的デリバリー(CD)
- アプリケーションを止めずに変更やデプロイをするってやつですね。
- ポイントは<font color="Red">誰がやっても同じようにデプロイができる（ようにする）</font>こと
- 品質の保証。アプリケーションの開発に専念できる。などいいこといっぱい。

#5.<font color="red">Cluster/Agent</font>
#####・Cluster...コンテナが実行される場所を提供するリソース群`実態はVPC 内の任意のEC2インスタンス`
#####・Agent...EC2の様々な情報をECS側に送るマネージャー的存在




##２０１９年のAWSSummitにて`株式会社アカツキ`様がこんな発表をしています。
[ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker 運用の知見 #AWSSummit](https://dev.classmethod.jp/cloud/aws-summit-2019-i3-04-romasaga-rs-ecs-and-docker/)で以下のようにEC2ベースのコンテナ管理に戻す結果になっています。
>一部のプロダクション環境で使っていたがEC2/ECSに戻した
・ Pros（メリット）
　・サーバーレス
　・簡単にスケールする
・ Cons（デメリット）
　・スケール時間があまり早くない
　・EC2のスケール時間と変わらない
・ロギング
　・当時はCloudWatch Logsのみサポートだった


今の所、要件に応じて使い分けるべき。という見解です。

これらを踏まえて実際の構築の手順を記事にします。
~~`目標：2019/08/19まで`~~
作成中のポートフォリオの機能面を充実させたいため`8/31`まで新機能の実装に注力します。