CN112379969A - Continuous integrated delivery method based on containerized application and related equipment - Google Patents

Continuous integrated delivery method based on containerized application and related equipment Download PDF

Info

Publication number
CN112379969A
CN112379969A CN202011270487.7A CN202011270487A CN112379969A CN 112379969 A CN112379969 A CN 112379969A CN 202011270487 A CN202011270487 A CN 202011270487A CN 112379969 A CN112379969 A CN 112379969A
Authority
CN
China
Prior art keywords
application
file
continuous integration
test
integration process
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
Application number
CN202011270487.7A
Other languages
Chinese (zh)
Other versions
CN112379969B (en
Inventor
张青南
张凯磊
李明泽
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Life Insurance Co Ltd China
Original Assignee
China Life Insurance Co Ltd China
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China Life Insurance Co Ltd China filed Critical China Life Insurance Co Ltd China
Priority to CN202011270487.7A priority Critical patent/CN112379969B/en
Publication of CN112379969A publication Critical patent/CN112379969A/en
Application granted granted Critical
Publication of CN112379969B publication Critical patent/CN112379969B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45562Creating, deleting, cloning virtual machine instances
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45575Starting, stopping, suspending or resuming virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

One or more embodiments of the present specification provide a containerized application-based persistent integrated delivery method and related apparatus, the method including: defining a first file under a root directory of a code project, wherein the first file is used for describing a continuous integration process and a dependency relationship of related tools so as to execute the continuous integration process; and performing trigger starting setting on the continuous integration process defined in the first file, wherein the trigger starting of the continuous integration process is integrated on a module visual interface. The continuous integration defining process is preposed, and a developer defines a continuous integration task in a program coding stage, so that the waste of personnel is reduced.

Description

Continuous integrated delivery method based on containerized application and related equipment
Technical Field
One or more embodiments of the present disclosure relate to the field of containerized application technologies, and in particular, to a persistent integrated delivery method and related apparatus based on containerized applications.
Background
An assembly line in a factory produces consumer goods from raw materials in a fast, automated, repeatable manner. Also, the software delivery pipeline generates releases from source code in a fast, automated, and repeatable manner. The process of starting an assembly line is referred to as "sustained integration" (CI), and the overall design of how this is done is referred to as "sustained delivery" (CD).
The container technology is developed vigorously to drive the change of CI/CD work, and the traditional program delivery, script delivery, configuration delivery and mirror image delivery are derived. Fragmented results delivery, gradually replaced by mirrored delivery.
Compared with the traditional construction and program release efficiency, the efficiency of the continuous integration step is improved, but a special post personnel is required to be configured between the program coding stage and the program construction stage to set a task configuration file which is depended on for completing the continuous integration task, so that the efficiency is improved, but the labor cost is increased; in addition, in the deployment test stage of the application, the multi-service is generally deployed and upgraded through the non-visual back-end script, and the program is complex and is prone to errors. However, in the continuous delivery step, the completion degree of the continuous delivery is greatly reduced due to the current situation of network isolation of the test environment and the production environment.
Disclosure of Invention
In view of the above, an object of one or more embodiments of the present disclosure is to provide a persistent integration delivery method and related apparatus based on containerized applications, so as to solve the problems encountered in the prior art regarding persistent integration and persistent delivery processes.
In view of the above, one or more embodiments of the present specification provide a continuous integrated delivery method based on containerized applications, including:
defining a first file under a root directory of a code project, wherein the first file is used for describing a continuous integration process and a dependency relationship of related tools so as to execute the continuous integration process;
performing trigger starting setting on the continuous integration process defined in the first file, wherein the trigger starting of the continuous integration process is integrated on a module visual interface; and the trigger starting setting is matched with the first file to complete the triggering and execution of the continuous integration process.
Further, the continuous integration process comprises:
pulling the source code engineering in the program coding stage to a program construction platform to obtain a program construction result;
performing quality detection, safety scanning and automatic testing on the program construction result;
packaging the program construction result passing the test into a Docker application mirror image;
deploying at least one application formed by the Docker application mirror image to a testing rancher platform through a first group of configuration files in a one-key mode, and carrying out functionality testing on the application;
storing the first set of configuration files and a second set of configuration files describing the application in a test application store.
Further, the first file is a jenkinsfile file.
Further, the deploying at least one application formed by the Docker application image to a testing rancher platform by one key through a first set of configuration files, and performing functionality testing on the application includes:
the jenkinsfile calls a ranker container management platform open api interface built based on a cattle scheduling framework through a shell command, a deployment test action is triggered, and an application formed by at least one Docker application image in a hardor image warehouse is deployed to a testing ranker platform through a first group of configuration files by one key;
performing a functionality test on the application;
writing problem repair codes aiming at problems encountered in the application testing process, and submitting the problem repair codes to a gitlab tool, thereby automatically triggering the continuous integration process.
Further, the storing the first set of configuration files and the second set of configuration files describing the application in a test application store, comprising:
defining a first group of configuration files related to the running mode of the system related to the service corresponding to the Docker application image and the incidence relation among the services, and placing the configuration files in a test application store; the first set of configuration files are used for deploying an application key formed by at least one Docker application image passing the test to a testing rancher platform for running;
a second set of profiles describing the application is defined and placed in a test application store.
Further, still include:
submitting at least one Docker application mirror image used for forming the application from a hardor mirror image warehouse to a buffer mirror image warehouse and submitting the Docker application mirror image from the buffer mirror image warehouse to a production application mirror image warehouse;
and transmitting the configuration file in the test application store to a production application store, executing a deployment action, and realizing that the application formed by at least one Docker application image is deployed to a production ran-cher platform to run through one key of the configuration file in the production application store.
Furthermore, a firewall between the hardor mirror image warehouse and the buffer mirror image warehouse and a firewall between the buffer mirror image warehouse and the production application mirror image warehouse are damaged by a black and white list or a port release strategy, so that the mirror image files in the three mirror image warehouses can be transmitted in sequence.
Based on the same inventive concept, one or more embodiments of the present specification further disclose a continuous integrated delivery apparatus based on containerized application, including:
the program coding submodule defines a first file under a root directory of a code project, and the first file is used for describing a continuous integration process and the dependency relationship of related tools so as to execute the continuous integration process;
the continuous integration task definition sub-module is used for carrying out trigger starting setting on the continuous integration process defined in the first file, wherein the trigger starting of the continuous integration process is integrated on a module visual interface; and the trigger starting setting is matched with the first file to complete the triggering and execution of the continuous integration process.
Based on the same inventive concept, one or more embodiments of the present specification further disclose an electronic device, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor implements the above method when executing the program.
Based on the same inventive concept, one or more embodiments of the present specification also disclose that the non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the above-mentioned method.
As can be seen from the above description, according to one or more embodiments of the present disclosure, a continuous integration delivery method based on containerized applications and related devices thereof, a definition process of continuous integration is advanced, a developer defines a continuous integration task in a program coding stage, a docker tool stores a build result in a mirror image warehouse in a mirror image manner, and an application is automatically deployed by one key under multiple sets of test environments by means of an open api provided by a test ranker management platform implemented based on a cattle scheduling framework, so as to provide multiple sets of verification environments for developers and testers. In addition, a connecting channel between the test environment and the production environment is established, and the application mirror image is pushed to a buffer mirror image application warehouse in an automatic mode, so that a deployment team does not need to copy and move the edition-sending finished product (such as a Docker application mirror image) again; the deployment or upgrading of the application is finished in a key way by directly using the function of a production application store on a production ran-cher management platform.
Drawings
In order to more clearly illustrate one or more embodiments or prior art solutions of the present specification, the drawings that are needed in the description of the embodiments or prior art will be briefly described below, and it is obvious that the drawings in the following description are only one or more embodiments of the present specification, and that other drawings may be obtained by those skilled in the art without inventive effort from these drawings.
FIG. 1 is a schematic flow diagram of a method for continuous integrated delivery based on containerized applications according to one or more embodiments of the present disclosure;
FIG. 2 is a schematic flow diagram of the continued integration step according to one or more embodiments of the present disclosure;
FIG. 3 is a schematic flow diagram of the deployment test phase in accordance with one or more embodiments of the present disclosure;
FIG. 4 is a schematic illustration of the sustained delivery step according to one or more embodiments of the disclosure;
FIG. 5 is a schematic diagram of a continuous integrated delivery apparatus based on containerized applications according to one or more embodiments of the present disclosure;
FIG. 6 is a schematic structural diagram of the persistent integration module in accordance with one or more embodiments of the present disclosure;
FIG. 7 is a block diagram of the persistent delivery module in accordance with one or more embodiments of the present disclosure;
fig. 8 is a schematic structural diagram of an electronic device according to one or more embodiments of the present disclosure.
Detailed Description
For the purpose of promoting a better understanding of the objects, aspects and advantages of the present disclosure, reference is made to the following detailed description taken in conjunction with the accompanying drawings.
It is to be understood that unless otherwise defined, technical or scientific terms used in one or more embodiments of the present disclosure should have the ordinary meaning as understood by one of ordinary skill in the art to which this disclosure belongs. The use of "first," "second," and similar terms in one or more embodiments of the specification is not intended to indicate any order, quantity, or importance, but rather is used to distinguish one element from another. The word "comprising" or "comprises", and the like, means that the element or item listed before the word covers the element or item listed after the word and its equivalents, but does not exclude other elements or items. The terms "connected" or "coupled" and the like are not restricted to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "upper", "lower", "left", "right", and the like are used merely to indicate relative positional relationships, and when the absolute position of the object being described is changed, the relative positional relationships may also be changed accordingly.
As described in the background art, in the continuous integration process in the prior art, a technician who needs to set a special post builds a task configuration file that a continuous integration task depends on, which consumes labor; in addition, in the deployment test stage of the application, the multi-service is generally deployed and upgraded through the non-visual back-end script, and the program is complex and is prone to errors.
Interpretation of related technical terms;
jenkins: open source continuous construction platform
SonarQube open source code quality management platform
gitlab/svn: open source code management tool
JFrog arthritis/Nexus reproduction binary storage management tool
Fortify: safety scanning tool
Selenium: automatic change testing tool
Rancher: open source container management platform
Harbor: open source mirror image management warehouse
Rancher: containerization management platform
A bottle: containerized dispatch framework
In view of the above problems in the prior art, referring to fig. 1, one or more embodiments of the present specification provide a continuous integrated delivery method based on containerized applications, including:
s101, a continuous integration step, namely continuously integrating the source code engineering in a test environment to form at least one Docker application mirror image, wherein the at least one Docker application mirror image forms an application to run and test; setting a configuration file for deploying the application to a testing ranker platform by one key, wherein the configuration file is stored in a testing application store;
s102, a continuous delivery step, namely, continuously delivering at least one Docker application image forming the application to a production application image warehouse of a production environment, and transmitting a configuration file in the test application store to a production application store; and at least one Docker application image in the production application image warehouse is deployed to a production rancher platform through one key of a configuration file in the production application store.
Wherein the continuously integrating step is performed in a test environment and the continuously delivering step is performed in a production environment.
It should be noted that before the continuous integration process is performed, the integration platform and the third-party platform on which the continuous integration platform depends need to be built, which is specifically as follows:
the integrated platform is built, the operation platform is built by means of jenkins tools, the platform integrates open source tools maven and docker, the two tools are support tools which are necessary for continuous integration and continuous delivery, each tool is integrated to the jenkins platform in a jenkins plug-in mode, and each tool can be repeatedly used by all assembly line operations.
The method comprises the steps that a third-party platform is built, servers used for code safety scanning, code quality scanning and code automatic testing are built respectively, specifically, a code safety scanning server, a code quality scanning server and a code automatic testing server can be built respectively by means of tools such as fortify, sonarytte and selenium, and after the server building is completed, server addresses are configured to jenkins platforms respectively.
Referring to fig. 2, the continuous integration step includes a program encoding stage, a continuous integration task definition stage, a program building stage, a code testing stage, a packaging stage, a deployment testing stage, and a test application store delivery stage, which are sequentially arranged;
s201, in a program coding stage, a developer defines a first file and a second file under a root directory of a code project, wherein the first file is used for describing a continuous integration process and a dependency relationship of a related tool so as to execute the continuous integration process; the second file is used for defining configuration items on which the application runs;
in this phase, the code developed by the developer is submitted to the gitlab tool.
In this embodiment, the definition process of persistent integration is advanced to the program coding stage, that is, a developer sets a task configuration file that is relied on by the persistent integration process in the program coding stage, and no longer needs to configure a special post person to set the configuration file in the persistent integration task definition stage.
Further, the first file may be a jenkinsfile, and the second file may be a dockerfile.
Further, the continuous integration process comprises:
a program construction stage, wherein the source code engineering of the program coding stage is pulled to a program construction platform to obtain a program construction result;
a code testing stage, which is used for carrying out quality detection, safety scanning and automatic testing on the program construction result;
a packing stage, packing the program construction result passing the test into a Docker application mirror image;
a deployment test stage, namely deploying at least one application formed by the Docker application mirror image to a testing rancher platform through a first group of configuration files by one key, and performing functionality test on the application;
a test application store delivery stage, wherein the first set of configuration files and a second set of configuration files describing the application are stored in a test application store;
the first group of configuration files define the operation mode of the service related to the Docker application image and the incidence relation between the services.
The stages involved in the continued integration process are described in more detail in the examples that follow.
Further, the dependency relationship between the persistent integration process and the related tools is, for example, as follows: in the program construction stage, a source code project on a gitlab tool can be pulled to a jenkins platform by a maven tool; in the code testing stage, a sonarytte tool can be used for performing quality scanning action on a source code, a fortify tool can be used for performing security scanning on the source code, and a Selenium tool can be used for performing automatic code testing; in the packing stage, a Commit tool can be used for packing the binary program package into a Docker mirror image;
further, the configuration items may be embodied as base images (e.g., ubuntu, centros, etc.), runtime environments (e.g., tomcat, weblogic, etc.), service ports (e.g., 8080, 8088, 7001, etc.), and the like.
S202, a continuous integration task definition phase, which comprises a process that a developer triggers and starts each continuous integration process defined in the first file through a jenkins platform, wherein the triggering and starting of each integration process are integrated on a module visual interface; and the trigger starting setting is matched with the first file to complete the triggering and execution of the continuous integration process.
For example, in the program building phase, the source code engineering is stored on the gitlab tool, and the building of the program is completed on the jenkins platform, so the source code engineering on the gitlab tool needs to be pulled to the jenkins platform for building, and when the pulling action is triggered, the source code engineering needs to be completed in the persistent integration task definition phase.
The triggering starting mode can be manual triggering or timing triggering, and the two operation flows have no difference after starting in any mode.
In this embodiment, because the configuration file does not need to be set in the process, technicians in special posts do not need to be equipped, and labor waste is reduced.
S203, a program construction stage, which comprises a process of pulling the source code project of the program coding stage to a program construction platform, and obtaining a program construction result.
Specifically, a startup procedure building stage can be triggered by continuous integration tasks according to a jenkins file, a jenkins platform pulls a source code project on a gitlab to the jenkins platform through an integrated maven tool and compiles the source code, and a third party jar depended on in a compiling stage automatically obtains the source code from an intranet maven warehouse Nexus reproduction platform through a component warehouse address configured in a code project.
And S204, a code testing stage, which comprises the processes of quality detection, safety scanning and automatic testing of the program construction result.
Specifically, after the program construction is finished, according to a jenkins file, the continuous integration task triggers and starts the quality detection of the program construction result, the quality detection action is completed by depending on a sonarytte tool, the tool service address is configured on a jenkins platform, and the code quality scanning result can be checked after the scanning is completed.
After the quality detection is finished, according to the jenkins file, the task is continuously integrated to trigger and start the security scanning of the program construction result, the scanning action is completed by relying on a fortify tool, the process improves the system security inspection to the initial coding stage, and the cost and the influence surface of the later-stage program repair are reduced.
After the security scanning is finished, according to the jenkins file, the continuous integration task is triggered to start the automatic test of the program construction result, the automatic test action is completed by depending on a Selenium tool, the Selenium automatic test tool runs in a container mode, and after the automatic test is completed, the Selenium container is automatically destroyed, namely, the continuous integration platform provides a set of operation mode without a service framework for the automatic test, and the waste of resources is reduced.
It should be noted that the execution sequence of the three processes of quality detection, security scan and automation test is executed according to the defined sequence of jenkins file, and the sequence of this embodiment is only for illustration and is not used to limit the execution sequence.
S205, a packing stage, which comprises a process of packing the program construction result passing through the code testing stage into a Docker application mirror image.
Specifically, after the code testing stage is finished, according to a jenkins file, the integration task is continuously triggered to start the packing stage, namely, a Docker file under a source code engineering is read by using a Docker tool on a jenkins platform, a program construction result is packed into a Docker application mirror image through a Commit tool, and a hardor mirror image warehouse is automatically uploaded after tag of the Docker application mirror image is labeled.
S206, a deployment test stage, which comprises a process of deploying an application formed by at least one Docker application mirror image to a testing rancher platform through a first group of configuration files by one key and performing functionality test on the application;
specifically, referring to fig. 3, the deployment test phase includes:
s301, calling a ranker container management platform open api interface built based on a cattle scheduling framework by the jenkinsfile through a shell command, triggering a deployment test action, and deploying an application formed by at least one Docker application image in a hardor image warehouse to a testing ranker platform through a first group of configuration files by one key;
s302, performing a functionality test on the application;
and S303, writing problem repair codes aiming at the problems encountered in the application test process, and submitting the problem repair codes to a gitlab tool, so as to automatically trigger the continuous integration process (namely, sequentially triggering a program building stage, a code test stage, a packaging stage and a deployment test stage).
The configuration file defines the operation mode related to the service corresponding to the Docker application image and the incidence relation between the services.
Specifically, after the packing stage is finished, continuously integrating tasks to trigger and start a deployment test stage according to a jenkins file, preferably, the jenkins file calls a ran cher container management platform open api interface built based on a cattle scheduling framework through a shell command to trigger a deployment test action, so that an application formed by at least one Docker application mirror image in the harbor mirror image warehouse is deployed on a testing ran cher platform through a first group of configuration files by one key; in the automatic deployment process, a first group of configuration files required to be used are a Docker-composition.yml file and a remote-composition.yml file, the Docker-composition file is Docker general configuration, the relationship between services corresponding to a Docker application image and the service is defined, and the service runs the depended image; the RANCHER-compose is a configuration file specific to a testing RANCHER platform, is a supplement to the Docker-compose, defines the number of instances of a running container under the service, and is set to enable the application formed by at least one Docker application image to be deployed on the testing RANCHER platform as a key. Then, the tester performs functional test on the application, the tester feeds back problems encountered in the test process to the developer, the developer compiles problem repair codes and submits the problem repair codes to a gitlab tool; and then, according to the jenkins file, the continuous integration task sequentially triggers a program building stage, a code testing stage, a packaging stage and a deployment testing stage, namely, the repaired application is deployed to a testing rancher platform again, namely, the process is automatic when the program is converted from static code to container operation.
It should be noted that the one-key deployment process of the configuration file in this embodiment solves the problems of complicated procedure and easy error caused by the non-visual backend script for deploying and upgrading multiple services in the prior art. In addition, the prior art calls the api interface provided by K8s through a kubecect tool provided by a K8S scheduling framework, and the technology relies on the heavier K8s scheduling framework, so that the cattle is relatively lighter and more efficient.
S207, a delivery stage of the test application store, wherein the delivery stage comprises a process of storing the first set of configuration files and a second set of configuration files describing the application in the test application store.
That is, the configuration files in the test application store include at least the first set of configuration files and the second set of configuration files.
Specifically, the first group of configuration files has been specifically introduced in the deployment test stage, and is not described again; the second group of configuration files comprise a catalogIcon headed icon file and a config.xml global definition file; the icon file of the heading of the catalogIcon can be cattlogIcon-xxx.icon; xml file defines the name, description, version, etc. of the application.
The two groups of configuration files in the test application store enable development and operation and maintenance personnel to easily upgrade a plurality of services in parallel when the development and operation and maintenance personnel face dozens of or even hundreds of micro services.
In addition, in the prior art, the continuous delivery mode of the Docker application image is as follows: and manually packaging at least one Docker application image for forming the application in a harbor image warehouse into tgz files by the development and configuration post, uploading the tgz files to an ftp, copying tgz files on the ftp to a certain production server by production operation and maintenance personnel, and finally uploading tgz files to the production application image warehouse. The continuous delivery process in the prior art has a problem of network isolation between the test environment and the production environment, and the main reason for the network isolation is that a firewall is arranged between the hardor mirror image warehouse of the test environment and the production application mirror image warehouse of the production environment, so that the firewall needs to be avoided to carry out multiple uploading and copying processes, and the completion degree of the continuous delivery is greatly reduced.
To solve the above problem, as an alternative embodiment, referring to fig. 4, the continuous delivery step is configured to continuously deliver at least one Docker application image forming the application to a production application image repository of a production environment, and to transfer a configuration file in the test application store to a production application store; at least one Docker application image in the production application image warehouse is deployed to a production rancher platform through one key of a configuration file in the production application store; the method comprises the following steps:
s401, submitting at least one Docker application mirror image used for forming the application from a hardor mirror image warehouse to a buffer mirror image warehouse, and submitting the Docker application mirror image from the buffer mirror image warehouse to a production application mirror image warehouse; and the firewall between the hardor mirror image warehouse and the buffer mirror image warehouse and the firewall between the buffer mirror image warehouse and the production application mirror image warehouse are damaged by a black and white list or a port release strategy, so that the mirror image files in the three mirror image warehouses can be transmitted in sequence.
S402, transmitting the configuration file in the test application store to a production application store, executing deployment action, and realizing that the application formed by at least one Docker application image is deployed to a production ran-cher platform to run through one key of the configuration file in the production application store.
And manually uploading the first group of configuration files and the second group of configuration files in the delivery stage of the test application store into the production application store to obtain the configuration files of the production application store, in other words, the configuration files in the production application store are the same as the configuration files in the test application store, and are not described again.
It should be noted that the method of one or more embodiments of the present disclosure may be performed by a single device, such as a computer or server. The method of the embodiment can also be applied to a distributed scene and completed by the mutual cooperation of a plurality of devices. In such a distributed scenario, one of the devices may perform only one or more steps of the method of one or more embodiments of the present disclosure, and the devices may interact with each other to complete the method.
It should be noted that the above description describes certain embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
Based on the same inventive concept, corresponding to any embodiment method, one or more embodiments of the present specification further provide a continuous integrated delivery device based on containerized applications.
Referring to fig. 5, the continuous integrated delivery apparatus based on containerized application includes a continuous integrated module 501 and a continuous delivery module 502;
referring to fig. 6, the persistent integration module includes:
a program coding sub-module 601 configured to define a first file and a second file under a root directory of a code project, where the first file is used to describe a dependency relationship between a persistent integration process and a related tool, and the second file is used to define a configuration item on which an application runs;
the continuous integration task definition sub-module 602 is configured to perform trigger start setting on each continuous integration process defined in the first file through a jenkins platform, and the trigger start of each integration process is integrated on a module visual interface;
the program construction sub-module 603 is configured to pull the source code project in the program encoding stage to a program construction platform, and obtain a program construction result;
a code testing sub-module 604 configured to perform quality detection, security scanning, and automated testing of the program build results;
a packing sub-module 605 configured to pack the program building result that passes the code test into a Docker application image;
a deployment test sub-module 606 configured to deploy an application formed by at least one Docker application image to a testing ranker platform through a first set of configuration files by one key, and perform functionality test on the application;
a test application store delivery sub-module 607 configured to store the first set of profiles and a second set of profiles describing the applications in a test application store.
Referring to fig. 7, the sustained delivery module 702 includes:
a submission submodule 701 configured to submit at least one Docker application image used for forming the application from a hardor image repository to a buffer image repository, and submit the Docker application image from the buffer image repository to a production application image repository;
and a production deployment sub-module 702, which is used for transferring the configuration file in the test application store to a production application store, executing a deployment action, and implementing that the application formed by at least one Docker application image is deployed to a production ran-cher platform to run through the configuration file in the production application store by one key.
For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, the functionality of the modules may be implemented in the same one or more software and/or hardware implementations in implementing one or more embodiments of the present description.
The apparatus of the foregoing embodiment is used to implement a persistent integrated delivery method based on containerized applications in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiment, which are not described herein again.
Based on the same inventive concept, corresponding to any of the above-mentioned embodiments, one or more embodiments of the present specification further provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the program, the electronic device implements the persistent integrated delivery method based on containerized applications according to any of the above-mentioned embodiments.
Fig. 8 is a schematic diagram illustrating a more specific hardware structure of an electronic device according to this embodiment, where the electronic device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.
The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).
Bus 1050 includes a path that transfers information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.
It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
The electronic device of the foregoing embodiment is used to implement a persistent integrated delivery method based on containerized applications in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiment, which are not described herein again.
Based on the same inventive concept, corresponding to any of the above-described embodiment methods, one or more embodiments of the present specification further provide a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute a containerization application-based persistent integrated delivery method according to any of the above-described embodiments.
Computer-readable media of the present embodiments, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.
The computer instructions stored in the storage medium of the foregoing embodiment are used to enable the computer to execute a persistent integrated delivery method based on containerized applications according to any of the foregoing embodiments, and have the beneficial effects of corresponding method embodiments, which are not described herein again.
Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the spirit of the present disclosure, features from the above embodiments or from different embodiments may also be combined, steps may be implemented in any order, and there are many other variations of different aspects of one or more embodiments of the present description as described above, which are not provided in detail for the sake of brevity.
In addition, well-known power/ground connections to Integrated Circuit (IC) chips and other components may or may not be shown in the provided figures, for simplicity of illustration and discussion, and so as not to obscure one or more embodiments of the disclosure. Furthermore, devices may be shown in block diagram form in order to avoid obscuring the understanding of one or more embodiments of the present description, and this also takes into account the fact that specifics with respect to implementation of such block diagram devices are highly dependent upon the platform within which the one or more embodiments of the present description are to be implemented (i.e., specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the disclosure, it should be apparent to one skilled in the art that one or more embodiments of the disclosure can be practiced without, or with variation of, these specific details. Accordingly, the description is to be regarded as illustrative instead of restrictive.
While the present disclosure has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic ram (dram)) may use the discussed embodiments.
It is intended that the one or more embodiments of the present specification embrace all such alternatives, modifications and variations as fall within the broad scope of the appended claims. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of one or more embodiments of the present disclosure are intended to be included within the scope of the present disclosure.

Claims (10)

1. A continuous integrated delivery method based on containerized applications, comprising:
defining a first file under a root directory of a code project, wherein the first file is used for describing a continuous integration process and a dependency relationship of related tools so as to execute the continuous integration process;
performing trigger starting setting on the continuous integration process defined in the first file, wherein the trigger starting of the continuous integration process is integrated on a module visual interface; and the trigger starting setting is matched with the first file to complete the triggering and execution of the continuous integration process.
2. The continuous integrated delivery method based on containerized application of claim 1, wherein the continuous integration process comprises:
pulling the source code engineering in the program coding stage to a program construction platform to obtain a program construction result;
performing quality detection, safety scanning and automatic testing on the program construction result;
packaging the program construction result passing the test into a Docker application mirror image;
deploying at least one application formed by the Docker application mirror image to a testing rancher platform through a first group of configuration files in a one-key mode, and carrying out functionality testing on the application;
storing the first set of configuration files and a second set of configuration files describing the application in a test application store;
the first group of configuration files define the operation mode of the service related to the Docker application image and the incidence relation between the services.
3. The method of claim 1, wherein the first file is a jenkinsfile.
4. The method of claim 3, wherein the deploying, by one key, an application formed by at least one Docker application image to a testing ranker platform through a first set of configuration files and performing functionality testing on the application comprises:
the jenkinsfile calls a ranker container management platform open api interface built based on a cattle scheduling framework through a shell command, a deployment test action is triggered, and an application formed by at least one Docker application image in a hardor image warehouse is deployed to a testing ranker platform through a first group of configuration files by one key;
performing a functionality test on the application;
writing problem repair codes aiming at problems encountered in the application testing process, and submitting the problem repair codes to a gitlab tool, thereby automatically triggering the continuous integration process.
5. The method of claim 2, wherein storing the first set of configuration files and the second set of configuration files describing the application in a test application store comprises:
defining a first group of configuration files related to the running mode of the system related to the service corresponding to the Docker application image and the incidence relation among the services, and placing the configuration files in a test application store; the first set of configuration files are used for deploying an application key formed by at least one Docker application image passing the test to a testing rancher platform for running;
a second set of profiles describing the application is defined and placed in a test application store.
6. The method of claim 1, further comprising:
submitting at least one Docker application mirror image used for forming the application from a hardor mirror image warehouse to a buffer mirror image warehouse and submitting the Docker application mirror image from the buffer mirror image warehouse to a production application mirror image warehouse;
and transmitting the configuration file in the test application store to a production application store, executing a deployment action, and realizing that the application formed by at least one Docker application image is deployed to a production ran-cher platform to run through one key of the configuration file in the production application store.
7. The method of claim 6, wherein a firewall between the hardor mirror repository and the buffer mirror repository, and a firewall between the buffer mirror repository and the production application mirror repository are destroyed by a black and white list or port clearance policy so that the mirror files in the three mirror repositories can be transferred in sequence.
8. A continuous integrated delivery apparatus based on containerized applications, comprising:
the program coding submodule defines a first file under a root directory of a code project, and the first file is used for describing a continuous integration process and the dependency relationship of related tools so as to execute the continuous integration process;
the continuous integration task definition sub-module is used for carrying out trigger starting setting on the continuous integration process defined in the first file, wherein the trigger starting of the continuous integration process is integrated on a module visual interface; and the trigger starting setting is matched with the first file to complete the triggering and execution of the continuous integration process.
9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of any one of claims 1 to 7 when executing the program.
10. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1 to 7.
CN202011270487.7A 2020-11-13 2020-11-13 Continuous integrated delivery method based on containerized application and related equipment Active CN112379969B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011270487.7A CN112379969B (en) 2020-11-13 2020-11-13 Continuous integrated delivery method based on containerized application and related equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011270487.7A CN112379969B (en) 2020-11-13 2020-11-13 Continuous integrated delivery method based on containerized application and related equipment

Publications (2)

Publication Number Publication Date
CN112379969A true CN112379969A (en) 2021-02-19
CN112379969B CN112379969B (en) 2024-04-16

Family

ID=74582288

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011270487.7A Active CN112379969B (en) 2020-11-13 2020-11-13 Continuous integrated delivery method based on containerized application and related equipment

Country Status (1)

Country Link
CN (1) CN112379969B (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113190447A (en) * 2021-04-30 2021-07-30 成都新潮传媒集团有限公司 Method, device, equipment and storage medium for automatically merging codes
CN113535334A (en) * 2021-08-17 2021-10-22 成都长城开发科技有限公司 Docker-based project construction method, Docker-based project construction equipment and storage medium
CN114327478A (en) * 2021-12-27 2022-04-12 海信集团控股股份有限公司 Automatic application program delivery method and device
CN117114019A (en) * 2023-10-23 2023-11-24 天津异乡好居网络科技股份有限公司 Internationalized resource file extraction and back-filling method and device and continuous integration platform thereof

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108334437A (en) * 2018-03-02 2018-07-27 江苏电力信息技术有限公司 It is a kind of that acceptance method is delivered based on the software continuous of continuous integrating and automatic test
CN109814879A (en) * 2019-01-16 2019-05-28 福建省天奕网络科技有限公司 Automate CI/CD project dispositions method, storage medium
CN110083369A (en) * 2019-04-25 2019-08-02 中电科嘉兴新型智慧城市科技发展有限公司 A kind of continuous integrating and lasting delivery method based on container scheme
US10402302B1 (en) * 2018-03-13 2019-09-03 Red Hat Israel, Ltd. Reproduction of testing scenarios in a continuous integration environment
US20190303187A1 (en) * 2018-03-29 2019-10-03 The United States Of America As Represented By The Secretary Of The Navy Methods, devices, and systems for distributing software to and deploying software in a target environment
KR102118487B1 (en) * 2019-11-04 2020-06-03 주식회사 인재아이엔씨 Automatic quality inspection system and method of container based application for ci/cd
CN111259406A (en) * 2020-01-14 2020-06-09 中国传媒大学 Automatic construction method and system for cloud native application vulnerability reproduction environment
CN111552629A (en) * 2020-03-20 2020-08-18 北京海致星图科技有限公司 Docker-based continuous integration test environment construction method and system
CN111831396A (en) * 2020-07-10 2020-10-27 融慧金科金融服务外包(北京)有限公司 Docker software and hardware integration-based delivery method and device

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108334437A (en) * 2018-03-02 2018-07-27 江苏电力信息技术有限公司 It is a kind of that acceptance method is delivered based on the software continuous of continuous integrating and automatic test
US10402302B1 (en) * 2018-03-13 2019-09-03 Red Hat Israel, Ltd. Reproduction of testing scenarios in a continuous integration environment
US20190303187A1 (en) * 2018-03-29 2019-10-03 The United States Of America As Represented By The Secretary Of The Navy Methods, devices, and systems for distributing software to and deploying software in a target environment
CN109814879A (en) * 2019-01-16 2019-05-28 福建省天奕网络科技有限公司 Automate CI/CD project dispositions method, storage medium
CN110083369A (en) * 2019-04-25 2019-08-02 中电科嘉兴新型智慧城市科技发展有限公司 A kind of continuous integrating and lasting delivery method based on container scheme
KR102118487B1 (en) * 2019-11-04 2020-06-03 주식회사 인재아이엔씨 Automatic quality inspection system and method of container based application for ci/cd
CN111259406A (en) * 2020-01-14 2020-06-09 中国传媒大学 Automatic construction method and system for cloud native application vulnerability reproduction environment
CN111552629A (en) * 2020-03-20 2020-08-18 北京海致星图科技有限公司 Docker-based continuous integration test environment construction method and system
CN111831396A (en) * 2020-07-10 2020-10-27 融慧金科金融服务外包(北京)有限公司 Docker software and hardware integration-based delivery method and device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
丘晖;: "基于容器的持续集成和部署方法研究", 广东通信技术, no. 10, 15 October 2017 (2017-10-15), pages 66 - 70 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113190447A (en) * 2021-04-30 2021-07-30 成都新潮传媒集团有限公司 Method, device, equipment and storage medium for automatically merging codes
CN113535334A (en) * 2021-08-17 2021-10-22 成都长城开发科技有限公司 Docker-based project construction method, Docker-based project construction equipment and storage medium
CN113535334B (en) * 2021-08-17 2023-09-05 成都长城开发科技股份有限公司 Project construction method, device and storage medium based on Docker
CN114327478A (en) * 2021-12-27 2022-04-12 海信集团控股股份有限公司 Automatic application program delivery method and device
CN117114019A (en) * 2023-10-23 2023-11-24 天津异乡好居网络科技股份有限公司 Internationalized resource file extraction and back-filling method and device and continuous integration platform thereof
CN117114019B (en) * 2023-10-23 2024-01-12 天津异乡好居网络科技股份有限公司 Internationalized resource file extraction and back-filling method and device and continuous integration platform thereof

Also Published As

Publication number Publication date
CN112379969B (en) 2024-04-16

Similar Documents

Publication Publication Date Title
CN112379969B (en) Continuous integrated delivery method based on containerized application and related equipment
CN110928529B (en) Method and system for assisting operator development
CN105718289B (en) Component relation establishing method and equipment
US11389960B2 (en) Systems and methods for robotic process automation
EP2615555A1 (en) Framework for automated testing of mobile apps
CN111026403A (en) Packing deployment method and device, computer equipment and storage medium
CN107526676B (en) Cross-system test method and device
CN101930400A (en) SDK (Software Development Kit) automatic test system and method
CN110647470B (en) Test method, manufacturing method, device, medium and electronic equipment
US11068243B2 (en) Application stack builder based on node features
CN106874028A (en) Using dispositions method and device
US11995444B2 (en) Systems and methods for modernizing legacy applications
CN117093286B (en) Plug-in generation method, device, equipment and computer readable storage medium
US20170344458A1 (en) System and method for determining relevance of application software maintenance
CN103150161B (en) Based on task encapsulation method and the device of MapReduce computation module
CN114489704A (en) Version compiling and deploying method and device based on strategy
CN113138768A (en) Application package generation method and device, electronic equipment and readable storage medium
CN117492804A (en) Customized operating system based on information creation environment
CN111443944A (en) Program construction method, device and equipment
CN116382718A (en) Code offline deployment method and device, computer equipment and storage medium
CN116599881A (en) Cloud platform tenant modeling test method, device, equipment and storage medium
CN116974716A (en) Scheduling task issuing method and device, electronic equipment and storage medium
CN115248680A (en) Software construction method, system, device, medium, and program product
CN114942887A (en) Program safety testing method, device, equipment and medium
CN115185599A (en) Project deployment method, system and storage medium based on Golang

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