Disclosure of Invention
The application aims to provide a method for realizing automatic construction of a container platform. The application also provides corresponding electronic equipment and a computer storage medium.
In one aspect of the application, a method for automatically building a container platform based on an stable is provided, comprising the following steps:
a configuration playbook, the playbook comprising a plurality of plays for mounting a Kubernetes container platform, each play corresponding to at least one role;
configuring a host list, and setting an ip address corresponding to each role in the host list;
And running playbook, and installing a Kubernetes container platform on the server indicated by the ip address.
Optionally, the plurality of play-corresponding roles include a role for system initialization, a role for installing containers, a role for installing mirror warehouse, and a role for installing Kubernetes orchestration platform.
Optionally, each of the roll is configured to perform at least one task, the method further comprising:
before the playbook is operated, an allowable predefined module is called to write the task corresponding to each role.
Optionally, the method further comprises:
Before running the playbook, creating a plurality of folders for each of the roles, the plurality of folders including a folder storing static files, a folder storing template files, a folder setting variables, a folder storing the at least one task performed by the role.
Optionally, the method further comprises:
If the server indicated by the ip address is at a first security level, the playbook is run to remotely install a Kubernetes container platform on the server.
Optionally, running the playbook to remotely install the Kubernetes container platform on the server specifically includes:
and running playbook, and remotely installing a Kubernetes container platform on the server based on the ssh protocol.
Optionally, the method further comprises:
If the server indicated by the ip address is at a second security level, then the playbook is migrated to a device connected to the server, and the playbook is run on the device to install a Kubernetes container platform on the server.
Optionally, the Kubernetes container platform comprises:
the Kubernetes container platform is installed in a binary fashion.
In another aspect of the present application, there is provided an electronic apparatus including:
A memory storing executable instructions;
a processor that executes the executable instructions in the memory to implement the method of automatically building a container platform based on an onsible as described above.
In another aspect of the present application, a computer readable storage medium is provided, which stores a computer program which, when executed by a processor, implements a method of automatically building a container platform based on an onsite as described above.
According to the technical scheme disclosed by the application, an existing automated operation and maintenance tool is introduced, and through configuring playbook and configuring a host list (inventory) in the existing, and operating playbook to install a Kubernetes container platform on a server, the standardized and batched delivery and deployment modes for constructing a k8s platform are realized, the obvious synergy and cost reduction are realized, and good technical conditions are created for the application, popularization and popularization of micro-services. In addition, the Kubernetes platform is built by adopting an stable, an agent (agent) in an operating system is not required to be installed on the client, and the resource loss of the client can be reduced.
Detailed Description
The application will be described in more detail below with reference to the accompanying drawings. While the preferred embodiments of the present application are illustrated in the drawings, it should be understood that the present application may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the application to those skilled in the art.
As described above, kubernetes has important significance for application, popularization and promotion of micro services and the like, but at present, the Kubernetes cluster needs to be manually deployed, so that the problems of inconsistent system environment version, increased deployment time, high artificial learning cost, difficult transplantation and the like are caused, and great difficulty is brought to the application of micro services.
Through deep knowledge of numerous technical schemes and combinations thereof, the applicant selects to introduce an existing into the Kubernetes cluster for deployment, realizes a standardized delivery deployment mode for constructing a Kubernetes container platform, remarkably improves efficiency and reduces cost, creates good technical conditions for application, popularization and popularization of micro-services, and can also reduce resource loss of a client operating system.
Ansible is a simple, powerful and agent-free automation language written based on YAML text, simple and legible. an onstable does not require an agent, and no additional agents (agents) need to be installed on the host or network device. Furthermore, the stable may also implement cross-platform support, which may support linux, windows, unix and network devices. playbook, play, role, manifest (invertory), task (task), module, etc. are important terms in the allowable. playbook can be viewed as a task list of roles, which are script files built based on YAML in an existing. The main function of play is to impersonate hosts that have been grouped together in advance into a roll that is defined in advance by the task. roll is a new property introduced by an onsible from version 1.2 for hierarchically, structured organization playbook. the task calls a module predefined in the stable to perform the desired task. A module (module) is a predefined module in an allowable. Inventory (inventory) is a list of roles, with an existing supporting dynamic objects as well as static objects. Plugin refers to a code segment added to an existing platform for extending the existing platform.
FIG. 1 shows a flowchart of a method for automatically building a container platform based on an onsite, according to one embodiment of the application. As shown in fig. 1, the method includes steps 102, 104, and 106.
Step 102, configuring playbook, wherein the playbook comprises a plurality of plays, wherein the plays are used for installing a Kubernetes container platform, and each play corresponds to at least one role.
In some possible embodiments, the plurality of play-corresponding roles include a role for system initialization, a role for installing containers, a role for installing mirror image warehouses, a role for installing Kubernetes' orchestration platform, and so on. The Kubernetes orchestration platform typically includes a master and a node.
In some possible embodiments, each of the roles is configured to execute at least one task (task), and an allowable predefined module may be called to write the task corresponding to each of the roles.
The deployment task may be split into multiple plays, each corresponding to at least one role, which impersonates hosts that have been previously grouped into a group into roles that are previously defined by tasks in the stable. An allowable predefined module (module) may be invoked to write the corresponding task. copy, template, shell, yum, etc. are commonly called modules in an existing. copy module to cover the files under the appointed directory to roll; the template module is used for replacing the configuration file on the covering roll; the shell module is used for remotely executing the shell script; yum module for remote installation and uninstallation of software.
In some possible embodiments, the method further comprises: creating a plurality of folders for each role, wherein the folders comprise folders for storing static files, folders for storing template files, folders for setting variables, folder groups for storing the at least one task executed by the role, file groups for setting variables, and file groups for storing the at least one task executed by the role.
A files, tasks, templates, vars folder may be created for each role. files are used for storing static files; the templates are used for storing template files; vars is used to set the variables of the operation; tasks are used for storing one or more tasks (tasks) executed by the role, and a predefined module in an existing can be called in a task file.
Step 104, configuring a host list, and setting an ip address corresponding to each role in the host list.
The ip address corresponding to each of the role may be set in the host list. The same role can be deployed on a plurality of servers, so that batch deployment is realized, and high availability of the system is also facilitated.
And 106, running playbook, and installing a Kubernetes container platform on the server indicated by the ip address.
The server may be a host (host) server or a network (networking) server.
In some possible implementations, if the server indicated by the ip address is at the first security level, the playbook is run to remotely install the Kubernetes container platform on the server. In one example, the Kubernetes container platform may be installed remotely on the server indicated by the ip address based on the ssh protocol.
In some possible implementations, if the server indicated by the ip address is at the second security level, then the playbook is migrated to a device connected to the server, on which the playbook is run to install the Kubernetes container platform on the server.
For servers in a common production environment (first security level), all the container platform servers can be opened by using a ssh authentication mode to carry out remote installation and deployment; and deleting the public key and the private key after deployment is completed, and adding the public key and the private key into the fort machine.
For a server in a network isolated environment (second security level), playbook may be copied to a device in communication with the server, which may be other servers in the same network isolated environment as the server or the server itself; running playbook on the device to install and deploy on the server; and playbook on the device may be deleted after installation, etc.
According to the technical scheme disclosed by the application, an allowable automatic operation and maintenance tool is introduced, through configuration playbook and a host list, and operation playbook, a Kubernetes container platform is installed on a server, so that a standardized delivery deployment mode for constructing a k8s platform is realized, remarkable synergy and cost reduction are realized, and good technical conditions are created for application, popularization and popularization of micro-services. In addition, the Kubernetes platform is built by adopting an onsible, an agent (agent) is not required to be installed on the client, and the resource loss of the client can be reduced.
For example, operating system initialization unified configuration optimization may be achieved by defining an init_system role in a play, typically including repairing security vulnerabilities, baseline repairs, etc. By the present application, an init_system is set in playbook, which can directly cover multiple remote container platform servers: sshd_ config, selinux, localtime, limits. Conf, sudo, sysctl. Conf, logic. Defs, pwquality. Conf, and can upgrade the linux kernel kube-APISERVER, KUBELET, KUBE-controller-manager, kube-scheduler, kube-prox, etc. at one time, install and delete RPM (RPM package manager), etc., thereby remarkably improving deployment efficiency and reducing error rate. In addition, since the agent is not deployed at the client, no resource loss is caused to the operating system thereof.
For another example, the deployment of container platform kubernetesdocker is complex, requiring manual deployment by highly experienced technicians in the prior art, and lead times are long. By defining the role of installing the dock container in one play, the method realizes the establishment of certificates, etcd clusters, master high availability, automatic installation of multiple components and the like, and can rapidly carry out delivery without knowing the internal principle of the container and a module calling mechanism. In addition, the role is stored in a file mode, has strong portability and reusability, and can be quickly copied to other projects.
In some possible implementations, the multiple plays in playbook can install the Kubernetes container platform on the character in a binary fashion.
The deployment is performed in a binary mode, so that the occurrence problem is easier to be checked, but the deployment is more complex and is easy to make mistakes. According to the application, automatic deployment of an automatic deployment binary mode is realized by introducing an allowable, so that the defects of complicated configuration file modification, easy error and the like of binary deployment are avoided.
Figure 2 shows a flow chart of a method of setting up a container platform according to an exemplary embodiment of the application. As shown in S202, operation playbook is started. S204, performing play corresponding to the system initialization role. S206, performing play corresponding to a install container (dock) role. S208, performing play of the corresponding installation mirror warehouse (harbor) role. S210, executing play corresponding to the installation etcd cluster role. When S210 is executed, the images in the image repository are also pulled. S212, performing play of the corresponding installation cluster master assembly (master) role. S214, performing play of the corresponding installation cluster controlled node (node) role.
The foregoing description of embodiments of the application has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described.