Posted:
| Categories:
cheatsheet
| Tags:
AWS,
aws-cli,
cheatsheet,
ECR
2021/09/10 時点だと --region us-east-1 が必要だった。でないと
Could not connect to the endpoint URL: "https://api.ecr-public.ap-northeast-1.amazonaws.com/"
というエラーがでる。AWS 管理コンソール上は東京リージョンで存在を確認できる。
作成
AWS 管理コンソールでの作り方は パブリックリポジトリの作成
aws ecr-public create-repository --repository-name hogehoge --region us-east-1
削除
aws ecr-public delete-repository --repository-name hogehoge --region us-east-1
push までの流れ
- push する前にログインする( public とはいえ push にはログインが必要
- ビルドする
- タグづけをする
- push
aws ecr-public get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin public.ecr.aws/hoge
docker build -t test-20210910-1 .
docker tag test-20210910-1:latest public.ecr.aws/hoge/test-20210910-1:latest
docker push public.ecr.aws/hoge/test-20210910-1:latest
push の手順は各リポジトリにある。
Read more...Posted:
| Categories:
AWS
| Tags:
aws-cli,
docker,
ECR
dockerコンテナをECR repository( 以下、ECR )にアップする
まず、Web UIにログインした後、上部メニューの[ サービス ]->[ Elastic Container Registry ]->[ リポジトリ ]->[ リポジトリの作成 ] からリポジトリを作成する。
リポジトリ名
『リポジトリ名は英字で始まる必要があり、小文字、数字、ハイフン、アンダースコア、スラッシュのみを含めることができます。』というルールがある。
スラッシュがつけられるので、組織名をつけた。Githubのレポジトリ名は大文字を許容するが、ECRは許容しないので小文字に変更する。
example/Hoge_Web -> example/hoge_web
AWS CLIがインストールされていなければインストールして、アカウント設定する
ECRへのアクセス設定をする
( これはリポジトリ作成時に説明が表示されます。一度、空のリポジトリを作成すると流れがより良く分かるかもしれません )
ECRにログインする
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
上記コマンドはそのまま実行できる形なので、出力を別途実行する必要はありません。
Dockerイメージをビルドする
カレントディレクトリにあるDockerfileを用いてイメージ作成。Dockerfileにある場所に移動してから docker buildする。
docker build -t example/hoge_api .
イメージにタグを付ける
docker tag example/hoge_api:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/example/hoge_api:latest
Dockerレポジトリを作成
aws ecr create-repository --region us-east-1 --repository-name hoge
実行例。 これは2017/12に出たばかりの fargateモードで検証するため、バージニア北部リージョンにレポジトリを作成している
Read more...Posted:
| Categories:
AWS
| Tags:
ECR,
ECS
基本、下記をなぞる。
が、「artifacts として事前準備で作成したタスク定義ファイルを指定します。」という表現だけが違う、気がする。
AWS CodePipelineがECSへのデプロイをサポートしたのでやってみる - Qiita
ECSのタスク定義に使用する( aws ecs register-task-definition –cli-input-json ./imagedefinitions.json で使用する )ファイルのフォーマットと
artifactsのフォーマットは異なる。
[ The image definition file image definitions.json contains invalid JSON format ]というエラーが出る。
構成
- Githubのあるブランチにgit pushすると、CodePipelineが反応する
- CodePipeline経由で、CodeBuildが起動、DockerイメージをビルドしてECRにdocker push、ECRのタスク定義も更新して新しいイメージが見えるようにする
- 開発者が見る、URLはALB -> ECSインスタンス -> ECSコンテナ という形でアクセスする
- ALBはリクエストヘッダ中のホスト名の箇所で特定のターゲットグループに振り分ける設定にする
- むやみにALBインスタンスを増やさない
作業の流れ
ECRでDockerレポジトリを作成、Dockerイメージをビルドして、Dockerレポジトリに入れる。
Dockerレポジトリにあるイメージを用いて、ECSのタスク定義を行う。
CodePipelineは設定を行えば、定期的にGithubの特定のレポジトリを監視して、
変更があったらDockerイメージをビルドできる。この際、『どのようにビルドするか』を
Gitレポジトリのトップディレクトリにある buildspec.yml に従って行う。このbuildspec.ymlを用意しておく。
あらかじめGithubに目的のブランチを作っておく( でないとCodePipelineの設定時に、ターゲットのブランチがプルダウンメニューに現れない )
CodePipelineの設定を行い、自動ビルドを回し始める。
手順
- 対応ブランチごとにECRのリポジトリを作成する
https://ap-northeast-1.console.aws.amazon.com/ecs/home?region=ap-northeast-1#/repositories
ECSの管理コンソールにログイン ->[ リポジトリの作成 ]->[ リポジトリ名 ]にレポジトリ名[ api9 ]などを入れる。
このECRのレポジトリ名はGithubのブランチと揃えるようにした。
- Dockerイメージを作成する
既にあるDockerの作業環境を流用する。
Dockerイメージをビルドする。
このコマンドは ECRでDockerレポジトリを作成した後、[ プッシュコマンドの表示 ]で確認できるコマンドに沿う。
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
で表示されたコマンドを実行。Dockerfileがあるディレクトリに移動し
Read more...Posted:
| Categories:
AWS
| Tags:
ECR,
ECS
ALB->ECSインスタンス->コンテナ->RDSとかRedis といった構成を構築する
- ネットワークはECSデフォルトのブリッジをつかう
- イメージ内には2つのポートをlistenするnginxが立っている。
- ALBのリスナーでは、リクエストヘッダ内のパラメータを見て、人ごとに作られたターゲットグループに振る
- ターゲットグループからECRのタスク、サービスに振られる。
作業の流れ
ECRにログイン
- Dockerイメージ作成
- ECRにコンテナイメージのpush
- クラスターを作成( ECSインスタンスの入れ物的なもの )
- タスク定義
- タスク定義を元にクラスター内にサービスを作成
ECRにイメージをpush
ECRへのアクセス権を得るには下記出力を実行する
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
コンテナにタグつけ
docker tag example_web:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/example_web:latest
push
docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/example_web:latest
タスク定義
- タスク定義名 : 何か入力
- ネットワークモード :
<default>
コンテナの追加
コンテナ名 : 任意
イメージ : 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
Read more...Posted:
| Categories:
AWS
| Tags:
ECR,
ECS
CPUとメモリに組み合わせがある
Amazon ECS タスク定義の無効な CPU またはメモリエラーをトラブルシューティングする - Amazon Elastic Container Service
どうしてもCPUのスペックに合わせてメモリも増やす必要がある…
ECSサービス定義
Amazon ECS サービス定義パラメータ - Amazon Elastic Container Service
Read more...Posted:
| Categories:
AWS
| Tags:
ECR,
ECS
ECSのある環境を再起動したい
いろいろな理由で再起動したいことはあります。例えば
- SecretsManagerの変更したので再起動して反映したい
- docker-php環境を更新したので、再起動して最新のdockerイメージで起動し直したい
- 起動時のログを追いかけたいとき
などですね。
手順
1. タスク定義のリビジョンを上げる
- AWS管理画面にログイン
- 左上のサービス一覧から[ ECS ]を検索してクリック
- 左側メニューから[ タスク定義 ]を選択
- 目的の環境のタスク定義をクリック(env25など)
- 一番新しいリビジョン( 数字の大きいもの )をクリック
- [ 新しいリビジョンを作成 ]->[ 作成 ] ( この作成は失敗することがあります )
2. クラスター内の各サービスが参照するタスク定義のリビジョンを上げる
- ECS管理画面の左側のメニューから[ クラスター ]を選択
- [ dev-20181030-1 ]
- サービス名のカラムから再起動したいサービス名をクリック(env25など)
- 右上の方の[ 更新 ]をクリック
- [ リビジョン ]のプルダウンメニューをクリック
- 少しスライドして[ latest ]と書いてあるタスク定義を選択(1で作成したリビジョン番号を選択)
- [ 次のステップ ]->[ 次のステップ ]…->[ サービスの更新 ]
以上でECSコンテナの再起動が行われます
※ 再起動ですが、結構時間かかります…
細かく『いまどういう状態なのか?』を確認する場合ですが、
この再起動はブルーグリーン方式で、ダウンタイムが無いように再起動するようにしています。
どのような順番で行われるかというと、
- ECSの該当サービスで追加のタスク( タスクの中には nginx, php-fpm, volumeなどのコンテナが含まれます )が追加されます。
- タスクはロードバランサーの中のターゲットグループの中に追加されます( EC2 -> ロードバランサー -> ターゲットグループで該当のサービス名が書いてあるターゲットグループを探す )
- dockerコンテナはターゲットグループに追加され、ヘルスチェックに成功すると
新しいコンテナをheltyにし、アクセスを受け付け始め 、 古いコンテナをdrainingします
上記の流れで『今、デプロイがどのような状態なのか?』を知ることができます
Read more...