CN118656085A - Microservice publishing method, device, terminal device and storage medium - Google Patents

Abstract

The present application discloses a microservice publishing method, apparatus, terminal device and storage medium, which relates to the field of microservice management. The method includes: obtaining branch code data; generating an image file according to the branch code data, and building a microservice image through the image file, wherein the microservice image includes a microservice name and branch information; generating a declarative file according to the microservice name and the branch information; and publishing the microservice image through a preset container orchestration cluster according to the declarative file. The present invention can improve the publishing efficiency of microservices.

Description

Microservice publishing method, device, terminal device and storage medium

Technical Field

The present invention relates to the field of microservice management, and in particular to a microservice publishing method, apparatus, terminal equipment and storage medium.

Background Art

With the continuous development and progress of society, microservice architecture has become one of the important trends in modern software development. Microservice architecture splits complex applications into smaller and more independent service components, which can be developed, tested and deployed independently, thereby improving development efficiency and product quality. At the same time, microservice architecture also supports rapid iteration and flexible scalability. In the microservice architecture, each service can be developed, tested and deployed independently, which means that the team can focus more on their work and reduce the cost of collaboration and communication.

The currently commonly used microservice release method relies on manual operations and interactions, that is, developers mainly manually perform various steps of microservice release. The process is cumbersome, error-prone, and lacks automation and continuous integration features. Therefore, this microservice release method still has the problem of low release efficiency.

Summary of the invention

The main purpose of the present invention is to provide a microservice publishing method, apparatus, terminal device and storage medium, which can improve the publishing efficiency of microservices.

To achieve the above object, the present invention provides a microservice publishing method, the method comprising:

Get branch code data;

Generate an image file according to the branch code data, and build a microservice image through the image file, wherein the microservice image includes a microservice name and branch information;

Automatically generate a declarative file according to the microservice name and the branch information;

According to the declarative file, the microservice image is published through a preset container orchestration cluster.

Optionally, the step of obtaining branch code data includes:

Get the object code;

Storing the target code in the code repository Gitlab;

According to the process configuration gitflow, the code warehouse Gitlab performs branch management on the target code to obtain branch code data.

Optionally, the step of generating an image file according to the branch code data, and building a microservice image through the image file, wherein the microservice image includes a microservice name and branch information, comprises:

Get the image template file;

Automatically generate an image file according to the image template file and the code version number, wherein the code version number is included in the branch code data;

The branch code data is mirrored according to the mirror file to obtain a microservice mirror, where the microservice mirror includes a microservice name and branch information.

Optionally, the step of automatically generating a declarative file according to the microservice name and the branch information includes:

Get declarative template files and publishing instructions;

Send the microservice image to an image warehouse, which stores and manages the microservice image;

According to the publishing instruction, the microservice name and the branch information are obtained from the image repository, and a declarative file is automatically generated according to the declarative template file, the microservice name and the branch information.

Optionally, the step of publishing the microservice image through a preset container orchestration cluster according to the declarative file includes:

Sending the declarative file to a preset container orchestration cluster according to the environment type in the branch information;

According to the declarative file, obtain the microservice image through the container orchestration cluster;

The microservice image is published through the container orchestration cluster.

Optionally, the step of obtaining a microservice image through the container orchestration cluster according to the declarative file includes:

Obtaining access rights to the image repository through the container orchestration cluster;

According to the access permission and the image address, the image is pulled from the image repository through the container orchestration cluster to obtain a microservice image, and the image address is included in the declarative file.

Optionally, after the step of publishing the microservice image through the container orchestration cluster, the step includes:

The microservice image is supervised by the preset container management platform Rancher to obtain microservice data, which includes microservice instance status and log information;

According to the microservice instance status and the log information, the microservice is adjusted through the container management platform Rancher.

The present application also provides a microservice publishing device, which includes:

A data acquisition module, used to acquire branch code data;

An image building module, used to generate an image file according to the branch code data, and build a microservice image through the image file, wherein the microservice image includes a microservice name and branch information;

A file generation module, used to automatically generate a declarative file according to the microservice name and the branch information;

The microservice publishing module is used to publish the microservice image through a preset container orchestration cluster according to the declarative file.

An embodiment of the present application also proposes a terminal device, which includes a memory, a processor, and a microservice publishing program stored in the memory and executable on the processor, wherein the microservice publishing program implements the steps of the microservice publishing method described above when executed by the processor.

An embodiment of the present application further proposes a computer-readable storage medium, on which a microservice publishing program is stored. When the microservice publishing program is executed by a processor, the steps of the microservice publishing method as described above are implemented.

The microservice publishing method, apparatus, terminal device and storage medium proposed in the embodiments of the present application obtain branch code data; generate an image file according to the branch code data, and build a microservice image through the image file, wherein the microservice image includes a microservice name and branch information; generate a declarative file according to the microservice name and the branch information; and publish the microservice image through a preset container orchestration cluster according to the declarative file. Since image files and declarative files play a key role in the microservice publishing process, when a large number of microservices need to be published, for each microservice, each publication requires manual modification of the corresponding image files and declarative files, and the process is very cumbersome and inefficient. The image files and declarative files in this solution are automatically generated according to the corresponding data, and no human intervention is required. Therefore, in this way, not only the probability of errors can be greatly reduced, but also the microservice publishing process can be made more automated, thereby improving the overall publishing efficiency of microservices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of the functional modules of a terminal device to which the microservice publishing device of the present application belongs;

FIG2 is a flow chart of a first exemplary embodiment of a microservice publishing method of the present application;

FIG3 is a flow chart of a second exemplary embodiment of a microservice publishing method of the present application;

FIG4 is a flow chart of a third exemplary embodiment of a microservice publishing method of the present application;

FIG5 is a flowchart of a fourth exemplary embodiment of a microservice publishing method of the present application;

FIG6 is a flowchart of a fifth exemplary embodiment of a microservice publishing method of the present application;

FIG7 is a flowchart of a sixth exemplary embodiment of a microservice publishing method of the present application;

FIG8 is a flow chart of a seventh exemplary embodiment of the microservice publishing method of the present application;

FIG9 is a flow chart of the microservice publishing method of the present application.

The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings.

DETAILED DESCRIPTION

It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

The main solution of the embodiment of the present application is: by obtaining branch code data; generating an image file according to the branch code data, and building a microservice image through the image file, the microservice image includes a microservice name and branch information; generating a declarative file according to the microservice name and the branch information; according to the declarative file, publishing the microservice image through a preset container orchestration cluster. Since the image file and the declarative file play a key role in the microservice publishing process, when a large number of microservices need to be published, for each microservice, each publication requires manual modification of the corresponding image file and declarative file, and the process is very cumbersome and inefficient. The image file and declarative file in this solution are automatically generated according to the corresponding data, and no human intervention is required. Therefore, through this method, not only the probability of error can be greatly reduced, but also the microservice publishing process can be made more automated, thereby improving the overall publishing efficiency of microservices.

This embodiment takes into account that with the development and progress of society, microservice architecture has become one of the important trends in modern software development. Microservice architecture splits complex applications into smaller and more independent service components, which can be independently developed, tested and deployed, thereby improving development efficiency and product quality. The currently commonly used microservice publishing method relies on manual operations and interactions, that is, the various steps of microservice publishing are mainly manually performed by developers. The process is cumbersome, error-prone and lacks automation and continuous integration features. Therefore, this microservice publishing method still has the problem of low publishing efficiency.

Based on this, an embodiment of the present application proposes a solution. During the microservice publishing process, an image file is automatically generated through the corresponding data and then a microservice image is built based on the image file. This allows the microservice image to be easily deployed and run in different environments. Through the automatically generated declarative file, the preset container orchestration cluster can automatically publish the corresponding microservice image. Through this method, microservices can be continuously integrated and continuously released in an automated manner, thereby improving the overall release efficiency of microservices.

Specifically, referring to Figure 1, Figure 1 is a functional module diagram of a terminal device to which the microservice publishing device of the present application belongs. The microservice publishing device can be a device independent of the terminal device and capable of data processing, or it can be carried on the terminal device in the form of hardware or software.

In this embodiment, the terminal device to which the microservice publishing apparatus belongs includes at least an output module 110 , a processor 120 , a memory 130 and a communication module 140 .

The memory 130 stores an operating system and a microservice publishing program, obtains branch code data; generates an image file according to the branch code data, and builds a microservice image through the image file, wherein the microservice image includes a microservice name and branch information; generates a declarative file according to the microservice name and the branch information; and publishes the microservice image through a preset container orchestration cluster according to the declarative file, wherein the microservice image is stored in the memory 130. The output module 110 may be a display screen, a speaker, etc. The communication module 140 may include a WIFI module, a mobile communication module, a Bluetooth module, etc., and communicates with an external device or server through the communication module 140.

Among them, when the microservice publishing program in the memory 130 is executed by the processor, the following steps are implemented:

Obtain branch code data; generate an image file according to the branch code data, and build a microservice image through the image file, wherein the microservice image includes a microservice name and branch information; generate a declarative file according to the microservice name and the branch information; and publish the microservice image through a preset container orchestration cluster according to the declarative file.

Furthermore, when the microservice publishing program in the memory 130 is executed by the processor, the following steps are also implemented:

Get the object code;

Storing the target code in the code repository Gitlab;

According to the process configuration gitflow, the code warehouse Gitlab performs branch management on the target code to obtain branch code data.

Furthermore, when the microservice publishing program in the memory 130 is executed by the processor, the following steps are also implemented:

Get the image template file;

Automatically generate an image file according to the image template file and a code version number, wherein the code version number is included in the branch code data;

The branch code data is mirrored according to the mirror file to obtain a microservice image, where the microservice image includes a microservice name and branch information.

Furthermore, when the microservice publishing program in the memory 130 is executed by the processor, the following steps are also implemented:

Get declarative template files and publishing instructions;

Send the microservice image to an image warehouse, which stores and manages the microservice image;

According to the publishing instruction, the microservice name and the branch information are obtained from the image repository, and a declarative file is automatically generated according to the declarative template file, the microservice name and the branch information.

Furthermore, when the microservice publishing program in the memory 130 is executed by the processor, the following steps are also implemented:

Sending the declarative file to a preset container orchestration cluster according to the environment type in the branch information;

According to the declarative file, obtain the microservice image through the container orchestration cluster;

The microservice image is published through the container orchestration cluster.

Furthermore, when the microservice publishing program in the memory 130 is executed by the processor, the following steps are also implemented:

Obtaining access rights to the image repository through the container orchestration cluster;

According to the access permission and the image address, the image is pulled from the image repository through the container orchestration cluster to obtain a microservice image, and the image address is included in the declarative file.

Furthermore, when the microservice publishing program in the memory 130 is executed by the processor, the following steps are also implemented:

The microservice image is supervised by the preset container management platform Rancher to obtain microservice data, which includes microservice instance status and log information;

According to the microservice instance status and the log information, the microservice is adjusted through the container management platform Rancher.

This embodiment uses the above scheme to obtain branch code data; generate an image file based on the branch code data, and build a microservice image through the image file, wherein the microservice image includes a microservice name and branch information; generate a declarative file based on the microservice name and the branch information; and publish the microservice image through a preset container orchestration cluster based on the declarative file. Since image files and declarative files play a key role in the microservice publishing process, when a large number of microservices need to be published, for each microservice, each publication requires manual modification of the corresponding image file and declarative file, and the process is very cumbersome and inefficient. The image file and declarative file in this scheme are automatically generated based on the corresponding data, and no human intervention is required. Therefore, this method can not only greatly reduce the probability of errors, but also make the microservice publishing process more automated, thereby improving the overall microservice publishing efficiency.

Referring to FIG. 2 , FIG. 2 is a flow chart of a first exemplary embodiment of a microservice publishing method of the present application.

An embodiment of the present invention provides a microservice publishing method, the method comprising:

Step S10, obtaining branch code data;

In software development, a version control system (such as Git) is usually used to manage code. When multiple functions need to be developed, versions released, or emergency fixes need to be carried out simultaneously, developers will create different branches based on the main development line to work in parallel.

Specifically, Gitflow is a Git branch model that provides a complete set of process specifications for team collaborative development based on the idea of branch management. The Gitflow process can include two long-term branches: master (main branch) and develop (development branch) and three short-term branches: feature (feature branch), release (release branch) and hotfix (repair branch).

Branch code data can be understood as various data generated during the development process, including code files, configuration files, test cases, documents, etc. on these branches. These data may cover the implementation of new features, bug fixes, performance optimization, etc.

Methods for obtaining branch code data may include:

Clone the entire repository: Use the clone command provided by the version control system (such as Git) to copy the entire repository including the code data of all branches to the local computer. For example, use the git clone command in Git to clone a remote repository to the local computer.

Switch to the specified branch: If you only need to obtain the code data of a specific branch, you can obtain it by switching branches. In Git, use the git checkout command to switch to the target branch, and then you can view the code data of the branch.

Download branch code compressed package: Some code hosting platforms (such as GitHub, GitLab) provide the function of downloading branch code. Therefore, after finding the corresponding branch on the platform, you can download the compressed package of the branch code. This method can avoid cloning the entire repository and only obtain the code data of a specific branch.

Use the API of a specific version control tool: Some version control tools provide API interfaces that can obtain branch code data programmatically. By calling these APIs, you can obtain information such as the code content and file list of a specified branch.

You can choose a suitable method to obtain branch code data according to the specific situation.

Step S20, generating an image file according to the branch code data, and building a microservice image through the image file, wherein the microservice image includes a microservice name and branch information;

After obtaining the branch code data, the image file can be automatically generated according to the branch code data.

Among them, the image file Dockerfile refers to a text file used to define the image. The image file contains a series of instructions and configuration items for building an executable Docker image. The image file can be used to control the image version and repeatedly deploy it, making it convenient for developers to quickly build consistent container images in different environments. In addition, the image file also provides a highly readable way to describe the image building process, making the image building and maintenance simpler and more reliable.

Specifically, the image file (Dockerfile) can be automatically generated through the template provided by the publishing platform. The publishing platform usually provides a series of predefined templates that contain common software configurations and environment settings as well as best practice recommendations. Developers can select the appropriate template based on the application requirements and provide some configuration parameters. Furthermore, the publishing platform can automatically generate the image file based on these related data.

After the image file is automatically generated, you can build a microservice image based on the image file.

Among them, a microservice image refers to a container image used to deploy and run a single microservice. In a microservice architecture, an application is split into multiple small, independent service units. Each service unit can be packaged as an independent container image. These images can be deployed to containerized platforms (such as Docker, Kubernetes, etc.) and managed and expanded through container orchestration tools.

Specifically, the steps of building a microservice image through an image file may include:

Write Dockerfile: Create an image file in the root directory of the microservice project, which contains the dependencies and environment settings required to build the microservice image. You can use commands such as base image, install software packages, copy project files, etc. to write the image file.

Build microservice images: Use Docker commands or other build tools to build microservice images. For example, you can use the docker build command to perform build operations and specify tags to identify the image.

Run the microservice container: Use the docker run command to start the microservice container. For example, docker run -p8080:8080my_microservice means mapping the container's port 8080 to the corresponding port of the host and running the image marked as my_microservice.

The above are general steps and guidelines. Since the specific circumstances of each microservice project may be different, they can be adjusted and modified according to the actual situation.

Step S30, automatically generating a declarative file according to the microservice name and the branch information;

The microservice name refers to the naming of a microservice. The microservice architecture is a method of splitting an application into a series of small, independent services. Since each service has its own specific functions and can be deployed, expanded, and managed independently, in the microservice architecture, each service has a clear and descriptive name for easy understanding and identification.

For example, an e-commerce application may contain multiple microservices, such as user service, product service, order service, etc. In this case, you can use naming methods such as "user-service", "product-service", "order-service", etc. to name the microservices. This naming method can help team members quickly understand the functions and responsibilities of each microservice.

Branch information refers to the branch name and its corresponding meaning used to manage code development and version control. Branch information can contain corresponding environment information. For example, the environment where the branch code in the development branch is located is the development environment, and the environment where the branch code in the test branch is located is the test environment. Through branch information, developers can easily understand and manage the purpose and environment of different branches in the code base, providing data support for subsequent orchestration of images.

A declarative file is a file that describes the system status or configuration. It declares the desired target state without specifying the specific steps to achieve that state. Specifically, the declarative file may include information such as the generated microservice image, the number of running microservice instances, and the resources required for the microservice.

Specifically, the declarative file format may include:

YAML: YAML is a human-readable data serialization format that can be used to describe configurations and data structures. In software development, YAML is used to write Kubernetes configuration files, Docker Compose files, etc.

JSON: JSON is a lightweight data exchange format that is easy to read and write. It can be used to describe REST API requests and responses, configuration files, etc.

Specifically, the steps of generating a declarative file according to the microservice name and branch information may include:

Determine the type of declarative file: Determine the type of declarative file to be generated, such as Kubernetes YAML file, Dockerfile, Swagger specification, etc. Different declarative file types have different syntax and structure.

Define a template: You can create a template-based file to automatically generate a declarative file, which can contain some placeholders or variables. The placeholders or variables are used to insert the microservice name and branch information into the corresponding locations. Furthermore, you can use a markup language (such as Jinja2, Mustache) or a scripting language (such as Python, Go) to define and process the template.

Parse microservice name and branch information: According to actual needs, you can manually enter the microservice name and branch information or obtain this information from other sources (such as version control systems, configuration files).

Filling the template: If a declarative template file exists, the parsed microservice name and branch information can be filled into the corresponding positions in the declarative template file. Specifically, this can be achieved through simple string replacement or more complex template engine functions.

Generate files: Generate the final declarative files based on the filled template. The generated files can be saved to a specified directory or output to a specific location for further use and deployment.

It should be noted that the automatic generation of declarative files needs to consider the correctness and security of the files. Make sure that the generated files comply with the corresponding syntax specifications, and perform proper validation and escape on the input when filling in the template to prevent potential security vulnerabilities.

In addition, the process of automatically generating declarative files can be integrated into the continuous integration/continuous deployment (CI/CD) pipeline to achieve automated building and deployment processes. This ensures that the corresponding declarative files are automatically generated for each code change, and improves development efficiency and deployment consistency.

Step S40, publishing the microservice image through a preset container orchestration cluster according to the declarative file;

After the declarative file is generated, the preset container orchestration cluster can publish the microservice image according to the declarative file.

Among them, the container orchestration cluster refers to an open source container orchestration platform for running and managing containerized applications. Specifically, the container orchestration cluster can be a Kubernetes cluster. The Kubernetes cluster provides a reliable and scalable way to deploy, scale and manage containerized applications, enabling developers to manage complex distributed systems more easily.

Specifically, the Kubernetes cluster manages containerized applications by using the Container Abstraction Layer, where the cluster uses a set of abstract concepts called Pods to organize and manage containers. A Pod is a combination of one or more related containers that share network and storage resources and run on the same node. The Kubernetes cluster is responsible for scheduling and managing the life cycle of the Pod to ensure the health of the Pod.

Through the information in the declarative file, such as the image address, the Kubernetes cluster can obtain the microservice image. After the Kubernetes cluster obtains the microservice image, the Kubernetes cluster can publish it and run it in the Pod to complete the entire microservice publishing process.

The microservice publishing method proposed in the embodiment of the present application obtains branch code data; generates an image file according to the branch code data, and builds a microservice image through the image file, wherein the microservice image includes a microservice name and branch information; generates a declarative file according to the microservice name and the branch information; and publishes the microservice image through a preset container orchestration cluster according to the declarative file. Since image files and declarative files play a key role in the microservice publishing process, when a large number of microservices need to be published, for each microservice, each publication requires manual modification of the corresponding image files and declarative files, and the process is very cumbersome and inefficient. The image files and declarative files in this solution are automatically generated according to the corresponding data, and no human intervention is required. Therefore, in this way, not only the probability of errors can be greatly reduced, but also the microservice publishing process can be made more automated, thereby improving the overall publishing efficiency of microservices.

Referring to FIG. 3 , FIG. 3 is a flow chart of a second exemplary embodiment of a microservice publishing method of the present application.

Based on the first embodiment, a second embodiment of the present application is proposed. The difference between the second embodiment of the present application and the first embodiment is that:

In this embodiment, step S10, obtaining branch code data, is refined, wherein the refining steps may include:

Step S11, obtaining the target code;

The target code refers to the complete code for the final released software or service. It includes all the necessary code and resources to enable it to be deployed and run in a specific environment. For the microservice architecture, the target code contains the code data that constitutes each microservice.

Methods for obtaining object code may include:

Obtained from open source projects: If the object code comes from an open source project, you can download the source code by accessing the code repository (such as GitHub) and compile it according to the instructions in the project documentation to generate the object code.

Obtained through third-party code repositories: Some third-party code repositories may provide precompiled target code, so you can obtain these codes from these code repositories and use them. For example, when using Python, you can use PyPI, the Python package index, to obtain precompiled Python modules.

Step S12, storing the target code in the code repository Gitlab;

Among them, the code repository Gitlab is a Git-based code hosting and collaboration platform that provides a private Git repository and a web interface, allowing users to easily manage, develop and deploy code. GitLab includes a range of tools and features, such as version control, continuous integration/deployment (CI/CD), project management, code review, issue tracking, etc., and supports integrations such as Slack, JIRA, etc.

Specifically, the steps of storing the target code in the code repository Gitlab may include:

Create a project: Log in to GitLab and create a new project on GitLab. Click the New Project button, fill in the project name, description and select the appropriate visibility option (private or public).

Clone the repository: Select a suitable folder on your local computer and open the command line terminal. Use the Git command to clone the newly created project repository to your local computer.

Add code: Copy or move your target code to the local repository folder you just cloned.

Submit changes: In the command line terminal, enter the path of the local warehouse folder and submit the code to the GitLab warehouse:

View code: After refreshing the GitLab page, you can see the pushed code on the project's code page and view the file history, compare and merge, and other operations on the GitLab interface.

Through the above steps, the target code can be stored in the GitLab code repository, which is convenient for subsequent version control, collaborative development, and other GitLab-related operations.

Step S13, configuring gitflow according to the process, and having the code repository Gitlab perform branch management on the target code to obtain branch code data;

Process configuration gitflow refers to a popular Git branch management workflow, which defines a set of branch naming conventions and branch management strategies used in software development.

Specifically, the branches generated by configuring gitflow to manage the target code can include:

Master branch: The master branch is used to store stable, releasable code. When development is completed and tested, the code will be merged into the master branch.

Development branch (Develop): The development branch is the main integration branch, and all feature development should be created from this branch. Developers develop on their own feature branches and merge the code into the development branch.

Feature branch: Each new feature or user story should be developed on an independent feature branch. Feature branches are created from development branches and merged back to development branches after development is completed. Test branches can be included in feature branches.

Release branch: The release branch is used to prepare for the release of a new version. When the functions on the development branch have been completed and tested, a release branch can be created from the development branch for final debugging and preparation.

Hotfix: If you find an urgent bug or problem in the production environment, you can create a hotfix branch from the main branch to solve the problem. After the hotfix branch is completed, it needs to be merged back to the main branch and the development branch.

The core idea of process configuration gitflow is to split the development process into different branches to improve the maintainability of the code and the flexibility of version control.

By configuring gitflow according to the process to manage the target code, you can get the branch code data.

Specifically, branch code data refers to the relevant data contained in the code in different branches under the management of the process configuration gitflow. Each branch can contain different code modifications, additions or deletions, as well as corresponding configuration files, resource files and other data required by the project. Branch code data can include information such as the code version number and the environment in which the code is located.

The main function of branch code data is to perform code management and version control in different development environments. By creating and using different branches, team members can perform independent development work in parallel without interfering with each other. Each branch can be used to implement different functions, fix bugs, perform tests, or generate images or containers for deployment and operation in different environments.

The microservice publishing method proposed in the embodiment of the present application obtains the target code; stores the target code in the code warehouse Gitlab; and according to the process configuration gitflow, the code warehouse Gitlab performs branch management on the target code to obtain branch code data. Storing the target code in the code warehouse Gitlab can help the team better manage and develop the code. Furthermore, in the code warehouse Gitlab, the target code is managed according to the process configuration gitflow. The process configuration gitflow can divide the development process into several types of branches for subsequent function development, version release and error repair. In this way, code conflicts can be effectively avoided and the efficiency of code management, development and release can be improved.

Referring to FIG. 4 , FIG. 4 is a flow chart of a third exemplary embodiment of a microservice publishing method of the present application.

Based on the second embodiment, a third embodiment of the present application is proposed. The difference between the third embodiment of the present application and the second embodiment is that:

In this embodiment, for step S20, an image file is generated according to the branch code data, and a microservice image is constructed by the image file. The microservice image includes a microservice name and branch information for refinement, wherein the refinement step may include:

Step S21, obtaining an image template file;

An image template file is a configuration file or blueprint used to create a container image. A container image is a lightweight, portable way of packaging software that contains all the dependencies, operating environment, and configuration information required to run an application.

An image template file contains the instructions and configuration information required to build a container image. It describes how to add, configure, and run a specific application or service based on a base image. Common image template file formats include Dockerfile (for Docker containers) and Kubernetes YAML files (for container orchestration).

An image template file usually includes the following:

Base image: Specifies the operating system image or other existing image used as the basis, such as Ubuntu, Alpine, etc.

Installation steps: Define the commands and dependencies required to install and configure the application in the container. This may include package manager commands, downloading and unpacking files, setting environment variables, etc.

Configuration file: Specifies the configuration options of the application, such as database connection string, port number, log, etc. These configurations can be passed to the container through environment variables, configuration files, or command line parameters.

Run command: Defines the command executed when the container starts and the entry point of the application, which can be starting a web server, running a script, starting a background service, etc.

Specifically, the method for obtaining the image template file may include:

Default templates provided by the publishing platform: Since the publishing platform provides some default image template files that are suitable for different types of applications, you can search for these default image template files in the documents or interfaces of the publishing platform and select the appropriate template to use as needed.

Shared templates: Find shared image template files through search engines, code hosting platforms (such as GitHub), or community forums. For example, Docker Hub provides a large number of image template files, so you can find the corresponding image template files that can be used to generate Dockerfile in their repositories.

Step S22, automatically generating an image file according to the image template file and the code version number, wherein the code version number is included in the branch code data;

After obtaining a suitable image template file, the image file can be automatically generated according to the image template file and the code version number.

Among them, the code version number refers to an identifier used to identify and recognize a specific version of the software code. It can be used to track and manage code changes, release different versions of software, and perform bug fixes and functional improvements on specific versions. The code version number can be included in the branch code data.

Specifically, in the process of configuring gitflow to manage the target code, the code version number can be represented by a tag. A tag is a reference created on a specific commit to identify a specific version of the code base. Using tags to represent the version number of the code can easily track and trace back to a specific version of history, while also providing reliable identification for different versions.

In the Gitflow workflow, tags are usually created based on different branches and stages. For example, common tags include:

Release tag: When releasing software, you can create a Release tag to identify the code of that version. Usually, when the code passes various tests and is ready for release, a Release tag is created on the main branch (usually the master branch).

Hotfix tag: When an urgent problem in the production environment needs to be fixed immediately, a Hotfix tag can be created. Hotfix tags are usually created based on the main branch and will not be affected by other development branches.

Specifically, the method for automatically generating an image file according to an image template file and a code version number may include:

Write Dockerfile: Write a Dockerfile file that describes how to build an image. In the Dockerfile, you can specify the image's base operating system, dependency installation, code copying, and other operations. Specifically, you can use commands like COPY to add code to the image. In this process, you can pass the code version number to the Dockerfile as a build parameter.

Use build tools: Use Docker or other build tools to build image files by executing build commands. In the build command, you can pass the code version number as a parameter for use in the build process. For example, in Docker, you can use the docker build command and pass the code version number to the Dockerfile through the -build-arg option.

Automation script: In order to realize the automation process of automatically generating image files, the above steps can be completed by writing a script. This script can receive the code version number as input and then execute the command to build the image. Through this method, when a new code version is released, you only need to run the script to automatically build the image file of the corresponding version.

Step S23, mirroring the branch code data according to the mirror file to obtain a microservice mirror, wherein the microservice mirror includes a microservice name and branch information;

After obtaining the image file, the branch code data can be mirrored according to the instructions contained in the image file to obtain a microservice image.

Specifically, the step of building the branch code data into an image according to the image file may include:

1. Prepare all the necessary files and codes in the directory of Dockerfile.

2. Open a terminal or command prompt and navigate to the directory containing the Dockerfile.

3. Execute the build command docker build -t image_name:tag path_to_dockerfile, where image_name:tag is the name and tag specified by the image, and path_to_dockerfile is the path where the Dockerfile is located. This command can automatically find and read the Dockerfile and build the image according to the instructions therein.

4. Docker will step by step complete the building process according to the instructions in the Dockerfile. During the building process, Docker will run each instruction in the Dockerfile, such as loading branch code data, installing dependencies, running build commands, etc.

5. After the build is complete, you can use the command docker images to list all built images to check whether the built image exists.

It should be noted that the above steps are one way to build a microservice image, and the specific method can be modified as needed.

Understandably, the container image obtained by packaging the source code and related dependencies of the microservice application into a Dockerfile and building the container image using the Docker command can be understood as a microservice image.

The microservice publishing method proposed in the embodiment of the present application obtains an image template file; automatically generates an image file according to the image template file and a code version number, wherein the code version number is included in the branch code data; mirrors the branch code data according to the image file to obtain a microservice image, wherein the microservice image includes a microservice name and branch information. According to the image template file and the code version number, the platform can automatically generate an image file for subsequent mirroring of the branch code data. Since the entire image file is automatically generated, the efficiency of the entire integration and publishing can be improved when facing a large number of microservice publishing and integration requirements.

Referring to FIG. 5 , FIG. 5 is a flow chart of a fourth exemplary embodiment of a microservice publishing method of the present application.

Based on the third embodiment, a fourth embodiment of the present application is proposed. The difference between the fourth embodiment of the present application and the third embodiment is that:

In this embodiment, step S30, automatically generating a declarative file according to the microservice name and the branch information, is refined, wherein the refinement step may include:

Step S31, obtaining a declarative template file and publishing instructions;

A declarative template file is a text file used to define infrastructure resources. It is usually written in YAML or JSON format. These files describe the required resource types, configurations, and properties, as well as the relationships between them, such as dependencies and references. It should be noted that declarative template files define infrastructure in a declarative manner rather than creating and configuring resources programmatically.

Declarative template files can be used with infrastructure management tools such as Kubernetes. Kubernetes can read declarative template files and automatically create and configure infrastructure resources according to the definitions in them. Declarative template files can also be used for version control and collaboration. Multiple developers can jointly edit and maintain a template file to better manage infrastructure changes and evolution.

A release instruction refers to an authorization instruction of an authorization mechanism. After building a microservice image for a branch code, the microservice image needs to be continuously released to each environment cluster. However, in order to prevent untested code from entering the production environment and causing serious problems, before releasing the microservice image, you can obtain release authorization information through a release instruction. Through the release instruction, you can obtain relevant information and generate a declarative file based on the relevant information. The declarative file can be used for the subsequent continuous release of the microservice image.

Specifically, the release instruction may include data for querying information related to branch code data, that is, the branch code data that can be used for subsequent release, such as the microservice name and branch information, can be queried through the release instruction. It can be understood that only by obtaining the release instruction can the information related to the branch code data that has been authorized for release be obtained and a declarative file corresponding to the branch code data be generated.

The method for obtaining declarative template files and release instructions can be through a version control system, that is, the declarative template files and release instructions can be stored in a version control system (such as Git) together with the code, to help developers or system platforms obtain the latest template files and release instructions.

Step S32, sending the microservice image to an image warehouse, which stores and manages the microservice image;

An image repository is a central repository for storing and managing container images. It is used to centrally manage and distribute container images. The image repository provides a centralized location for developers, operations personnel, and other relevant parties to obtain the required container images. The image repository can store multiple versions of images and provide tags or identifiers to uniquely identify each image. Specifically, the image repository can also provide some additional functions, such as permission control, image search, image building and release process, image review and verification, etc.

Step S33, according to the publishing instruction, obtaining the microservice name and the branch information from the image repository, and automatically generating a declarative file according to the declarative template file, the microservice name and the branch information;

After obtaining the release instructions, the microservice name and branch information can be obtained from the image repository according to the branch code data related data in the release instructions, and a declarative file can be automatically generated according to the obtained microservice name and branch information.

The microservice image obtained by mirroring the branch code data according to the image file carries the microservice name and branch information, wherein the branch information can reflect which code branch the branch code data comes from. Through this information, the microservice image can be published to the corresponding environment cluster for operation, and the publishing instruction carries the permission and query address for querying the branch code data. Therefore, the branch information can be obtained in the image repository through the query permission and query address. Similarly, the corresponding microservice name can also be obtained in the image repository through the publishing instruction.

Methods for automatically generating declarative files (such as deployment.yaml) based on declarative template files, microservice names, and branch information may include:

1. Read the required Kubernetes YAML configuration template from the declarative template file, such as the deployment.yaml file that contains deployment, service and other related configuration information.

2. Replace relevant variables in the YAML template: Based on the passed in microservice name and branch information, you can replace the variables in the YAML configuration template with specific values. For example, you can use a template engine like Mustache or Jinja2 to achieve this.

3. Get the information of the corresponding microservice image: You can connect to the Docker image repository based on the incoming branch information to obtain the name and version number of the corresponding microservice image.

4. Fill the image information and other necessary information into the YAML template: Fill the information obtained in steps 2 and 3 into the corresponding positions in the YAML template.

5. Specify the number of microservice running instances, required resources and other information as needed. This information can also be obtained from the incoming parameters and then added to the corresponding position in the YAML template.

6. Save the generated deployment.yaml to the specified location: Save the generated file to the Git repository or deploy the image directly through the Kubernetes API Server.

It should be noted that the specific implementation may vary. Here we only provide a basic implementation method for reference. At the same time, we also need to verify the generated declarative file to ensure that it can be correctly parsed and deployed by the Kubernetes cluster.

The microservice publishing method proposed in the embodiment of the present application obtains a declarative template file and a publishing instruction; sends the microservice image to an image repository, and the image repository stores and manages the microservice image; obtains the microservice name and the branch information from the image repository according to the publishing instruction, automatically generates a declarative file according to the declarative template file, the microservice name and the branch information, sends the microservice image to the image repository, and the image repository manages uploading and downloading the generated microservice image, which can improve the efficiency and reliability of deploying containerized applications, and obtains information such as the microservice name and branch information from the image repository according to the publishing instruction to prevent untested code from entering the production environment and causing serious problems. Finally, after obtaining the microservice name and branch information, a declarative file can be automatically generated according to the declarative template file. Since the declarative file is automatically generated according to the relevant information obtained by the publishing instruction, this method can not only improve the efficiency of obtaining declarative files, but also ensure that the obtained declarative files have high availability.

Referring to FIG. 6 , FIG. 6 is a flowchart of a fifth exemplary embodiment of a microservice publishing method of the present application.

Based on the fourth embodiment, a fifth embodiment of the present application is proposed. The difference between the fifth embodiment of the present application and the fourth embodiment is that:

In this embodiment, in step S40, according to the declarative file, the microservice image is published through a preset container orchestration cluster for refinement, wherein the refinement step may include:

Step S41, sending the declarative file to a preset container orchestration cluster according to the environment type in the branch information;

Among them, the environment type refers to the branch type of the code branch where the branch code is located in the process configuration gitflow. Since the microservice image is built by mirroring the branch code data, and the branch code data includes the branch type of the branch where the branch code is located, the microservice image will also contain the branch type. For example, if the code comes from the test branch, the microservice image built by the code will contain the environment type representing the test branch. In order to enable the microservice image to run in the corresponding container orchestration cluster (such as the kubernetes cluster), the declarative file can be sent to the cluster of the corresponding environment according to the environment type in the branch information contained in the microservice image.

Specifically, continuous release publishes different microservice images to different environments and runs them in the form of containers. For example, the microservice image of the development branch (Develop) is published to the cluster of the development environment, the microservice image of the test branch (UAT) is published to the cluster of the test environment, and the microservice image of the master branch (Master) is published to the cluster of the production environment.

In addition, there is physical isolation between the development, testing, and production environments to avoid mutual impact. At the same time, development, testing, and operation and maintenance each perform their respective duties and complete their respective work in the corresponding environment, greatly improving the work efficiency of engineers.

Step S42, obtaining a microservice image through the container orchestration cluster according to the declarative file;

After the container orchestration cluster obtains the declarative file, the container orchestration cluster can obtain the microservice image according to the relevant information in the declarative file, such as the image address.

Specifically, the container orchestration cluster can automatically pull the microservice image of the corresponding environment and deploy it according to the microservice name and version number specified in the declarative file. If you want to check whether the microservice image is successfully pulled, you can use the Kubernetes command line tool kubectl to check.

Step S43, publishing the microservice image through the container orchestration cluster;

After the container orchestration cluster obtains the microservice image, it can publish the microservice image.

Specifically, the method for publishing a microservice image may include:

Create a namespace: Create a namespace in the cluster to isolate different applications or services.

Create a service configuration: Create a service configuration file (Service Configuration) according to actual needs, which includes information such as service name, port number, protocol, etc. This will help cluster management and expose your microservices.

Create a deployment file: Use a declarative file to define the deployment configuration of the microservice. The deployment file should contain information such as the container image name, version number, resource requirements, and environment variables.

Application deployment: Use tools such as kubectl to apply the deployment file to the cluster, which will trigger the cluster to create the corresponding Pod according to the deployment file and pull the microservice image to the cluster node for running.

Verify release: Verify that the microservice is successfully released and working properly by accessing the service entry point to ensure that the service can respond to requests and provide functions as expected.

It should be noted that the above method is one of the microservice image release processes, and the specific steps can be adjusted according to actual conditions.

The microservice publishing method proposed in the embodiment of the present application sends the declarative file to a preset container orchestration cluster according to the environment type in the branch information; obtains the microservice image through the container orchestration cluster according to the declarative file; and publishes the microservice image through the container orchestration cluster. According to the environment type in the branch information, the generated declarative file can be sent to the container orchestration cluster of each environment. After the container orchestration cluster receives the declarative file, it can query and pull the relevant microservice image in the image repository according to the corresponding microservice image information in the declarative file, and finally publish the pulled microservice image in the cluster. Through this method, microservice images can be continuously published to the container orchestration cluster of the corresponding environment, thereby improving the continuous publishing efficiency of microservice images.

Referring to FIG. 7 , FIG. 7 is a flowchart of a sixth exemplary embodiment of a microservice publishing method of the present application.

Based on the fifth embodiment, a sixth embodiment of the present application is proposed. The difference between the sixth embodiment of the present application and the fifth embodiment is that:

In this embodiment, in step S42, the microservice image is obtained through the container orchestration cluster according to the declarative file and refined, wherein the refining step may include:

Step S421, obtaining image repository access rights through the container orchestration cluster;

Image repository access permissions refer to permissions required to pull microservice images from the image repository in a container orchestration cluster. When a container orchestration cluster needs to pull images from the image repository, the container orchestration cluster needs to provide legitimate credentials to verify its identity and obtain access permissions.

Specifically, methods for obtaining access rights to an image repository may include:

Username and password: Use username and password as credentials for authentication. Specifically, you can create a Secret object in the container orchestration cluster and store the username and password information in it. Further, reference the Secret object in the declarative file so that the cluster can use these credentials to pull the corresponding microservice image.

Token: Create an access token so that the cluster can use the token for authentication. Specifically, you can generate an access token in the image repository and store it in the cluster's Secret object. Then, specify the token information in the Secret object in the declarative file.

OAuth token: If the image repository supports OAuth authentication, you can generate an OAuth token and store it in the cluster's Secret object. Then, specify the token information in the Secret object in the declarative file.

The above are some ways to obtain access rights to the image repository. The specific way to obtain access rights to the image repository may depend on the image repository platform and authentication mechanism used.

Step S422, according to the access permission and the image address, pull the image from the image repository through the container orchestration cluster to obtain a microservice image, wherein the image address is included in the declarative file;

Specifically, after obtaining access rights to the image repository, the steps for the container orchestration cluster to pull the microservice image may include:

Apply declarative files: Use kubectl or other tools to deploy the declarative files to the cluster and create one or more Pods based on the definition of the declarative files. Then, the cluster pulls the corresponding microservice images from the image repository based on the access permissions and image address and runs them in these Pods.

Pull the image: According to the image address specified in the declarative file, the container orchestration cluster will verify the identity through access permissions and use the corresponding credentials to pull the microservice image from the image repository. The cluster will automatically handle the authentication process and download the required image file.

Get the microservice image: Once the image is pulled successfully, the container orchestration cluster will create the corresponding containers on the cluster nodes and build and run these containers using the pulled microservice image. In this way, you have successfully obtained the required microservice image.

The microservice publishing method proposed in the embodiment of the present application obtains image repository access rights through the container orchestration cluster; according to the access rights and the image address, the image is pulled from the image repository through the container orchestration cluster to obtain a microservice image, and the image address is included in the declarative file. According to the image repository access rights, the container orchestration cluster can access the image repository, and through the image address, the container orchestration cluster can query and pull the corresponding microservice image in the image repository to obtain the microservice image. Through this method, the container orchestration cluster can accurately and securely pull the corresponding microservice image, thereby improving the security of the system.

Referring to FIG. 8 , FIG. 8 is a flow chart of a seventh exemplary embodiment of the microservice publishing method of the present application.

Based on the sixth embodiment, a seventh embodiment of the present application is proposed. The difference between the seventh embodiment of the present application and the sixth embodiment is that:

In this embodiment, in step S43, after publishing the microservice image through the container orchestration cluster, the following further includes:

Step S50, supervising the microservice image through the preset container management platform Rancher to obtain microservice data, wherein the microservice data includes microservice instance status and log information;

After the microservice is released and running normally, you can use the container management platform (rancher) to manage it. The container management platform can monitor the microservice instance status, logs, and resource usage.

Among them, the container management platform Rancher is an open source container management platform designed to simplify the deployment, management and operation of containerized applications. It provides a unified interface and tool set to help users easily manage containerized applications and infrastructure in a production environment.

Specifically, the functions of the container management platform Rancher can include:

Multi-cluster management: Rancher can support the management of multiple Kubernetes clusters in different environments. Users can manage different types of container clusters through a unified visual interface without switching multiple management tools.

User-friendly interface: Rancher provides an intuitive and easy-to-use web interface that allows users to easily deploy, monitor, expand, and maintain clusters without having to delve into the underlying technical details.

Security and permission control: Rancher can support permission management for users and teams, and can define different roles and permission policies to ensure that only authorized personnel can perform specific operations.

Continuous Delivery and CI/CD: Rancher integrates continuous delivery (Continuous Delivery) and continuous integration/continuous deployment (CI/CD) tools, allowing users to automate deployment processes through the Rancher platform.

The microservice instance status refers to the current status of the microservice running in the container. Specifically, the microservice instance status may include the following information:

Running status: Indicates whether the microservice instance is running, stopped, or faulty.

Health status: indicates the health status of the microservice instance, such as whether it is normal, whether there are errors or warnings, etc.

Resource utilization: Indicates the utilization of computing resources (such as CPU, memory, and storage) currently used by the microservice instance.

Running time: indicates the running time of the microservice instance from startup to the current time.

Log information refers to the log records generated during the operation process. It includes the output, errors, warnings, and other log messages related to the microservice instance. By viewing the log information of the microservice instance, administrators and developers can track the execution process of the application, troubleshoot problems, and perform troubleshooting.

By monitoring the status of microservice instances and viewing log information, the container management platform Rancher can help users better understand the operating status of microservices, discover and solve problems in a timely manner, and thus improve the reliability and maintainability of applications.

Step S51, adjusting the microservice through the container management platform Rancher according to the microservice instance status and the log information;

Based on the microservice instance status and log information, the container management platform Rancher can adjust the microservice. Specifically, the adjustment operations may include:

Scaling: Determine whether to increase or decrease the number of microservice instances based on the status of the microservice instances and resource utilization. If you find that the resource utilization of a microservice instance is high, you can choose to scale up the instance and increase the number of its replicas to meet the load demand. Conversely, if the resource utilization of an instance is low, you can choose to scale down the instance and reduce the number of its replicas to save resources.

Fault recovery: By monitoring the health status and log information of microservice instances, you can promptly detect faulty instances. When a fault occurs, you can use the automatic fault recovery mechanism provided by the platform, such as automatically restarting the instance, replacing the faulty instance, etc. to ensure the availability of the microservice.

Log analysis and troubleshooting: The container management platform provides the function of aggregating and displaying the log information of microservice instances. Administrators and developers can search, filter, and view the logs of microservice instances to track the execution process of applications and perform troubleshooting. By analyzing the log information, problems can be quickly located and corresponding adjustment measures can be taken.

Performance optimization: By monitoring the resource utilization and performance indicators of microservice instances, potential performance bottlenecks or resource shortages can be discovered. Based on this information, adjustments can be made, such as adjusting the resource quota of microservices, optimizing configuration parameters, and redesigning the service architecture to improve the performance and scalability of microservices.

The microservice publishing method proposed in the embodiment of the present application supervises the microservice image through a preset container management platform Rancher to obtain microservice data, and the microservice data includes: adjusting the microservice through the container management platform Rancher according to the microservice instance status and the log information. According to the microservice instance status and the log information, the container management platform can provide targeted adjustment operations to help administrators and developers optimize the operating status of microservices and solve problems. This method can improve the reliability and performance of the overall application.

FIG9 is a flow chart of the microservice publishing method of the present application.

As shown in Figure 9, the overall process can be divided into the following steps:

Step S1: The developer submits the target code to the code repository (Gitlab). Specifically, Git can be used for version control. At the same time, the process configuration gitflow is used to manage the branches and versions of the code. The process configuration gitflow is a commonly used branch management strategy. By using the process configuration gitflow to manage the target code, code conflicts can be effectively avoided, code management efficiency can be improved, and development and release efficiency can be improved.

Step S2: After submitting the target code to the code repository (Gitlab) and creating a branch, continuous integration can be performed. The continuous integration process can be implemented based on container technology (Docker). In this process, an image can be created for the branch code data based on the image file (Dockerfile), and then the image can be pushed to the image repository (a warehouse used to uniformly manage container images, for uploading and downloading images). The image file (Dockerfile) is automatically generated based on a template on the publishing platform. When there are multiple microservices, no manual operation is required, which reduces the difficulty and error probability of publishing multiple microservices. At the same time, the image of each version of the microservice is stored in the image repository. When a problem occurs with a microservice, it can be traced back to which version of the image has the problem, and it can be rolled back to the previous normal version at any time.

Step S3: After the microservice image is created and uploaded to the image repository, it can be continuously released. During the continuous release process, different microservice images can be released to container orchestration clusters in different environments (such as the K8S cluster in Figure 9). The microservice image runs in the container orchestration cluster in the form of a container, as shown in Figure 9, where the microservice image of the development branch (Develop) is released to the development environment, the microservice image of the test branch (UAT) is released to the test environment, and the microservice image of the master branch (Master) is released to the production environment. It should be noted that the container orchestration clusters of each environment are isolated from each other to avoid mutual influence. At the same time, development, testing, and operation and maintenance each perform their duties and complete their respective work in the corresponding environment, greatly improving the work efficiency of engineers.

Step S4: Continuous publishing is based on container orchestration technology (Kubernetes), in which the publishing platform can automatically generate the declarative file deployment.yaml required by the container management cluster (Kubernetes container orchestration cluster) according to the microservice name and the code branch where the microservice is located (this file may include the microservice image generated in the above steps, the number of microservice running instances, the resources required for the microservice, and other information). Based on this declarative file, the microservice image can be run in the container orchestration cluster in the form of a container. In addition, the container orchestration cluster (Kubernetes cluster) can automatically schedule the microservice to a node with sufficient resources to run. When the microservice is abnormal, it can also be automatically pulled up. That is, the combination of microservices and container orchestration technology can greatly improve the stability of the microservice system.

Step S5: After the microservice is published and running normally, it can be managed by a container management platform (rancher). The container management platform can monitor the status, logs, and resource usage of the microservice instance, and can also expand, shrink, or update the microservice, as well as perform other management operations. Under the management of the container platform, the stability of the microservice can be further improved.

In addition, the embodiment of the present application also provides a microservice publishing device, the microservice publishing device comprising:

A data acquisition module, used to acquire branch code data;

An image building module, used to generate an image file according to the branch code data, and build a microservice image through the image file, wherein the microservice image includes a microservice name and branch information;

A file generation module, used to automatically generate a declarative file according to the microservice name and the branch information;

The microservice publishing module is used to publish the microservice image through a preset container orchestration cluster according to the declarative file.

For the principle and implementation process of implementing microservice release in this embodiment, please refer to the above embodiments and will not be repeated here.

In addition, an embodiment of the present application also proposes a terminal device, which includes a memory, a processor, and a microservice publishing program stored in the memory and executable on the processor, and the microservice publishing program implements the steps of the microservice publishing method described above when executed by the processor.

Since all the technical solutions of all the aforementioned embodiments are adopted when this microservice publishing program is executed by the processor, it has at least all the beneficial effects brought by all the technical solutions of all the aforementioned embodiments, which will not be described one by one here.

In addition, an embodiment of the present application also proposes a terminal device, which includes a memory, a processor, and a microservice publishing program stored in the memory and executable on the processor, and the microservice publishing program implements the steps of the microservice publishing method described above when executed by the processor.

Since all the technical solutions of all the aforementioned embodiments are adopted when this microservice publishing program is executed by the processor, it has at least all the beneficial effects brought by all the technical solutions of all the aforementioned embodiments, which will not be described one by one here.

Compared with the prior art, the microservice publishing method proposed in the embodiment of the present application obtains branch code data; generates an image file according to the branch code data, and builds a microservice image through the image file, wherein the microservice image includes a microservice name and branch information; generates a declarative file according to the microservice name and the branch information; and publishes the microservice image through a preset container orchestration cluster according to the declarative file. Since image files and declarative files play a key role in the microservice publishing process, when a large number of microservices need to be published, for each microservice, each publication requires manual modification of the corresponding image files and declarative files, and the process is very cumbersome and inefficient. The image files and declarative files in this solution are automatically generated according to the corresponding data, and no human intervention is required. Therefore, in this way, not only the probability of errors can be greatly reduced, but also the microservice publishing process can be made more automated, thereby improving the overall publishing efficiency of microservices.

It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or system including the element.

The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

The above are only preferred embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims (10)

1. A method of micro-service distribution, the method comprising:

acquiring branch code data;

Generating an image file according to the branch code data, and constructing a micro-service image through the image file, wherein the micro-service image comprises a micro-service name and branch information;

Generating a declaration file according to the micro-service name and the branch information;

and according to the declarative file, arranging the cluster to issue the micro-service mirror image through a preset container.

2. The micro service distribution method according to claim 1, wherein the step of acquiring branch code data comprises:

acquiring an object code;

Storing the object code to a code repository Gitlab;

According to flow configuration gitflow, branch management is performed on the target code by the code warehouse Gitlab to obtain branch code data.

3. The micro service distribution method according to claim 2, wherein the steps of generating an image file from the branch code data and constructing a micro service image from the image file, the micro service image including a micro service name and branch information include:

obtaining a mirror image template file;

Automatically generating an image file according to the image template file and a code version number, wherein the code version number is included in the branch code data;

and carrying out mirror image construction on the branch code data according to the mirror image file to obtain a micro-service mirror image, wherein the micro-service mirror image comprises a micro-service name and branch information.

4. The micro service distribution method according to claim 3, wherein the step of automatically generating the declarative file according to the micro service name and the branch information comprises:

acquiring a declarative template file and an issuing instruction;

The micro-service image is sent to an image warehouse, and the image warehouse performs storage management on the micro-service image;

and acquiring the micro-service name and the branch information from the mirror image warehouse according to the issuing instruction, and automatically generating a declaration file according to the declaration template file, the micro-service name and the branch information.

5. The micro service distribution method according to claim 4, wherein the step of distributing the micro service image through a preset container arrangement cluster according to the declarative file comprises:

According to the environment type in the branch information, sending the declaration file to a preset container arrangement cluster;

according to the declarative file, acquiring a micro-service image through the container arrangement cluster;

And distributing the micro-service image through the container arrangement cluster.

6. The micro-service distribution method according to claim 5, wherein the step of obtaining the micro-service image through the container arrangement cluster according to the declarative file comprises:

Obtaining mirror image warehouse access rights through the container arrangement cluster;

And pulling a mirror image in the mirror image warehouse through the container arrangement cluster according to the access right and the mirror image address to obtain a micro-service mirror image, wherein the mirror image address is included in the declaration file.

7. The method for publishing micro services of claim 6, wherein the step of publishing the micro service image through the container orchestration cluster comprises, after:

Monitoring the micro-service mirror image through a preset container management platform rancher to obtain micro-service data, wherein the micro-service data comprises micro-service instance states and log information;

And according to the micro-service example state and the log information, the micro-service is adjusted through the container management platform rancher.

8. A micro service distribution apparatus, characterized in that the micro service distribution apparatus comprises:

The data acquisition module is used for acquiring branch code data;

The image construction module is used for generating an image file according to the branch code data and constructing a micro-service image through the image file, wherein the micro-service image comprises a micro-service name and branch information;

the file generation module is used for automatically generating a declaration file according to the micro-service name and the branch information;

and the micro-service issuing module is used for issuing the micro-service mirror image through a preset container arrangement cluster according to the declaration file.

9. A terminal device, characterized in that it comprises a memory, a processor and a micro service distribution program stored on the memory and executable on the processor, which micro service distribution program, when executed by the processor, implements the steps of the micro service distribution method according to any of claims 1-7.

10. A computer readable storage medium, characterized in that it has stored thereon a micro service distribution program, which when executed by a processor, implements the steps of the micro service distribution method according to any of claims 1-7.