Docker Practices

Introduction

Those are my recommendations & practices against Docker deployment & dperations. If you think it’s wrong, please argue against it. Anyway, this is how I take advantage of the Docker features and work around its operational drawbacks.

Building Docker images

You don’t necessarily have to play with Dockerfiles. You can also run e.g. the official ubuntu image, tweak the container on its shell and then commit to an image. It’s actually easier. It’s just that you need to keep track of command lines somewhere, so you’ll able to rebuild the image in the future.

Also, when I build a Docker image using Dockerfile, I just put all the command lines into a shell script. Why bother with hundreds of ^RUN commands?

FROM ubuntu:latest
MAINTAINER user@example.com
COPY upload/ /root/upload/
RUN /root/upload/install.bash
CMD /root/upload/fakeinit.sh

Think of an image as for apps' (load-balanced) deployments

First, you need to think docker images & containers in terms of applications' deployments on several nodes (ideally the applications are cluster-ready). And the nicest thing in that situation would be to deploy an entire app with only one image/container right? This is a way to go. However it would make quite some redundant processes for example MariaDB and Elasticsearch (preferably on bare-hardware anyway) instances would be running several times. So if you asking what parts of an application you need to split into containers, here’s my method to decide:

1. the http/https serving part of the application may be executed directly on the docker host, as long as it’s very light e.g. if it’s raw html data. If there is PHP, special modules or too hardcore tweaks against your Apache or NGINX reverse-proxy, then forget it and keep the little security a container provides. This means you need to embed the apache, nginx or what ever http daemon inside the application container and reverse-proxy it on the docker host.
2. the parts that are application specific are obviously embedded in the application container
3. the parts that are possibly shared with other applications and that would bring heavy process load duplicates on the docker hosts would not be embedded e.g. MariaDB

So for example if you got an application doing LAMP + specific JAVA + ES, I would split into:

• apache/php + java container, which would be application-specific
• mariadb container for all the containers
• elastic container for all the containers

Therefore, when you deploy the application, you need to make sure the DB & indexes are ready for it on the mutualized maria & elastic containers.