2024.06.21

AWS ECR になぜか複数のイメージが登録されてしまう。。の原因と対策





コンテナイメージをECRに登録する際の注意点

次世代システム研究室の Y.I です。コンテナイメージをECRに登録する際の注意点についてのブログ記事です。

導入

AWSのElastic Container Registry (ECR)にコンテナイメージを登録する際、場合によっては4つのレコードが作成されることがあります。当初なぜ4つのレコードが登録されるのか理由がわからないまま解消する時間がなく(言い訳ですね…)モヤモヤしながら利用していましたが、やっと判明したので原因と1つのレコードに統一する方法をまとめます。コンテナのビルドとプッシュは Github Actions の docker/build-push-action@v5 を利用しています。

以下の図は、ECR に4つのアーキファクトタイプが登録された結果を示しています。

ECRに4つのイメージが登録される

結論

コンテナイメージの登録時に4つのレコードが作成される理由と、それを1つに統一するための具体的な方法は以下の通りです。

  • docker build コマンドで platform を指定する
  • provenance false を指定する

4つのアーキフェクトタイプが登録されてしまうコマンド

        - name: Build docker image and push
          uses: docker/build-push-action@v5
          with:
            push: true
            context: .
            file: path/to/Dockerfile
            tags: |
              1234567890.dkr.ecr.ap-northeast-1.amazonaws.com/repository:tag
            cache-from: type=registry,ref=1234567890.dkr.ecr.ap-northeast-1.amazonaws.com/repository:tag:cache
            cache-to: type=registry,ref=1234567890.dkr.ecr.ap-northeast-1.amazonaws.com/repository:tag:cache,oci-mediatypes=true,mode=max,image-manifest=true
    

対策

この問題を回避し、ECRに1つのコンテナイメージレコードだけを作成するための対策は以下の通りです。

  • platform を指定する
                    platform: linux/amd64
                
  • provenance を指定する
                    provenance false
                
  • cache の指定をやめる
                    # 下記cache利用を箇所を削除
                    cache-from: type=registry,ref=1234567890.dkr.ecr.ap-northeast-1.amazonaws.com/repository:tag:cache
                    cache-to: type=registry,ref=1234567890.dkr.ecr.ap-northeast-1.amazonaws.com/repository:tag:cache,oci-mediatypes=true,mode=max,image-manifest=true
                
  • 1つのアーキフェクトタイプが登録されるコマンド

  • 修正後のコマンド
                    - name: Build docker image and push
                      uses: docker/build-push-action@v5
                      with:
                        push: true
                        context: .
                        file: path/to/Dockerfile
                        platform: linux/amd64
                        provenance: false
                        tags: |
                          1234567890.dkr.ecr.ap-northeast-1.amazonaws.com/repository:tag
                

修正後の登録されたイメージ

1度のpushでcacheを含めて2イメージが登録された状態(修正後のコマンド通りcache箇所を指定しなければ1イメージになります)

cacheを含め2イメージが登録される

コマンドとECRアーキファクトタイプの関連

docker/build-push-action の platform と provenance の指定と ECR への登録され方は以下のような関連となっていました。

platform の指定ありなし

  • 指定しないと => image が2つと image index が1つ登録されます
  • 指定すると => image が1つ登録されます
  • 今回の挙動は platform を指定しないことでdocker buildが動作したサーバーアーキテクチャ amd64 だけではなく、 おそらく arm64 向けのコンテナイメージも ECR へ登録したと考えています。そのため 0 バイトの image と image index が作られてしまったではと推測しています。実際に platform を1つ指定したことで 0バイトの image と image index が登録されなくなりました。

provenance の指定ありなし

  • 指定しないと(true扱いとなる) => image と image index が1つ登録されます
  • false指定すると => image のみ登録されます
  • provenance は 起源、履歴、および変更履歴を追跡し、証明するためのプロセスまたは手法とのことで、 ECR には meta情報として image index に登録されることがわかりました。

cache 利用ありなし

  • cache利用すると => cache と other が登録されます。かつ既存の同名イメージタグ(cache)はなし「-」へ変更される
  • cache利用しないと => image のみが登録され other は登録されない
  • イメージタグなし「-」の other レコードはなぜ登録されるのかと不思議でしたが、既存のcacheが残っているだけでした。

まとめ

AWS ECRにコンテナイメージを登録する際に、複数のレコードが作成されることを避けるためには、docker/build-push-action@v5 actions で platform を指定し、provenance false を設定してすることが有効です。cache の利用は必要に応じて判断しましょう。筆者の環境では1分程度の時間短縮につながったので cache を利用しています。これにより、ECRにおける管理がシンプルになり、意図しない複数のレコードの作成を防ぐことができます。

最後に

グループ研究開発本部では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。技術が好きな方、業務時間に興味がある技術の研究をしたい方、1つのプロジェクトに長く拘束されず多くのPJを経験したい方(1つのPJを長く担当することも可能です)など次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。


  • Twitter
  • Facebook
  • はてなブックマークに追加

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

 
  • AI研究開発室
  • 大阪研究開発グループ

関連記事