翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon ECR でのライフサイクルポリシーを使用したイメージのクリーンアップの自動化
Amazon ECR ライフサイクルポリシーを使用すると、プライベートリポジトリ内のイメージのライフサイクル管理をより詳細に制御できます。ライフサイクルポリシーには 1 つ以上のルールが含まれ、各ルールで Amazon ECR のアクションが定義されます。ライフサイクルポリシーの有効期限基準に基づいて、ライフサイクルポリシーで指定された基準に基づいて 24 時間以内にイメージをアーカイブまたは期限切れにすることができます。Amazon ECR がライフサイクルポリシーに基づいてアクションを実行した場合、このアクションはイベントとして AWS CloudTrailにキャプチャされます。詳細については、「[を使用した Amazon ECR アクションのログ記録 AWS CloudTrail](logging-using-cloudtrail.md)」を参照してください。
## ライフサイクルポリシーの機能
ライフサイクルポリシーは、リポジトリ内のどのイメージに有効期限切れにするかを決定する 1 つ以上のルールで構成されています。ライフサイクルポリシーの使用を検討する場合、リポジトリに適用する前に、ライフサイクルポリシーのプレビューでライフサイクルポリシーが有効期限切れになったイメージを確認することが重要です。ライフサイクルポリシーがリポジトリに適用されると、イメージが有効期限の基準を満たしてから 24 時間以内に期限切れになることが予想されます。Amazon ECR がライフサイクルポリシーに基づいてアクションを実行すると、これはイベントとして AWS CloudTrailにキャプチャされます。詳細については、「[を使用した Amazon ECR アクションのログ記録 AWS CloudTrail](logging-using-cloudtrail.md)」を参照してください。
次の図表は、ライフサイクルポリシーのワークフローを示します。
1. テストルールを 1 つ以上作成します。
1. テストルールを保存し、プレビューを実行します。
1. ライフサイクルポリシーエバリュエーターは、すべてのルールを評価し、各ルールが影響するイメージにマークを付けます。
1. 次に、ライフサイクルポリシーエバリュエーターはルールの優先度に基づいてルールを適用し、リポジトリ内のどのイメージの有効期限が切れるかアーカイブされるかを表示します。ルールの優先度の数値が低いほど、優先度が高くなります。例えば、優先度 1 のルールは、優先度 2 のルールよりも優先されます。
1. テストの結果を確認し、期限切れまたはアーカイブとマークされたイメージが意図したとおりであることを確認します。
1. テストルールをリポジトリのライフサイクルポリシーとして適用します。
1. ライフサイクルポリシーが作成されると、イメージの有効期限が切れるか、有効期限の基準を満たしてから 24 時間以内にアーカイブされるはずです。
### ライフサイクルポリシーの評価ルール
ライフサイクルポリシーエバリュエーターは、ライフサイクルポリシーのプレーンテキスト JSON を解析して、すべてのルールを評価し、ルールの優先順位に基づいてリポジトリ内のイメージに適用します。次に、ライフサイクルポリシーエバリュエーターのロジックについて詳しく説明します。例については「[Amazon ECR でのライフサイクルポリシーの例](lifecycle_policy_examples.md)」を参照してください。
+ リポジトリに参照アーティファクトが存在する場合、Amazon ECR ライフサイクルポリシーは、対象イメージの削除またはアーカイブから 24 時間以内にそれらのアーティファクトを自動的に期限切れまたはアーカイブします。
+ 優先順位に関係なく、すべてのルールが同時に評価されます。すべてのルールが評価された後、優先度に基づいてルールが適用されます。
+ イメージの有効期限が切れているか、1 つまたはゼロのルールによってアーカイブされています。
+ ルールのタグ付け要件に一致するイメージを、優先度の低いルールで期限切れにしたりアーカイブしたりすることはできません。
+ ルールは、優先度の高いルールでマークされたイメージをマークすることはできませんが、有効期限が切れていないかアーカイブされていないかのように識別できます。
+ 特定のストレージクラスを選択するすべてのルールのセットには、一意のプレフィックスのセットが含まれている必要があります。
+ タグ付けされていないイメージを選択できるのは、特定のストレージクラスを選択する 1 つのルールのみです。
+ イメージがマニフェストリストによって参照されている場合、マニフェストリストが最初に削除またはアーカイブされない限り、有効期限が切れたりアーカイブされたりすることはできません。
+ 有効期限は常に `pushed_at_time`または によって順序付けられ`transitioned_at_time`、古いイメージは新しいイメージより前に期限切れになります。イメージがアーカイブされ、過去の任意の時点で復元された場合、イメージの `last_activated_at`が の代わりに使用されます`pushed_at_time`。
+ ライフサイクルポリシールールでは、`tagPatternList` または `tagPrefixList` のいずれかを指定できますが、両方は指定できません。ただし、ライフサイクルポリシーにはパターンリストとプレフィックスリストの両方を使用する複数のルールが含まれる場合があります。`tagPatternList` または `tagPrefixList` の値に含まれるすべてのタグがイメージのいずれかのタグと一致した場合に、イメージは一致したことになります。
+ `tagPatternList` または `tagPrefixList` パラメータは、`tagStatus` が `tagged` の場合にのみ使用できます。
+ `tagPatternList` を使用する場合、ワイルドカードフィルターに一致すればイメージがマークされます。例えば、`prod*` のフィルターを適用すると、`prod` で始まる名前 (`prod`、`prod1`、`production-team1` など) を持つリポジトリと一致します。同様に、`*prod*` のフィルターを適用すると、名前に `prod` が含まれる (`repo-production`、`prod-team` など) リポジトリと一致します。
**重要**
1 文字列あたりのワイルドカード (`*`) の上限は 4 つです。例えば、`["test*1*2*3*4*5*6"]` は有効ですが `["*test*1*2*3", "test*1*2*3*"]` は無効です。
+ `tagPrefixList` を使用した場合、`tagPrefixList` 値の***すべて***のワイルドカードフィルターがイメージのいずれかのタグと一致した場合に、イメージは一致したことになります。
+ `countUnit` パラメータは、 `countType`が `sinceImagePushed`、`sinceImagePulled`、または の場合にのみ使用されます`sinceImageTransitioned`。
+ では`countType = imageCountMoreThan`、イメージは に基づいて最も新しいイメージから古いイメージにソートされ`pushed_at_time`、指定された数を超えるすべてのイメージは期限切れまたはアーカイブされます。
+ では`countType = sinceImagePushed`、 に基づく指定された日数よりも`pushed_at_time`古いすべてのイメージ`countNumber`が期限切れまたはアーカイブされます。
+ では`countType = sinceImagePulled`、 に基づく指定された日数よりも古いすべてのイメージ`last_recorded_pulltime`が`countNumber`アーカイブされます。イメージがプルされたことがない場合は、 の代わりにイメージの `pushed_at_time`が使用されます`last_recorded_pulltime`。イメージがアーカイブされてから復元されたが、復元されてからプルされなかった場合、イメージの `last_activated_at`は の代わりに使用されます`last_recorded_pulltime`。
+ では`countType = sinceImageTransitioned`、 に基づく指定された日数よりも`last_archived_at`古いアーカイブ済みイメージはすべて期限切れ`countNumber`になります。
+ 有効期限は常に によって順序付け`pushed_at_time`され、古いイメージは新しいイメージより前に有効期限が切れます。