Docker. Why and how
There are many wonderful publications for those who already use docker. There are good articles for those who want to learn it. I write for those who not only do not know what a docker is, but also not sure whether he should know this.
I deliberately omit some technical details, and some where I allow simplifications. If you see that docker is what you need, you can easily find more complete and accurate information in other articles.
I will begin by describing a few typical problems.
The first problem is how to transfer the product to the customer.
')
Suppose you have a server project that you have completed and now you need to transfer it to the user. You prepare a lot of different files, scripts and write installation instructions. And then spend a lot of time on solving client problems like: “nothing works for me”, “your script fell in the middle - what to do now”, “I mixed up the steps in the instructions and now I can’t go further”, etc.
Everything is aggravated if the product is replicated and instead of one customer you have hundreds or thousands of buyers. And it becomes even more difficult if we recall the need to install new versions of the product.
The second problem is replicability. Let you need to raise 5 (or 50) almost identical servers. Doing it manually for a long time is expensive and error prone.
Finally, the third problem is reusability. Suppose you have a department that makes browser games. Suppose you already have several. And they all use the same technology stack (for example, java-tomcat-nginx-postgre). But at the same time, in order to install a new game, you have to re-prepare almost the same configuration on a new server. You can't just say and say - “I want a server, like wanderers in the game, but only with a different web archive”
As usual, these problems are solved.
I have already mentioned the first approach - you can write a script that will install everything you need and run it on all the necessary servers. (The script can be either a simple sh file, or something complex created using special tools).
The disadvantages of this approach are fragility and instability to errors. No matter how well the script is written, sooner or later it will fall on some machine. And after this crash, the car will actually be “spoiled” - it’s just that you’ll not be able to “roll back” the actions that the script managed to perform.
The second approach is the use of cloud services. You manually install everything you need on a virtual server. Then make it an image. And then clone it as many times as you need.
There are two drawbacks. First, vendor-lock-in. You can not run your solution outside the selected cloud, which is not always convenient and can lead to losses of clients who disagree with this choice. Secondly, the clouds are slow. Virtual (and even “bare-metal”) servers provided by clouds today are much inferior in performance to dedicated servers.
The third approach is the use of virtual machines. There are also disadvantages here:
Size - it is not always convenient to download the image of a virtual machine, which can be quite large. At the same time, any change within the virtual machine image requires you to download the entire image again.
Complicated management of server resource sharing — not all virtual machines support shared memory or CPU sharing. Those that support require fine tuning.
And here comes the docker, in which
Like a virtual machine, the docker runs its processes in its own pre-configured operating system. But at the same time, all the processes of the docker run on the physical host server, dividing all the processors and all the available memory with all the other processes running on the host system. The docker approach is midway between running everything on a physical server and full virtualization offered by virtual machines. This approach is called containerization.
First a docker image (or image) is created. It is created using the script that you write for this.
Images are inherited and, usually, to create our first image, we take the finished image and inherit from it.
Most often, we take an image that contains one or another version of linux. The script then starts something like this:
RUN , .
, COPY.
:
. ,
— . — : , Dockerfile docker build, docker image.
- , . image. .
docker image , . image – «», container «», .
— image, . , image. . , web- .
«» . , . , , . .
— . ? , , — , .
. 100500 , , . union file system.
Union file system (layers). . . , , .
. , , , «» .
, docker image . , . 100 , Ubuntu Ubuntu 100 . ?
, . , docker registry. Docker registry . ( ) docker registry. , . , , .
, , , registry , .
, registry - , , .
Docker registry open source , .
, , . . , , .
, . docker compose. , , ( A 5432 B)
:
, , «».
I deliberately omit some technical details, and some where I allow simplifications. If you see that docker is what you need, you can easily find more complete and accurate information in other articles.
I will begin by describing a few typical problems.
Problems
The first problem is how to transfer the product to the customer.
')
Suppose you have a server project that you have completed and now you need to transfer it to the user. You prepare a lot of different files, scripts and write installation instructions. And then spend a lot of time on solving client problems like: “nothing works for me”, “your script fell in the middle - what to do now”, “I mixed up the steps in the instructions and now I can’t go further”, etc.
Everything is aggravated if the product is replicated and instead of one customer you have hundreds or thousands of buyers. And it becomes even more difficult if we recall the need to install new versions of the product.
The second problem is replicability. Let you need to raise 5 (or 50) almost identical servers. Doing it manually for a long time is expensive and error prone.
Finally, the third problem is reusability. Suppose you have a department that makes browser games. Suppose you already have several. And they all use the same technology stack (for example, java-tomcat-nginx-postgre). But at the same time, in order to install a new game, you have to re-prepare almost the same configuration on a new server. You can't just say and say - “I want a server, like wanderers in the game, but only with a different web archive”
Common solutions
As usual, these problems are solved.
Installation script
I have already mentioned the first approach - you can write a script that will install everything you need and run it on all the necessary servers. (The script can be either a simple sh file, or something complex created using special tools).
The disadvantages of this approach are fragility and instability to errors. No matter how well the script is written, sooner or later it will fall on some machine. And after this crash, the car will actually be “spoiled” - it’s just that you’ll not be able to “roll back” the actions that the script managed to perform.
Cloud Services
The second approach is the use of cloud services. You manually install everything you need on a virtual server. Then make it an image. And then clone it as many times as you need.
There are two drawbacks. First, vendor-lock-in. You can not run your solution outside the selected cloud, which is not always convenient and can lead to losses of clients who disagree with this choice. Secondly, the clouds are slow. Virtual (and even “bare-metal”) servers provided by clouds today are much inferior in performance to dedicated servers.
Virtual machines
The third approach is the use of virtual machines. There are also disadvantages here:
Size - it is not always convenient to download the image of a virtual machine, which can be quite large. At the same time, any change within the virtual machine image requires you to download the entire image again.
Complicated management of server resource sharing — not all virtual machines support shared memory or CPU sharing. Those that support require fine tuning.
Docker Approach - Containerization
And here comes the docker, in which
- there is a controlled environment (like in virtual machines)
- there is an effective server resource management
- and no vendor lock-in
Like a virtual machine, the docker runs its processes in its own pre-configured operating system. But at the same time, all the processes of the docker run on the physical host server, dividing all the processors and all the available memory with all the other processes running on the host system. The docker approach is midway between running everything on a physical server and full virtualization offered by virtual machines. This approach is called containerization.
How docker works
Image creation
First a docker image (or image) is created. It is created using the script that you write for this.
Images are inherited and, usually, to create our first image, we take the finished image and inherit from it.
Most often, we take an image that contains one or another version of linux. The script then starts something like this:
FROM ubuntu:16.04RUN , .
RUN apt-get install -y mc midnight commander., COPY.
:
COPY mzoo.war /opt/tomcat/webapps/ROOT.war. ,
USER roman roman. ENTRYPOINT [“/opt/tomcat/catalina.sh”] , .— . — : , Dockerfile docker build, docker image.
- , . image. .
docker image , . image – «», container «», .
— image, . , image. . , web- .
«» . , . , , . .
Union filesystem
— . ? , , — , .
. 100500 , , . union file system.
Union file system (layers). . . , , .
. , , , «» .
Container registry
, docker image . , . 100 , Ubuntu Ubuntu 100 . ?
, . , docker registry. Docker registry . ( ) docker registry. , . , , .
, , , registry , .
, registry - , , .
Docker registry open source , .
, , . . , , .
, . docker compose. , , ( A 5432 B)
:
, , «».
Source: https://habr.com/ru/post/309556/
All Articles