Artifact RegistryのCleanup Policyについて調べたり行ったこと。
kentaroはじめに
こんにちは。SRE チーム所属の Kentaro です。
直近で Artifact Registry 上に溜まっているアーティファクトを定期的に削除、また特定の数を保持するといった設定を行いました。
今回の対応を行うためにクリーンアップポリシー（Cleanup Policy）というものを活用して対応を行なったので、この記事ではこちらについて調べたことや行ったことについて書いていきます。
クリーンアップポリシーについて
クリーンアップポリシーとは設定することで、Artifact Registry 上の不要になったアーティファクトを自動的に削除したり、無期限に保持したりすることができるポリシーです。
Artifact Registry 上の定期的な削除については、他に gcr cleaner を使った方法やクライアントライブラリを使った方法があります。
gcr cleaner: https://github.com/GoogleCloudPlatform/gcr-cleaner?tab=readme-ov-file
クライアントライブラリ：https://github.com/googleapis/google-cloud-python/tree/main/packages/google-cloud-artifact-registry
今回は以下 2 点の理由からクリーンアップポリシーを採用することにしました。
- 公式から提供されている方法であるということ。
- 管理の手間が少ないこと。
gcr cleaner については、もう既にサポートが終了しているような記載があります。
またこのツールが提供していた機能は Artifact Registry に直接組み込まれているとも記載されていました。
The functionality provied by this tool is now built directly into Artifact Registry! We are no longer accepting bug reports or feature requests.
引用元：https://github.com/GoogleCloudPlatform/gcr-cleaner?tab=readme-ov-file
ライブラリを使用する方法だと、コードとコードを実行する環境の管理が発生するのでなるべく管理の手間については少なくしたいということでクリーンアップポリシーを採用しました。
クリーンアップポリシーの種類
クリーンアップポリシーには以下 3 種類のタイプが存在しています。
- 条件付き削除
- 条件付き保持
- 最新バージョンを保持
条件付き削除・保持ポリシーについて
条件付き削除・保持ポリシーは文字通り設定した条件基づいて削除・保持してくれるポリシーです。
設定できる条件としては以下のような条件があります。
- タグの状態
- タグ接頭辞
- バージョン接頭辞
- パッケージ接頭辞
- アップロード後の期間（最小）（Older than）
- アップロード後の期間（最大）（Newer than）
最新バージョンを保持について
最新バージョンを保持では、以下のような条件で最新のバージョンを起点にアーティファクトを保持してくれる設定です。
- 保持数
- パッケージ接頭辞
tips
アップロード後の期間（最小）とアップロード後の期間（最大）どっちがどのように影響するのか？ということをよく忘れるのでここに記載しておきます。
アップロード後の期間（最小）では、アーティファクトがアップロードされてから経過した時間以降のものに対して影響します。
例えばアップロード後の期間（最小）を 86400s（1 日）と設定すると、アップロードしてから 1 日経過したものがポリシーの適用対象になります。
アップロード後の期間（最大）では、アーティファクトがアップロードされてから経過した時間以内のものに対して影響します。
例えばアップロード後の期間（最大）を 86400s（1 日）と設定すると、アップロードしてから 1 日以内のものがポリシーの適用対象になります。
注意点
クリーンアップポリシーを試すには、以下のようにいくつか注意するべき点があります。
- 実際に設定したポリシーが適用されるまでインターバルがある。
- データアクセスログを有効にしたとしても、適切なロールを割り当てないとログを見ることができない。
- 特定のタグのみを最低保持するといった柔軟な適用ができない。
実際に設定したポリシーが適用されるまでインターバルがあるについて
これがクリーンアップポリシーを利用する場合のデメリットでもありますが、クリーンアップポリシーは適用してもすぐに反映されません。
これはドライランモードを活用しても同様です。
以下のドキュメントにあるように 1 日以内としか記載されていないため、検証するのに時間を要します。
（ドライランモードだけでもせめて任意のタイミングで実行できればすごく助かるのですが。。。）
Artifact Registry では、定期的に実行されるバックグラウンド ジョブを使用して、クリーンアップ ポリシーに一致するアーティファクトを削除、保持します。 変更は約 1 日以内に有効になります。
データアクセスログを有効にしたとしても、適切なロールを割り当てないとログを見ることができないについて
クリーンアップポリシーを適用した後適用されたログを追うためには、以下を行う必要があります。
- Audit Logs の API 一覧から Artifact Registry の API を選択。
- データアクセスにチェックを入れる。
上記を行ったとしても、特定のロールを割り当てないとログを見ることはできません。
というのもデータアクセスログは監査ログになるため、ログを見るにはプライベート ログ閲覧者（roles/logging.privateLogViewer）の権限が必要になります。
https://cloud.google.com/iam/docs/audit-logging?hl=ja#audit_log_permissions
権限がない場合は、データアクセス権にチェックを入れてログを確認してもログを見ることができません。
また、プライベート ログ閲覧者を付与した後反映されるまで少し待つ必要があります。 （体感 2,3 分ほど。）
Cloud Logging 上での確認について
以下のクエリで確認することができます。
もし Artifact Registry 上で削除されているけど、以下のクエリを実行してもログが確認できない場合は、上記記載のデータアクセスログの設定と権限の確認をしてみてください。
protoPayload.serviceName="artifactregistry.googleapis.com"
protoPayload.methodName="google.devtools.artifactregistry.v1.ArtifactRegistry.BatchDeleteVersions"
protoPayload.request.@type="type.googleapis.com/google.devtools.artifactregistry.v1.BatchDeleteVersionsRequest"
実際に行っていた検証方法
検証については以下のような方法で確認していました。
- 適当な Dockerfile を作成
- ローカルのターミナル上のコマンドで作ったリポジトリのイメージに対してプッシュ
- クリーンアップポリシーの適用
Dockerfile
# Pythonのイメージ
FROM python:3.9-slim
# ローカルのソースコードをコピーする
COPY . .
# コンテナ起動時に実行するコマンドを設定する
CMD ["python", "./main.py"]
main.py
print("Hello")
以下のコマンドを実行して image のタグを打ち Artifact Registry 上に push します。
docker tag {$DOCKER_IMAGE_NAME}:{$TAG} \
{$region}-docker.pkg.dev/{$PROJECT_ID}/{$REPOSITORY_ID}/{$PACKAGE_NAME}:v1.0
docker push {$region}-docker.pkg.dev/{$PROJECT_ID}/{$REPOSITORY_ID}/{$PACKAGE_NAME}:v1.0
一回各リポジトリのパッケージにプッシュした後は、Dockerfile 関連のファイルを更新して再度ビルドします。
ビルドができたら Artifact Registry 上にプッシュということを繰り返すということを行っていました。
まとめ
今回はクリーンアップポリシーについて調べたことや行ったことについてまとめました。
また、弊社 Belong では一緒に働く仲間を募集しています。
興味がある方は エンジニアリングチーム紹介ページ をご覧いただけると幸いです。