AWS上でDockerを使ったプロジェクトの構造と各サービスの役割から関係性を理解する。複数のAWSサービスの連携

**AWS上でDockerを使ったプロジェクト**について。ECR・ECS・EC2・ELB・Route53など多数のサービスが必要になる。

そもそも、Docker関連のECR・ECSの繋がりや、ECS内のタスク、コンテナ、クラスター、サービスの違いがイマイチ分からなかったので図で理解してみる。


##目次

1. [アプリケーションの概要](#アプリケーションの概要)
2. [ECSとECRの関係](#ecsとecrの関係)
3. [ECS](#ecs)
4. [ネットワーキング](#ネットワーキング)
5. [AWSのサービスとの関係](#awsのサービスとの関係)
6. [プロジェクト作成の流れ](#プロジェクト作成の流れ)
7. [参考リンク（一部）](#参考リンク一部)



<br>
##アプリケーションの概要

ECRにプッシュしたイメージからECSでコンテナを起動する。**コンテナはEC2のサービスと結びついており、ELBでサービスを割り振る構造**になっている。

ネットワーキングは、ユーザーが入力したFQDN/URLを、設定したエイリアスレコードで識別し、ロードバランサー（ELB）でサービスにつなぐ。



##ECSとECRの関係
**ECRはイメージを保存するレポジトリ**。DockerのDocker hubに該当する。

ECSがDockerに該当する。**コンテナの要件定義にあたる、docker-compose.ymlをECS（のタスク定義）に記述**する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563526/10dca55d-018d-a0bc-f9d3-a44e944e513a.png)

流れとしては、ローカル（自分のPC）でイメージを作成してECRにプッシュ。ECSでそのイメージを拾ってきてコンテナを起動する。

プロジェクトによって他のAWSサービス（S3, EC2, CloudFrontなど）が必要な場合はIAMで設定する。


<br>
##ECS
ECSはdocker-compose.ymlの用件定義をするだけでなく、AWS上で複数のサービス（プロジェクト）を実行するためにプラットホームとなる仮想サーバーをサービスとして定義する。

アプリケーションを更新した場合のデプロイ（展開）方法や、ロードバランサーでEC2とコンテナを接続する設定もここで行う。

<br>
**▼ECSの構造**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563526/51ac9766-00f5-3d79-de7c-c47d8c11a63c.png)

クラスターはプロジェクトを管理しやすくするためのグループといった位置付け。その中に例えば、productionやstagingといった環境の異なるサービスを作成する。

実際のサービスの根幹となるコンテナはタスクの中に定義する。このタスクをサービスの上に乗っける。



<br>
##ネットワーキング
例えば、エディタアプリケーション（EC2）が複数のサービス（ECS）につながっている場合など、

ユーザーがURLを叩いて、このコンテナにアクセスするまでの流れは以下のようになる。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563526/d5caedfb-af3e-2df8-e0eb-55c34dcaf07c.png)


```ネットワークの流れ
FQDN/URLはユーザーが入力した内容
（sub.example.com）
　↓
エイリアスレコードで識別
（example.comのエイリアス）
　↓
セキュリティグループ
（許可されたIPアドレスか確認）
　↓
ロードバランサー
(sub.example.comに対応するサービスに割り振る)
　↓
コンテナ
（Dockerのアプリケーションに入る）
　↓
必要に応じてDBなどのコンテナにアクセス
```


<br>
##AWSのサービスとの関係
このネットワークとサービスを、AWSのサービス毎にまとめると以下のようになる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563526/9809c81e-e5e6-10fc-5c72-8bdd9dcd3094.png)

さらに、EC2がS3など他のAWSサービスとも連携していることが多い。


###デプロイの自動化
上記では、手動デプロイになっているため、ローカルで更新があったら、イメージをECRにプッシュ、タスク定義の更新（対象のイメージの変更）、サービスの更新（対象のタスクのリビジョンの変更）をする必要がある。

この一連の**更新作業を自動化するためにCodePipelineを使う**。

CodePipelineはmasterとなるgithubやCodeCommitのレポジトリ/ブランチを指定して、変更があった場合に自動検知して更新をかける。


###モニタリング
CloudWatchというAWSのサービスを使うと、CPUやタスクの使用状況などをモニタリングすることができる。

サービスからCloud Watchにログを送る設定をすればすぐに使える。


<br>
**▼アプリケーションとAWSサービスの関係**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563526/574cf1b5-33b7-e195-23d1-3293d1b12601.png)


<br>
AWSの難解さはこのサービスの多さだと思う。。そして、一つ一つのサービスが結構複雑で専門用語も多い。

まずは、各サービスの役割と関係性を覚えるのが導入としてはわかりやすい。



<br>
##プロジェクト作成の流れ
様々なサービスが必要になるが、例えばECSのクラスターの作成など、事前にEC2でサービスを作成し、Route53のエイリアスレコードやELB、ECSのタスク定義などをしておく必要がある。

絶対にコレという手順はなく後から変更できるものも多い。（名前は変更できない場合が多い）


<br>
**▼大まかな作成の流れ**

1. EC2インスタンス
2. セキュリティグループ
3. ロードバランサー
4. IAM
4. Route53
5. ECR
6. ECS（タスク定義）
7. ECS（クラスター・サービス）
8. CodePipeline



<br>
##参考リンク（一部）

・ロードバランサー

https://qiita.com/yuta-38/items/44420fc734424b926495


<br>
・Route53 エイリアスレコードの作成

https://qiita.com/yuta-38/items/7ac74a4be398a0483f36


<br>
・ECRにイメージをプッシュする方法

https://qiita.com/yuta-38/items/5069bfbf249e6dee15fe



<br>
・ECSのタスク定義手順

https://qiita.com/yuta-38/items/03e682a3b6ae499716f1


<br>
・Fargateとは何か？

https://qiita.com/yuta-38/items/db146e88f083eea4ea9f


<br>
・ECSのクラスター作成手順

https://qiita.com/yuta-38/items/801b28fb7f365b064b77


<br>
・Blue/Greenデプロイとは何か？

https://qiita.com/yuta-38/items/f40f8f40efc260a7fe27


<br>
・CodeCommitとGithubの違い

https://qiita.com/yuta-38/items/83c5dd9bac89cda986f3



<br>
・更新したイメージをビルドした後のECRとECSの作業手順

https://qiita.com/yuta-38/items/1b6c215413ea5f13985b