Launching an environment, and isolating the components of this container with the components of my host, this is what Docker knows how to do! It does it very well and remains an alternative much better than the VMs (for equivalent use).
- Ok, I understand better. In a virtual machine, you allocate “physically” RAM and storage, such as 2GB of RAM and 20GB. While on Docker, everything is shared with the Linux host that uses Docker. That’s why everything is faster, I’m wrong?
It’s exactly that! If you already have a little experience with virtual machines ( Virtual Box or even with Vagrant ), you will see that Docker is much, much faster! Besides, if Docker looks like a VM from afar, here’s a point that should convince you that it is not one. Docker can be installed on a Linux only and can instantiate from Linux only. Convinced?
In this way, all developers, whatever their platform, are able to work on the same application, with a similar environment.
Ok, if I summarize: Docker only installs on Linux, so to run it on Mac or Windows, you need a VM that hosts it. Is not it a little bit the snake that has died its tail?
Yes, however, boot2docker and other available VMs are not intended to work in production, but only for developers wishing to place themselves under the exact conditions as the production servers.
As part of a production, the use of a Linux environment (and therefore not a Docker) is HIGHLY advised.
Attention, Docker requires a version 3.8 of the Kernel (compatible therefore for a Debian 8 or Ubuntu) at least. For the servers that are currently on Debian 7 (so with a kernel in version 3.2), the team in charge of development Docker has implemented a fallback to install a newer kernel without having to upgrade to Debian 8 called Jessie).
Docker, soon available natively on Windows.
Now, Docker is only available for Linux but a recent partnership between Docker Inc. and Microsoft provides for Windows container development. These will not be compatible with Linux but will meet the same need.
Wanadev, wishes to develop a Symfony project as they know how to do. Their team is made up of two people.
- Manu is an old man of old. He, Debian 7, is perfect. In addition, it is ISO with production servers.
- Baptiste is a true hippie. It features the latest exotic distribution. He, PHP, is the latest version or nothing. However, it can generate code that cannot run correctly with an older version, such as that of Manu.
Until today, we all said, “let’s do unit tests”. Yes, this answered a good part of our problems (on the condition of doing good unit tests).
In fact, it is a problem that two developers do not work on the same environments … So, thanks to Docker, we can make sure that Manu and Baptiste work on the same Linux versions without fear of problems compatibility between their codes respective?
Exactly! In this case, the simplest is to set up a Dockerfile, “conductor” document, which will allow Manu and Baptiste to mount a similar image. By being smart, this Dockerfile will be modeled on the elements present in production. Therefore, Manu and Baptiste, in addition to working on an identical environment, will be in an environment similar to that of production!
Above, I was talking about a particular version of PHP. It is obvious that you will not forget to install PHP on your production server, but maybe the configuration of your PHP–FPM will be slightly different. Perhaps you need an additional library like Imagick and its PHP extension. Maybe you need a Postfix to send emails. As many details as you might forget when you mount your production server.To limit these errors, would it not be simpler to deploy the container (s) to run your application? In this way, rather than pulling source code and performing some deployment scripts, you could deploy a packaged consistent packet matching an application.
We often talk about an application in the world of the web, a ” Symfony ” application, would not be much without a front end like Nginx or Apache2, an engine like FPM or HHVM, and a database.
If I can run multiple Dockers on my machine, does that mean I can multiply the configurations as I wish?
That’s quite right! In this way, you can build self-contained and isolated environments. The good old project SPIP in 5.3 could rub shoulders on the same server the last project Symfony with PHP 5.5. Cool not?