導入：なぜクリーンアップが必要なのか
DevOpsの現場では、CI/CDパイプラインが稼働するたびにビルド成果物（DockerイメージやJARファイルなど）が生成されます。これらを無制限に保存していると、ストレージコストが肥大化するだけでなく、リポジトリの検索性低下や、コンプライアンス上のリスクを招きます。本記事では、必要な世代数を残しつつ不要な成果物を自動削除する「クリーンアップポリシー」の重要性と実装方法を解説します。
基礎知識：アーティファクト管理の考え方
アーティファクトとは、ビルドプロセスによって生成された実行可能な成果物です。
ライフサイクルポリシー（Lifecycle Policy）とは、これらの成果物に対して「作成から何日経過したか」や「最新のN個以外は削除する」といった自動削除ルールを定義したものです。これにより、障害発生時のロールバックに必要な「過去N世代分」を維持しつつ、それ以前のゴミデータを自動でクリーンアップできます。
実装：論理的なクリーンアップ設計
クリーンアップポリシーを設計する際は、以下の2つの軸を組み合わせるのが一般的です。
1. 時間ベース：一定期間（例：90日）経過したものを削除。
2. 個数ベース：最新のビルドから数えて、古いものを削除。
これらを組み合わせることで、「直近5ビルドは必ず残し、それ以外は30日で削除する」といった柔軟な運用が可能になります。
サンプルプログラム：AWS ECRのライフサイクルポリシー定義
AWS ECR（Elastic Container Registry）で、タグ付けされていない古いイメージを削除し、タグ付きイメージは直近10個まで保持する設定例です。
{
“rules”: [
{
“rulePriority”: 1,
“description”: “タグなしイメージは1日で削除”,
“selection”: {
“tagStatus”: “untagged”,
“countType”: “sinceImagePushed”,
“countUnit”: “days”,
“countNumber”: 1
},
“action”: {
“type”: “expire”
}
},
{
“rulePriority”: 2,
“description”: “最新の10個のタグ付きイメージを保持し、それ以外は削除”,
“selection”: {
“tagStatus”: “any”,
“countType”: “imageCountMoreThan”,
“countNumber”: 10
},
“action”: {
“type”: “expire”
}
}
]
}
応用・注意点：運用上のリスク回避
現場で導入する際、以下のポイントに注意してください。
・本番環境のタグ付け戦略：ポリシーを適用する前に、本番環境で利用しているイメージに「production」などの永続的なタグが付与されているか確認してください。タグなしイメージを一括削除するルールを適用すると、誤って必要なファイルを消すリスクがあります。
・Dry Runの実施：多くのクラウドサービスでは、削除対象をシミュレーションする機能があります。いきなり本番適用せず、まずは「削除対象の確認」から始めるのが鉄則です。
・依存関係の確認：削除された成果物が、古い環境のデプロイやログ分析で必要にならないか、事前にステークホルダーと合意形成を図りましょう。
コメント