DEV Community

Julie Hourcade
Julie Hourcade

Posted on • Updated on

Docker Best Practices, back to basics.

You're new to Docker ? I was too. Everyone wants to build awesome projects with Docker, build some images and start containers. That's cool ! Docker is cool. But you missed a point, there are some rules to use it.

Rule number one ! Keep it simple and small.

Docker images are meant to be SMALL. As small as possible.
Docker is a conteneurisation system not a virtual machine. Don't reproduce all your GNU/Linux distribution on it.

To have a lightweight image, you can first take a look to Alpine versions. Alpine is a Linux based on MUSL and BusyBox instead of basical GNU. If you want to use a Debian base image anyway, don't forget to clean apt after installing packets.

Choose a Official Docker image, you must.

There is an ocean of Docker images available on Docker Hub but they are not all secured. You must choose a official image and add to it what you need. For example, don't use a PHP image made by a unknown person found on the Hub but prefer to use the php official image with the adapted tag.

If you really need to use a unofficial image, take a look at the Dockerfile. Most of images provides the Dockerfile associated to the image. If the base image is based itself on an other unofficial image, search it ! Go the deeper possible. Finally, avoid closed images with no Dockerfile provided, it could be insecure.

You're saying image tag ? Don't use the latest.

When you're building a Dockerfile, everyone has already added a FROM statement with the latest tag on the image. Everyone, don't lie.
So don't do that ! For the simple reason that the latest tag is the latest not the more stable. If the latest tag change to an upper version it could broke all your system. You should consider to choose a version no matter the base image you use.

Dev environements are not the same as Prod environements.

For a use in production, there are more rules.
First of all, don't use docker-compose on production. Prefer using a orchestrator like Swarm or Kubernetes. If you have to use docker-compose on a project, you could switch to an orchestrator. It's not too much.

Secondly, containers should be stateless. For example, don't conteneurize databases.

Finally, One container, One task. A container should do only one thing like running a webserver, execute a script, run a ElasticSearch or a Redis or a RabbitMQ even a GitLab but not all together.


To conclude :

  • Make small and simple images
  • Use official Docker Hub images as possible
  • Never use the latest tag
  • Be careful on what you're doing on production

Useful links
and all the Docker documentation

Feel free to add your best practices in comments !

Top comments (0)