Update Promote an image using policies and Mirror images to another registry pages with new screenshots and instructions
|
After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 247 KiB After Width: | Height: | Size: 33 KiB |
|
Before Width: | Height: | Size: 338 KiB After Width: | Height: | Size: 107 KiB |
|
Before Width: | Height: | Size: 278 KiB After Width: | Height: | Size: 69 KiB |
|
After Width: | Height: | Size: 39 KiB |
|
Before Width: | Height: | Size: 235 KiB After Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 290 KiB After Width: | Height: | Size: 80 KiB |
|
Before Width: | Height: | Size: 297 KiB After Width: | Height: | Size: 68 KiB |
|
|
@ -11,7 +11,7 @@ redirect_from:
|
||||||
Docker Trusted Registry allows you to create image promotion pipelines based on
|
Docker Trusted Registry allows you to create image promotion pipelines based on
|
||||||
policies.
|
policies.
|
||||||
|
|
||||||
In this example we'll create an image promotion pipeline such that:
|
In this example we will create an image promotion pipeline such that:
|
||||||
|
|
||||||
1. Developers iterate and push their builds to the `dev/website` repository.
|
1. Developers iterate and push their builds to the `dev/website` repository.
|
||||||
2. When the team creates a stable build, they make sure their image is tagged
|
2. When the team creates a stable build, they make sure their image is tagged
|
||||||
|
|
@ -23,31 +23,30 @@ With this promotion policy, the development team doesn't need access to the
|
||||||
QA repositories, and the QA team doesn't need access to the development
|
QA repositories, and the QA team doesn't need access to the development
|
||||||
repositories.
|
repositories.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
## Configure your repository
|
## Configure your repository
|
||||||
|
|
||||||
Once you've [created the repository](../manage-images/index.md), navigate to
|
Once you've [created the repository](../manage-images/index.md), navigate to
|
||||||
the **DTR web UI**, go to the **repository details** page, and choose
|
the repository page on the DTR web interface, and select the
|
||||||
**Promotions**.
|
**Promotions** tab.
|
||||||
|
|
||||||
{: .with-border}
|
{: .with-border}
|
||||||
|
|
||||||
Click **New promotion policy**, and define the criteria that an image needs
|
Click **New promotion policy**, and define the image promotion criteria.
|
||||||
to meet to be promoted.
|
|
||||||
|
|
||||||
DTR allows defining the following criteria:
|
DTR allows you to set your promotion policy based on the following image attributes:
|
||||||
|
|
||||||
| Name | Description |
|
| Name | Description | Example |
|
||||||
|:----------------|:---------------------------------------------------|
|
|:----------------|:---------------------------------------------------| :----------------|
|
||||||
| Tag name | If the tag name contains |
|
| Tag name | Whether the tag name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Promote to Target if Tag name ends in `stable`|
|
||||||
| Component name | If the image has a given component |
|
| Component name | Whether the image has a given component and the component name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Promote to Target if Component name starts with `b` |
|
||||||
| Vulnerabilities | If the image has vulnerabilities |
|
| Vulnerabilities | Whether the image has vulnerabilities – critical, major, minor, or all – and your selected vulnerability filter is greater than or equals, greater than, equals, not equals, less than or equals, or less than your specified number | Promote to Target if Critical vulnerabilities = `3` |
|
||||||
| License | If the image uses an intellectual property license |
|
| License | Whether the image uses an intellectual property license and is one of or not one of your specified words | Promote to Target if License name = `docker` |
|
||||||
|
|
||||||
Now you need to choose what happens to an image that meets all the criteria.
|
Now you need to choose what happens to an image that meets all the criteria.
|
||||||
|
|
||||||
Select the **organization** and **repository** where the image is going to be
|
Select the target **organization** or **namespace** and **repository** where the image is going to be
|
||||||
pushed. You can choose to keep the image tag, or transform the tag into
|
pushed. You can choose to keep the image tag, or transform the tag into
|
||||||
something more meaningful in the destination repository, by using a tag template.
|
something more meaningful in the destination repository, by using a tag template.
|
||||||
|
|
||||||
|
|
@ -59,7 +58,12 @@ timestamp of when the image was promoted.
|
||||||
{: .with-border}
|
{: .with-border}
|
||||||
|
|
||||||
Everything is set up! Once the development team pushes an image that complies
|
Everything is set up! Once the development team pushes an image that complies
|
||||||
with the policy, it automatically gets promoted.
|
with the policy, it automatically gets promoted. To confirm, select the **Promotions** tab on the `dev/website` repository.
|
||||||
|
|
||||||
|
{: .with-border}
|
||||||
|
|
||||||
|
|
||||||
|
You can also review the newly pushed tag in the target repository by navigating to `qa/website` and selecting the **Tags** tab.
|
||||||
|
|
||||||
{: .with-border}
|
{: .with-border}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -6,46 +6,42 @@ keywords: registry, promotion, mirror
|
||||||
|
|
||||||
Docker Trusted Registry allows you to create mirroring policies for a repository.
|
Docker Trusted Registry allows you to create mirroring policies for a repository.
|
||||||
When an image gets pushed to a repository and meets a certain criteria,
|
When an image gets pushed to a repository and meets a certain criteria,
|
||||||
DTR automatically pushes it to repository in another DTR deployment or Docker
|
DTR automatically pushes it to a repository in a remote Docker Trusted or Hub registry.
|
||||||
Hub.
|
|
||||||
|
|
||||||
This not only allows you to mirror images but also allows you to create
|
This not only allows you to mirror images but also allows you to create
|
||||||
image promotion pipelines that span multiple DTR deployments and datacenters.
|
image promotion pipelines that span multiple DTR deployments and datacenters.
|
||||||
|
|
||||||
In this example we'll create an image mirroring policy such that:
|
In this example we will create an image mirroring policy such that:
|
||||||
|
|
||||||
1. Developers iterate and push their builds to `dev.example.org/website/ui`, the
|
1. Developers iterate and push their builds to `dtr-example.com/dev/website` &endash; the
|
||||||
`website/ui` repository in the DTR deployment dedicated to development.
|
repository in the DTR deployment dedicated to development.
|
||||||
2. When the team creates a stable build, they make sure their image is tagged
|
2. When the team creates a stable build, they make sure their image is tagged
|
||||||
with `-stable`.
|
with `-stable`.
|
||||||
3. When a stable build is pushed to `dev.example.org/website/ui`, it will
|
3. When a stable build is pushed to `dtr-example.com/dev/website`, it will
|
||||||
automatically be pushed to `qa.example.org/website/ui`, mirroring the image and
|
automatically be pushed to `qa-example.com/qa/website`, mirroring the image and
|
||||||
promoting it to the next stage of development.
|
promoting it to the next stage of development.
|
||||||
|
|
||||||

|
With this mirroring policy, the development team does not need access to the
|
||||||
|
QA cluster, and the QA team does not need access to the development
|
||||||
With this mirroring policy, the development team doesn't need access to the
|
|
||||||
QA cluster, and the QA team doesn't need access to the development
|
|
||||||
cluster.
|
cluster.
|
||||||
|
|
||||||
The person setting this mirroring policy needs to have permissions to push
|
You need to have permissions to push to the destination repository in order to set up the mirroring policy.
|
||||||
to the destination repository.
|
|
||||||
|
|
||||||
## Configure your repository
|
## Configure your repository
|
||||||
|
|
||||||
Once you've [created the repository](../manage-images/index.md), navigate to
|
Once you have [created the repository](../manage-images/index.md), navigate to
|
||||||
the **DTR web UI**, go to the **repository details** page, and choose
|
the repository page on the web interface, and select the
|
||||||
**Mirrors**.
|
**Mirrors** tab.
|
||||||
|
|
||||||
{: .with-border}
|
{: .with-border}
|
||||||
|
|
||||||
Click **New mirroring policy**, and define where the image will be pushed if
|
Click **New mirror**, and define where the image will be pushed if
|
||||||
it meets the policy criteria. Make sure the account you use for the integration
|
it meets the mirroring criteria. Make sure the account you use for the integration
|
||||||
has permissions to write in the destination repository.
|
has permissions to write to the remote repository. Under **Mirror direction**, choose **Push to remote registry**.
|
||||||
|
|
||||||
In this example we'll push the image to the `website/ui` repository of a
|
In this example, the image gets pushed to the `qa/website` repository of a
|
||||||
DTR deployment available at `qa.example.org`. We also use a service account
|
DTR deployment available at `qa-example.com` using a service account
|
||||||
that was created just for mirroring images between repositories.
|
that was created just for mirroring images between repositories. Note that you may use a password or access token to log in to your remote registry.
|
||||||
|
|
||||||
If the destination DTR deployment is using self-signed TLS certificates or
|
If the destination DTR deployment is using self-signed TLS certificates or
|
||||||
certificates issued by your own certificate authority, click
|
certificates issued by your own certificate authority, click
|
||||||
|
|
@ -58,33 +54,28 @@ Once you're done, click **Connect** to test the integration.
|
||||||
|
|
||||||
{: .with-border}
|
{: .with-border}
|
||||||
|
|
||||||
Under **Mirror direction** choose **push to remote registry**. Then specify the
|
DTR allows you to set your mirroring policy based on the following image attributes:
|
||||||
policy that will trigger the image to be pushed to the external registry.
|
|
||||||
|
|
||||||
DTR allows defining the following criteria:
|
| Name | Description | Example |
|
||||||
|
|:----------------|:---------------------------------------------------| :----------------|
|
||||||
| Name | Description |
|
| Tag name | Whether the tag name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Copy image to remote repository if Tag name ends in `stable`|
|
||||||
|:----------------|:---------------------------------------------------|
|
| Component name | Whether the image has a given component and the component name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Copy image to remote repository if Component name starts with `b` |
|
||||||
| Tag name | If the tag name contains |
|
| Vulnerabilities | Whether the image has vulnerabilities – critical, major, minor, or all – and your selected vulnerability filter is greater than or equals, greater than, equals, not equals, less than or equals, or less than your specified number | Copy image to remote repository if Critical vulnerabilities = `3` |
|
||||||
| Component name | If the image has a given component |
|
| License | Whether the image uses an intellectual property license and is one of or not one of your specified words | Copy image to remote repository if License name = `docker` |
|
||||||
| Vulnerabilities | If the image has vulnerabilities |
|
|
||||||
| License | If the image uses an intellectual property license |
|
|
||||||
|
|
||||||
Finally you can choose to keep the image tag, or transform the tag into
|
Finally you can choose to keep the image tag, or transform the tag into
|
||||||
something more meaningful in the destination registry, by using a tag template.
|
something more meaningful in the remote registry by using a tag template.
|
||||||
|
|
||||||
{: .with-border}
|
{: .with-border}
|
||||||
|
|
||||||
In this example, if an image in the `website/ui` repository is tagged with
|
In this example, if an image in the `dev/website` repository is tagged with
|
||||||
a word that ends in "stable", DTR will automatically push that image to
|
a word that ends in "stable", DTR will automatically push that image to
|
||||||
the DTR deployment available at `qa.example.org`. The image is pushed to the
|
the DTR deployment available at `qa-example.com`. The image is pushed to the
|
||||||
`website/ui` repository and is tagged with the timestamp of when the image
|
`qa/website` repository and is tagged with the timestamp of when the image
|
||||||
was promoted.
|
was promoted.
|
||||||
|
|
||||||
Everything is set up! Once the development team pushes an image that complies
|
Everything is set up! Once the development team pushes an image that complies
|
||||||
with the policy, it automatically gets promoted.
|
with the policy, it automatically gets promoted to `qa/website` in the remote trusted registry at `qa-example.com`.
|
||||||
|
|
||||||
{: .with-border}
|
|
||||||
|
|
||||||
## Metadata persistence
|
## Metadata persistence
|
||||||
|
|
||||||
|
|
|
||||||