vendredi 27 octobre 2017

What is important in Docker is the Dockerfile



Most important part of a Docker container is the dockerfile.

In fact, doing good dockerfiles is enough for efficient Devops !



TL;DR : Use Docker in development but once your dockerfile is fine tuned, transform it into a "native" package (DEB, RPM...) and replace the content of the dockerfile by the installation of the package => more portable across container platforms and OS.

What is Docker ?

Docker is a way to create a world for your application (or a part of it) and isolating it from the outer world (for the oldest geeks, do you remember Populous? Well, that's what you're doing by using Docker, you are the God and you rules everything from ground design to interactions)

How do we do that ?

We do that by telling Docker how to construct the world, creating the lands, populating it with living creatures, all of this is described in the dockerfile : to continue with the god metaphor, this is the Genesis Book. You will describe everything that makes your application's ecosystem functional; from the operating system you choose to the starting of your application through all configuration parts.

 Why is it good ?

This is good because by writing this description of the world creation, we create a reproducible and stable world. And a stable world is the first step for a stable application.
If environment surrounding your application changes in every new installation (and doing it manually, it will) it will lead you to instability.
Imagine we transpose this to real world : it would be similar to start working in a different company every day, not the best way to be top productive, isn't it?
 This is why it is important to stabilize environment.
And this is the first step of the industrialisation process of your application, and with this you reduce instability, greatly accelerates deployment, and finally that will raise the productivity of you, your teammates and your application will looks shinier.

Why do you want to use dockerfile without Docker ? Isn't it a nonsense ?

Yes nut no :-).
Of course, you can't reuse dockerfile as-it outside the docker world, but you can reuse the content (or more generally, the concepts).

When you're thinking of how you will construct your world, you think about the dependencies, their relationships, the way to configure it effectively, in short, you think about the industrialisation of your application, how to install/configure/manage it.

Once you achieved to use docker for your application, you made the most difficult (in general, you made modifications to the dockerfile AND to your application), it is now easy to extrapolate/generify the process to make your application deployable (almost) everywhere. If you compare a dockerfile and the postinst file of a debian package (or any other package manager file), you'll see they have a lot in common, it's most a subject of translating one description to another, no magic needed.


Using Docker during development is now a commonly accepted idea, and this is a good habit but when it won't be changing anymore, you could think of transforming it into a native package (debian, RPM, once you made it for one, it's only some adaptations for another, they're all similar).
By doing this, you will gain those benefits:

  1. you won't be stuck with a single container will be independent of container technology (there is not only Docker in the Container's world : LXC, Solaris Zone, RKT...maybe it's not changing as fast a JS ecosystem, but it's moving), with native packaging, you won't have problems to adpat your application to one or another technology.
  2. some customers prefer native installations or classical Virtual Machines. This won't be a problem once you made native packaging (to understand why some customers would like this, take some time to have a look to the container management jungle ? Swarm, Kubernetes, Mesos, it's even moving faster than container technology, and nobody seems to take the lead for the moment) 

And finally, you will be able to fly yourself !

Ecosystem independence

Aucun commentaire:

Enregistrer un commentaire

Typical arguments to avoid to write automated tests (and their counter arguments :) )

As a test aficionado, I often have to deal with some people who are refractory to tests, with many stereotypes and preconceptions. Here is...