はじめに
Google Cloud の Artifact Registry に保存されたイメージを整理する機会がありましたので、その際の世代
管理⽅法の⼀例について紹介です。
概要
コンテナイメージ等を保存するのに利⽤される Artifact Registry ですが、Docker イメージを更新して運⽤していくと、過去のものは蓄積され、基本的にはたまり続ける状態となります。
AWS の ECR でいう、ライフサイクルルールが適⽤されていない状態です。
その状態を Google Cloud の場合、どう解消するか、を後述していきます。
詳細
思いつくものとしては⼤きく以下があります。
- クリーンアップ ポリシー
- Cloud Build でスクリプトなどを組んで実⾏する
- gcr-cleanerを使う
クリーンアップ ポリシー
世代管理する⽅法が機能として準備されているものですが、まだGAされておりません。
https://cloud.google.com/artifact-registry/docs/repositories/cleanup-policy
この⽅法ではタグや⽇付単位でイメージの削除が可能です。
開発のサイクルにもよるかと思いますが、⽇付単位ですと、思ったような管理が出来ない場合がありますし、タグですと、削除が必要なタイミングなどで、タグでコントロールが必要になるのかなと思っています。
※タグでのコントロールだと Cloud Build でタグ付けするような形でしょうか、、、
Cloud Build でスクリプトなどを組んで実⾏する
タグをつけている場合、タグで grep 可能で、ダイジェストの数値がわかればそれの絞り込みも可能なので、以下のようなコマンドを組み合わせれば、Cloud Build 内で削除することも可能かと思います。
こちらで更新⽇順にイメージを並べ替えられるので、必要な項⽬をgrepすれば必要な情報の絞り込みも可能です。
gcloud artifacts files list \
--project=XXXXXXX \
--repository=XXXXXXXX \
--location=asia-northeast1 \
--package=XXXXXXXX \
--sort-by="UPDATE_TIME"
上記絞り込みで得た情報をもとに削除をループ処理などすることで、複数イメージの削除も可能です。
gcloud artifacts docker images delete イメージパス
尚、スクリプトやシェルで処理をするにあたって、Cloud Build 内に script の記載が少し前にできるようになりました。
ただ、bash を使って script を利⽤しようとすると、 標準の bash イメージには gcloud コマンドがなかったりします。
そのため、script の記載を利⽤する場合、Cloud Build ⽤のコンテナをカスタムで作成し利⽤するなどの考慮が必要です。
gcr-cleanerを使う
公式ページのこちらにも記載があるのですが、gcr-cleanerというツールがあり、簡単なコマンドで世代管理を⾏うことができます。
例えば対象イメージを3世代残したい場合、Cloud Buildでは以下で可能です。
- name: 'asia-docker.pkg.dev/gcr-cleaner/gcr-cleaner/gcr-cleaner-cli:latest'
args:
- >-
--repo=asia-northeast1-docker.pkg.dev/$PROJECT_ID/XXXXXXX/XXXXXXXX
- '--keep=3'
- '--tag-filter-any=.*'
先に記載した未GAの機能を使ったり、スクリプトを組むことを考えると、この機能で条件を満たせるケースが多いと感じました。
所感
正直に⾔うと、スクリプトを組もうとしていたところ、クリーンアップポリシーとgcr-cleanerを知りました。
gcr-cleanerで複数回挙動を検証したところ、特に問題なく稼働しておりましたので、⾮公式ではあるものの、Artifact Registry の世代管理については、 gcr-cleaner の利⽤を検討していきたいと思います。
世代管理については、些細な部分ではありますが、地味に費⽤へ響く項⽬であり、蓄積され続けると影響がある内容なので考慮したい項⽬だと感じました。
