The Docker Registry acts as the repository for image data for most deployments. Whether you’re using the fully supported Docker Trusted Registry, or the open source version deployed by itself or in combination with something like Red Hat’s OpenShift, the preferred storage for the images is object based. While the registry can be configured to store its image data in many different ways, it was designed with object storage in mind, and that method brings with it certain advantages.
One significant advantage is that a Docker client pulling an image will simply receive the location in the object store, then retrieve it from the store directly. Other methods tend to pull the data through the registry directly, creating a potential bottleneck.
StorageGRID WebScale is NetApp’s object storage solution. It’s scalable, highly available, capable of doing automatic tiering of data being stored, supports geographically distributed sites, and much more. You can find a lot more information on netapp.com, or Tech ONTAP Podcast episode 84.
First, you’ll need S3 credentials and a bucket from your StorageGRID instance.
- Create an S3 tenant in StorageGRID (or identify an existing tenant to use)
- Create a tenant user (or use an existing user)
- Create S3 credentials for the user (or use an existing set of credentials). This creates the access key and secret key we will need for Registry.
- Using the AWS CLI, s3browser, or other suitable S3 tool, create a bucket using the S3 credentials created or identified above. Clemens did a great job of explaining how to use the AWS CLI with StorageGRID here.
With credentials in hand, and your bucket created, we can continue with configuring Registry.
- Create a customized registry config file,
config.yml. Modify the example configuration to include S3 details in the storage section:
1234567storage:s3:region: localaccesskey: <access key>secretkey: <secret key>regionendpoint: https://<endpoint ip>:<port>bucket: <bucket name>
Alternatively, this could be done using environment variables when the container is instantiated as well. The documentation has additional details on how to customize the Registry instance.
- Start the registry, specifying the custom config file location:
123docker run -d -p 5000:5000 \-v `pwd`/config.yml:/etc/docker/registry/config.yml \registry:2
That’s it! Follow the normal method of adding certificates, or setting as an insecure instance, for the local Registry to your container hosts. Once fully configured, we can verify by pulling a small image, retagging for the local Registry instance it, and then pushing it.
# pull an image from Docker Hub
docker pull busybox
# retag it for the local registry
docker tag busybox registry.thepub.netapp.io/busybox
# push it to the local Registry instance
docker push registry.thepub.netapp.io/busybox
# to thoroughly test the new instance, let's pull the image too
# first, remove the local image
docker rmi registry.thepub.netapp.io/busybox
# pull the image from the local registry
docker pull registry.thepub.netapp.io/busybox
Simple, Scalable Registry Storage
Docker Registry works with StorageGRID WebScale 10.4 or later. There is an issue with the golang web client, which is used by the Registry, which prevents StorageGRID WebScale 10.3 or earlier from working with the Regsitry.
The Registry is a core component of any successful deployment of a containerized solution leveraging on-premises resources. Whether you have one container image, or ten thousand, a Registry which uses StorageGRID WebScale as the underlying storage can meet your capabilities for performance, availability, and reliability.
If you have any questions about using StorageGRID WebScale with a Registry instance, please leave us a comment below or contact us via our Slack channels.