Docker: is it customary to install in production?

Question

Software Deployment

When studying docker, 2 questions arose:

1. Is it customary to install docker in production? If not, why and how is the deployment issue solved, etc.?

2. If you install docker on a dev (prod) environment, do I understand correctly that we install docker on top of any version of Linux (centos, ubuntu) and run our containers on top?

And how is the issue with mounting the config and log directories solved? Is it better to place them in the project directory, or is it better to place them in the appropriate directories of the base OS? For example, for a container with nginx, should its configs be mounted from /etc/nginx/..conf?

Answer 1

1. accepted. If someone starts shushing you for this, that's their problem, and we have free morals!
2. correct.
Mounting is different. How convenient. Options:

• in the project, the folder /dockerunder it in a subfolder contains /docker/nginxnginx configs that are bound into the container one by one, or by the entire subfolder. It is convenient if you want to edit configs in a live way;
  
• in the container during its build, instructions in it Dockerfile, files from the folder are copied ;
  
• a ready-assembled image arrives , from which a working container rises, without worrying about the location of the configs and some settings.
  

The logs are sent to the Stdout of the container and stored by Docker. View tail:docker logs --tail 50 имя_контейнера

Answer 2

The standard prod now looks like this: a cluster of servers, on top of which a cloud is stretched, in which containers are launched. The final product, accordingly, works like in any Google cloud - it starts up stupidly. The rest is not your problem.
ps
Although, on the other hand, bearded guys are very common, who, of course, on Windows 10 Enterprise edition, run the WMVare Workstation virtual machine, in which they install the docker in which they run your container. But this is already their problem, that everything is done through one place.

Answer 3

I agree with Saboteur - it all depends.

When learning docker

- I advise you to proceed not from the tools, but from the requirements of the project.
It is important that the program runs quickly, reliably, with a reproducible configuration and deployment. This can be achieved on hardware (bare metal), virtual machines, containers, and so on. (serverless, for example).

Answer 4

First, make sure you really need it. Many stick it in every hole without even thinking.

Answer 5

yes, no, I don't know - all three answers are correct
. Automation of machine settings is possible with your own scripts or, for example, ansible. Cloud services represent payment for the use of resources, which means that it may be justified to divide their services into provider virtual machines (my opinion is no, any ready-made cloud solution will be more expensive than its own, with the exception of short-term use and maintenance of rare habra effects).
Docker is just another isolation and autotuning tool, plus if you remember, docker for linux is based on lxc, which means that almost any hosting can implement their virtual machines with it.
In the end, homemade virtual machine tools can degenerate into a copy of docker, so it all depends on how deep you need to get into this hole.

Answer 6

A good way to use docker on prod is kubernetes. But in general, not required.
It is desirable to write logs to stderr of the container.
Mounting config directories is not best practice. But if you really want to, and in your particular case it is convenient - then why not?

Answer 7

What does "accepted" mean. It depends on the project and your preferences.
There are no obvious generally accepted solutions, since there are few identical projects.
If you have a single application, then you can simply set up a server for it, both without docker and with docker.
If there are a lot of components, then a pure docker will already be small and difficult, you need to use an orchestrator (kubernetes or openshift). But you can also just set up virtual machines / pieces of iron.
Docker imposes its moments, but makes it easier to support for the future.