CIでAmazon ECRにDockerイメージをpushするときのプラクティス

ECRにpushするとき、皆さんはどうやってECRの認証をしていますか？大体の人が、aws cliをインストールして認証しているのではないかと思っています。

今回はAmazon ECRへPushする仕事があったので、一から見直してみた結果をここにまとめておきます。いくつかのパターンを例に挙げながら、最終的に良さそうだな、と思った内容をここに書いておきます。

僕としては、「aws cli v2」でECRに認証するのが楽かな、という結論になりました。

前提

筆者はCircleCIを主に使っているので、CircleCIベースで話を進めます。また、アプリケーションの開発時、Amazon ECRは認証が必要です。（認証なしでpush出来るように出来るかは筆者は分かりませんが、使うこともないでしょう。）開発用の言語はpython以外の前提で書いていきます。この辺りを踏まえた上で続きをお読みください。

今回の開発用の言語ではgoを想定した上で書いていきます。また、特に言及がない限り、開発用の言語をビルドするためのイメージを使うことにします。加えて、aws cliと表記した場合はaws cliのv1を指します。

はじめに

ECRに楽にログインする場合、aws cliを使うのがメジャーな方法だと思います。しかし、aws cli v1ではpythonのランタイムが必須のため、aws cliのインストールのために開発用の言語に加えてaws cliを入れたCI用のDockerイメージを作るか aws cliを使わず、他の手段で認証する必要がありました。

今回の記事ではそれらを踏まえた上で、ECRにDockerイメージをpushする方法をこの記事で書いていきます。

今回この記事で書くのは以下の方法です。

aws cliをインストールして認証を行う
CircleCI orbを使ってaws cliをインストールして認証を行う
persist_to_workspace/attach_workspaceを使って別のジョブでpushする
任意の言語で認証を行う
amazon-ecr-credential-helperを使って認証を行う
aws cli v2をインストールして認証を行う

pipからaws cliをインストールして認証を行う

これは単純です。しかし、aws cliをインストールするためだけに時間がかかります。ちなみにCircleCIの公式のイメージのように、pythonの入ってないイメージの場合はpythonのインストールから必要になります。

メリット
- 単純
デメリット
- インストール時間がそれなりにかかる

CircleCI Orbを使ってaws cliをインストールする

CircleCI Orbを使ってaws cliをインストールすることで公式がメンテナンスしてくれるという安心感があります。しかし、awcliのインストールスクリプトはpythonなので、やっぱりpythonのランタイムは必要です。

メリット
- 公式がメンテナンスしてくれる安心感が得られる
デメリット
- 依存を含めたzipを落としてるので最初のやつよりかは早いかも？
- でもやっぱりpythonのランタイムは必要（zipの中にあるinstall scriptがpythonに依存している）

persist_to_workspace/attach_workspaceを使って別のジョブでpushする

CircleCIにはworkflowで生成された成果物を別のジョブに引きわたす機能があります。それが、persist_to_workspace/attach_workspaceです。この方法は、persist_to_workspace/attach_workspaceを使って開発用の言語のジョブとは別のジョブでアプリケーションのDockerイメージを作成します。そのため、開発用の言語のDockerイメージで生成した成果物を awscliを入れたイメージでのビルドに引き渡すことで awscliのインストールをすることがありません。しかし、そもそもawscliの入ったdocker imageを公式が提供していません。。。

メリット
- awscliのインストールがなくなる
デメリット
- そもそもawscliの入ったdocker imageを公式が提供していないので自前で用意する必要がある
  - 野良のイメージを使ってもいいんですがライフサイクルのよく分からないイメージを使うのは怖い
- ビルド間での成果物の引き渡しをするのでビルド自体の起動時間（docker imageのpullとコンテナが立ち上がるまでの時間）が増える

任意の言語で認証を行う

これは、前職でやっていた手法なのですが、gradleなどでビルドツールからECRとの認証を行ってpushします。 awscli周りは簡単になるのですが、ビルド周りの複雑さは避けられないでしょう。

メリット
- awscliのインストールがなくなる
デメリット
- ビルド周りの複雑さが少し増える
- ジョブのコンテナの起動時間が増える

amazon-ecr-credential-helperを使って認証を行う

以下のようなjsonを ~/.docker/config.json に配置しておきます。そうすると、dockerは docker-credential-ecr-login というPATHに入っている実行ファイルを使って認証を行ってくれます。ちなみに以下の方法の場合、全てのdockerの通信をecrの通信として扱います。ECR以外のリポジトリにもpushする場合は注意が必要です。 dockerの1.13以降ではリポジトリのURLで認証を分けられます。詳しくはDockerのドキュメントをみてください。

{
    "credsStore": "ecr-login"
}

しかし、この方法もやはりデメリットがあり、amazon-ecr-credential-helperはディストリビューションからのインストール以外は自分でビルドする必要があります。ちなみに、goで開発されているため、ビルドにはgoのランタイムが必要です。

installする方法は https://github.com/awslabs/amazon-ecr-credential-helper をみてください。

メリット
- ディストリビューションからインストールするため、pipでインストールするよりは早い
デメリット
- ディストリビューションが対応してない場合は、自前でビルドする必要がある

aws cli v2をインストールして認証を行う

aws cli v2の場合、pythomのランタイム入りのzipが配布されています。そのため、その他のツールのインストールが必要ありません。これは便利です。

aws cli v2のインストールは、以下のようなスクリプトを使ってインストールすることになるでしょう。

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

中のファイル構成に依存しても良いなら、キャッシュもうまく効かせられます。ちなみに現状、上記のような形でunzipした場合は ./aws/dist/aws に実行バイナリが入っています。

メリット
- 公式がランタイムも含めて配布してくれているので簡単にインストールできる
- 中のファイルの構成に依存しても良いなら、キャッシュしやすい
デメリット
- URLにバージョンが含まれていないので、動かないzipが配信された時にCIが壊れる

まとめ

今回、docker imageをECRにpushする要件があったので、調べていたところ aws cliをインストールをする必要があるなぁと思っていたんですが、それをTwitterで呟いていたところ、aws cli v2がリリースされていたのを思い出してリリース方法を確認したところ、ランタイムもまとめて配布されていることを確認しました。

aws cli v2を使ってビルドする前に、credential helperでPushも出来たのですが goのランタイムで自前ビルドをしてしまっていたのでこれもaws cli v2に移行しました。

Amazon ECRにpushするなら、aws cli v2で認証するので良いんじゃないでしょうか。

追記

書くの忘れてたんですが aws cli v2を使う場合、ECRへのログイン方法が変わっていることに注意してください。

# aws cli v1の場合
eval "$(aws ecr get-login --no-include-email)"

# aws cli v2の場合
aws ecr get-login-password | docker login --username AWS --password-stdin $REPO_URL