Docker の認証付きプルの使用
ここでは、Docker レジストリのプロバイダーでイメージのプルを認証する方法について説明します。
プルを認証することで、プライベートの Docker イメージにアクセスできるようになります。 お使いのレジストリ プロバイダーによっては、レート制限が引き上げられる可能性もあります。
CircleCI は Docker と連携して、ユーザーの皆さまが今後もレート制限なしで Docker Hub にアクセスできるようにしています。 2020 年 11 月 1 日時点では、いくつかの例外を除き、CircleCI を通じて Docker Hub からイメージをプルする際に、レート制限の影響を受けることはありません。 ただし、今後 CircleCI ユーザーにもレート制限が適用される可能性があります。 そのため、将来的にレート制限の影響を受けることのないよう、お使いの CircleCI 設定ファイルに Docker Hub 認証を追加すると共に、必要に応じてご利用中の Docker Hub プランのアップグレードを検討することをお勧めします。
Docker Hub
Docker Executor
Docker Executor を使用する場合は、 config.yml ファイル の auth
フィールドにユーザー名とパスワードを指定します。 パスワードを保護したい場合は、 コンテキスト を作成するか、プロジェクトごとの環境変数を使用します。
コンテキストを作成するほうがより柔軟性の高い方法です。 CircleCI は複数のコンテキストをサポートしており、シークレットをモジュール化したり、ジョブが_必要_なものだけにアクセスできるようにしたりするのにとても便利です。 |
次の例では、既存の build-env-vars
コンテキストを肥大化させずに、build ジョブに Docker 認証情報の docker-hub-creds
コンテキストへのアクセスを付与しています。
workflows:
my-workflow:
jobs:
- build:
context:
- build-env-vars
- docker-hub-creds
jobs:
build:
docker:
- image: acme-private/private-image:321
auth:
username: mydockerhub-user # 文字列リテラル値を指定します
password: $DOCKERHUB_PASSWORD # または、プロジェクトの環境変数を参照するように指定します
既に 2 要素認証を Docker Hub に設定している場合は、`password`キーの代わりに パーソナルアクセストークンを使用することができます。 たとえば以下のようになります。
- image: acme-private/private-image:321
auth:
username: mydockerhub-user
password: $DOCKERHUB_ACCESS_TOKEN
また、 gcr.io や quay.io などのプライベート リポジトリにあるイメージも使用できます。image
キーに対してリポジトリ/イメージのフル URL を指定し、auth
キーに対して適切なユーザー名とパスワードを使用してください。 以下に例を示します。 image
キーに対してリポジトリ/イメージのフル URL を指定し、auth
キーに対して適切なユーザー名とパスワードを使用してください。 たとえば以下のようになります。
- image: quay.io/project/image:tag
auth:
username: $QUAY_USERNAME
password: $QUAY_PASSWORD
machine Executor (Docker Orb を使用)
または、以下のように machine
Executor と Docker Orb を使用する場合にも同じ結果が得られます。
version: 2.1
orbs:
docker: circleci/docker@1.4.0
workflows:
my-workflow:
jobs:
- machine-job:
context:
- build-env-vars
- docker-hub-creds
jobs:
machine-job:
machine: true
steps:
- docker/check:
docker-username: DOCKERHUB_LOGIN # DOCKER_LOGIN がデフォルト値です。
存在する場合、自動的に使用されます。
docker-password: DOCKERHUB_PASSWORD # DOCKER_PASSWORD がデフォルト値です。
- docker/pull:
images: 'circleci/node:latest'
存在する場合、自動的に使用されます。
docker-password: DOCKERHUB_PASSWORD # DOCKER_PASSWORD がデフォルト値です。
- docker/pull:
images: 'circleci/node:latest'
存在する場合、自動的に使用されます。
docker-password: DOCKERHUB_PASSWORD # DOCKER_PASSWORD がデフォルト値です。
- docker/pull:
images: 'circleci/node:latest'
存在する場合、自動的に使用されます。
docker-password: DOCKERHUB_PASSWORD # DOCKER_PASSWORD がデフォルト値です。
- docker/pull:
images: 'circleci/node:latest'
machine Executor (Docker CLI を使用)
または、CLI を使用します。
version: 2.1
jobs:
build:
machine: true
working_directory: ~/my_app
steps:
# Docker is preinstalled, along with docker-compose
- checkout
# start proprietary DB using private Docker image
- run: |
docker login -u $DOCKER_USER -p $DOCKER_PASS
docker run -d --name db company/proprietary-db:1.2.3
AWS ECR
または、以下のように machine
Executor と Docker Orb を使用する場合にも同じ結果が得られます。
任意のリージョンの ECR リポジトリから、プライベート イメージをプルできます。 ただし、最高のエクスペリエンスを得るために、us-east-1 リージョンにイメージのコピーを作成し、その us-east-1 のイメージを Docker Executor に指定することを強くお勧めします。 CircleCI のジョブ実行インフラストラクチャは us-east-1 リージョンにあります。 そのため、us-east-1 のイメージを使用すると、環境のスピンアップ プロセスにかかる時間が短縮されます。 |
ECR からジョブ用のイメージをプルには、いくつかの方法があります。
お勧めするのアプローチは、OpenID Connect(OIDC)を使用して ECR からプルすることです。 See the Pull an image from AWS ECR with OIDC how-to guide for full details.
ECR からイメージをプルために、AWS の認証情報を使用するよりも OIDC を使用することの利点がいくつかあります:
-
セキュリティの向上:OIDC 認証を利用することで、CircleCI の設定や環境変数に直接 AWS の認証情報を保存することが避けられ、漏洩のリスクを低減できます。
-
クレデンシャル管理の簡素化: OIDC により、CircleCI は認証プロセスを自動的に管理し、AWS のクレデンシャルを手動で管理しローテーションする必要がなくなります。
-
きめ細かなアクセスコントロール:OIDC 認証に IAM ロールを関連付けることで、CircleCI がECR イメージを取り込む際に付与する権限を厳密にコントロールし、最小特権を確保することが可能です。
または、以下のいずれかの方法を使用することもできます:
-
CircleCI 標準のプライベート環境変数を使用して、AWS 認証情報を設定する
-
aws_auth
を使用して、.circleci/config.yml
に AWS 認証情報を指定する
version: 2
jobs:
build:
docker:
- image: account-id.dkr.ecr.us-east-1.amazonaws.com/org/repo:0.1
aws_auth:
aws_access_key_id: AKIAQWERVA # 文字列リテラル値を指定します
aws_secret_access_key: $ECR_AWS_SECRET_ACCESS_KEY # または、プロジェクトの UI 環境変数を参照するように指定します
いずれの方法もほぼ同じです。 2 番目の方法では認証情報に対して任意の変数名を指定できます。 これは、インフラストラクチャごとに異なる AWS 認証情報を持っている場合に便利です。 たとえば、SaaS アプリケーションに対して短時間のテストを実行し、コミットのたびに Git タグを付けながらステージング インフラストラクチャにデプロイして、本番にデプロイする前には本格的なテスト スイートを実行します。
version: 2.1
jobs:
build:
docker:
- image: account-id.dkr.ecr.us-east-1.amazonaws.com/org/repo:0.1
aws_auth:
aws_access_key_id: $AWS_ACCESS_KEY_ID_STAGING
aws_secret_access_key: $AWS_SECRET_ACCESS_KEY_STAGING
steps:
- run:
name: "Every Day Tests"
command: "testing...."
cli"
deploy:
docker:
- image: account-id.dkr.ecr.us-east-1.amazonaws.com/org/repo:0.1
aws_auth:
aws_access_key_id: $AWS_ACCESS_KEY_ID_PRODUCTION
aws_secret_access_key: $AWS_SECRET_ACCESS_KEY_PRODUCTION
steps:
- run:
name: "フル テスト スイート"
command: ".... のテスト"
- run:
name: "本番インフラストラクチャへのデプロイ"
command: "なんらかのコマンド....
- run:
name: "Deploy to Production Infrastructure"
command: "something something darkside.... cli"
workflows:
main:
jobs:
- build:
filters:
tags:
only: /^\d{4}\.\d+$/
- deploy:
requires:
- build
filters:
branches:
ignore: /.*/
tags:
only: /^\d{4}\.\d+$/
AWSアカウントに必要な最低限の権限は以下の通りです(`YOUR_ECR_REPO_ARN`を代入する必要があります):
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Effect": "Allow",
"Resource": "<your-ECR-repo-ARN>"
},
{
"Action": [
"ecr:GetAuthorizationToken"
],
"Effect": "Allow",
"Resource": "*"
}
]
}