Container layered deployment method and system

Abstract

The present invention discloses a container hierarchical deployment method and system, the method comprising: each functional single board downloads a version file from a disk of a main control single board, wherein the version file specifically comprises: a basic image file, a public software package, and a feature software package; each functional single board creates a container in layers based on the basic image file, the public software package, and the feature software package.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a container layered deployment method and system. Background Art

[0002] Computer system virtualization has many advantages. One important benefit is to improve the utilization efficiency of hardware resources. Embedded devices also face the choice of virtualization. Compared with traditional virtual machines, Docker has less overhead, faster startup, and better performance. It is currently the most widely used virtualization technology.

[0003] Docker is an open source application container platform, based on which applications can be developed, shipped, and run. Using Linux's namespace technology and Union File System (UnionFs), containers can establish an isolated program running space in user mode, in which specified user-mode programs and dependencies are run, thereby isolating different applications and isolating the impact of exceptions.

[0004] like Figure 1 As shown in the figure, Docker uses a C / S architecture. The client and server can run on the same machine or on different hosts. They interact with each other using RESTful API. The Docker client provides management tools to manage images, containers, networks, data volumes, etc. Users interact with the Docker server (i.e., docker daemon) through these tools. The Docker daemon usually runs in the background of the host machine, waiting to receive messages from the client.

[0005] Docker containers are created and run based on Docker images. Docker images are independently runnable software packages that contain everything needed to run the corresponding application: code, system tools, dependent libraries, configuration files, etc. Figure 2 As shown in the figure, a Docker image consists of a series of layers, which are read-only. Each layer has an ID and metadata. Except for the base image layer, each layer has a pointer to the next layer. Based on the base image, various application images with different functions can be made. UnionFs can be used to integrate various layers into a unified file system to provide a unified perspective. Docker images can be pushed to the image repository for storage, or pulled from the image repository for local use.

[0006] Telecommunications equipment is generally a multi-board embedded computer distributed system. Applying virtualization technology on telecommunications equipment has its own characteristics. Figure 3 As shown, telecommunication equipment generally consists of a control board and multiple function boards. Each board is an independent embedded computer system, which interacts with each other and has close connections. The main control board manages the software versions of each board. When each function board starts, it obtains the version file of the board from the main control board. Each function board runs different services, but the basic software components are the same, and the application software packages are quite different. Therefore, the software packages that need to be deployed in the container have great similarities and differences.

[0007] Traditional container deployment methods such as Figure 4 As shown, a separate Docker image is created for each board in the background and loaded into the main controller's disk through the network.

[0008] service_mu.tar runs on the main control board and contains the functional software on the main control board; service_fu1.tar, service_fu2.tar, ..., service_fuN.tar, respectively contain the software packages of the corresponding functional boards. Each of these images contains the base image, the processes required for each startup, and the libraries and configuration files that the processes depend on, specifically:

[0009] service_mu.tar contains: baseimage, processes started on the master, library files that the processes depend on, and related configuration files.

[0010] service_fu1.tar contains: baseimage, board-independent processes and library files, function board 1-related processes and library files, and configuration files;

[0011] service_fu2tar contains: baseimage, single board-independent processes and library files, function board 2-related processes and library files, and configuration files; ...

[0012] service_fuN.tar contains: baseimage, board-independent processes and library files, function board 3-related processes and library files, and configuration files.

[0013] Deploy a local registry on the main control board, and the registry manages all images in the system. In order to deploy the registry, a registry image file is also required on the main control. After the system is up, load all images into the local warehouse first, and then use the docker push command to put the image into the registry warehouse. Other peripheral boards obtain the image through docker pull.

[0014] The above method of deploying Docker has the following problems:

[0015] 1. There is a lot of redundant content between multiple image files in the same system, which makes the entire version file very large, the version building time is long, and the version file occupies a lot of disk space on the main control board after being loaded into the device.

[0016] 2. Using the registry to manage images consumes a lot of memory resources. Each image needs to be loaded into the memory on the main control first, and then pushed to the registry, which consumes two more copies of memory. When there are many images, the memory of the main control board will be overwhelmed. In addition, when pushing images from the local to the registry, conflict detection of each layer of the image is required, which consumes CPU resources. Summary of the invention

[0017] The embodiment of the present invention provides a container layered deployment method and system, which are used to solve the problem in the prior art that there is a large amount of redundant content between multiple image files in the same system, resulting in a large number of version files, a long version construction time, and a large amount of disk space of the main control board occupied by the version file after it is loaded into the device.

[0018] An embodiment of the present invention provides a container hierarchical deployment method, including:

[0019] Each functional board downloads the version file from the disk of the main control board, wherein the version file specifically includes: basic image file, public software package, and feature software package;

[0020] Each functional board creates containers in layers based on the basic image file, public software package, and feature software package.

[0021] The embodiment of the present invention further provides a container hierarchical deployment system, which is arranged on each functional board and includes:

[0022] The download module is used to download the version file from the disk of the main control board, wherein the version file specifically includes: basic image file, public software package, and feature software package;

[0023] The container creation module is used to create containers in layers based on basic image files, public software packages, and feature software packages.

[0024] By adopting the embodiment of the present invention, the repeated contents between the images are extracted as the common parts, so as to solve the problem in the prior art that there is a large amount of redundant contents between multiple image files in the same system, resulting in a large number of version files, a long version building time, and a large amount of disk space of the main control board occupied after the version files are loaded into the device. The size of the version files is reduced, and the consumption of memory and disk is reduced when the system is running.

[0025] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0027] Figure 1 It is a schematic diagram of docker components in the prior art;

[0028] Figure 2 It is a schematic diagram of mirror image composition in the prior art;

[0029] Figure 3 It is a diagram of the composition of telecommunication equipment in the prior art;

[0030] Figure 4 This is a schematic diagram of the traditional Docker deployment method in the prior art;

[0031] Figure 5 is a flowchart of a container hierarchical deployment method according to an embodiment of the present invention;

[0032] Figure 6 is a schematic diagram of an improved Docker container deployment according to an embodiment of the present invention;

[0033] Figure 7 Schematic diagram of a container hierarchical deployment system in an embodiment of the present invention. DETAILED DESCRIPTION

[0034] In order to solve the problem of the image file being too large in the prior art, an embodiment of the present invention proposes a container layered deployment method. The Docker client receives the base image and the public software package and the feature software package, processes the public software package and the feature software package on the Docker server, integrates them into the base image, and dynamically generates a container instance.

[0035] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0036] Method Embodiment

[0037] According to an embodiment of the present invention, a container hierarchical deployment method is provided. Figure 5 is a flowchart of a container layered deployment method according to an embodiment of the present invention. Figure 5 As shown, the container hierarchical deployment method according to an embodiment of the present invention specifically includes:

[0038] Step 501, each functional board downloads a version file from the disk of the main control board, wherein the version file specifically includes: a basic image file, a public software package, and a feature software package;

[0039] It should be noted that before executing step 501, the following preparations need to be performed:

[0040] First, you need to create a basic image baseimage.tar (i.e. the above-mentioned basic image file) in the background. The basic image only contains the root file system; make the common software of each board into a common tar package or docker image package common.tar (i.e. the above-mentioned public software package), and make the unique software of each board into a common tar package or docker image package boardx.tar (i.e. the above-mentioned feature software package);

[0041] Secondly, the Docker client and Docker server codes need to be modified to support the newly added command options -commontar and -individualtar, and / or -commonimg and -individualimg; the Docker client passes the option parameters to the Docker server. After the code of the Docker server is modified, it can parse the new options, decompress the public software package and the feature software package, and selectively copy the public software and feature software contents to the container read-write layer.

[0042] Finally, deploy the docker client and docker server (also called dockerd) to the target system; and deploy the FTP server on the main control board;

[0043] The version file is loaded into the disk of the main control board through the version management service, wherein the version file specifically includes: basic image file, public software package, and feature software package;

[0044] Step 502: Each functional board creates a container in layers based on the basic image file, the public software package, and the feature software package.

[0045] The specific processing includes the following:

[0046] 1. Each functional board downloads the basic image file, public software package, and feature software package from the disk of the main control board;

[0047] Preferably, in an embodiment of the present invention, in order to solve the problem of memory consumption of registry management images, the registry deploys an FTP server to manage images, and each functional board downloads the basic image file, the public software package, and the feature software package, namely, baseimage.tar, common.tar and boardx.tar, from the disk of the main control board through the FTP service, and then runs the image through the docker API.

[0048] 2. The Docker client on each functional board loads the basic image file into the local image repository, obtains the image ID, and sends the public software package and feature software package to the Docker server through the two options pre-added in the Docker client, and also sends the image ID to the Docker server;

[0049] 3. The Docker server on each functional board parses the public software package and feature software package and decompresses them in whole or in part into the read-write layer of the container, and creates a container based on the image ID and the public software package and feature software package in the read-write layer.

[0050] In an embodiment of the present invention, if the common software package and the feature software package are common tar packages; the two newly added options in the docker client specifically include: options -commontar and -individualtar in the NewCreateCommand function, then step 504 specifically includes the following processing: the docker server on each functional board parses the -commontar and -individualtar parameters through the postContainersCreate function, and decompresses the common software package and the feature software package into the read-write layer of the container through the daemon.create function.

[0051] In an embodiment of the present invention, if the common software package and the feature software package are docker image packages; the two newly added options in the docker client specifically include: options -commonimg and -individualimg in the NewCreateCommand function, then step 504 specifically includes the following processing: the docker server on each functional board parses the -commonimg and -individualimg parameters through the postContainersCreate function, decompresses the common software package and the feature software package to a temporary directory through the daemon.create function, removes the basic image related content, removes the metadata file, and copies the application file to the read-write layer of the container.

[0052] In summary, the improved Docker container deployment is as follows Figure 6 As shown, we can see that the duplicate content between the images is extracted as the common part, which reduces the version size and reduces the memory and disk consumption when the system is running.

[0053] The above technical solution of the embodiment of the present invention is described in detail below.

[0054] Example 1: The public software package and the feature software package are common tarballs.

[0055] 1. Backstage production version

[0056] Step 1. Make a base image file baseimage.tar, make the public software package into a common TAR package common.tar, and make the feature software package into a common TAR package boardx.tar;

[0057] Step 2. Put baseimage.tar, common.tar, boardx.tar and other files in the version into the version file version.set.

[0058] 2. Modify the docker source code

[0059] Step 1. Get the Docker source code from the Docker official website, including the three components of Docker-engine, containerd and runc.

[0060] Step 2. Modify the NewCreateCommand function in the docker client code, which defines the dockercreate command and adds two options -commontar and -individualtar;

[0061] Step 3. Modify the docker daemon code, parse the -commontar and -individualtar parameters in the postContainersCreate function, and decompress common.tar and individual.tar into the read-write layer of the container in the daemon.create function;

[0062] Step 4. Compile the docker source code with the cross tool chain of the target environment in the background to obtain docker and dockerd.

[0063] 3. Target system deployment process

[0064] Step 1. Deploy docker and dockerd to the target system;

[0065] Step 2: Deploy the FTP server on the main control board;

[0066] Step 3, load version.set to the disk of the main control board, and parse baseimage.tar, common.tar, and boardx.tar through the version management service;

[0067] Step 4. Each functional board downloads baseimage.tar, common.tar, and boardx.tar from the main control board via FTP.

[0068] Step 5. Use the docker load command on each function board or the REST API to load baseimage.tar into the local image repository, as follows:

[0069] Docker load -i baseimage.tar

[0070] Step 6. Create a container based on the image ID obtained in step 5.

[0071] Docker run-it baseimageID-commontar common.tar-individualtarboardx.tar

[0072] Example 2: Public and feature packages are Docker images

[0073] 1. Backstage production version

[0074] Step 1. Create a base image file baseimage.tar, use the public software package to create a public image file common.tar, and use the feature software package to create each feature image file boardx.tar;

[0075] Step 2. Put baseimage.tar, common.tar, boardx.tar and other files in the version into the version file version.set.

[0076] 2. Modify the docker source code

[0077] Step 1. Get the Docker source code from the Docker official website, including the three components of Docker-engine, containerd and runc.

[0078] Step 2. Modify the NewCreateCommand function in the docker client code, which defines the dockercreate command and adds two options -commonimg and -individualimg;

[0079] Step 3. Modify the docker daemon code, parse the -commonimg and -individualimg parameters in the postContainersCreate function, decompress common.tar and individual.tar to a temporary directory in the daemon.create function, remove the base image related content, remove the metadata file, and copy the application file to the read-write layer of the container;

[0080] Step 4. Compile the docker source code with the cross tool chain of the target environment in the background to obtain docker and dockerd.

[0081] 3. Target system deployment process

[0082] Step 1. Deploy docker and dockerd to the target system;

[0083] Step 2: Deploy the FTP server on the main control board;

[0084] Step 3, load version.set to the disk of the main control board, and parse baseimage.tar, common.tar, and boardx.tar through the version management process;

[0085] Step 4. Each functional board downloads baseimage.tar, common.tar, and boardx.tar from the main control board via FTP.

[0086] Step 5. Use the docker load command on each function board or the REST API to load baseimage.tar into the local image repository, as follows:

[0087] Docker load -i baseimage.tar

[0088] Step 6. Create a container based on the image ID obtained in step 5.

[0089] Docker run-it baseimageID-commonimg common.tar-individualimgboardx.tar

[0090] In summary, by using the technical solution of the embodiment of the present invention, by sharing the same basic image file and public software package among the single boards, redundancy is greatly reduced, and the version size and disk consumption are reduced. By using the FTP service, the problem of memory consumption by registry management images is solved.

[0091] The technical solution implemented by the present invention can be used in data products, for example, high-end routers and switches can be applied to the technical solution of the embodiment of the present invention. The technical solution of the embodiment of the present invention can also be applied to the fields of computer virtualization technology and Internet technology.

[0092] Device Embodiment

[0093] According to an embodiment of the present invention, a container hierarchical deployment system is provided, which is arranged on each functional board. Figure 7 Schematic diagram of a container hierarchical deployment system according to an embodiment of the present invention, which specifically includes:

[0094] The download module 70 is used to download the version file from the disk of the main control board, wherein the version file specifically includes: a basic image file, a public software package, and a feature software package;

[0095] It should be noted that before performing layered container deployment, the following preparations are required:

[0096] First, you need to create a basic image baseimage.tar (i.e. the above-mentioned basic image file) through the background. The basic image only contains the root file system; make the common software of each board into a common tar package or docker image package common.tar (i.e. the above-mentioned public software package), and make the unique software of each board into a common tar package or docker image package boardx.tar (i.e. the above-mentioned feature software package);

[0097] Secondly, the Docker client and Docker server codes need to be modified to support the newly added command options -commontar and -individualtar, and / or -commonimg and -individualimg; the Docker client passes the option parameters to the Docker server. After the code of the Docker server is modified, it can parse the new options, decompress the public software package and the feature software package, and selectively copy the public software and feature software contents to the container read-write layer.

[0098] Finally, deploy the docker client and docker server (also called dockerd) to the target system; and deploy the FTP server on the main control board;

[0099] The version management service module loads the version file into the disk of the main control board, wherein the version file specifically includes: a basic image file, a public software package, and a feature software package;

[0100] The download module 70 is specifically used to download basic image files, public software packages, and feature software packages from the disk of the main control board; specifically, the basic image files, public software packages, and feature software packages can be downloaded from the disk of the main control board through the FTP service and sent to the corresponding functional board.

[0101] The container creation module 72 is used to create containers in layers based on the basic image file, the public software package and the feature software package.

[0102] The container creation module 72 specifically includes:

[0103] The docker client is used to load the base image file into the local image repository, obtain the image ID, and send the public package and feature package to the docker server through two options pre-added in the docker client, and also send the image ID to the docker server;

[0104] The docker server is used to parse the public software package and feature software package and decompress them in whole or in part into the read-write layer of the container, and create a container based on the image ID and the public software package and feature software package in the read-write layer. The docker server is specifically used to: parse the -commontar and -individualtar parameters through the postContainersCreate function, and decompress the public software package and feature software package into the read-write layer of the container through the daemon.create function.

[0105] That is to say, the docker client loads the basic image file into the local image repository, obtains the image ID, and sends the public software package and feature software package to the docker server through two options pre-added in the docker client, and also sends the image ID to the docker server; the docker server parses the public software package and feature software package and decompresses them in whole or in part into the read-write layer of the container, and creates a container based on the image ID and the public software package and feature software package in the read-write layer.

[0106] Preferably, in the embodiment of the present invention, it also includes:

[0107] In the embodiment of the present invention, the common software package and the characteristic software package can be common tar packages; thus, the two newly added options in the docker client specifically include: options -commontar and -individualtar in the NewCreateCommand function. In the above case, each functional board 74 is specifically used for: the docker server thereon parses the -commontar and -individualtar parameters through the postContainersCreate function, and decompresses the common software package and the characteristic software package into the read-write layer of the container through the daemon.create function.

[0108] In another embodiment, the common software package and the characteristic software package can be docker image packages; thus, the two newly added options in the docker client specifically include: options -commonimg and -individualimg in the NewCreateCommand function. In the above case, each functional board 74 is specifically used for: the docker server thereon parses the -commonimg and -individualimg parameters through the postContainersCreate function, decompresses the common software package and the characteristic software package to a temporary directory through the daemon.create function, removes the basic image related content, removes the metadata file, and copies the application file to the read-write layer of the container.

[0109] In summary, by using the technical solution of the embodiment of the present invention, by sharing the same basic image file and public software package for each board, redundancy is greatly reduced, and the version size and disk consumption are reduced. By using the FTP service, the problem of memory consumption of registry management images is solved.

[0110] Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order than here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present invention is not limited to any specific combination of hardware and software.

[0111] The above are only preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A container layered deployment method, characterized in that: include: Each functional board downloads a version file from the disk of the main control board, wherein the version file specifically includes: a basic image file, a public software package, and a feature software package; Each functional board creates a container in layers based on the basic image file, the public software package and the feature software package; The layered creation of containers by each functional board based on the basic image file, the public software package and the feature software package specifically includes: The docker client on each functional board loads the basic image file into the local image repository, obtains the image ID, and sends the public software package and the feature software package to the docker server through two options pre-added in the docker client, and also sends the image ID to the docker server; The docker server on each functional board parses the public software package and the feature software package and decompresses them in whole or in part into the read-write layer of the container, and creates a container according to the image ID and the public software package and the feature software package in the read-write layer.

2. The method according to claim 1, characterized in that Each functional board downloads the basic image file, the public software package, and the feature software package from the disk of the main control board, specifically including: Each functional board downloads the basic image file, the public software package, and the characteristic software package from the disk of the main control board through the FTP service.

3. The method according to claim 1, characterized in that The public software package and the feature software package are common tarballs; The two new options added to the docker client include: options -commontar and -individualtar in the NewCreateCommand function.

4. The method according to claim 3, characterized in that The Docker server on each functional board parses the public software package and the feature software package and decompresses them in whole or in part into the read-write layer of the container, specifically including: The docker server on each functional board parses the -commontar and -individualtar parameters through the postContainersCreate function, and decompresses the common software package and the characteristic software package into the read-write layer of the container through the daemon.create function.

5. The method according to claim 1, characterized in that The public software package and the feature software package are Docker image packages; The two new options added to the docker client specifically include: options -commonimg and -individualimg in the NewCreateCommand function.

6. The method according to claim 5, characterized in that The Docker server on each functional board parses the public software package and the feature software package and decompresses them in whole or in part into the read-write layer of the container, specifically including: The docker server on each functional board parses the -commonimg and -individualimg parameters through the postContainersCreate function, decompresses the public software package and the feature software package to a temporary directory through the daemon.create function, removes the base image related content, removes the metadata file, and copies the application file to the read-write layer of the container.

7. A container hierarchical deployment system, characterized in that: Set up on each functional board, the system specifically includes: A download module, used to download version files from the disk of the main control board, wherein the version files specifically include: basic image files, public software packages, and feature software packages; A container creation module, used to create a container in layers based on the basic image file, the public software package and the feature software package; The container creation module specifically includes: The docker client is used to load the basic image file into the local image repository, obtain the image ID, and send the public software package and the feature software package to the docker server through two options pre-added in the docker client, and also send the image ID to the docker server; The docker server is used to parse the public software package and the feature software package and decompress them in whole or in part into the read-write layer of the container, and create a container according to the image ID and the public software package and the feature software package in the read-write layer.

8. The system according to claim 7, characterized in that The download module is specifically used to download the basic image file, the public software package, and the characteristic software package from the disk of the main control board through the FTP service, and send them to the corresponding functional board.

9. The system according to claim 7, characterized in that The public software package and the feature software package are common tarballs; The two new options added to the Docker client specifically include: options -commontar and -individualtar in the NewCreateCommand function; The docker server is specifically used for: parsing -commontar and -individualtar parameters through the postContainersCreate function, and decompressing the common software package and the characteristic software package into the read-write layer of the container through the daemon.create function.

10. The system according to claim 7, characterized in that The public software package and the feature software package are Docker image packages; The two new options added to the docker client specifically include: options -commonimg and -individualimg in the NewCreateCommand function; The docker server is specifically used to: parse -commonimg and -individualimg parameters through the postContainersCreate function, decompress the public software package and the feature software package to a temporary directory through the daemon.create function, remove the base image related content, remove the metadata file, and copy the application file to the read-write layer of the container.

Images