My first encounter with containers in the Linux edition was greatly "burdened" with the previous experiences with virtualisation. The containers were another, after paravirtualisation, step towards making the visualization even "lighter" and less resource consuming! I thought they were. When my colleagues experimented with the duet vagrant + virtualbox I tried to experiment with Lxc and I was not especially interested with how the Lxc works – it was just "a virtual environment". A moment of "enlightenment" came after the Linux autumn 2016. I participated in workshop concerning Linux Namespaces – it was really interesting! However after the conference I put this subject aside. Sometime in 2017 I looked through the recordings from DockerConf 2015 where I found a recording called: Cgroups, namespaces, and beyond: what are containers made from? – it reminded me of the Linux Autumn and one of my post-autumnal resolutions: to look at Namespacom more closely!
If your docker environment consists of more than one container, then knowing the docker-compose will make your life easier. Besides, even with one or maybe – two containers it becomes a very helpful tool. What makes using the "bare" docker difficult, so the multiplicity of options and parameters indicated at start-up of the containers in more advanced (than "hello world") implementations, is quite clearly and comfortably simplified by the docker-compose itself. Thanks to that tool we can manage our environment by the defined names/aliases without the necessity to remember (and constantly inserting) given details of implementation. Of course we could do this as well using the clever shell scripts, however yaml (this format of the configuration file is used by the docker-compose) seems more… elegant and elegance is an important thing.
Containers, containers – up to the horizon. Not so long ago (a few years ago) I enjoyed the possibilities and lightness of LXC (I was writing about it - unfortunately only in Polish) and honestly, in my discussions with colleagues I rather ignored Docker. Well, the LXC is quite a nice tool, what more could I want?... But of course I could! Although I am personally unwilling to agree with the statement that either Docker or LXC (which, according to me, depends mostly on the type of task), in the developer’s work Docker seems to be more successful – LXC is, well, "too heavy". Here it is worth mentioning that in case of Docker the difference is mostly in the "attitude". Everything that I came across before Docker (VMWare, ESXi, Xen, Hyper-V, VirtualPC, Qemu, Bochs, VirtualBox and of course LXC) – is some sort of a virtualization (paravirtualization or containerization) of the WHOLE system. Docker focuses on the application without taking care of those parts of the system which the application itself doesn't take care of. Speaking the language of the Linux gurus: the app is started with the process identifier (PID) equal to "1" (normally reserved for the "Init" process, however in the docker container there is no Init process nor any counterpart) – does it change anything? It seems that it changes a lot!
