image image 18th November 2015

5 useful developer hacks to know about Docker…

Docker is fast becoming the architectural building block for any microservice based strategy with a clear focus on ‘do one thing and do it well’.  A well designed container will have all components necessary (but no more!) to provide the service and they will be built from Dockerfiles in a CI environment for direct deployment to production.

However, sometimes the developer needs to be able to get into the container and have a look around to see what’s really going on…

1: Calling exec on running container

This is day one stuff at Docker school – but somehow I missed it for quite a while. You have a running container that has been designed correctly to start one service (e.g mysql) but it is not running quite as you expect – you want to log in and look around. You don’t have to rebuild the container and include an ssh daemon. Simply:

docker exec –ti [container name or id] /bin/bash

and you are in!

2: Using user in a Dockerfile

A Docker service runs as root by default and this is not a good practice for many obvious reasons. When used with volumes it can cause irritating file permission problems. As a developer you may mount (using volumes) your home directory into the container to run your code directly out of a git tree. I create a user in the Dockerfile and supply the same UID and GID as my account on the host:

RUN groupadd appuser -g 1000

RUN useradd appuser -u 1000 -g 1000

USER appuser

When this container runs it will execute the Docker command as appuser which has the same file permissions as my developer account on the host so I can read/write files mounted from my home directory.

3: centos6 service commands

Sometimes you need to take the Docker design ethos of ‘run one service- and throw it out the window. You need to have a number of services start automatically using init.d scripts. You can do this with the official centos6 image. Include whatever services you need to start in your Dockerfile and ensure you run chkconfig on – they will start in addition to the ‘command’.

4: save+load

Docker hub and private Docker repositories are an essential part of the whole Docker ecosystem – but sometimes you need to shift a Docker image from one server to another (or more likely your laptop). There can be a whole host of reasons why you cannot do this through a repository (no internet access in production etc.) so this is where Docker save and load are essential.

You can save a Docker image to a tar file:

docker save [image name NOT instance] > out .tar

Then copy the file across and on the target server:

docker load < out.tar

5: X

Why would you want to run a GUI app in a container? I have actually found it useful on occasion to run eclipse inside a container to debug applications that are also running in containers. Supplying these two parameters on your run command allow you to forward X base GUI applications to your host (remember to run xhost + on your host first).


-v /tmp/.X11-unix:/tmp/.X11-unix \

If you are feeling really adventurous you could try running Quake3 in your container:


We Love Data

Want to know more?

Drop us a line – we’re always happy
to chat – we promise we’ll keep the
geek speak to a minimum (unless
that’s your bag in which case we’ll
happily comply)!