CN114489955A - System and method for realizing GitOps by Docker Swarm cluster - Google Patents
System and method for realizing GitOps by Docker Swarm cluster Download PDFInfo
- Publication number
- CN114489955A CN114489955A CN202210135395.0A CN202210135395A CN114489955A CN 114489955 A CN114489955 A CN 114489955A CN 202210135395 A CN202210135395 A CN 202210135395A CN 114489955 A CN114489955 A CN 114489955A
- Authority
- CN
- China
- Prior art keywords
- application
- deployment
- git
- cluster
- docker
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
A system for implementing gilops by a Docker Swarm cluster, comprising: the system comprises a Web interface component, a CLI client, a GitOps controller, a Git listener, a log component and a configuration component. According to the method and the system, the Docker Swarm management nodes are expanded, reasonable scheduling is adopted, a Docker Swarm environment supporting GitOps is constructed, the deployment state of the application service in the Docker Swarm is automatically updated according to the state of the application deployment description service file in the Git warehouse, the processing capacity of continuous delivery and deployment is improved, and the stability of the deployment service in the cluster is improved.
Description
Technical Field
The invention discloses a system and a method for realizing GitOps by a Docker Swarm cluster, belonging to the technical field of cloud computing container systems.
Background
Swarm is a popular container cluster management system developed by Docker corporation, and is integrated in Docker Engine by default, and nodes of the Docker Swarm cluster are divided into two types, namely a management node and a working node.
A management node: the manager of the cluster is responsible for sending the task to the working node; maintaining cluster expectation state and cluster management functions and leader elections. The management node will also run tasks by default, or may be configured to only do management tasks.
And (4) working nodes: the task distributed from the management node is received and executed, and the current state of the task is reported, so that the management node maintains each service expectation state.
The infrastructure, code (IaC), is a practice for providing and managing infrastructure as declarative files, stored as code. All operational procedures can be optimized by utilizing IaC and a version control team.
GitOps is a set of practice for managing infrastructure and application configuration by using Git and a model for realizing continuous delivery, and the core idea is to store declarative infrastructure and application deployment files of an application system in a version control library of Git, wherein Git is a single fact source of declarative infrastructure and application. The system automatically manages the provisioning and deployment of the infrastructure by using a Git pull request, the Git repository contains all the states of the system, changes of the system can be checked or audited through the modification trace of the Git repository states, and the actual state of the system is tracked. By adopting the GitOps workflow, the productivity can be improved, the development and deployment speed of the application service can be accelerated, and the stability and reliability of the system can be improved.
The concept of GitOps was originally proposed by the Kubernets management company Weaveworks. At present, tools related to GitOps mainly run in a Kubernetes cluster environment, and the tools are directed to the situation that an existing Docker Swarm tool does not have GitOps tool support, namely, a Docker Swarm related command cannot support direct container application deployment from a Git warehouse, can only be deployed from a local file, and the deployed file lacks uniform version management.
Although Kubernets are used in large-scale data centers at present, in information centers of numerous small and medium-sized enterprises, a lot of application services are still deployed and operated in a Docker Swarm environment.
Disclosure of Invention
Aiming at the defects of the prior art, the invention discloses a system for realizing GitOps by a Docker Swarm cluster.
The invention also discloses a method for realizing GitOps by the Docker Swarm cluster.
The invention discloses a method and a system device for automatically updating container applications in a Docker Swarm environment by storing deployment description files in a remote Git warehouse, deploying container applications in a manner of designating the remote Git warehouse in a GitOps software system, and monitoring file changes of the remote Git warehouse in real time.
The detailed technical scheme of the invention is as follows:
a system for implementing GitOps by a Docker Swarm cluster is characterized in that,
the GitOps software system itself runs on the management node of the Swarm cluster in a container mode and comprises the following component modules:
the Web interface component provides a visual interface: the system comprises a visual interface, a deployment container application and a cluster management server, wherein the visual interface is used for inputting git parameter information used by the deployment container application, deploying the container application, displaying the deployed container application of the cluster, and managing and configuring the cluster;
the CLI client is used for deploying the container application in a mode of appointing a remote Git warehouse through a terminal command interface;
a GitOps controller, a core module of the system, which is responsible for program scheduling, and is used for receiving command parameters sent by a CLI client and a Web interface component, and calling a relevant API interface of a Docker Swarm cluster to realize deployment of a container application re-cluster and management work of the cluster (application management, service management, container instance management, network, storage, configuration and log management of the Docker Swarm cluster);
the Git monitor is a Git client program extension and is responsible for monitoring the change of a remote Gi warehouse and pulling a file to the local;
the log component is used for recording the operation process of a system user and calling log information to help the user to locate problems;
and the configuration component is used for configuring parameter information of the system, and the parameter information comprises user information of a GitOps software system, Git warehouse listening interval information and the like.
A method for realizing GitOps by a Docker Swarm cluster is characterized by comprising the following steps:
1) in a development environment, a development operation and maintenance worker uses a Git client tool to submit a container application deployment description file and an application parameter configuration file referenced by a deployment file to a Git warehouse used for application deployment;
the container application deployment description file is a file with a file name of Docker-composition.yml, and conforms to a Docker-composition specification of a multi-container application description specification proposed by a Dockers company, and the Docker-composition is a standard deployment file format of a Docker Swarm cluster;
the application parameter configuration file referenced by the deployment file is specified according to actual needs, and is not specified, such as: phpmyadmin. ini for phpmyadmin;
2) sending a gitopdeploy application deployment instruction to a gitop controller for deploying an application through an interactive command window provided by the gitop controller, and specifying a name of the current deployment through a name parameter, specifying a Git warehouse address used by the application through the Git parameter, specifying a user name used by a gitop software system for accessing a Git warehouse through a user, specifying a password used by the gitop software system for accessing the Git warehouse through a password, specifying a branch name of a remote Git warehouse used by the software system for obtaining the code through a branch parameter, and specifying deployment file name information in the remote Git warehouse through a file parameter; the GitOps controller automatically pulls the data of the Git warehouse from the appointed address to the local environment according to the received parameter information, sends a Docker stack deployment order deployment application service to the Docker Swarm management node by using a container application deployment description file in the Git warehouse in the local environment and an application configuration file referenced by the deployment file, and simultaneously monitors the change of the appointed far-end Git warehouse, namely automatically pulls the changed file from the far-end Git warehouse to the Git warehouse in the local environment according to a preset certain time interval;
4) the method comprises the steps that a Docker Swarm management node receives an application deployment command, creates an application deployment task, queries a Swarm working node in a Docker Swarm cluster, wherein the Swarm working node conforms to deployment description convention, can specify running node information of an application container instance in the Docker Swarm cluster through a label of the Docker node, automatically allocates a working node to run the application container instance if the running node information of the application container instance is not specified, and pulls a container mirror image used by an application on the corresponding Docker Swarm working node to create and run an application service instance;
5) when a new version of an application is released, the traditional mode needs to modify mirror version information, file storage directory information and the like used by the application in a deployed file, and update and deploy application deployment information on a Docker Swarm node by using a command; by using the method, the manual operation of updating and deploying is finished only by submitting the modified deployment file (Docker-composition.yml) and the quoted application parameter configuration file to a remote Git warehouse by a Git client tool and pushing the submitted deployment file to the remote Git warehouse, and the application deployment information does not need to be updated by using commands on a Docker Swarm node;
6) a Git monitor of the gitOps software system monitors file changes in a Git warehouse in real time, automatically pulls the content of the changed files to a local Git warehouse of a machine (namely a management node of a Docker Swarm cluster) where the gitOps software system is located, then calls an API (application programming interface) interface of the Docker Swarm cluster, and uses a Docker task deploy command to update application services deployed in the Docker Swarm cluster;
the state of the application service in the Docker Swarm cluster is always kept consistent with the service state parameters described in the deployment description configuration file Docker-compound.
The technical advantages of the invention are as follows:
the technical problem solved by the invention is that the Docker Swarm cluster is expanded to support the storage, deployment and updating of the configuration information and the deployment description information of the service deployed in the Docker Swarm cluster through a Git warehouse, so as to realize continuous delivery and deployment, and the invention has the following technical advantages:
(1) the GitOps system operates at a management node as a system level extension service in a Swarm cluster, monitors the change of a specified Git warehouse and automatically updates the deployed service according to the change;
(2) the method supports the branch deployment of the private Git warehouse and supports different environments corresponding to the branches;
(3) providing a secure cloud-native CI/CD pipeline model;
(4) faster average deployment time and average recovery time;
(5) a stable and reproducible rollback, e.g., according to Git recovery/rollback/fork.
In a word, the method and the system expand the Docker Swarm management nodes, adopt reasonable scheduling to construct a Docker Swarm environment supporting GitOps, and automatically update the deployment state of the application service in the Docker Swarm according to the state of the application deployment description service file in the Git warehouse, so that the processing capacity of continuous delivery and deployment is improved, and the stability of the deployment service in the Swarm is improved. The manual operation times of operation and maintenance personnel are greatly reduced, the reliability and stability of service operation are improved, the development and operation and maintenance efficiency of the system can be obviously improved, and the technical support is provided for the stable operation of cloud native services in a Docker Swarm environment. In addition, because the system adopts a container service operation mode, the environments of all the working nodes in the cluster are not modified, and additional expenditure is not increased.
Drawings
FIG. 1 is a diagram of the Docker Swarm cluster GitOps software system architecture of the present invention;
FIG. 2 is an interaction diagram of a Docker Swarm cluster implementing GitOps according to the present invention.
Detailed Description
The invention is described in detail below with reference to the following examples and the accompanying drawings of the specification, but is not limited thereto.
Examples 1,
As shown in fig. 1, a system of a Docker Swarm cluster implementing a GitOps, the GitOps software system itself running on a management node of the Swarm cluster in a container manner, includes the following component modules:
the Web interface component provides a visual interface: the system comprises a visual interface, a deployment container application and a cluster management server, wherein the visual interface is used for inputting git parameter information used by the deployment container application, deploying the container application, displaying the deployed container application of the cluster, and managing and configuring the cluster;
the CLI client is used for deploying the container application in a mode of appointing a remote Git warehouse through a terminal command interface;
a GitOps controller, a core module of the system, which is responsible for program scheduling, and is used for receiving command parameters sent by a CLI client and a Web interface component, and calling a relevant API interface of a Docker Swarm cluster to realize deployment of a container application re-cluster and management work of the cluster (application management, service management, container instance management, network, storage, configuration and log management of the Docker Swarm cluster);
the Git monitor is a Git client program extension and is responsible for monitoring the change of a remote Gi warehouse and pulling a file to the local;
the log component is used for recording the operation process of a system user and calling log information to help the user to locate problems;
and the configuration component is used for configuring parameter information of the system, and the parameter information comprises user information of a GitOps software system, Git warehouse listening interval information and the like.
Examples 2,
As shown in fig. 2, a method for implementing GitOps by a Docker Swarm cluster includes:
1) in a development environment, a development operation and maintenance worker uses a Git client tool to submit a container application deployment description file and an application parameter configuration file referenced by a deployment file to a Git warehouse used for application deployment;
the container application deployment description file is a file with a file name of Docker-composition.yml, and conforms to a Docker-composition specification of a multi-container application description specification proposed by a Dockers company, and the Docker-composition is a standard deployment file format of a Docker Swarm cluster;
the application parameter configuration file referenced by the deployment file is specified according to actual needs, and is not specified, such as: phpmyadmin. ini for phpmyadmin;
2) sending a gitopdeploy application deployment instruction to a gitop controller for deploying an application through an interactive command window provided by the gitop controller, and specifying a name of the current deployment through a name parameter, specifying a Git warehouse address used by the application through the Git parameter, specifying a user name used by a gitop software system for accessing a Git warehouse through a user, specifying a password used by the gitop software system for accessing the Git warehouse through a password, specifying a branch name of a remote Git warehouse used by the software system for obtaining the code through a branch parameter, and specifying deployment file name information in the remote Git warehouse through a file parameter; the GitOps controller automatically pulls the data of the Git warehouse from the appointed address to the local environment according to the received parameter information, sends a Docker stack deployment order deployment application service to the Docker Swarm management node by using a container application deployment description file in the Git warehouse in the local environment and an application configuration file referenced by the deployment file, and simultaneously monitors the change of the appointed far-end Git warehouse, namely automatically pulls the changed file from the far-end Git warehouse to the Git warehouse in the local environment according to a preset certain time interval;
4) the method comprises the steps that a Docker Swarm management node receives an application deployment command, creates an application deployment task, queries a Swarm working node in a Docker Swarm cluster, wherein the Swarm working node conforms to deployment description convention, can specify running node information of an application container instance in the Docker Swarm cluster through a label of the Docker node, automatically allocates a working node to run the application container instance if the running node information of the application container instance is not specified, and pulls a container mirror image used by an application on the corresponding Docker Swarm working node to create and run an application service instance;
5) when a new version of an application is released, the traditional mode needs to modify mirror version information, file storage directory information and the like used by the application in a deployed file, and update and deploy application deployment information on a Docker Swarm node by using a command; by using the method, the manual operation of updating and deploying is finished only by submitting the modified deployment file (Docker-composition.yml) and the quoted application parameter configuration file to a remote Git warehouse by a Git client tool and pushing the submitted deployment file to the remote Git warehouse, and the application deployment information does not need to be updated by using commands on a Docker Swarm node;
6) a Git monitor of the gitOps software system monitors file changes in a Git warehouse in real time, automatically pulls the content of the changed files to a local Git warehouse of a machine (namely a management node of a Docker Swarm cluster) where the gitOps software system is located, then calls an API (application programming interface) interface of the Docker Swarm cluster, and uses a Docker stack default command to update application services deployed in the Docker Swarm cluster;
the state of the application service in the Docker Swarm cluster is always kept consistent with the service state parameters described in the deployment description configuration file Docker-compound.
As in embodiments 1 and 2, the deployment file and parameter configuration file of mariaddb database + PHPAdmin application, deployment file docker-compound.yml:
wherein, the parameter configuration file config/phpmyadmin. ini of the PHP phpmyadmin application:
“upload_max_filesize＝128M
post_max_size＝128M”。
Claims (2)
1. a system for implementing GitOps by a Docker Swarm cluster is characterized in that,
the GitOps software system itself runs on the management node of the Swarm cluster in a container mode and comprises the following component modules:
and the Web interface component: the system comprises a visual interface, a deployment container application and a cluster management server, wherein the visual interface is used for inputting git parameter information used by the deployment container application, deploying the container application, displaying the deployed container application of the cluster, and managing and configuring the cluster;
the CLI client is used for deploying the container application in a mode of appointing a remote Git warehouse through a terminal command interface;
the GitOps controller is used for receiving command parameters sent by the CLI client and the Web interface component and calling a related API (application programming interface) of the Docker Swarm cluster to realize deployment of the container application re-cluster and management work of the cluster;
the Git monitor is responsible for monitoring the change of the remote Gi warehouse and pulling the file to the local;
the log component is used for recording the operation process of a system user and calling log information to help the user to locate problems;
and the configuration component is used for configuring parameter information of the system, and the parameter information comprises user information of a GitOps software system, Git warehouse listening interval information and the like.
2. The working method of the system for implementing GitOps in a Docker Swarm cluster according to claim 1, comprising:
1) in a development environment, a development operation and maintenance worker uses a Git client tool to submit a container application deployment description file and an application parameter configuration file referenced by a deployment file to a Git warehouse used for application deployment;
2) sending a GitOps deployment instruction to the GitOps controller to deploy an application through an interactive command window provided by the GitOps controller, and specifying the name of the current deployment through a name parameter, specifying a Git warehouse address used by the application through the Git parameter, specifying a user name used by the Git software system to access the Git warehouse through a user, specifying a password used by the Git software system to access the Git warehouse through a password, obtaining a branch name of a remote Git warehouse used by the code through a branch parameter, and specifying deployment file name information in the remote Git warehouse through a file parameter; the GitOps controller automatically pulls the data of the Git warehouse from the appointed address to the local environment according to the received parameter information, sends a Docker stack deployment order deployment application service to the Docker Swarm management node by using a container application deployment description file in the Git warehouse in the local environment and an application configuration file referenced by the deployment file, and simultaneously monitors the change of the appointed far-end Git warehouse, namely automatically pulls the changed file from the far-end Git warehouse to the Git warehouse in the local environment according to a preset certain time interval;
4) the method comprises the steps that a Docker Swarm management node receives an application deployment command, creates an application deployment task, queries a Swarm working node in a Docker Swarm cluster, wherein the Swarm working node conforms to deployment description convention, can specify running node information of an application container instance in the Docker Swarm cluster through a label of the Docker node, automatically allocates a working node to run the application container instance if the running node information of the application container instance is not specified, and pulls a container mirror image used by an application on the corresponding Docker Swarm working node to create and run an application service instance;
5) submitting the modified deployment file and the quoted application parameter configuration file by using a Git client tool and pushing the modified deployment file and the quoted application parameter configuration file to a remote Git warehouse, namely finishing the manual operation of updating deployment;
6) a Git monitor of the gitOps software system monitors file changes in a Git warehouse in real time, automatically draws the content of the changed files to a local Git warehouse of a machine where the gitOps software system is located, then calls an API (application programming interface) of a Docker swap cluster, and uses a Docker stack deployment command to update application services deployed in the Docker swap cluster;
the state of the application service in the Docker Swarm cluster is always kept consistent with the service state parameters described in the deployment description configuration file Docker-compound.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210135395.0A CN114489955A (en) | 2022-02-14 | 2022-02-14 | System and method for realizing GitOps by Docker Swarm cluster |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210135395.0A CN114489955A (en) | 2022-02-14 | 2022-02-14 | System and method for realizing GitOps by Docker Swarm cluster |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114489955A true CN114489955A (en) | 2022-05-13 |
Family
ID=81481378
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210135395.0A Pending CN114489955A (en) | 2022-02-14 | 2022-02-14 | System and method for realizing GitOps by Docker Swarm cluster |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114489955A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115314354A (en) * | 2022-07-19 | 2022-11-08 | 中电通商数字技术(上海)有限公司 | Mass container cluster management method and system |
| CN118092982A (en) * | 2024-04-25 | 2024-05-28 | 浪潮通用软件有限公司 | Multi-cluster operation and maintenance method, equipment and medium for cloud native application |
-
2022
- 2022-02-14 CN CN202210135395.0A patent/CN114489955A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115314354A (en) * | 2022-07-19 | 2022-11-08 | 中电通商数字技术(上海)有限公司 | Mass container cluster management method and system |
| CN118092982A (en) * | 2024-04-25 | 2024-05-28 | 浪潮通用软件有限公司 | Multi-cluster operation and maintenance method, equipment and medium for cloud native application |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110768833B (en) | Application arrangement and deployment method and device based on kubernets | |
| US11379311B2 (en) | Configuring computing devices using a template | |
| US10762075B2 (en) | Database interface agent for a tenant-based upgrade system | |
| CN111274001B (en) | Micro-service management platform | |
| CN114489955A (en) | System and method for realizing GitOps by Docker Swarm cluster | |
| US10191733B2 (en) | Software change process orchestration in a runtime environment | |
| CN111027921A (en) | Business processing method and device, electronic equipment and storage medium | |
| CN113220416B (en) | Cluster node expansion system based on cloud platform, implementation method and operation method | |
| CN109614219B (en) | Condor task mapping method of remote sensing image processing Docker cluster | |
| CN111142881A (en) | Kubernets-based charts automation deployment system and method | |
| CN115292026B (en) | Management method, device and equipment of container cluster and computer readable storage medium | |
| CN112801607A (en) | Management service platform and construction method | |
| CN116339749A (en) | Containerized DevOps method, system and equipment capable of performing task scheduling | |
| CN115061717A (en) | Application management method, application subscription method and related equipment | |
| CN111147291B (en) | Service maintenance method and device | |
| CN110633250B (en) | Resource management system and method | |
| US10365925B2 (en) | Merging applications | |
| CN114385126A (en) | K8 s-based multi-tenant deep learning model research and development system and method | |
| US10101993B2 (en) | System and method for updating content without downtime | |
| CN116450153B (en) | Rapid deployment method for containerized simulation platform | |
| US20230195596A1 (en) | Cloud agnostic shared load testing platform | |
| CN111045697A (en) | Automatic rapid deployment method and system | |
| CN115421847A (en) | Management method and equipment for research, development, operation and maintenance platform and CICD (common information carrier) assembly line supporting multiple engines | |
| US10642594B2 (en) | System and method for updating monitoring software using content model with validity attributes | |
| CN114579364A (en) | Cloud native database backup method based on hybrid cloud |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |