This is a geeky post for those Googling for relevant phrases. Sometimes a Docker Registry is referred to as a ‘Docker repository’; technically, they’re different things, but the terms are often used interchangeably.
It can be useful to have a private Docker repository for sharing images within your organisation, and from which to deploy the definitive versions of your containers to production.
At Telemarq, we do this by running:
- a standard registry:2 container on one of our DigitalOcean servers
- an nginx container in front of it, with basic HTTP auth enabled
- a letsencrypt system to provide HTTPS certificates for nginx, so the communications are secure.
The registry container can, itself, handle both authentication and the certificates, but it’s easier for us to deploy it this way as part of our standard infrastructure. It all works very nicely, and we’re just starting to incorporate it into some of our more serious workflows.
So how do you make sure that the right images end up in your repository?
One practice we adopt for any deployment system, with or without Docker, is to require that things pushed to the servers should come directly from the git repository, so that they aren’t influenced by what just happens to be in the directory on some arbitrary machine at some time. Typically we might have a script that creates a temporary directory, checks out a known version of the code, builds and deploys it to the server, and then tidies up after itself. (If you use a continuous delivery system, this may happen automatically on a regular basis.)
In the Docker world, you can take advantage of the fact that the docker command itself understands git repositories. So you can build a container from the current master branch of your github project using something like:
docker build -t myproject git@github.com:quentinsf/myproject.git
and docker will do the necessary bits behind the scenes, assuming there’s a Dockerfile in the source. (More details here).
So, suppose you want to build version 1.6 of ‘myapp’ and upload it, appropriately tagged, to your Docker registry, you can do so with a couple of simple commands:
docker build -t dockerregistry.example.com/myapp:1.6 \
gitrepository.example.com/myapp.git#1.6
docker push dockerregistry.example.com/myapp:1.6
I can run this on my Mac, a Windows machine, or any Linux box, and get a consistent result. Very nice. You could also tag it with the SHA1 fingerprint of the git commit, if wanted.
Listing the containers on your Docker registry
At present, there isn’t a convenient command-line interface for examining what’s actually stored on your registry. If I’m wondering whether one of my colleagues has already created and uploaded a container for one of our services, how would I know? There is, however, an HTTP API which will return the information as JSON, and you can then use the excellent jq utility to extract the bits you need:
curl -s -u user:password https://dockerregistry.example.com/v2/_catalog | jq .repositories[]
If you want to see the version tags available for mycontainer, you can use:
curl -s -u user:password https://dockerregistry.example.com/v2/mycontainer/tags/list | jq .tags[]
And you can of course wrap these in scripts or shell aliases if you use them often.
Hope that’s useful for someone!
RSS feed
Recent Comments