CN106936636A - A kind of implementation method of the cloud computing test platform of rapid deployment containerization - Google Patents

Abstract

The present invention provides a method for quickly deploying a containerized cloud computing test platform, comprising the following steps: S1, using the virtual machine description file of Vagrant to configure the basic information of the deployment node, and running the vagrant up command to pull the pre-loaded information from the public warehouse. installed Linux operating system, and run in Virtual Box; install Docker in the deployment node and use Docker to create a private container warehouse; use Kolla to make container image files for each service of Openstack, and save them in the private container warehouse; S2, traverse Execute the process of step S1 to deploy the container image file to the target node. In the present invention, the deployment steps of the cloud computing test platform are simplified, the deployment efficiency and the flexibility of the deployment process are improved, and the compatibility between Openstack and different versions of Linux operating systems released by different manufacturers is improved. Perform flexible expansion.

Description

A method for quickly deploying a containerized cloud computing test platform

technical field

The invention relates to the technical field of cloud computing, in particular to an implementation method for rapidly deploying a containerized cloud computing test platform.

Background technique

Private Clouds are built for the sole use of one customer, thus providing the most effective control over data, security and quality of service. The company owns the infrastructure and can control how applications are deployed on this infrastructure. Private clouds can be deployed inside the firewall of an enterprise data center, or they can be deployed in a secure hosting location, and the core attribute of a private cloud is dedicated resources.

With the rapid development of cloud computing technology, more and more companies are trying to deploy their own cloud computing platform and perform functional verification and testing on it. In addition, there are also a large number of development testers who need to quickly deploy a cloud computing platform for development. test.

As a very mainstream private cloud platform at present, Openstack has been applied internally by many organizations to improve the efficiency of their internal IT infrastructure operation and management. Openstack deployment has always been a cumbersome and error-prone but very important step, and it is the pre-stage of a component private cloud. In the prior art, there are many solutions for deploying Openstack, but due to the complexity of Openstack itself and the wide variety of deployment environments, it is very difficult to deploy.

At present, the rapid deployment method of Openstack-based private cloud is usually based on the configuration management framework Puppet to manage software installation, configuration file modification and resource dependency processing of Openstack components. The defect of this prior art: there are too many configuration options and many configurations need to be adjusted manually according to the difference of system environment, thereby causing the probability of error to increase greatly; meanwhile, due to this prior art, the Linux operating system cannot be installed automatically. At present, the Linux operating system that is compatible and runs Openstack needs to be pre-installed, and relevant information (such as host name, IP address) is written into the configuration file, so that it can be read when deploying Openstack, which still needs to be deployed during the process The operator manually participates in the intervention and adjusts the configuration options, so the probability of error will also be greatly increased.

The Chinese invention patent application with the publication number CN104580519A discloses "a method for rapidly deploying an openstack cloud computing platform". The main technical route of this prior art is to make various services and components of the Linux operating system and the Openstack platform into a mirror template, and then start by PXE, DHCP and TFTP. The defect of this prior art: the operation of the configuration process is too complicated; In addition, when a certain node in the deployed Openstack needs to be reconfigured, it is necessary to redeploy the image template after remaking, which causes this prior art to be unfavorable to the later stage maintenance and performance upgrade defects; more importantly, this prior art cannot adapt to the different versions of the Linux operating system released by different manufacturers, Openstack is seriously coupled with the different versions of the Linux operating system released by different manufacturers, so this prior art There is also the problem of poor compatibility between Openstack and different versions of Linux operating systems released by different manufacturers.

In view of this, it is necessary to improve the deployment method based on the Openstack cloud platform in the prior art to solve the above problems.

Contents of the invention

The purpose of the present invention is to disclose a method for quickly deploying a containerized cloud computing test platform, which is used to simplify the deployment steps of the cloud computing test platform, improve deployment efficiency and flexibility of the deployment process, and improve the difference between Openstack and different manufacturers. version of the Linux operating system compatibility.

To achieve the above object, the present invention provides a method for quickly deploying a containerized cloud computing test platform, comprising the following steps:

S1. Use Vagrant's virtual machine description file to configure the basic information of the deployment node, run the vagrant up command to pull the pre-installed Linux operating system from the public warehouse, and run it in Virtual Box; install Docker on the deployment node and use Docker to create Private container warehouse; use Kolla to make container image files of Openstack services and save them in the private container warehouse;

S2. Go through the process of executing step S1, so as to deploy the container image file to the target node.

As a further improvement of the present invention, the "install Docker on the deployment node and use Docker to create a private container warehouse" in step S1 also includes: after configuring the configuration file of ansible, add the virtual machine description file calling ansible command, after the deployment node is running normally, Docker is automatically installed by calling ansible.

As a further improvement of the present invention, an operation of modifying the configuration option Config.vm.box in the virtual machine description file in the deployment node and the target node is also included.

As a further improvement of the present invention, the cloud computing test platform is a containerized Openstack cloud computing test platform.

As a further improvement of the present invention, the cloud computing test platform runs in a physical host computer.

As a further improvement of the present invention, the step S2 also includes performing a manual or automatic clearing operation on the residual Docker volume in the target node and the container on which the residual Docker volume is mounted when the previous container image file deployment operation fails, And redeploy the container image file to the target node.

Compared with the prior art, the beneficial effects of the present invention are: through the present invention, the deployment steps of the cloud computing test platform are simplified, the deployment efficiency and the flexibility of the deployment process are improved, and the compatibility between Openstack and different versions released by different manufacturers is improved. Linux operating system compatibility.

Description of drawings

Fig. 1 is based on the topological diagram of a kind of rapid deployment containerized cloud computing test platform shown in the present invention;

Fig. 2 is the deployment process flowchart of the first stage in the realization method of a kind of rapid deployment containerized cloud computing test platform shown in the present invention;

FIG. 3 is a flow chart of the deployment process in the second stage of a method for quickly deploying a containerized cloud computing test platform shown in the present invention.

detailed description

The present invention will be described in detail below in conjunction with the implementations shown in the drawings, but it should be noted that these implementations are not limitations of the present invention, and those of ordinary skill in the art based on the functions, methods, or structural changes made by these implementations Equivalent transformations or substitutions all fall within the protection scope of the present invention.

Before elaborating the present invention in detail, the main technical terms involved in the description are defined and explained as follows:

1. OpenStack: An open source-based cloud computing management platform project, the goal is to provide a cloud computing management platform that is simple to implement, scalable on a large scale, rich, and unified in standards.

2. VirtualBox: Open source virtual machine software.

3. Vagrant: A cross-platform virtual machine construction tool that can describe a virtual machine through a configuration file, and then call the underlying VirtualBox to create a virtual machine.

4. Ansible: Automated deployment operation and maintenance tool, features: distributed, no client, lightweight.

5. Kolla: A project to containerize various services of Openstack, including two parts: making container image files corresponding to each service of Openstack; using ansible to deploy container image files.

6. Docker: An open source application container engine that allows developers to package their applications and dependencies into a portable container, and then publish it to any popular Linux operating system computer, and can also implement virtualization. Containers use a sandbox mechanism completely, and there will be no interfaces between them.

7. Public warehouse: a warehouse built by Docker and facing all users.

Next, a detailed description will be given of a specific implementation method of a fast-deploying containerized cloud computing platform of the present invention.

Referring to FIG. 1 , multiple virtual machines (VMs) are created on one physical host machine 10, and one of the virtual machines is used as the deployment node 4, and the other virtual machines are used as target nodes. Deployment node 4 couples and connects multiple target nodes (i.e. target node 1, target node 2, target node 3...target node N in Fig. 1) through the management network 20, and is used to store the container image files of each service of Openstack; Virtual machines are used as target nodes for deployment, and these target nodes are used as functional nodes of the final deployed Openstack. Wherein, the target node N generally refers to any functional node among the above-mentioned target nodes 1-3.

This embodiment shows a method for quickly deploying a containerized cloud computing test platform. The deployed cloud computing test platform runs on a physical host machine 10, which has the beneficial effect that the deployment process is not affected by the outside world.

Referring to FIG. 1 , FIG. 1 shows a plurality of target nodes, which are target node 1 (as a control node), target node 2 (as a computing node) and target node 3 (as a network node). In addition, the number of target nodes can be increased correspondingly according to needs and hardware configuration, and different types of target nodes can be defined. When deploying Openstack, deploy the container image files of each service of Openstack on deployment node 4 to each target node according to the direction of the arrow in Figure 1, so as to complete the deployment of the entire OpenStack architecture-based cloud computing test platform.

During the deployment process, you can use the kolla-ansible prechecks command to pre-check the deployment environment to reduce the risk of deployment failure; in addition, once an error occurs during the deployment process, you can use kolla-ansibledestroy --yes-i-really-really-mean- it command to clear the residual data in the deployment process. When solving the error problem and redeploying, ensure that the physical host 10 has a clean deployment environment, which ensures the idempotence of the deployment process and can greatly reduce the The probability of deployment failure.

In this embodiment, the implementation method of the rapid deployment of the containerized cloud computing test platform mainly includes two stages.

As shown in Figure 2, the first stage: making container image files for each service of OpenStack, specifically as shown in the following steps 1 to 3.

Step 1: Prepare to deploy nodes.

Use Vagrant's virtual machine description file (Vagrantfile) to configure the basic information of deploying node 4. The main code is as follows:

Then run the vagrant up command. Vagrant pulls pre-installed Linux OS from its public repository. In order to simplify the description, in this specification, the Linux operating system is selected as the Linux operating system whose version number is CentOS7 (hereinafter referred to as "CentOS7"). Run CentOS7 in Virtual Box, and set the name of CentOS7 in Virtual Box at the same time. After CentOS7 runs, it will also perform the operation of automatically configuring the host name and IP address.

You can determine whether this step has been completed correctly by checking whether you can SSH into the deployment node 4 and verify whether the IP address and host name are correct; if there is an error, you can first check the virtual machine description file (Vagrantfile) of the deployment node 4 and check the current The connectivity between the physical host machine 10 and the external network is solved. Specifically, the TTL of ping 114.114.114.114 (the address of the public DNS server) can be used to judge the connectivity with the external network. As long as there is a returned data packet and there is no packet loss, it can be determined that the physical host machine 10 and the external network have been connected. establish connection.

Step 2: Install Docker on the deployment node, and use Docker to create a private container warehouse (Docker registry).

Preferably, in this embodiment, the installation of Docker in the deployment node and use of Docker to create a private container warehouse also includes: after the configuration file of ansible is configured, adding a command to call ansible in the virtual machine description file (Vagrantfile) , after the deployment node runs normally, Docker is automatically installed by calling ansible. So that the content of installing Docker is written in the configuration file of ansible. The main code for this step 2 is shown below.

Among them, the content of playbook.yml is as follows:

Then create a private container warehouse (Docker registry), the main code of the command corresponding to the creation operation is as follows:

mkdir -p /root/image_repo

docker run -d -p 4000:5000 -v /root/image_repo:/var/lib/registry --restart=always --name registry registry:2

At the same time, in this embodiment, it is also necessary to configure the Docker daemon process so that it can use the private container warehouse just created by adding startup parameters in /lib/systemd/system/docker.service.

ExecStart=/usr/bin/dockerd --insecure-registry 192.168.0.10:4000...

Then restart Docker, the code is: systemctl restart docker.

This step can be verified by pushing any container image file to the newly created private container repository; if there is an error, you can check the Docker configuration and the configuration of the private container repository to see if the private container is enabled correctly storehouse.

Step 3: Use Kolla on deployment node 4 to make container image files for each service of Openstack and save them in a private container repository.

Specifically, first download and install Kolla, run the following commands to make all images and push them to the private container repository:

kolla-build --type source --registry 192.168.0.10:4000 --push

After this step, you can check whether all the container image files in the private container repository have been created to determine whether the execution is successful. Due to the need to download various software packages and source codes from the network (specifically, the external network), factors such as the instability of the network and software sources will cause execution failures, and you can try again after stabilization. In addition, if the configuration file of Kolla has Errors will also cause failure to create container image files.

Specifically, use the command: curl 192.168.0.10:4000/v2/_catalog to view all container image files in the private container repository. If the result is consistent with the container image files listed by the kolla-build--list-images command, it can be considered that all container image files have been created.

Referring to Figure 1 and Figure 3, the second stage is to deploy the prepared container image file to the target node.

Step 4, prepare the target node.

Define the configuration of these three target nodes in Vagrant's virtual machine description file (Vagrantfile). The main code is as follows:

It can be seen that three network segments are defined: management network 20: 192.168.0.0/24, computing network 30: 192.168.1.0/24 and external network 40: 192.168.2.0/24. The role of the external network 40 is to provide a way for the virtual machines in the Openstack test environment to access the external network.

In addition, in the first step, the defined IP of the deployment node 4 is within the range of the management network 20 , and the deployment node 4 can access the target node, the target node 2 and the target node 3 through the management network 20 .

After the virtual machine description file (Vagrantfile) is ready, run the vagrant up command, as in step 1, Vagrant will pull the pre-installed CentOS 7 from the public warehouse, and run CentOS 7 in Virtual Box, and at the same time Set the name of CentOS 7 in Virtual Box, and the host name and IP address will be automatically configured after CentOS 7 runs.

As in step 1, you can verify whether this step is completed correctly by checking whether you can SSH into the deployment node 4 and verify whether the IP and host name are correct. If there is an error, you can first check the virtual machine description file of the deployment node ( Vagrantfile), check the connectivity between the current physical machine and the external network, etc. to solve the problem.

Step 5: Install Docker on target node 1, target node 2, and target node 3, and modify the default configuration so that the above three target nodes can use the private container warehouse that has been created in deployment node 4. By configuring the Docker daemon process, the above three target nodes can use the private container warehouse that has been created. You can add startup parameters to /lib/systemd/system/docker.service. The specific code is as follows:

ExecStart=/usr/bin/dockerd --insecure-registry 192.168.0.10:4000...

Then restart Docker, the code is: systemctl restart docker.

Whether the current step is successfully executed can be verified by whether the container image file created in the first stage can be downloaded correctly among the target nodes deployed. If there is an error, check the Docker configuration of the current node to determine whether the private container repository for storing images is correctly enabled.

Specifically, if the container image file can be pulled from the private container warehouse (Docker registry) described in step 2, it proves whether the verification operation in step 5 is successful. The specific code is:

docker pull 192.168.0.10:4000/kolla/centos-source-nova-api,

Among them, "kolla/centos-source-nova-api" is a container image file in the private container warehouse (Docker registry).

Step 6: Deploy using Kolla in deployment node 4.

This step requires a little preparatory work, that is, the management network IP addresses of the three target nodes and the corresponding roles of each node (such as control nodes, computing nodes, and network nodes) are written into the Kolla configuration file, so that Kolla can be used when deploying Openstack These different target nodes can then be identified. Again, this step can also be done automatically by invoking the ansible command.

In this way, the two isolated steps of installing CentOS 7 and deploying Openstack can be integrated to solve the problem of a large number of manual configurations that must be performed in other deployment methods, which not only simplifies the deployment process of the containerized cloud computing test platform, It also effectively reduces the risk of deployment failure due to configuration errors, thereby greatly improving the deployment efficiency of the containerized cloud computing test platform.

After the configuration file is modified, the official deployment can be carried out. Run the following command:

kolla-ansible deploy

After the execution is completed, a complete containerized Openstack private cloud platform is ready and deployed.

You can judge whether this step is successfully executed by testing whether each function of Openstack is available. If there is any problem, you can check the running status and configuration file of the container corresponding to each Openstack service, check the Kolla configuration file, and re-run the command to deploy after finding the problem. .

Specifically, how to verify whether step 6 is successfully executed is as follows:

Execute nova service-list and neutron agent-list; if the execution is successful, the computing node (ie target node 2) and network node (ie target node 3) can be listed in the result, and both are active and virtual machines can be created And resources such as the network prove whether the deployment using Kolla is successful.

After the deployment is completed, if there is a demand for capacity expansion, such as adding computing nodes or network nodes, the capacity can be expanded according to the same steps as the second stage of the present invention. Since the private container warehouse and container image files have been prepared in the first stage, Therefore, the first stage does not need to be re-executed; in addition, this method has no effect on the deployed target nodes, so that resource expansion can be easily and conveniently performed.

The present invention can support Linux operating systems of different version numbers and different distribution versions. What we use above is the Linux operating system of CentOS 7, and can also support other manufacturers or different versions of Linux operating systems, such as mainstream Ubuntu/Debian, SUSE Wait. All we need to do is to simply modify the config.vm.box configuration items in each virtual machine configuration file (Vagrantfile) to achieve self-adaptation. The specific code is as follows:

config.vm.box="ubuntu/trusty64", means using Ubuntu 14.04 64bit;

config.vm.box="ubuntu/xenial64", means using Ubuntu 16.04 64bit;

config.vm.box="debian/jessie64", means using Debian 8 64bit;

config.vm.box="suse/sles11sp3", means use SUSE enterprise

Version SLES 11 SP3.

In step 6, the present invention also proposes a corresponding solution to the problem of deployment failure that may occur when Kolla is used for deployment for the first time, as shown in detail below.

During the deployment process, the deployment may fail, and the mariadb database cannot be logged in:

TASK[mariadb:Creating haproxy mysql user]

FAILED-RETRYING: TASK: mariadb: Creating haproxy mysql user (10 retries left).

...

FAILED-RETRYING: TASK: mariadb: Creating haproxy mysql user (2 retries left).

FAILED-RETRYING: TASK: mariadb: Creating haproxy mysql user (1 retries left).

NO MORE HOSTS LEFT

to retry, use: --limit@/usr/share/kolla/ansible/site.retry

PLAY RECAP

controller1: ok=49 changed=22 unreachable=0 failed=1

The target node 1 as the control node includes a database, and the mariadb database is preferred. When the first deployment failed, a Docker volume remained in the control node due to an error in the previous deployment and installation using Kolla, and there were bugs in the code. Therefore, once the residual Docker volume is detected when using Kolla for deployment and installation for the second time, the step of initializing the database (that is, the mariadb database) will be skipped, resulting in the loss of the database password set in the two configuration processes. Different causes the problem that you can never log in to the mariadb database, and eventually lead to the problem that you cannot deploy successfully.

For this reason, in this embodiment, in step 6, when the previous container image file deployment operation fails, manually clear the residual Docker volume in the target node and the container that mounts the residual Docker volume or Automatically clear the operation, and redeploy the container image file to the target node. Therefore, you need to clear the Docker volume and related Docker (container) in mariadb, and then redeploy. At this time, Docker is a container with a Docker volume mounted. To this end, the above problems can be solved by modifying the bugs of kolla itself or using scripts to clear all residual data (including Docker Volume and Docker with Docker Volume mounted) before deployment.

It should be noted that the container referred to here refers to the container that the control node is running. The command to delete DockerVolume is docker volume rm mariadb, where mariadb is the name of Docker Volume, which contains the data of each component database in Openstack.

Specifically, the scheme for manually clearing the residual Docker volume and mounting the container operation of the residual Docker volume is as follows:

Run the following command on all control nodes to clear the Docker volume and running containers:

First, stop the running mariadb container on all control nodes, the command is as follows:

docker stop mariadb;

Then, delete the container on all control nodes, the command is as follows:

docker stop mariadb;

Finally, clear the docker volume on all control nodes, the command is as follows:

docker volume rm mariadb.

The scheme for automatically clearing the residual Docker volume and mounting the container operation of the residual Docker volume is as follows:

Write the following content into the ansible configuration file, and run ansible to automatically clear the residual Docker volume on the control node and mount the residual Docker volume container. The command is as follows:

Through the above technical solution, it is possible to avoid the problem of never being able to log in to the mariadb database due to the difference in the database passwords set in the two configuration processes when using Kolla for deployment and installation twice, thereby significantly improving The success rate and simplicity of deployment prevent errors.

In this embodiment, the combination scheme of Vagrant and Virtual Box is used to uniformly deploy the cloud computing test platform of the Openstack architecture, and Openstack is deployed in the virtual machine of the physical host machine 10, and configured as a target node with different functions, which solves the problem of Deployment failures due to inconsistent environments. At the same time, the combination of Vagrant and Ansible can support different versions of the Linux operating system and deploy Openstack, which are two independent deployment stages, to achieve organic integration, reducing the difficulty of user deployment. Finally, due to the use of private container warehouses and container image files, the failure rate of deploying cloud computing test platforms is greatly reduced.

The series of detailed descriptions listed above are only specific descriptions for feasible implementations of the present invention, and they are not intended to limit the protection scope of the present invention. Any equivalent implementation or implementation that does not depart from the technical spirit of the present invention All changes should be included within the protection scope of the present invention.

It will be apparent to those skilled in the art that the invention is not limited to the details of the above-described exemplary embodiments, but that the invention can be embodied in other specific forms without departing from the spirit or essential characteristics of the invention. Accordingly, the embodiments should be regarded in all points of view as exemplary and not restrictive, the scope of the invention being defined by the appended claims rather than the foregoing description, and it is therefore intended that the scope of the invention be defined by the appended claims rather than by the foregoing description. All changes within the meaning and range of equivalents of the elements are embraced in the present invention. Any reference sign in a claim should not be construed as limiting the claim concerned.

In addition, it should be understood that although this specification is described according to implementation modes, not each implementation mode only contains an independent technical solution, and this description in the specification is only for clarity, and those skilled in the art should take the specification as a whole , the technical solutions in the various embodiments can also be properly combined to form other implementations that can be understood by those skilled in the art.

Claims (6)

1. a kind of implementation method of the cloud computing test platform of rapid deployment containerization, it is characterised in that comprise the following steps：

S1, described using the virtual machine of Vagrant file configuration dispose node essential information, operation vagrant up orders from The (SuSE) Linux OS of prepackage is pulled in Public Warehouse, and is run in Virtual Box；Installed in node is disposed Docker simultaneously creates privately owned container warehouse using Docker；The container mirror image text of each service of Openstack is made using Kolla Part, preserves into the privately owned container warehouse；

S2, traversal perform the process of step S1, and the container image file is deployed into destination node.

2. implementation method according to claim 1, it is characterised in that described in step S1 " is installed in node is disposed Docker simultaneously creates privately owned container warehouse using Docker " also include：After the configuration file configuration of ansible is finished, in void Plan machine describes to add the order for calling ansible in file, after after deployment node normally operation, by calling ansible with certainly It is dynamic that Docker is installed.

3. implementation method according to claim 1, it is characterised in that also including to in deployment node and destination node Virtual machine describes the operation that the config option Config.vm.box in file makes an amendment.

4. implementation method according to claim 1, it is characterised in that the cloud computing test platform is based on containerization Openstack cloud computing test platforms.

5. implementation according to claim 1, it is characterised in that the cloud computing test platform runs on a physics In host.

6. implementation method according to claim 1, it is characterised in that the step S2 also includes a current container mirror image During file deployment operation failure, to remaining Docker volume described in the residual Docker volume and carry in destination node Container make manual clear operation or automatic clear operation, and the container image file is redeployed to destination node.