CN111309441A - Micro-service deployment method for realizing DevOps based on Jenkins - Google Patents
Micro-service deployment method for realizing DevOps based on Jenkins Download PDFInfo
- Publication number
- CN111309441A CN111309441A CN202010102269.6A CN202010102269A CN111309441A CN 111309441 A CN111309441 A CN 111309441A CN 202010102269 A CN202010102269 A CN 202010102269A CN 111309441 A CN111309441 A CN 111309441A
- Authority
- CN
- China
- Prior art keywords
- jenkins
- variables
- helm
- chart
- description
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 241000380131 Ammophila arenaria Species 0.000 claims abstract description 42
- 238000012423 maintenance Methods 0.000 claims abstract description 14
- 238000004891 communication Methods 0.000 claims abstract description 13
- 238000011161 development Methods 0.000 claims description 22
- 230000008859 change Effects 0.000 claims description 17
- 238000010276 construction Methods 0.000 claims description 13
- 238000012795 verification Methods 0.000 claims description 9
- 238000012986 modification Methods 0.000 claims description 6
- 230000004048 modification Effects 0.000 claims description 6
- 238000012544 monitoring process Methods 0.000 claims description 4
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 238000007689 inspection Methods 0.000 claims description 3
- 238000012856 packing Methods 0.000 abstract description 3
- 238000007726 management method Methods 0.000 description 29
- 239000000243 solution Substances 0.000 description 6
- 238000012360 testing method Methods 0.000 description 6
- 230000010354 integration Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000014759 maintenance of location Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000000275 quality assurance Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
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
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- 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/45562—Creating, deleting, cloning virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Stored Programmes (AREA)
Abstract
The invention relates to a micro-service deployment method for realizing DevOps based on Jenkins. Through specification and unified configuration in advance, utilize gitlab + jenkins assembly line to accomplish automatic structure, packing, generate the helm chart that can manage mirror image and configuration file to dispose to each environment, greatly reduced artificial communication cost and the possibility of maloperation, improved efficiency. In addition, the variable names are clear at a glance, so that developers can more conveniently understand the use environment of the developers, and operation and maintenance personnel have better maintainability and retrievability. The generated helm chart and docker images are stored in a hardor warehouse, and as relevant information such as variables, versions and configuration files is recorded in the helm, traceability of historical versions can be achieved.
Description
Technical Field
The invention relates to the technical field of micro-service deployment, in particular to a micro-service deployment method for realizing DevOps based on Jenkins.
Background
With the development of docker technology and the emergence of kubernets container management platforms, evolution and updating are brought to traditional service architectures, and micro-service architectures are favored by more and more enterprises. It brings many advantages: the service is divided into more detailed, which is beneficial to the utilization of resources. Due to the decentralized and decoupling design, single service has maintainability, development efficiency is improved, and the iteration cycle is shorter. But the convenience and high efficiency of development also lead to the great increase of the number of services of the micro-service and the high treatment cost of the services. Huge system, complicated environment, numerous services, and production, development, test environment are not right, the understanding and the requirement of developer to environment and used technique have been greatly increased, no matter single point to cluster transition, also or the environment multiplexing brings the unknown to the environmental usage, or the unknown to the used technique itself of environment again, each step from development environment to test environment to deployment production becomes more frustrating. The artificial communication cost is increased day by day, the working efficiency is reduced, and the failure probability caused by artificial uncertainty of on-line deployment is increased.
Therefore, various solutions exist, such as a solution of a kubernets container management platform, which is self-contained, and variables used by a configmap unified management application are created through commonly agreed configuration information, so that the service standardized management function is achieved. However, the non-reusability of the across-namespaces leads to the increase of the management cost of the configmap, the centralized management and configuration cannot be realized, and once the multi-environment multi-namespaces management occurs, the practicability of the multi-environment multi-namespaces management is greatly reduced.
Due to the evolution and maturity of micro-service technology, application service becomes light and loosely coupled, the application iteration is accelerated, and the Devops plays an important role in achieving the purposes of agile development and continuous integration. But the split of the coupling results in service management becoming more complex than in traditional applications. The problems of inexhaustible micro-service deployment work, differential configuration before different environments and the like, the problems that configuration and application versions cannot be corresponded and the like are increasingly highlighted, the communication cost before each department is increased, and the hidden trouble that online failure is caused by human errors exists.
The technical terms related to the present application explain:
DevOps: DevOps (a combination of Development and Operations) is a collective term for a set of processes, methods and systems for facilitating communication, collaboration and integration between Development (application/software engineering), technical Operations and Quality Assurance (QA) departments. IT is a culture, exercise or practice that attaches importance to the communication and cooperation between "software developers (Dev)" and "IT operation and maintenance technicians (Ops)". Through the automatic software delivery and architecture change processes, the software can be built, tested and released more quickly, frequently and reliably.
Kubernetes: the short name K8s is an open source, and is used for managing containerized applications on a plurality of hosts in a cloud platform, the goal of Kubernets is to make it simple and efficient to deploy containerized applications (powerfull), and Kubernets provides a mechanism for application deployment, planning, updating and maintenance.
The micro-service can run in the 'own program' and communicates with the HTTP type API through the 'lightweight equipment'. The key is that the service can run in its own program. By this we can distinguish service exposure from microservice architecture (distributing an API in existing systems).
Helm: helm is the packet manager of Kubernetes. The package manager can quickly find, download and install software packages similar to the apt used by us in Ubuntu, yum used in Centos, or pip in Python.
Docker: docker is an open source application container engine, so that developers can pack their applications and dependency packages into a portable image, and then distribute the image to any popular Linux or Windows machine, and also realize virtualization. The containers are fully sandboxed without any interface between each other.
Jenkins: jenkins is an open source software project, is a continuous integration tool developed based on Java, is used for monitoring continuous and repeated work, and aims to provide an open and easy-to-use software platform to enable continuous integration of software.
Gitlab: GitLab is an open source project for a warehouse management system, and is a web service built on the basis of Git serving as a code management tool.
Namespaces in kubernets, namespaces can be considered as virtualized clusters in your kubernets cluster. There may be multiple namespaces in a kubernets cluster that are logically isolated from each other.
Configmap is a kubernets resource object used to store configuration files, and all configuration contents are stored in etcd. The using mode can be directly hung on the configuration directory and provided in a file mode, and the stored key values can be endowed with certain variables and methods for use.
Helm chart: helm's software package, in TAR format (a common linux packaging). Like the packet management tool in linux, such as the DEB packet of APT or the RPM packet of YUM. It contains a set of YAML files that define kubernets resource associations.
deployment, statefuelet, daemonset: the device comprises a pod manager in Kubernetes, a stateless container set, a stateful container set and a daemon application set.
Disclosure of Invention
In view of this, the present invention provides a method for deploying DevOps based on Jenki ns to overcome the deficiencies of the prior art, so as to solve the problems in the prior art that the number of micro services is increasing, and the complexity, the administration cost and the communication cost are higher and higher due to the differentiation of multi-environment management.
In order to achieve the purpose, the invention adopts the following technical scheme:
a micro-service deployment method for realizing DevOps based on Jenkins comprises the following steps:
step S1, determining variables required by the project to be developed;
step S2, submitting item changes to a gitlab version warehouse;
step S3, monitoring the change of branches in the gitlab version library through jenkins, and triggering the pipeline construction when the change meets the preset conditions;
step S4, judging the type of the project according to the variable name extracted by jenkins from the gitlab version library, compiling the codes, constructing the codes into docker images, and uploading the docker images to a hardor warehouse for management;
step S5, building and uploading a palm chart;
step S6, calling a helm management tool by jenkins to deploy the application to uat environment for verification;
step S7, the palm management tool carries out differentiated deployment in different environments, and gray scale upgrading is carried out according to the upgrading mode defined in the palm chart so that application upgrading is not perceived;
and step S8, the jenkins sends the online result description to the relevant personnel through the mail.
Preferably, the step S1 is specifically:
the operation and maintenance personnel and the development personnel negotiate the variables used by the project, and the operation and maintenance personnel log in the management platform to add new variables or inform the development personnel of the existing variables, so that the names of the variables in each environment are unified, and the corresponding values are different according to different environments.
Preferably, the step S2 is specifically:
and the developer submits the project change to the gitlab version warehouse, and if the project change needs to be merged to the master branch, the project change needs to be audited by the related technical personnel and then uploaded to the gitlab version warehouse.
Preferably, the step S3 is specifically:
drawing branch project codes in a gitlab warehouse, finding a description file and a configuration file which are well agreed with developers by a jenkins program, reading the description file, and storing contents in the description file into a variable list of jenkins;
and reading the configuration file by the jenkins program, and sequentially extracting the variable names related to the configuration file into a variable list for storage by the jenkins program through regular matching.
Preferably, the method further comprises:
determining construction information for being called by jenkins programs;
the construction information at least comprises:
service name, quantity, deployment type, mode, environment, and development language information.
Preferably, the step S5 is specifically:
checking whether the item exists in the helm warehouse or not according to the variable information in jenkins, if so, modifying, and if not, creating through a basic template;
according to the information read from the previous configuration file and the description file, making a helm chart relevant to the helm chart, and making the configuration file into a configmap;
reading variables generated in the description file to modify relevant chart information, knowing values of the variables of relevant environments through calling of api through a previously acquired variable list, and recording names and values of the variables into env variables of values files in the palm chart;
when the jenkins program runs, related variables and values are transmitted to the deployment, stateful and daemon type env variables of kubernets, application configuration files of the jenkins program are mounted to an application configuration file directory of a container through configmap, so that the service runs, the helm chart has independent running capacity, and the version of the helm chart is uploaded to a hardor warehouse for storage management.
Preferably, the step S6 is specifically:
and calling a helm management tool by jenkins to deploy the application to an uat environment for verification, and after the verification is successful, automatically initiating an online request and a related condition description to an approver by jenkins according to the code updating content in the description document and git to wait for the approver to approve.
Preferably, the step S7 is specifically:
after the approver logs in jenkins to carry out related approval, according to the description in the previous description file, the jenkins calls api to read related variables, the related variables are transmitted to the helm management tool to carry out differentiated deployment in an blind environment, and gray scale upgrading is carried out according to an upgrading mode defined in the helm chart so that application upgrading is not perceived.
Preferably, the step S7 further includes:
if the online is the first time or the updating is changed greatly, relevant prompts are provided to draw the attention of operation and maintenance personnel so as to carry out relevant communication and inspection, relevant online information is stored in the database after the deployment is successful, rollback is applied after the deployment is failed, the reason of the failure is sent to relevant personnel, and the information is stored in the database.
Preferably, the step S8 is specifically:
and transmitting an online result description to related personnel by jenkins through mails, wherein the content comprises http construction links, project names, operation records, trigger time, running time, trigger reasons and description of code modification on jenkins, and the reasons and description information of failure are generated if the operation records, the trigger time, the running time, the trigger reasons and the code modification fail.
By adopting the technical scheme, the invention at least has the following beneficial effects:
according to the technical scheme provided by the invention, the mode that the configuration file of the application uses the variables is adopted, and the corresponding environment variables are read during the operation to run, so that the uniformity of the configuration file of the application running in multiple links can be realized. Through specification and unified configuration in advance, utilize gitlab + jenkins assembly line to accomplish automatic structure, packing, generate the helm chart that can manage mirror image and configuration file to dispose to each environment, greatly reduced artificial communication cost and the possibility of maloperation, improved efficiency.
In addition, the variable names are clear at a glance, so that developers can more conveniently understand the use environment of the developers, and operation and maintenance personnel have better maintainability and retrievability. The generated helm chart and docker images are stored in a hardor warehouse, and as relevant information such as variables, versions and configuration files is recorded in the helm, traceability of historical versions can be achieved. The method does not use a palm traditional template replacement mode, and uses a variable + template mode to solve the problem of testing of developers in a local environment. Because the local environment may not be managed by using a helm tool, variables are updated to the development environment of the local environment in real time by calling the relevant api, and the working cost of developers is greatly reduced.
By the technical scheme provided by the invention, the deployment work of the application service can be quickly realized, the problems of difference of the environment and configuration of the micro-service and the problem of application version retention and trace are solved, great convenience is brought to development, testing, examination and approval, online and rollback through a version control and examination and approval mechanism, the communication cost is reduced, and the working efficiency is improved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a flowchart of a method for deploying micro services based on Jenkins to implement DevOps according to an embodiment of the present invention;
fig. 2 is a logic flow diagram of a method for deploying micro services based on Jenkins to implement DevOps according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the technical solutions of the present invention will be described in detail below. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. All other embodiments, which can be derived by a person skilled in the art from the examples given herein without any inventive step, are within the scope of the present invention.
The technical solution of the present invention is further described in detail by the accompanying drawings and embodiments.
Referring to fig. 1 and fig. 2, a micro-service deployment method for implementing DevOps based on Jenkins according to an embodiment of the present invention includes:
step S1, determining variables required by the project to be developed;
step S2, submitting item changes to a gitlab version warehouse;
step S3, monitoring the change of branches in the gitlab version library through jenkins, and triggering the pipeline construction when the change meets the preset conditions;
step S4, judging the type of the project according to the variable name extracted by jenkins from the gitlab version library, compiling the codes, constructing the codes into docker images, and uploading the docker images to a hardor warehouse for management;
step S5, building and uploading a palm chart;
step S6, calling a helm management tool by jenkins to deploy the application to uat environment for verification;
step S7, the palm management tool carries out differentiated deployment in different environments, and gray scale upgrading is carried out according to the upgrading mode defined in the palm chart so that application upgrading is not perceived;
and step S8, the jenkins sends the online result description to the relevant personnel through the mail.
According to the technical scheme provided by the invention, the configuration file of the application uses a variable mode, and the corresponding environment variable can be read during operation to operate, so that the uniformity of the configuration file of the application which operates in multiple links can be realized. Through specification and unified configuration in advance, utilize gitlab + jenkins assembly line to accomplish automatic structure, packing, generate the helm chart that can manage mirror image and configuration file to dispose to each environment, greatly reduced artificial communication cost and the possibility of maloperation, improved efficiency.
In addition, the variable names are clear at a glance, so that developers can more conveniently understand the use environment of the developers, and operation and maintenance personnel have better maintainability and retrievability. The generated helm chart and docker images are stored in a hardor warehouse, and as relevant information such as variables, versions and configuration files is recorded in the helm, traceability of historical versions can be achieved. The method does not use a palm traditional template replacement mode, and uses a variable + template mode to solve the problem of testing of developers in a local environment. Because the local environment may not be managed by using a helm tool, variables are updated to the development environment of the local environment in real time by calling the relevant api, and the working cost of developers is greatly reduced.
By the technical scheme provided by the invention, the deployment work of the application service can be quickly realized, the problems of difference of the environment and configuration of the micro-service and the problem of application version retention and trace are solved, great convenience is brought to development, testing, examination and approval, online and rollback through a version control and examination and approval mechanism, the communication cost is reduced, and the working efficiency is improved.
Preferably, the step S1 is specifically:
the operation and maintenance personnel and the development personnel negotiate the variables used by the project, and the operation and maintenance personnel log in the management platform to add new variables or inform the development personnel of the existing variables, so that the names of the variables in each environment are unified, and the corresponding values are different according to different environments.
Preferably, the step S2 is specifically:
and the developer submits the project change to the gitlab version warehouse, and if the project change needs to be merged to the master branch, the project change needs to be audited by the related technical personnel and then uploaded to the gitlab version warehouse.
Preferably, the step S3 is specifically:
drawing branch project codes in a gitlab warehouse, finding a description file and a configuration file which are well agreed with developers by a jenkins program, reading the description file, and storing contents in the description file into a variable list of jenkins;
and reading the configuration file by the jenkins program, and sequentially extracting the variable names related to the configuration file into a variable list for storage by the jenkins program through regular matching.
Preferably, the method further comprises:
determining construction information for being called by jenkins programs;
the construction information at least comprises:
service name, quantity, deployment type, mode, environment, and development language information.
It can be understood that the change of branches in the gitlab version library is monitored through jenkins, and when the condition is met, the pipeline construction is triggered.
And (3) drawing the branch project codes in the gitlab warehouse, and finding the description file and the configuration file which are well agreed with the developer by the jenkins program. Reading the description file, storing the content in the description file into jenkins variables, and determining the information of the constructed service name, quantity, deployment type, mode, environment, development language and the like. Reading the configuration file, because the related specifications stipulate that the differentiated variables in different environments have special writing methods, for example, $ { DB _ MYSQL _ style } variable is described in three sections: the type, the service and the application scene are simple and easy to understand, and the management convenience is improved. And then jenkins sequentially extracts the names of the variables related in the configuration file into a variable list for storage through regular matching.
Preferably, the step S5 is specifically:
checking whether the item exists in the helm warehouse or not according to the variable information in jenkins, if so, modifying, and if not, creating through a basic template;
according to the information read from the previous configuration file and the description file, making a helm chart relevant to the helm chart, and making the configuration file into a configmap;
reading variables generated in the description file to modify relevant chart information, knowing values of the variables of relevant environments through calling of api through a previously acquired variable list, and recording names and values of the variables into env variables of values files in the palm chart;
when the jenkins program runs, related variables and values are transmitted to the deployment, stateful and daemon type env variables of kubernets, application configuration files of the jenkins program are mounted to an application configuration file directory of a container through configmap, so that the service runs, the helm chart has independent running capacity, and the version of the helm chart is uploaded to a hardor warehouse for storage management.
It can be understood that because variables are referenced in the configuration file and the variables are loaded into the docker container in an env injection mode, the service is operated, the lm chart has independent operation capability, and the version of the lm chart is uploaded to a hardor warehouse for storage and management, so that the version history can be traced, the configuration file and the application image are unified, and the configuration file and the application image can be operated and checked independently.
Preferably, the step S6 is specifically:
and calling a helm management tool by jenkins to deploy the application to an uat environment for verification, and after the verification is successful, automatically initiating an online request and a related condition description to an approver by jenkins according to the code updating content in the description document and git to wait for the approver to approve.
Preferably, the step S7 is specifically:
after the approver logs in jenkins to carry out related approval, according to the description in the previous description file, the jenkins calls api to read related variables, the related variables are transmitted to the helm management tool to carry out differentiated deployment in an blind environment, and gray scale upgrading is carried out according to an upgrading mode defined in the helm chart so that application upgrading is not perceived.
Preferably, the step S7 further includes:
if the online is the first time or the updating is changed greatly, relevant prompts are provided to draw the attention of operation and maintenance personnel so as to carry out relevant communication and inspection, relevant online information is stored in the database after the deployment is successful, rollback is applied after the deployment is failed, the reason of the failure is sent to relevant personnel, and the information is stored in the database.
Preferably, the step S8 is specifically:
and transmitting an online result description to related personnel by jenkins through mails, wherein the content comprises http construction links, project names, operation records, trigger time, running time, trigger reasons and description of code modification on jenkins, and the reasons and description information of failure are generated if the operation records, the trigger time, the running time, the trigger reasons and the code modification fail.
The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims. The terms "first" and "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. The term "plurality" means two or more unless expressly limited otherwise.
Claims (10)
1. A micro-service deployment method for realizing DevOps based on Jenkins is characterized by comprising the following steps:
step S1, determining variables required by the project to be developed;
step S2, submitting item changes to a gitlab version warehouse;
step S3, monitoring the change of branches in the gitlab version library through jenkins, and triggering the pipeline construction when the change meets the preset conditions;
step S4, judging the type of the project according to the variable name extracted by jenkins from the gitlab version library, compiling the codes, constructing the codes into docker images, and uploading the docker images to a hardor warehouse for management;
step S5, building and uploading a palm chart;
step S6, calling a helm management tool by jenkins to deploy the application to uat environment for verification;
step S7, the palm management tool carries out differentiated deployment in different environments, and gray scale upgrading is carried out according to the upgrading mode defined in the palm chart so that application upgrading is not perceived;
and step S8, the jenkins sends the online result description to the relevant personnel through the mail.
2. The method according to claim 1, wherein the step S1 specifically includes:
the operation and maintenance personnel and the development personnel negotiate the variables used by the project, and the operation and maintenance personnel log in the management platform to add new variables or inform the development personnel of the existing variables, so that the names of the variables in each environment are unified, and the corresponding values are different according to different environments.
3. The method according to claim 2, wherein the step S2 is specifically:
and the developer submits the project change to the gitlab version warehouse, and if the project change needs to be merged to the master branch, the project change needs to be audited by the related technical personnel and then uploaded to the gitlab version warehouse.
4. The method according to claim 3, wherein the step S3 is specifically:
drawing branch project codes in a gitlab warehouse, finding a description file and a configuration file which are well agreed with developers by a jenkins program, reading the description file, and storing contents in the description file into a variable list of jenkins;
and reading the configuration file by the jenkins program, and sequentially extracting the variable names related to the configuration file into a variable list for storage by the jenkins program through regular matching.
5. The method of claim 4, further comprising:
determining construction information for being called by jenkins programs;
the construction information at least comprises:
service name, quantity, deployment type, mode, environment, and development language information.
6. The method according to claim 4, wherein the step S5 is specifically:
checking whether the item exists in the helm warehouse or not according to the variable information in jenkins, if so, modifying, and if not, creating through a basic template;
according to the information read from the previous configuration file and the description file, making a helm chart relevant to the helm chart, and making the configuration file into a configmap;
reading variables generated in the description file to modify relevant chart information, knowing values of the variables of relevant environments through calling of api through a previously acquired variable list, and recording names and values of the variables into env variables of values files in the palm chart;
when the jenkins program runs, related variables and values are transmitted to the deployment, stateful and daemon type env variables of kubernets, application configuration files of the jenkins program are mounted to an application configuration file directory of a container through configmap, so that the service runs, the helm chart has independent running capacity, and the version of the helm chart is uploaded to a hardor warehouse for storage management.
7. The method according to claim 6, wherein the step S6 is specifically:
and calling a helm management tool by jenkins to deploy the application to an uat environment for verification, and after the verification is successful, automatically initiating an online request and a related condition description to an approver by jenkins according to the code updating content in the description document and git to wait for the approver to approve.
8. The method according to claim 7, wherein the step S7 is specifically:
after the approver logs in jenkins to carry out related approval, according to the description in the previous description file, the jenkins calls api to read related variables, the related variables are transmitted to the helm management tool to carry out differentiated deployment in an blind environment, and gray scale upgrading is carried out according to an upgrading mode defined in the helm chart so that application upgrading is not perceived.
9. The method according to claim 8, wherein the step S7 further comprises:
if the online is the first time or the updating is changed greatly, relevant prompts are provided to draw the attention of operation and maintenance personnel so as to carry out relevant communication and inspection, relevant online information is stored in the database after the deployment is successful, rollback is applied after the deployment is failed, the reason of the failure is sent to relevant personnel, and the information is stored in the database.
10. The method according to claim 8, wherein the step S8 is specifically:
and transmitting an online result description to related personnel by jenkins through mails, wherein the content comprises http construction links, project names, operation records, trigger time, running time, trigger reasons and description of code modification on jenkins, and the reasons and description information of failure are generated if the operation records, the trigger time, the running time, the trigger reasons and the code modification fail.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010102269.6A CN111309441B (en) | 2020-02-19 | 2020-02-19 | Micro-service deployment method for realizing DevOps based on Jenkins |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010102269.6A CN111309441B (en) | 2020-02-19 | 2020-02-19 | Micro-service deployment method for realizing DevOps based on Jenkins |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111309441A true CN111309441A (en) | 2020-06-19 |
| CN111309441B CN111309441B (en) | 2024-04-09 |
Family
ID=71149143
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010102269.6A Active CN111309441B (en) | 2020-02-19 | 2020-02-19 | Micro-service deployment method for realizing DevOps based on Jenkins |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111309441B (en) |
Cited By (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111984373A (en) * | 2020-08-19 | 2020-11-24 | 上海翘腾科技有限公司 | Method and system for ensuring environment consistency in Kubernetes container environment |
| CN112000585A (en) * | 2020-10-28 | 2020-11-27 | 深圳开源互联网安全技术有限公司 | Safety testing method and system based on DevSecOps platform |
| CN112000343A (en) * | 2020-08-24 | 2020-11-27 | 浪潮云信息技术股份公司 | Method and system for deploying multi-version service in Kubernets by using Devops |
| CN112181587A (en) * | 2020-09-18 | 2021-01-05 | 烽火通信科技股份有限公司 | Software product deployment method and system based on docker technology |
| CN112328263A (en) * | 2020-11-26 | 2021-02-05 | 杭州安恒信息安全技术有限公司 | Jenkins-based front-end project deployment method and device in intranet environment |
| CN112506613A (en) * | 2020-12-11 | 2021-03-16 | 四川长虹电器股份有限公司 | Method for automatically identifying Maven change submodule and pushing docker mirror image by Gitlab-ci |
| CN112596784A (en) * | 2020-12-28 | 2021-04-02 | 青岛海尔科技有限公司 | Iterative version deployment method and device |
| CN112965785A (en) * | 2021-03-05 | 2021-06-15 | 食亨(上海)科技服务有限公司 | Container-based micro-service application development method and development platform |
| CN113190326A (en) * | 2021-04-20 | 2021-07-30 | 北京异乡旅行网络科技有限公司 | Information processing method and device |
| CN113238764A (en) * | 2021-05-17 | 2021-08-10 | 西安点告网络科技有限公司 | Software delivery method and system based on DAG graph, electronic device and readable storage medium |
| CN113419744A (en) * | 2021-06-24 | 2021-09-21 | 广州欢网科技有限责任公司 | Method and device for project automatic deployment |
| CN113438104A (en) * | 2021-06-10 | 2021-09-24 | 上海甄汇信息科技有限公司 | System non-inductive automatic iteration method |
| CN113515293A (en) * | 2021-04-29 | 2021-10-19 | 上海安畅网络科技股份有限公司 | Method and system for managing DevOps tool chain |
| CN113778549A (en) * | 2021-08-16 | 2021-12-10 | 济南浪潮数据技术有限公司 | Implementation method, device, equipment and medium for replacing rear-end environment variables |
| CN114296832A (en) * | 2021-12-31 | 2022-04-08 | 北京易华录信息技术股份有限公司 | Method and device for deploying production environment of micro service |
| CN114691189A (en) * | 2020-12-30 | 2022-07-01 | 广州力挚网络科技有限公司 | Distributed project development processing method and system |
| US11385877B1 (en) | 2020-11-13 | 2022-07-12 | Microsoft Technology Licensing, Llc | Deploying applications |
| CN114840225A (en) * | 2022-04-26 | 2022-08-02 | 光大科技有限公司 | Application deployment method and device, storage medium and electronic device |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106873975A (en) * | 2016-12-30 | 2017-06-20 | 武汉默联股份有限公司 | Devops based on Docker persistently pays and automated system and method |
| US10055200B1 (en) * | 2016-03-29 | 2018-08-21 | EMC IP Holding Company LLC | Creation and use of development packages |
-
2020
- 2020-02-19 CN CN202010102269.6A patent/CN111309441B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10055200B1 (en) * | 2016-03-29 | 2018-08-21 | EMC IP Holding Company LLC | Creation and use of development packages |
| CN106873975A (en) * | 2016-12-30 | 2017-06-20 | 武汉默联股份有限公司 | Devops based on Docker persistently pays and automated system and method |
Non-Patent Citations (3)
| Title |
|---|
| ANALYSYS-YIGUAN: """三年连发3大重磅产品工具，憋不住想要分享的DevOps实操干货……"\"", 《HTTPS://WWW.IYUNYING.ORG/ZHA/HOT/145316.HTML》 * |
| 阳明: ""基于 Jenkins、Gitlab、Harbor、Helm 和 Kubernetes 的 CI/CD(一)"", 《HTTPS://WWW.QIKQIAK.COM/POST/COMPLETE-CICD-DEMONSTRATE-1/》 * |
| 阳明先生: ""基于 Jenkins、Gitlab、Harbor、Helm 和 Kubernetes 的 CI/CD(一)"", 《HTTPS://JUEJIN.CN/POST/6844903821299154952》 * |
Cited By (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111984373A (en) * | 2020-08-19 | 2020-11-24 | 上海翘腾科技有限公司 | Method and system for ensuring environment consistency in Kubernetes container environment |
| CN111984373B (en) * | 2020-08-19 | 2023-07-07 | 昆山旌展信息科技有限公司 | Method and system for guaranteeing environment consistency in Kubernetes container environment |
| CN112000343A (en) * | 2020-08-24 | 2020-11-27 | 浪潮云信息技术股份公司 | Method and system for deploying multi-version service in Kubernets by using Devops |
| CN112000343B (en) * | 2020-08-24 | 2024-02-20 | 浪潮云信息技术股份公司 | Method and system for deploying multi-version services in Kubernetes by using Devops |
| CN112181587A (en) * | 2020-09-18 | 2021-01-05 | 烽火通信科技股份有限公司 | Software product deployment method and system based on docker technology |
| CN112181587B (en) * | 2020-09-18 | 2022-09-09 | 烽火通信科技股份有限公司 | Software product deployment method and system based on docker technology |
| CN112000585A (en) * | 2020-10-28 | 2020-11-27 | 深圳开源互联网安全技术有限公司 | Safety testing method and system based on DevSecOps platform |
| US11385877B1 (en) | 2020-11-13 | 2022-07-12 | Microsoft Technology Licensing, Llc | Deploying applications |
| CN112328263A (en) * | 2020-11-26 | 2021-02-05 | 杭州安恒信息安全技术有限公司 | Jenkins-based front-end project deployment method and device in intranet environment |
| CN112506613A (en) * | 2020-12-11 | 2021-03-16 | 四川长虹电器股份有限公司 | Method for automatically identifying Maven change submodule and pushing docker mirror image by Gitlab-ci |
| CN112596784A (en) * | 2020-12-28 | 2021-04-02 | 青岛海尔科技有限公司 | Iterative version deployment method and device |
| CN112596784B (en) * | 2020-12-28 | 2023-11-28 | 青岛海尔科技有限公司 | Iterative version deployment method and device |
| CN114691189A (en) * | 2020-12-30 | 2022-07-01 | 广州力挚网络科技有限公司 | Distributed project development processing method and system |
| CN112965785A (en) * | 2021-03-05 | 2021-06-15 | 食亨(上海)科技服务有限公司 | Container-based micro-service application development method and development platform |
| CN112965785B (en) * | 2021-03-05 | 2023-06-13 | 食亨(上海)科技服务有限公司 | Container-based micro-service application development method and development platform |
| CN113190326A (en) * | 2021-04-20 | 2021-07-30 | 北京异乡旅行网络科技有限公司 | Information processing method and device |
| CN113515293A (en) * | 2021-04-29 | 2021-10-19 | 上海安畅网络科技股份有限公司 | Method and system for managing DevOps tool chain |
| CN113238764A (en) * | 2021-05-17 | 2021-08-10 | 西安点告网络科技有限公司 | Software delivery method and system based on DAG graph, electronic device and readable storage medium |
| CN113438104A (en) * | 2021-06-10 | 2021-09-24 | 上海甄汇信息科技有限公司 | System non-inductive automatic iteration method |
| CN113419744A (en) * | 2021-06-24 | 2021-09-21 | 广州欢网科技有限责任公司 | Method and device for project automatic deployment |
| CN113778549A (en) * | 2021-08-16 | 2021-12-10 | 济南浪潮数据技术有限公司 | Implementation method, device, equipment and medium for replacing rear-end environment variables |
| CN113778549B (en) * | 2021-08-16 | 2023-12-22 | 济南浪潮数据技术有限公司 | Method, device, equipment and medium for realizing back-end environment variable replacement |
| CN114296832A (en) * | 2021-12-31 | 2022-04-08 | 北京易华录信息技术股份有限公司 | Method and device for deploying production environment of micro service |
| CN114840225B (en) * | 2022-04-26 | 2023-09-19 | 光大科技有限公司 | Application deployment method and device, storage medium and electronic device |
| CN114840225A (en) * | 2022-04-26 | 2022-08-02 | 光大科技有限公司 | Application deployment method and device, storage medium and electronic device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111309441B (en) | 2024-04-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111309441A (en) | Micro-service deployment method for realizing DevOps based on Jenkins | |
| US10572249B2 (en) | Software kit release management | |
| Gallaba et al. | Use and misuse of continuous integration features: An empirical study of projects that (mis) use Travis CI | |
| CN110321152A (en) | A kind of Software Development Platform | |
| WO2019095936A1 (en) | Method and system for building container mirror image, and server, apparatus and storage medium | |
| US8074204B2 (en) | Test automation for business applications | |
| CN110471831B (en) | Automatic method and device for compatibility test | |
| CN110795078B (en) | Architecture method of APP engineering operation system based on IOS system | |
| CN111324379B (en) | Model deployment system based on general SOA service | |
| CN102693183A (en) | Method and system for realizing automatic software testing | |
| CN112965786A (en) | Continuous integration and continuous delivery method and device based on containerization | |
| CN112083948B (en) | Automatic construction and deployment method and tool based on data configuration | |
| CN112260877A (en) | AI-based RPA robot management method, platform and storage medium | |
| CN110471648A (en) | A kind of implementation method of the distributed CI/CD based on asynchronous mechanism | |
| CN109933519A (en) | Automated testing method, device, system, medium and electronic equipment | |
| EP4246332A1 (en) | System and method for serverless application testing | |
| CN114461269A (en) | Software development release management method, device, equipment and storage medium | |
| CN111324599A (en) | Block chain experiment system and management method | |
| CA2349654A1 (en) | Server configuration versioning tool | |
| CN112435072A (en) | Model creating method and device, electronic equipment and storage medium | |
| CN116599881A (en) | Cloud platform tenant modeling test method, device, equipment and storage medium | |
| CN116400950A (en) | DevOps element pipeline system based on version control | |
| CN114265595B (en) | Cloud native application development and deployment system and method based on intelligent contracts | |
| CN113515293B (en) | Method and system for managing DevOps toolchain | |
| CN111913706B (en) | Topology construction method of dispatching automation system, storage medium and computing equipment |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |