Docker Registry

Getting Started With Artifactory as a Docker Registry

There are these main ways to get started using Docker with Artifactory:

1. Artifactory SaaS account
2. Artifactory On-Prem

For more details, please refer to Getting Started with Artifactory as a Docker Registry. 

Configuring Docker Repositories

Remote Docker Repositories

With Docker, you can proxy a remote Docker registry through remote repositories. A Remote Repositories defined in Artifactory serves as a caching proxy for a registry managed at a remote URL such as https://registry-1.docker.io/ (which is the Docker Hub), or even a Docker repository managed at a remote site by another instance of Artifactory.

Docker images requested from a remote repository are cached on demand. You can remove downloaded images from the remote repository cache, however, you can not manually push Docker images to a remote Docker repository.

To define a remote repository to proxy a remote Docker registry follow the steps below:

1. From the Administration module, select Repositories | Repositories | Remote.
2. Click New Remote Repository and select Docker from the Select Package Type dialog. 
3. In the Basic tab, set the Repository Key value, and specify the URL to the remote registry in the URL field.
   If you are proxying the Docker Hub, use https://registry-1.docker.io/ as the URL, and make sure the Enable Token Authentication checkbox is checked (these are the default settings).
4. To use your Docker account type, you need to authenticate the Docker Hub pull requests, by setting your user and password in your basic Docker repository.
5. Click the Advanced tab to configure the Advanced Docker Repository settings you can enable Foreign Layers Caching to allow Artifactory to download foreign layers to a Docker remote repository.
   
6. Select the Enable Foreign Layers Caching checkbox to allow Artifactory to download foreign layers to a Docker remote repository.
7. You have an option to apply Patterns Allow List by setting Include patterns to match external URLs when trying to download foreign layers.

   Specify an Allow List of Ant-style path expressions that specify where foreign layers may be downloaded from. Supported expressions include (*, **, ?).
   By default, this field is set to ** which means that foreign layers may be downloaded from any external source.
   For example, specifying **/github.com/** will only allow downloading foreign layers from a github.com host.

8. To configure the Network settings, see Network Settings.
9. Click Save and Finish.
   
   

Docker Repository Path and Domain

Virtual Docker Repositories

Artifactory supports virtual Docker Repositories. A Virtual Repositories defined in Artifactory aggregates images from both local and remote repositories that are included in the virtual repositories. 

This allows you to access images that are hosted locally on local Docker repositories, as well as remote images that are proxied by remote Docker repositories, and access all of them from a single URL defined for the virtual repository. Using virtual repositories can be very useful since users will continue to work with the virtual repository while the admin can manage the included repositories, replace the default deployment target and those changes will be transparent to the users.

To define a virtual Docker repository follow the steps below:

1. From the Administration module, select Repositories | Repositories | Virtual.
2. Click New Virtual Repository and select Docker from the Select Package Type dialog. 
3. Set the Repository Key value.
4. Select the underlying local and remote Docker repositories to include under the Repositories section.
5. You can optionally also configure your Default Deployment Repository.  This is the repository to which Docker images uploaded to this virtual repository will be routed, and once this is configured, your virtual Docker repository is a fully-fledged Docker registry. Using the default deployment repository, you can set up your virtual repository to wrap a series of repositories that represent the stages of your pipeline, and then promote images from the default deployment repository through the pipeline to production. Any repository that represents a stage in your pipeline within this virtual repository can be configured with permissions for authenticated or unauthenticated (anonymous) access according to your needs. 

Resolve Latest Docker Image

To set your virtual Docker repository to pull Docker images according to their modification time, enable Resolve Docker Tags By Latest Timestamp. This is useful in scenarios where two or more aggregated repositories contain the same tag name. For example, busybox:1.1.

When enabled, instead of fetching the image that is positioned higher in the resolution order in the virtual repository, Artifactory will return the Docker image last deployed to one of the aggregated repositories in the Virtual repository. Artifactory will first try to fetch the tag from the Local repositories according to the modification time, if not found, it will continue to try to fetch the image from the Remote repositories according to the resolution order.

This functionality is useful for multi-site environments where you create the same image on two different instances.

Reverse Proxy Settings

Artifactory supports access to Docker registries either through a reverse proxy (using the subdomain method or through port bindings), or using direct access.

When accessing through a reverse proxy, if you are using the Artifactory Reverse Proxy configuration generator you can configure a Docker repository's reverse proxy settings under the Advanced settings tab. For details, please refer to Docker Reverse Proxy Settings.

Promoting Docker Images

Artifactory supports promoting Docker images from one Docker repository in Artifactory to another. 

Promoting is useful when you need to move Docker images through different acceptance and testing stages, for example, from a development repository, through the different gateways all the way to production. Instead of rebuilding the image multiple times using promotion will ensure the image you will have in your production environment is the one built by your CI server and passed all the relevant tests. 

Promotion can be triggered using the following endpoint with cURL:

POST api/docker/<repoKey>/v2/promote
{ 
    "targetRepo" : "<targetRepo>",  
    "dockerRepository" : "<dockerRepository>",  
    "tag" : "<tag>", 
	"targetTag" : "<tag>",
    "copy": <true | false>
}

where:

An example for promoting the docker image jfrog/ubuntu"] with all of it's tags from docker-local to docker-prod using cURL would be:

curl -i -uadmin:password -X POST "https://artprod.company.com/api/docker/<repoKey>/v2/promote" -H "Content-Type: application/json" -d '{"targetRepo":"docker-prod","dockerRepository":"jfrog/ubuntu"}'

https://artprod.company.com/api/docker/<repoKey>/v2/promote

Notice that the above example is executed through your reverse proxy. To go directly through Artifactory, you would execute this command as follows:

curl -i -uadmin:password -X POST "http://localhost:8080/artifactory/api/docker/docker-local/v2/promote" -H "Content-Type: application/json" -d '{"targetRepo":"docker-prod","dockerRepository":"jfrog/ubuntu"}'

curl -i -uadmin:password -X POST "https://artprod.company.com/api/docker/docker-local/v2/promote" -H "Content-Type: application/json" -d '{"targetRepo":"docker-prod","dockerRepository":"jfrog/ubuntu", "tag" : "4.9.0", "targetTag" : "latest"}'