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

This article introduces the relevant knowledge of "the method of containerization transformation of large-scale Docker projects". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

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 there is one more step in the process, 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!

This is the end of the content of "the method of containerization transformation of large-scale Docker projects". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.