Introduction

 

Over the past year, Docker has seen an extremely fast market adoption. Not only smaller companies, but also large enterprises are starting to build and transform their applications to run as Docker containers. Docker images are usually created during the automated build process, and then stored in a repository. Afterwards, they are pulled and deployed as running containers for automated testing, and eventually, deployed in production.

 

Docker Repositories

 

Docker repositories are the place where Docker images are being stored. Those repositories come in various flavors:

 

Especially in the enterprise space, it is important to protect intellectual property. Therefore, Docker images to be stored in a secure place (in the own datacenter) and should not be accessible by third parties.

 

NetApp StorageGRID Webscale

 

NetApp StorageGRID Webscale is a highly scalable, distributed object store, which supports object storage API standards like S3 and CDMI. It is fully software-defined, but can also be deployed as an appliance. StorageGRID scales beyond 100 Billion objects and 70PB under a single namespace. Click here to learn more about StorageGRID.

 

Running Docker Registry on NetApp StorageGRID Webscale

 

So let’s see how we can deploy Docker Registry to use NetApp StorageGRID Webscale in the backend. This allows users to store Docker images in a secure, controlled environment in their own datacenter.

 

Technology used:

 

  • Docker Registry
  • NetApp StorageGRID Webscale 10.1.1
  • Docker 1.7.0 on Ubuntu 14.04

First, create a new S3 user in StorageGRID Webscale:

 

s3_account.png

 

Then create a S3 Bucket for your user, in this case we’ll name it “docker-registry”. To do this, use your favorite way to access S3, e.g. REST, awscli, Cyberduck, etc. Next, let’s ssh into our Docker host where we want to deploy the Docker Registry. So, we’ll pull the Docker Registry image:

 

$ docker pull registry

Now, we’ll deploy Docker Registry with StorageGRID Webscale as the storage backend. In this example, StorageGRID Webscale’s API endpoint is running on 10.65.57.176 (port 8082). We also need to specify our S3 Access Key, S3 Secret Key, and the S3 bucket we just created:

 

$ docker run 
      -e SETTINGS_FLAVOR=s3 
      -e AWS_BUCKET=docker-registry 
      -e STORAGE_PATH=/registry 
      -e AWS_HOST=10.65.57.176 
      -e AWS_PORT=8082 
      -e AWS_ENCRYPT=false 
      -e AWS_KEY=Y4S2M3XXXXXXXXX 
      -e AWS_SECRET=+ftaO2D+DHLXXXXXXXXXXXXXXXXX 
      -e AWS_CALLING_FORMAT=boto.s3.connection.OrdinaryCallingFormat 
      -e SEARCH_BACKEND=sqlalchemy 
      -p 5000:5000 
      registry

At this point, we have the Registry running, and StorageGRID Webscale is being used as the storage backend. Obviously, those values can be embedded in a config.yml as described hereIn order to check if everything works, we’ll create a new docker image from an existing one:

 

$ docker pull training/sinatra

Re-tag it as our new image and specify our new registry (the hostname of Docker Registry is my-docker-registry on port 5000): 

 

$ docker tag training/sinatra my-docker-registry:5000/csiebler/sinatra:v0

Let’s push the image to our registry:

 

$ docker push my-docker-registry:5000/csiebler/sinatra:v0 The push refers to a repository [my-docker-registry:5000/csiebler/sinatra] (len: 1) Sending image list Pushing repository my-docker-registry:5000/csiebler/sinatra (1 tags) ... Pushing tag for rev [f0f4ab557f95] on {http://my-docker-registry:5000/v1/repositories/csiebler/sinatra/tags/v0}

Now, we can pull it from another host: 

 

$ docker pull my-docker-registry:5000/csiebler/sinatra:v0 Pulling repository my-docker-registry:5000/csiebler/sinatra ... Status: Downloaded newer image for my-docker-registry:5000/csiebler/sinatra:v0 $ docker images REPOSITORY                                      TAG                 IMAGE ID            CREATED             VIRTUAL SIZE my-docker-registry:5000/csiebler/sinatra        v0                  f0f4ab557f95        13 months ago       446.9 MB

If we look into our S3 bucket, we’ll notice that Docker Registry is using StorageGRID to store the images:

 

s3_objects.png

 

Done!

 

Limitations

 

There are few limitations you need to be aware of:

  • Object encryption is not supported when using Docker Registry with StorageGRID
  • Docker Distribution (Docker Registry’s successor), currently does not allow to talk to any S3-compatible object stores like StorageGRID Webscale

Summary

 

Using StorageGRID Webscale for storing Docker images via Docker Registry provides a simple way to build your own image repository in house, based on an enterprise class object store. This helps you to keep your Docker images under your own control and provides additional security (e.g., through StorageGRID’s policy engine).

 

Let me know if this post was helpful!

 

Follow me on Twitter: @clemenssiebler

Clemens_Siebler