Docker - Things I'd like to see fixed

Recently I've been lucky enough to spend some time with Docker.  I've really enjoyed it and would definitely consider myself a fan.  However I think a couple of issues really need fixing.

Docker registries should treat images as immutable entities

Currently docker registries (including docker hub) allow you to overwrite an image with the same tag.  This means you can't be sure that an image hasn't changed since you last pulled it.  This is a nightmare from a build and deploy point of view.  I can imagine a sequence of events whereby a small low risk change is pushed through the environments with plenty of testing, only to fail in production when suddenly a modified and incompatible dependent image is pulled and deployed for the first time.  Sadly it seems that this issue has been closed - presumably without a fix.


Registry locations and Image tags need to be separate entities

Uniquely identifying a specific docker image and a source/destination registry should be two different concepts, but with docker they are combined and seem confused.  

Docker images are specified by a tag which consists of user/image:version so running: 

docker pull someone/something

...will pull the latest something image as created by user someone from registry.hub.docker.com.  However, the user part also allows us to specify a different registry, perhaps our own locally available one.  So this means that

docker pull my.local.reg/something

...will pull something from my.local.reg.  This means that in order to push an image to a local registry you need to re-tag it to include the FQDN of my.local.reg as shown below...

docker tag someone/something my.local.reg/something

and then...

docker push my.local.reg/something

...now we've lost the user someone all together.  This seems strange to me for a number of reasons:

  • It implies that images are different if they have come from different registries which should not be the case.  
  • Your source code references your local registry's FQDN.  This is because Dockerfiles that are declared to be FROM an image need to specify the parent image in the same way.  
  • Your FQDN cannot ever be one word such as localhost as it will assume you are specifying username localhost on registry.hub.docker.com 
I'd prefer to keep these things separate as per Maven's GAV parameters with the registry (maven repo) specified in an external settings file.

Comments

Post a Comment

Popular posts from this blog

Lessons learned from a connection leak in production

We recently encountered a connection leak with one of our services in production.  Here's what happened, what we did and the lessons learned... Tests and Monitoring detected the issue (silently) Our automated tests (which run in production for this service) started failing soon after the incident occurred.  We didn't immediately realise since they just went red on the dashboard and we just carried on about our business.  Our monitoring detected the issue immediately and also went red but crucially didn't email us due to an environment specific config issue. The alarm is raised A tester on the team realises that the tests had been failing for some time (some time being 4 hours... eek!) and gets us to start investigating. Myself and another dev quickly looked into what was going on with our poorly  dropwizard  app.  We could see from the monitoring dashboard that the application's health check page was in error.  Viewing the page showed us tha...
Read more

How to connect your docker container to a service on the parent host

Recently I needed a docker container to access a service running on the parent host.  A lot of the examples on the internet were very close to what I needed, but not quite. First off, docker's documentation provided an example that (as far as I can see) doesn't actually work.  The following (I think) is meant to inject the src ip address of the parent host's default interface: $ alias hostip="ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print \$2 }'" $ docker run  --add-host=docker:$(hostip) --rm -it debian What it actually does is inject the ip of the default gateway on the parent host which doesn't help us. Michael Hamrah 's blog details the " gateway approach " of getting the parent's host ip from within the docker container.  This works great, although I wanted to inject the ip on container run and not have that logic within my docker image. Inject the src ip of the docker interface I think the best ...
Read more

Client Side vs Server Side Session

Image
We recently looked at replacing our legacy session management system with a new one.  During this analysis, we came close to choosing a client side session but eventually concluded server side was better for us.  Here's why... Client side session In this model, all session state is stored in the client in a cookie.  The benefits of this are you don't need to worry about persisting and replicating state across nodes, session validation is lightning fast since you don't need to query any data store which means it's super scalable.  The session cookie must obviously be tamper proof (to prevent people creating a session of their choice) which is achieved by signing the cookie using asymmetric cryptography. The signing of a cookie value uses the private key, the validation uses the corresponding public key.  Our idea was to try and keep the private key as private as possible by storing it in memory only.  Each node (4 shown below) would create a new priva...
Read more