Shulou(Shulou.com)06/02 Report--

Virtualization and containerization are two inevitable problems of project cloud. Because virtualization is a pure platform operation, a project running on the linux operating system can support virtualization without any modification. If the project is to support containerization, it needs to do a lot of meticulous transformation work. Containerization also has obvious advantages over virtualization, running on bare metal with high performance, starting and stopping containers in seconds, not to mention the consistent environment of development, testing and deployment (DevOps concept), as well as the ability of micro-services mentioned in the previous article. You can also find various articles to introduce the knowledge of Docker, so we won't repeat them here. Below we will introduce the problems and solutions that containerization transformation will face according to the actual situation of the project.

Containerization of a large project with hundreds of thousands of lines of C++ code and dozens of applications. How to modify the original code to a minimum, even the code does not need to be modified. How to be quiet, not even let the business programmer find out. How to minimize the volume of the business image. How to quickly create a business image. These have been problems that have plagued us for a long time. When classifying containers, if you need to adjust the organization and architecture of the code, it will be a disaster for projects with hundreds of thousands of lines. After the transformation, if the development model changes too dramatically, it will inevitably face dozens or hundreds of business programmers to re-learn to adapt to the process, the cost is staggering. The size of the business image directly affects whether it is convenient to update the container on site, especially when the project is overseas and the network speed is not very fast. Automatic and rapid mirror production is the key to agile development.

First, how to start

How to move a project running on linux to a container is usually the first problem encountered. Find a basic image with gcc compiler and linux operating system online, based on which you can first make a build image of compilation and CI checks (code checks, running unit tests, etc.). Use the build image for compilation and CI checking, then make a running image based on the basic image, and copy the compiled library and executable program into it (via Dockerfile). Such a simplest mirror image is made.

The business image made by the above method can run, but there are two problems: the production time is very long (our project needs an hour), and the business layer of the image is very large (our project has 1 G). The two problems are not particularly serious, but it is a troublesome problem if the project is put into commercial use.

2. Container layering

The concept of container layering is the core concept of Docker, which supports that each container can "inherit" from another container. Inheritance here should be the same concept as inheritance in object-oriented. In addition to the benefits of "inheritance", when the underlying image changes, you don't need to update the upper image, so you can update a lot less. It's really wonderful. I don't think object-oriented inheritance is so useful! Affected by this feature, we propose a separate layer of the third-party library used by the project. The production process is correspondingly changed to the figure below.

Although the process is one more step, but the effect is also immediate, the production time of the business layer has been shortened from 1 hour to 12 minutes, and the size has also become about 100m.

III. Classification of business containers

In the recommendations of Docker best practices, it is recommended that a container should run only one program, or one type of program. As before, it must be inappropriate for a container to run dozens of processes. Clearly classified containers are also easy to manage and perform various operations. At the same time, in the best practices of microservices, it is recommended that the code of the project be divided into microservices. The code for each microservice is maintained by a different team and is independent. Let's not discuss the advantages and disadvantages of this approach for the time being. The original project was a large project with hundreds of thousands of lines and dozens of programs, with dozens of developers and countless public modules. it is also common for each module to refer to each other, and each program is composed of a different number of modules. If we classify the business of Docker as suggested above, it will undoubtedly bring great changes to the project, and it will involve a major adjustment of the organizational structure, which is almost an impossible task. So how to do this can not only classify the containers, but also keep the original development model unchanged. Sometimes being unaware of change is the best way to advance a new technology.

The method is actually very simple. There is a script called docker-entrypoint.sh in the container to manage which processes to start after the container starts. We have made a unified image of the project above. When classifying, we just need to modify different docker-entrypoint.sh according to different types of containers to start different types of processes. To cooperate with the setting of different environment variables, different profiles, and so on. Of course, it's all easy!

Summary

The above is the whole content of this article. I hope the content of this article has a certain reference and learning value for everyone's study or work. Thank you for your support. If you want to know more about it, please see the relevant links below.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.