Configuring lifecycle policies
Lifecycle policies automate the management of artifact storage and deletion in a registry. This tutorial provides examples of setting up policies for various use cases.
Get your cloud ready
Sign up for Yandex Cloud and create a billing account:
- Navigate to the management console
and log in to Yandex Cloud or create a new account. - On the Yandex Cloud Billing
page, make sure you have a billing account linked and it has theACTIVEorTRIAL_ACTIVEstatus. If you do not have a billing account, create one and link a cloud to it.
If you have an active billing account, you can navigate to the cloud page
Learn more about clouds and folders here.
Example 1: Policy for Ubuntu Docker images
In this example, we create a policy to manage Docker images with the ubuntu.* path prefix. This policy contains three rules:
- Hard delete all untagged Docker images older than 7 days.
- Soft delete tagged Docker images exceeding a count of 10, with a 7-day waiting period.
- Keep the 5 lastest versions of tagged images.
Define the rules
Create a file named ubuntu-policy-rules.json with the following contents:
[
{
"path_prefix": "ubuntu.*",
"delete": {
"type": "HARD_DELETE",
"older_than_days": 7
},
"docker_filters": {
"tag_status": "UNTAGGED"
}
},
{
"path_prefix": "ubuntu.*",
"delete": {
"type": "SOFT_DELETE",
"cooldown_period_days": 7,
"version_condition": {
"versions_count_greater_than": 10
}
},
"docker_filters": {
"tag_status": "TAGGED"
}
},
{
"path_prefix": "ubuntu.*",
"keep_by_version": {
"keep_versions_count": 5
},
"docker_filters": {
"tag_status": "TAGGED"
}
}
]
-
The first rule (
HARD_DELETE) permanently deletes all untagged Docker images older than 7 days. This helps clean up the registry of intermediate images created during a build. -
The second rule (
SOFT_DELETE) marks tagged Docker images for deletion if the number of images exceeds 10. Docker images remain in the registry during the 7-day cooldown period before they are permanently deleted. This allows you to store the version history with a limited number of versions. -
The third rule (
keep_by_version) prevents the deletion of the 5 latest versions of tagged Docker images, even if they match the second rule conditions. This ensures availability of the latest production versions.
Note
Rules apply in the order of priority, where retention rules (keep_by_version) take precedence over deletion rules. This prevents the second rule from deleting the 5 most recent versions.
Create a policy
If you do not have the Yandex Cloud CLI installed yet, install and initialize it.
By default, the CLI uses the folder specified when creating the profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also set a different folder for any specific command using the --folder-name or --folder-id options.
Create a lifecycle policy:
yc cloud-registry registry lifecycle-policy create \
--name ubuntu-lifecycle-policy \
--description "Policy for managing Ubuntu Docker images" \
--registry-id <registry_ID> \
--state DISABLED \
--rules ubuntu-policy-rules.json
Where:
--name: Policy name.
--description: Policy description.
--registry-id: ID of the registry for which you are creating the policy.
--state: Policy state after creation (DISABLED).
--rules: ubuntu-policy-rules.json file path.
To create a lifecycle policy, use the Create REST API method for the LifecyclePolicy resource or the LifecyclePolicyService/Create gRPC API call.
Example 2: Java artifact policy
In this example, we create a policy to manage Java artifacts with the com/example/myapp/.* path prefix. This policy contains two rules:
- Hard delete all snapshots.
- Keep the 2 latest snapshots.
Define the rules
Create a file named maven-policy-rules.json with the following contents:
[
{
"path_prefix": "com/example/myapp/.*",
"delete": {
"type": "HARD_DELETE",
"always": true
},
"maven_filters": {
"version_type": "SNAPSHOT"
}
},
{
"path_prefix": "com/example/myapp/.*",
"keep_by_version": {
"keep_versions_count": 2
},
"maven_filters": {
"version_type": "SNAPSHOT"
}
}
]
-
The first rule (
HARD_DELETE) deletes all snapshots of Java artifacts matching the path prefix. This automates the registry clean up of obsolete snapshots, mostly used for development and testing. -
The second rule (
keep_by_version) prevents deletion of the 2 most recent snapshots. This secures developer access to the most recently built snapshots even if they are deleted by the first rule.
Note
The keep_by_version rule has a higher priority than the deletion rule. This means the 2 most recent snapshots will be retained even though the first rule should delete all snapshots.
Create a policy
Create a lifecycle policy:
yc cloud-registry registry lifecycle-policy create \
--name maven-snapshot-policy \
--description "Policy for managing snapshots of java artifacts" \
--registry-id <registry_ID> \
--state DISABLED \
--rules maven-policy-rules.json
Where:
--name: Policy name.
--description: Policy description.
--registry-id: ID of the registry for which you are creating the policy.
--state: Policy state after creation (DISABLED).
--rules: maven-policy-rules.json file path.
To create a lifecycle policy, use the Create REST API method for the LifecyclePolicy resource or the LifecyclePolicyService/Create gRPC API call.
Recommendations
- Create policies in
DISABLEDstate to test the rules before applying them. - Use
SOFT_DELETEfor key artifacts so you can restore them during the waiting period. - Use the
KEEPrules to explicitly protect artifacts from deletion: thekeep_by_versionandkeep_by_agerules take precedence over deletion rules and ensure retention of artifacts. - Use retention rules together with deletion rules to flexibly manage artifacts.