ECR「ライフサイクルポリシー」でイメージの保管数を管理する

はじめに

AWSでコンテナを利用する場合、ECRでDockerイメージを管理すると思いますが、みなさんECRリポジトリのお掃除はしていますか?

コンテナ開発をしていると知らず知らずのうちにECRにイメージが溜まってしまうことはよくあることかと思います。
1イメージサイズが100MBとか200MBとかでも、ちりつもで結構な量のイメージを保持していることも少なくないです。とくにCodeXXX等と連携してソースコードを更新したら自動でビルド・デプロイするようなCI/CDの仕組みを入れているとより起きやすい問題かなと。

私も、AWSアカウント内の整理をしていたところ、相当イメージが溜まっており、
気になってECRの料金 をみたところ、イメージのデータ量1GBあたり0.10USD/月がコストとして発生するようでした。
大きな金額ではないですが、世代管理しておくのが良さそうと感じました。

今回はそのECRイメージの世代数管理におすすめな方法、「ECR ライフサイクルポリシー」をご紹介します。

ECRのライフサイクルポリシーとは?

ライフサイクルポリシーはAmazon ECRの設定の一つです。

ライフサイクルポリシーを設定することで、イメージの世代管理を行うことができる機能となっています。

ライフサイクルポリシーで何ができるのか?

ライフサイクルポリシーを使用することで各ECRリポジトリごとに、下記条件でのライフサイクル管理が可能となります。

どのイメージタグを対象とするか?

  • タグ付き (ワイルドカードマッチング): イメージタグと一致するワイルドカード (*) を使用してイメージタグのリスト(コンマ区切り)を指定
  • タグ付き (プレフィックスマッチング): イメージタグと一致するプレフィックスのリスト(コンマ区切り)指定
  • タグ付けなし
  • すべて

イメージの保管条件をどうするか?

  • イメージをプッシュしてから: イメージプッシュ後の経過日数
  • 次の数値を超えるイメージ数: イメージの世代数

例えば、「イメージが100個以上になったら古いイメージから削除する」「プッシュされて90日経過したタグのないイメージは自動的に削除する」という設定が、簡単にできます。

評価ルール

ライフサイクルポリシーの評価ルール」に記載の通りですが下記ルールとなります。

評価ルール細かくいろいろと記載されていますが、実際にルールを設定する前に、作成したルールを検証することができるので、
悩まずにまずは試しながら設定してみると良さそうです。

また、

ライフサイクルポリシーがリポジトリに適用されると、イメージが有効期限の基準を満たしてから 24 時間以内に期限切れになることが予想されます。

と、ドキュメントにもあるため、期限切れ後24時間以内で消えること注意が必要そうです。

実際に設定&動作確認をしてみる

ライフサイクルポリシーの設定方法

ECR – レジストリ 
から「ライフサイクルポリシー」を設定したい「ECRのリポジトリ」を選択し、「Lifecycle Policy」を押下します。

作成するときは「テストルールの編集」から作成すると、作成したルールの動作確認をしてから適用ができるのでそちらから作成していきます。

まずは試しに「すべてのイメージを3世代管理(最新の3イメージのみ保持)」する設定をしてみます。
「ルールの作成」を押下します。

下記画像のように、

  • ルールの優先順位
  • ルールの説明(必須)
  • イメージのステータス: すべて
  • 一致条件: 次の数値を超えるイメージ数 = 3

を設定し「保存」を押下します。

「テストの保存と実行」を押下します。

すると、もともと6つあったイメージから「最新の3つ保持しそれ以外は削除されるルール」が作成できていることがわかります。
動作に問題がなければそのまま「ライフサイクルポリシーとして適用」を押下すれば、ルールの適用が可能となります。※適用を押下しないとルール適用されませんので忘れずに実施ください。

こちらでルールのテスト&設定が完了となります。

サンプル例

検証したなかではまった設定・気になった設定をサンプル形式で紹介します。

タグを「PUSHした日付」 + 「latest」の2種類で管理しており、「PUSHした日付」のタグのみ世代管理をしたい

基本的にはコンテナイメージは「latest」タグで稼働させているがプラスして、デプロイ日の日付等の情報もタグとして設定している場合の例となります。

  • ルールのタグ付け要件に一致するイメージは、優先度がより低いルールによって期限切れにはなりません。

こちらのルールを利用する形で設定可能です。

  • 優先度が高い(数字が小さいものから実行される)ルールで「latestタグを1世代保管」
  • 「日付のタグで2世代のみ保管」する

と設定することで可能となります。

こちらを実際にルールの検証をしてみると、このように「latestタグ」と「日付タグの2世代」保管ができていることがわかります。

参考までに、なぜこんなことをしたかというと、、、
このような「日付タグを2世代」保管と設定してみます。

何らかの理由でlatestタグが最新のイメージから遅れている場合にこのように、latestタグを持ったイメージも削除対象になってしまうのです。。。

こういった点も考慮しつつライフサイクルポリシーを検討する必要がありそうです。

まとめ

以上、ECRのライフサイクルポリシーの設定を実施してみました。CI/CDを取り入れている環境であればこういったECRリポジトリサイズの問題はよくあることかと思います。
ぜひ今回のECRのライフサイクルポリシー機能を活用してみてください!