AWS_ECSでECRのイメージを使用する #376
少し業務で触れたので、勉強のために整理しておきます。
Amazon ECR (Elastic Container Registry)
AWS マネージドコンテナイメージレジストリサービスで、つまりAWS版のDocker Hubのようなイメージです。Dockerイメージを任意のCLIを使用してプッシュ、プル、管理できます。Github Actionsと連携して、あるブランチにマージされたらECRにプッシュする、といった体制を作ることも可能です。
また、IAMで許可されたユーザーやEC2インスタンス、ECSタスクがコンテナリポジトリとイメージにアクセスできます。
つまりECRはECSと統合が可能で、本番環境へのデプロイがスムーズになります。
Amazon ECS (Elastic Container Service)
言わずと知れたAWSのコンテナオーケストレーションサービスです。複数のDockerコンテナを簡単に実行、停止、管理できます。上記の通りECRと統合できるので、AWS上で簡単にECRからdocker pullして、docker runできるイメージです。
起動タイプがEC2かFargateかを選択できます。
EC2は柔軟に細かい設定が可能ですが、自分で設定をやり切る&保守していかなければなりません。Fargateはコンテナ向けのサーバーレスコンピューティングエンジンで、細かいところはAWSが全てやってくれますがEC2ほど細かい設定はできません。
我々のチームではFargateを採用しています。
ECSがECRからイメージをプルするには
Fargateのパターンで整理します。
タスク実行IAMロールでECSコンテナにECRへのアクセス許可を付与
ECSのタスク定義でECRのイメージを指定
タスク実行IAMロールでECSコンテナにECRへのアクセス許可を付与
タスク実行IAMロールは公式で以下のように定義されています。
ここでは管理IAMポリシーであるAmazonECSTaskExecutionRolePolicyを付与します。このポリシーには以下のアクセス許可が含まれます。
以下のように記述されます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
ECSのタスク定義でECRのイメージを指定
アクセス許可が付与されたら、ECSのタスク定義でイメージを指定します。
このタスク定義とは、ECSでコンテナを起動するための情報を記載したものです。イメージを指定するだけでなく、vCPUとメモリサイズをどうするか、portはどうするか、コンテナが終了したり失敗した時の設定(再起動など)などができます。vCPUやメモリの性能は後から変更可能です。
で、このタスク定義では、Amazon ECR プライベートリポジトリでホストされているコンテナイメージを指定できます。イメージを指定する際は完全な registry/repository:tag の名前を使用する必要があります。
例えば以下のようになります。"image"部分が該当箇所です。
{
"family": "task-definition-name",
...
"containerDefinitions": [
{
"name": "container-name",
"image": "aws_account_id.dkr.ecr.region.amazonaws.com/my-repository:latest",
...
}
],
...
}
上記は公式のサンプルコードなのですが、タグの「latest」に注目してください。
現在はlatestタグを本番環境で使用することは推奨されていないようです。詳しくは追ってないのですが、dev環境用のイメージとタグが重複してしまい、複数の異なるバージョンが本番環境で稼働してしまった事例があるみたいでした。
そのため、本番用のECSタスクではlatest以外のタグでイメージを指定した方が良さそうです。我々のチームではECRイメージに「prod」や「dev」といったタグを付けて、本番環境用と開発環境用で使い分けています。
ここまでお読みいただきありがとうございました!
参考
この記事が気に入ったらサポートをしてみませんか?