このブログでは、CircleCI Orbs を使用して、プロダクショングレードの Docker イメージを構築し、Amazon Elastic Container Registry(ECR)にプッシュして保管する方法について説明します。このブログに登場するツールとテクノロジに精通していれば、より深くこの記事の内容を理解できますが、必須ではありません。一般的な用語とテクノロジについて以下に簡単に説明します。
- Docker: コンテナ仮想化を用いてアプリケーションをビルドするためのソフトウェアプラットフォーム。
- コンテナ: 一貫性、効率、生産性を高め、バージョン管理を容易にするために、アプリケーションのコード、コンフィグ、および依存関係を構成要素としてパッケージングする仮想化の手法。
- コンテナイメージ: アプリケーションを実行するために必要なすべて(コード、ツール、リソース)を備えた自己完結型のソフトウェア。
- コンテナイメージリポジトリ: 名前が付けられた関連するコンテナイメージのコレクション。通常は、同じアプリケーションまたはサービスの異なるバージョンを提供し、タグによって識別されます。
- Docker イメージレジストリ: コンテナイメージを格納し、サードパーティまたは Docker Hub、AWS(ECR)、GCP(GCR)、Quayなどのパブリック/プライベートレジストリとしてホストされるサービス。開発から本番環境へのワークフローを簡素化します。
- コンテナオーケストレーション: コンテナオーケストレーションは、特に大規模で動的な環境でコンテナのライフサイクルを管理することです。
では、Amazon ECR について説明しましょう。Amazon ECR とは何か、Amazon ECR を最大限に活用するために CircleCI をどのように活用できるのかを見てみましょう。
Amazon Elastic Container Registry (ECR)
Amazon ECR は、フルマネージドのプライベート Docker コンテナレジストリであり、開発者は、Amazon ECR を使用すると、Docker コンテナイメージを簡単に保存、管理、デプロイできます。Amazon ECR は、Amazon Elastic Container Service(Amazon ECSe)および Amazon Elastic Kubernetes Service(Amazon EKS)とシームレスに統合されます。Amazon ECR は、他のクラウドベンダーでも使用できます。
Amazon ECR のようなプライベート Docker レジストリを使用するメリットは何でしょうか?
- 多くの場合、開発、テスト、および本番稼働のレジストリを分離することが望ましいです。
- Amazon ECR は、フルマネージドであるため、独自のコンテナリポジトリを自社で運用したり、基盤となるインフラストラクチャを苦心してスケーリングしたりする必要はありません。
- セキュリティ対策も万全です。スキャン機能とロールベースのアクセスコントロールがあるプライベートコンテナレジストリは、セキュリティとガバナンス(IAM)を向上し、管理が効率化されます。コンテナイメージを HTTPS で転送し、保管しているイメージを自動的に暗号化します。
- コンテナを実行しているシステムの近くでレジストリを実行でき、デプロイのレイテンシが短縮され、ネットワーク中断の危険性が軽減されます。
開発者は、アプリケーション開発のプロセスで作成されたイメージを、レジストリを使用して保存する必要があります。継続的インテグレーションパイプラインによって、コンテナイメージのビルドとこれらのアーティファクトの Amazon ECR へのプッシュ作業を連続して行うことができるようになります。CircleCI でビルドをトリガーするコミットをプッシュし、新しいイメージを Amazon ECR にプッシュするパイプラインを想像してください。その後、レジストリは、Webhook を起動し、デプロイをトリガーできます。すべて人間が手動で操作する必要はありません。レジストリにより、このような完全に自動化されたパイプラインを非常に簡単に作成できます。レジストリに配置されたコンテナイメージは、開発のさまざまな段階で使用できます。ここでは、CircleCI Orbs を使用し、いくつかの簡単な手順を実行し、シンプルな Node.js アプリケーションをコンテナにして、イメージをビルドして、Amazon ECR にプッシュします。
Amazon ECR のセットアップ
AWS マネジメントコンソールから、IAM を選択します。このサービスを使用すると、AWS リソースへのアクセスを管理できます。
ロール/ユーザーを作成します。この例では、自分に ci-cd-ecr
という名前を付けましたが、任意の名前を使用できます。
次に、AWS_ACCESS_KEY
と AWS_SECRET_KEY
を使用してプログラミングによって、Amazon ECR サービスにアクセスする必要があります。新しく作成したユーザーをクリックし、Your Security Credentials ページに移動します。ここで、新しいアクセスキーを作成できます。このキーは安全に保管してください。これは、CircleCI から Amazon ECR サービスにアクセスするときに使用されます。キーは次のような形式になります。
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
次に、Policies セクションでポリシーを作成し、先ほど作成した ci-cd-ecr
ロールをこのポリシーに添付します。このポリシーによって、Amazon ECR へのフルアクセスが提供されます。この CircleCI Orb は、新しく作成した ci-cd-ecr
ロールを使用して、Amazon ECR サービスに完全なアクセスでき、イメージリポジトリが存在しない場合は作成できます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:*",
"cloudtrail:LookupEvents"
],
"Resource": "*"
}
]
}
ユーザーのアクセスキーとシークレットキーを生成し、安全な場所に保存します。これらのキーは、CircleCI パイプラインのサンプルを設定するときに必要になります。
aws-ecr orb を使用して CircleCI パイプラインをセットアップする
このデモのコードは、こちらのGitHub から入手できます。CircleCI のコンフィグファイルは .circleci/
フォルダにあります。ご覧のとおり、Orbs を使用すると、わずか 18 行のコンフィグで、イメージをビルドして、Amazon ECR にプッシュできます!Orbs を使用するには、CircleCI バージョン 2.1 を使用する必要があります。バージョン 2.1 から Orbs はサポートされています。aws-ecr orb には、次の操作を実行するコマンドがあらかじめパッケージ化されています。
- イメージをビルドする
- イメージにタグを付ける(
HEAD == CIRCLE_SHA1
の Git コミットハッシュを使用) - Amazon ECR にログインする
- Amazon ECR リポジトリが存在しない場合は作成する
- イメージを Amazon ECR にプッシュする
このパイプラインの完全なコンフィグは次のとおりです。
version: 2.1
orbs:
aws-ecr: circleci/aws-ecr@6.7.0
workflows:
build_and_push_image:
jobs:
- aws-ecr/build-and-push-image:
account-url: AWS_ECR_ACCOUNT_URL
aws-access-key-id: AWS_ACCESS_KEY_ID
aws-secret-access-key: AWS_SECRET_ACCESS_KEY
create-repo: true
dockerfile: Dockerfile
path: .
region: AWS_REGION
repo: circleci-ecr-orb-demo
tag: "$CIRCLE_SHA1"
CircleCI でプロジェクトをセットアップする
コンフィグで確認でき、設定する必要があるいくつかの環境変数を以下に示します。
AWS_ECR_ACCOUNT_URL
- AWS アカウントにマッピングされる Amazon ECR アカウント URL(例、{awsAccountNum}.dkr.ecr.us-west-2.amazonaws.com)を保存する環境変数AWS_ACCESS_KEY_ID
- 先ほど作成したci-cd-ecr
IAM ロールの AWS アクセスキー ID。AWS_SECRET_ACCESS_KEY
- 先ほど作成した ci-cd-ecr IAM ロールの AWS シークレットキー。これは、この値を保持するように設定する環境変数の名前(AWS_SECRET_ACCESS_KEY)に設定します。AWS_REGION
- ECR リソースを配置する AWS リージョン。
注: $CIRCLE_SHA1
はすべての CircleCI プロジェクトで使用可能なデフォルト変数であるため、設定する必要はありません。これは、現在のビルドの最後のコミットの SHA1
ハッシュです。Git コミットハッシュを使用すると、コンテナに何があるかをトレースできます。コンテナをその Docker イメージにトレースし、次に Dockerfile とイメージに含まれるコードに対してトレースできれば理想的です。自動のビルド環境では、これにより Docker イメージをビルドしたコミットに戻ります。
上記のコンフィグ例では、$CIRCLE_SHA1
を使用して tag:
を設定しています。また、CircleCI のビルド番号($CIRCLE_BUILD_NUM
)をビルドのタグとして使用できます。
上記の dockerfile:
コマンドは、Dockerfile へのパスを指定します。デモのリポジトリでは次の Dockerfile を使用します。
# CircleCI と Amazon ECR の両方が適切に構成されていれば、イメージのビルドとリポジトリへのプッシュを開始できます。
FROM node:alpine
# Add metadata to an image
LABEL app="simple-node-application"
# Directive to set environmental variables key to value pair
ENV NPM_CONFIG_LOGLEVEL warn
# Set the working directory for any subsequent ADD, COPY, CMD, ENTRYPOINT,
# or RUN instructions that follow it in the Dockerfile
WORKDIR /usr/src/app
# Copy files or folders from source to the dest path in the image's filesystem.
COPY package.json /usr/src/app/
COPY . /usr/src/app/
# Execute any commands on top of the current image as a new layer and commit the results.
RUN npm install --production
# Define the network ports that this container will listen on at runtime.
EXPOSE 3000
# Configure the container to be run as an executable.
ENTRYPOINT ["npm", "start"]
CircleCI と Amazon ECR の両方が適切に構成されていれば、イメージのビルドとリポジトリへのプッシュを開始できます。
結論
たった 18 行のコンフィグで、Docker イメージをビルドして Amazon ECR にプッシュできました。CircleCI Orbs は、ビルド済みのコマンド、ジョブ、および Executor を CircleCI のコンフィグファイルにインポートして作業時間を節約します。また、クラウドサービスや他のツールと簡単に統合できます。