ALB->ECSインスタンス->コンテナ->RDSとかRedis といった構成を構築する
- ネットワークはECSデフォルトのブリッジをつかう
- イメージ内には2つのポートをlistenするnginxが立っている。
- ALBのリスナーでは、リクエストヘッダ内のパラメータを見て、人ごとに作られたターゲットグループに振る
- ターゲットグループからECRのタスク、サービスに振られる。
作業の流れ
ECRにログイン
- Dockerイメージ作成
- ECRにコンテナイメージのpush
- クラスターを作成( ECSインスタンスの入れ物的なもの )
- タスク定義
- タスク定義を元にクラスター内にサービスを作成
ECRにイメージをpush
ECRへのアクセス権を得るには下記出力を実行する
$ aws ecr get-login --no-include-email --region ap-northeast-1コンテナにタグつけ
$ docker tag example_web:latest 111111111111111.dkr.ecr.ap-northeast-1.amazonaws.com/example_web:latestpush
$ docker push 111111111111.dkr.ecr.ap-northeast-1.amazonaws.com/example_web:latestタスク定義
- タスク定義名 : 何か入力
- ネットワークモード :
コンテナの追加
コンテナ名 : 任意
イメージ : ECRのページで確認。 あるいはdocker push で指定する先
メモリ制限 : ソフト制限 500MB / ハード制限 1000MB にした
コンテナ用に予約するメモリのソフト制限 (MiB 単位)。
システムメモリが競合している場合、Docker はコンテナメモリをこのソフト制限に維持しようとします。
ただし、コンテナは必要に応じて、memory パラメーターで指定したハード制限 (該当する場合)、またはコンテナインスタンスの使用可能なメモリの、
いずれか先に達するまで、追加のメモリを消費できます。
このパラメータは、Docker Remote API の コンテナを作成する セクションの MemoryReservation と docker run の --memory-reservation オプションにマッピングされます。
コンテナ定義で memory と memoryReservation の一方または両方を 0 以外の整数を指定する必要があります。 両方を指定する場合、memory は
memoryReservation より大きいことが必要です。memoryReservation を指定する場合、
コンテナが配置されているコンテナインスタンスの使用可能なメモリリソースからその値が減算されます。それ以外の場合は、memory の値が使用されます。
たとえば、コンテナが通常 128 MiB のメモリを使用しているが、短期間に 256 MiB のメモリにバーストする場合は、
memoryReservation を 128 MiB に、memory ハード制限を 300 MiB に設定できます。
この設定により、コンテナは、コンテナインスタンスの残りのリソースから 128 MiB のメモリのみを確保できますが、必要に応じて追加のメモリリソースを消費できるようにもなります。ポートマッピング ホストポート : 空 / コンテナポート 10080 / プロトコル TCP
ホストポート : 空 / コンテナポート 10081 / プロトコル TCP
環境
CPUユニット数 1 (コンテナが使用可能なCPU数) fargateでは、この値ごとに料金がかかる
基本 チェックボックスはon ( タスクが失敗すると止まる )
エントリポイント 空(将来的に安定したら、コマンドで指定している内容をエントリポイントに移すかも
コマンド /root/init.sh このスクリプト内でnginxとphp-fpmを起動している
作業ディレクトリ 空
環境変数 直近ですぐ必要な、キーと値の組み合わせで API_SERVER_NAME api.local.example.com WWW_SERVER_NAME www.local.example.com は設定を行った。
ネットワーク設定 これはデフォルトのまま。
追加ホストは設定するかもしれない。
ストレージとログ
ほぼデフォルト、ログの設定は ログドライバー : awslogs
ログオプション awslogs-group ecs awslogs-region ap-northeast-1 awslogs-stream-prefix example_web
セキュリティ そのまま
リソースの制限 そのまま
DOCKERラベル そのまま
クラスターでサービス作成
-
あるクラスターを選択
-
[ サービス ]のタブで[ 作成 ]ボタンをクリック
-
タスク定義は最新のものにする
-
クラスター : さっき作ったクラスター
-
サービス名 : 入力
-
タスクの数 : 起動するタスクの数、検証用コンテナで費用がかかるのは残念だが、コンテナのアップデートのしやすさを考えると 2以上を設定した方が良さそう
-
最小ヘルス率 : 新しいバージョンのタスク定義にした時に、「どこまで冗長化を落としてよいか?」 50%という事は『半分まで冗長化を落として良い』という意味になる
-
最大率 : デプロイ時、どの程度までサーバを増やせるか。 200%とした場合、デプロイ時、コンテナ数を2倍まで増やせる、という意味になる
タスクの配置
- デフォルトの[ AZバランススプレッド ]のままにした
ネットワーク構成
コンテナを立ち上げた時に、どのローロバランサーに紐付けるのか、の設定 (必要であれば)あらかじめEC2の管理画面からECS向けのALBを作っておく必要がある。 この時、ECSインスタンスを登録する必要はない。
ELB タイプ: ALBにした
サービス用 IAMロールの選択 : ecsServiceRole
ELB名 : ecs ( ここで、あらかじめALBを作成する必要がある事がわかったが、別のウィンドーでEC2の管理画面からALBを作成し、ELB名の隣のグルグルマーク押すと プルダウンに作ったALB名が追加された)
負荷分散用のコンテナ
コンテナでlistenしている/タスク定義で設定している、ポートごとに設定を追加する必要がある。 私の環境では10080と10081ポートでlistenしていたので、2つの設定を行った。
この設定は上記で指定したALBにどのようなリスナー設定をするのか、という事になる。
-
リスナーポート : 443
-
リスナープロトコル : HTTPS
-
ターゲットグループ : 新規作成 ターゲットグループ名
-
ターゲットグループのプロトコル : HTTP
-
パスパターン : /test-20171211********** 評価順 2 ※ ここは後で書き換える
Auto Scaling (オプション)
[ サービスの必要数を直接調整しない ]にした
ECSインスタンスにログインして 動作を見てみる
ECSクラスタを立てる際に、SSH鍵を設定している前提
ECSインスタンスにsshでログイン、dockerコンテナIDを確認
[ec2-user@ip-IPアドレス ~]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
facf553f1e85 11111111111111.dkr.ecr.ap-northeast-1.amazonaws.com/example_web "docker-php-entryp..." About a minute ago Up About a minute 9000/tcp, 0.0.0.0:32775->10080/tcp, 0.0.0.0:32774->10081/tcp ecs-example-web-1-exampleweb-badd91b2fe97abd13200ECSインスタンス内でcurlで確認。 この際に『Dockerfileでexposeしているportではなく、ロードバランサー用に用意されたポート』でアクセスすること 上記の例だと 32775ポートがそれ。
curlでアクセス、応答が帰ってくることを確認
[ec2-user@ip-IPアドレス ~]$ curl http://localhost:32777/トラブルシューティング
コンテナが再起動しまくる。2〜3分でコンテナが再起動しちゃっていたことがあった。
-
ECSのサービスの[ クラスター ]->[ 作成したクラスター ]->[ 作成したサービス ]->[ イベント ]のタブ を確認する。
-
ALBのターゲットグループのログ? ( ECSとALBを紐づけているので、問題になるのは『ALBからコンテナがどう見えているのか?』なので )
- ログを見てプロセスが起動しているか?
- CloudWatch logs のストリームは作ってあるか?( 作れる権限はあるか? )