Method and device for managing cloud platform component version based on gitea

Abstract

The invention discloses a gitea-based cloud platform component version management method and device, and relates to the technical field of cloud platform version management.The method comprises the steps that gitea, postgres and a container mirror image warehouse are deployed on cloud platform nodes, a stable and mutually-associated basic operation environment is built, and support is provided for subsequent component management and platform upgrading; in an independent git warehouse, a component list in a cloud platform is stored in a specified file structure and format, the component list comprises names and versions of components and detailed address information of all chart packages, and unified management of component information is achieved. The version standard stored in a local git warehouse is utilized, through labeling and label difference analysis, a changed chart package and a container mirror image are extracted, and unified packaging is carried out to generate an upgrade package; the cloud platform is comprehensively upgraded by uploading an upgrade package, pushing information and a mirror image by using an upgrade tool and then deploying a changed chart package. According to the invention, the automation of effective management and upgrading of the cloud platform component version can be realized.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud platform version management, and specifically relates to a method and device for managing cloud platform component versions based on gitea. Background Art

[0002] As an extremely advanced container orchestration and scheduling system at present, Kubernetes demonstrates powerful and excellent container orchestration and scheduling capabilities. With its many advantages such as high efficiency, flexibility, and scalability, it has already become the mainstream foundation of the current cloud platform. In the continuous evolution process of the cloud platform, the expansion of functions, the improvement of performance, and the expansion of service scale all mean the upgrade of the load within Kubernetes.

[0003] The Chart package plays a key role in managing Kubernetes loads and is currently the mainstream method for Kubernetes load management. It organizes and deploys applications and their dependencies in a structured and reusable manner, greatly simplifying the deployment process of complex applications in the Kubernetes cluster.

[0004] In recent years, with the booming development of container technology and the increasing maturity of the container orchestration and scheduling system Kubernetes, many cloud platforms have chosen to run with Kubernetes as the infrastructure foundation. These cloud platforms provide a rich variety of services for users through the workloads deployed on Kubernetes. The workloads are usually managed by Helm Charts. As a package manager for Kubernetes, Helm can install, upgrade, and manage applications conveniently and quickly. When there are a large number of services hosted on the cloud platform, a large number of releases will be deployed to the Kubernetes cluster. At the same time, each Chart requires a large number of images to support its operation. When the cloud platform faces upgrade requirements, the upgrade management work for each Chart becomes relatively complex. The traditional cloud platform Chart management method is extremely prone to causing version chaos due to the lack of an effective version tracking and coordination mechanism, thus affecting the stable operation of the cloud platform and service quality. Summary of the Invention

[0005] In view of the requirements and deficiencies of the current technological development, the present invention provides a method and device for managing cloud platform component versions based on gitea. By deploying gitea on the cloud platform, the versions of current various components are recorded, and a standard and fast upgrade process for the services on the cloud platform is provided.

[0006] In the first aspect, the present invention provides a method for managing cloud platform component versions based on gitea. The technical solutions adopted to solve the above technical problems are as follows:

[0007] A method for managing component versions of a cloud platform based on Gitea, which includes the following steps:

[0008] S1. Build a stable and interconnected basic operating environment by deploying Gitea, Postgres, and a container image repository on cloud platform nodes, providing support for subsequent component management and platform upgrades;

[0009] S2. Store the component list in the cloud platform in a specified file structure and format in a separate Git repository, including the names, versions, and detailed address information of each chart package, to achieve unified management of component information;

[0010] S3. Utilize the version standards stored in the local Git repository, extract the changed chart packages and container images by tagging and analyzing tag differences, and generate an upgrade package by unified packaging;

[0011] S4. Achieve a comprehensive upgrade of the cloud platform by uploading the upgrade package, pushing information and images using the upgrade tool, and then deploying the changed chart packages.

[0012] Optionally, step S1 specifically includes:

[0013] S1.1. Deploy Gitea on cloud platform nodes to store the component list and chart packages of the cloud platform, and perform version management on the stored component list and chart packages to achieve standardized version management of the components deployed on the cloud platform. The specific operations for deploying Gitea on cloud platform nodes are as follows: Run Gitea in the system service mode. In the Unit configuration, set the dependencies of Gitea on docker.socket, docker.service, and gitea-postgres.service through Wants, After, and Requires. In the Service configuration, set the user to root, define the start, stop commands, and restart policy to ensure that it can be pulled up by the system in a timely manner when exiting abnormally; Run Gitea in container mode, start it through a script, use the docker run command to mount the local directories / var / gitea / app.ini and / var / gitea / data as the configuration file and data storage directory respectively, and at the same time set the version tag, network, port mapping, and restart policy;

[0014] S1.2. Deploy postgres on the cloud platform nodes. The specific operations include: running postgres in the form of a system service. The startup method includes pre-cleaning operations. Through the ExecStartPre and ExecStart commands, ensure that the old containers are cleaned before startup and postgres is started correctly. At the same time, run postgres in a container mode. Use the docker run command, mount the local configuration file directory, adopt the host network, set the version tag and restart policy, so as to store the images required for the chart package and provide data support for the deployment and upgrade of the chart package.

[0015] S1.3. Deploy a container image repository on the cloud platform nodes. The specific operations include: running the container image repository in the form of a system service. The startup and stop commands ensure that it can be pulled up by the system in time when it exits abnormally. Run the container image repository in a container mode. Use the docker run command, mount the local configuration file directory, adopt the host network, set the version tag and restart policy, store the images required for the chart package, and provide image support for the deployment and upgrade of the chart package.

[0016] Optionally, the specific steps involved in S2 include:

[0017] S2.1. Create a xxx.yaml file in the git repository. This file is used to store the version information of each component in the cloud platform. In the xxx.yaml file, use the component name as the key and the corresponding component version as the value, and store them in the form of key-value pairs.

[0018] S2.2. For each chart package, create a corresponding chart.yaml file. The chart.yaml file is used to store the detailed information of the chart package, including the schema and metadata structure definitions, the information storage in the data part, and the address record in the source part. Among them, the information storage in the data part specifically includes the chart package name, the deployment instance name, and the deployment namespace. The address record in the source part specifically includes the save address of the chart package in gitea, which is used to record the storage location of the chart package in gitea.

[0019] Optionally, the specific steps involved in S3 include:

[0020] S3.1. In the local git repository, store the component list information and chart address information according to the cloud platform component management model, and build the standard record of the current version.

[0021] S3.2. After the development of each version is completed, perform tagging operations on the component list information project and each chart project respectively. Each tag corresponds to a set version.

[0022] S3.3. Develop a packaging tool. When packaging, the packaging tool obtains the differences between the component list information and project tags, and finds the changed chart packages and container images based on the tag differences.

[0023] S3.4. Package the obtained differentiated chart packages and container images uniformly to form an upgrade package for cloud platform upgrade.

[0024] Optionally, the specific steps of S4 include:

[0025] S4.1. Upload the packaged upgrade package to the cloud platform to prepare the required resources for subsequent upgrade operations.

[0026] S4.2. Develop an upgrade tool. Use this upgrade tool to push the component list information and chart packages in the upgrade package to the git repository, and at the same time push the container image to the container image repository.

[0027] S4.3. Deploy the changed chart packages to the cloud platform to complete the cloud platform upgrade process, where the chart packages use the chart packages newly pushed to the git repository, and the container images use the container images newly pushed to the container image repository.

[0028] In the second aspect, the present invention provides a device for managing cloud platform component versions based on gitea. The technical solutions adopted to solve the above technical problems are as follows:

[0029] A device for managing cloud platform component versions based on gitea includes:

[0030] A deployment and construction module for deploying gitea, postgres, and container image repositories on cloud platform nodes to construct a stable and interconnected basic operating environment to provide support for subsequent component management and platform upgrade.

[0031] A unified management module for storing the component list in the cloud platform in a specified file structure and format in a separate git repository, including the name, version, and detailed address information of each chart package of the components, to achieve unified management of component information.

[0032] An extraction and packaging module for extracting the changed chart packages and container images by using the version standard stored in the local git repository, tagging, and analyzing tag differences, and uniformly packaging them to generate an upgrade package.

[0033] An upgrade and deployment module for achieving a comprehensive upgrade of the cloud platform by uploading the upgrade package, using the upgrade tool to push information and images, and then deploying the changed chart packages.

[0034] Optionally, the involved deployment building blocks specifically include:

[0035] The gitea deployment unit is used to deploy gitea on cloud platform nodes to store the component list and chart packages of the cloud platform, and perform version management on the stored component list and chart packages, so as to achieve standardized version management of the components deployed on the cloud platform. The specific operations for the gitea deployment unit to deploy gitea include: running gitea in the system service mode. In the Unit configuration, set the dependencies of gitea on docker.socket, docker.service, and gitea-postgres.service through Wants, After, and Requires. In the Service configuration, set the user to root, define the start, stop commands, and restart policy to ensure that it can be pulled up by the system in time when it exits abnormally; running gitea in the container mode, starting it through a script, using the docker run command to mount the local directories / var / gitea / app.ini and / var / gitea / data as the configuration file and data storage directory respectively, and at the same time set the version tag, network, port mapping, and restart policy;

[0036] The postgres deployment unit is used to deploy postgres on cloud platform nodes. The specific operations include: running postgres in the system service form, and the startup method includes pre-cleaning operations. Through the ExecStartPre and ExecStart commands, ensure that the old containers are cleaned up before startup and it is started correctly; at the same time, run postgres in the container mode, use the docker run command, mount the local configuration file directory, adopt the host network, set the version tag and restart policy, so as to store the images required for the chart packages and provide data support for the deployment and upgrade of the chart packages;

[0037] The container image repository deployment unit is used to deploy the container image repository on cloud platform nodes. The specific operations include: running the container image repository in the system service mode, and the start and stop commands ensure that it can be pulled up by the system in time when it exits abnormally; running the container image repository in the container mode, using the docker run command, mounting the local configuration file directory, adopting the host network, setting the version tag and restart policy, storing the images required for the chart packages, and providing image support for the deployment and upgrade of the chart packages.

[0038] Optionally, the involved unified management module specifically includes:

[0039] Create storage unit 1 to create a xxx.yaml file in the git repository. The xxx.yaml file stores the version information of each component in the cloud platform. The xxx.yaml file uses the component name as the key and the corresponding component version as the value, and stores them in the form of key-value pairs;

[0040] Create storage unit 2 to create a corresponding chart.yaml file for each chart package. The chart.yaml file stores the detailed information of the chart package, including the schema and metadata structure definitions, the information storage of the data part, and the address record of the source part. Among them, the information storage of the data part specifically includes the chart package name, the deployment instance name, and the deployment namespace. The address record of the source part specifically includes the save address of the chart package in gitea, which is used to record the storage location of the chart package in gitea.

[0041] Optionally, the involved extraction and packaging module specifically includes:

[0042] Record construction unit, used to store the component list information and chart address information in the local git repository according to the cloud platform component management model, and construct the standard record of the current version;

[0043] Tagging unit, used to perform tagging operations on the component list information items and each chart project respectively after the development of each version. Each tag corresponds to a set version;

[0044] Packaging development unit, used to develop a packaging tool. When packaging, the packaging tool obtains the differences between the component list information item tags, and finds the changed chart packages and container images according to the tag differences;

[0045] Unified packaging unit, used to uniformly package the obtained differentiated chart packages and container images to form an upgrade package for cloud platform upgrade.

[0046] Optionally, the involved upgrade and deployment module specifically includes:

[0047] Upload unit, used to upload the packaged upgrade package to the cloud platform to prepare the required resources for subsequent upgrade operations;

[0048] Upgrade development unit, used to develop an upgrade tool, and use the upgrade tool to push the component list information and chart packages in the upgrade package to the git repository, and at the same time push the container images to the container image repository;

[0049] A deployment upgrade unit is used to deploy the changed chart package to the cloud platform to complete the upgrade process of the cloud platform. The chart package uses the chart package newly pushed to the git repository, and the container image uses the container image newly pushed to the container image repository.

[0050] A method and device for managing cloud platform component versions based on gitea according to the present invention have the beneficial effects compared with the prior art as follows:

[0051] 1. The present invention provides a complete and systematic solution for the cloud platform from the construction of the basic operating environment, the storage and management of component information to the component upgrade, realizes the effective management of cloud platform component versions and the automation of upgrade, and improves the maintainability, scalability and stability of the cloud platform;

[0052] 2. The present invention realizes the full-process optimization of the cloud platform from the basic environment construction to the component information management, then to the upgrade package generation and the final upgrade deployment, improves the overall performance and service quality of the cloud platform, reduces the errors and complexities of manual operations, and enhances the maintainability and scalability of the cloud platform in long-term operation and development. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Attached Figure 1 is the flowchart of the method in Embodiment 1 of the present invention;

[0054] Attached Figure 2 is the implementation architecture diagram of the method in Embodiment 1 of the present invention;

[0055] Attached Figure 3 is the module connection block diagram of Embodiment 2 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0056] To make the technical solutions, the technical problems to be solved and the technical effects of the present invention clearer and more understandable, the following combines specific embodiments to clearly and completely describe the technical solutions of the present invention.

[0057] Embodiment 1:

[0058] Combined with Attached Figure 1 、 2 , this embodiment proposes a method for managing cloud platform component versions based on gitea, which includes the following steps:

[0059] S1. By deploying gitea, postgres and container image repositories on cloud platform nodes, a stable and interconnected basic operating environment is constructed to provide support for subsequent component management and platform upgrade. This process specifically includes:

[0060] S1.1. Deploy gitea on the cloud platform nodes to store the component list and chart packages of the cloud platform, and manage the versions of the stored component list and chart packages, so as to achieve standardized version management of the components deployed on the cloud platform.

[0061] S1.1.1. The specific operations for deploying gitea on the cloud platform nodes are as follows:

[0062] Run gitea in the system service mode.

[0063] a) In the Unit configuration:

[0064] Set the dependencies of gitea on docker.socket, docker.service, and gitea-postgres.service through Wants, After, and Requires. Specifically, ① through Wants=docker.socket, it indicates that gitea expects docker.socket to be in the running state, but even if docker.socket is not running, gitea can still try to start; ② through After=docker.service, ensure that gitea starts after docker.service starts to ensure that gitea can use docker-related functions normally when starting; ③ through Requires=gitea-postgres.service, specify the strong dependency of gitea on gitea-postgres.service, that is, gitea-postgres.service must be running normally, otherwise gitea cannot start.

[0065] b) In the Service configuration:

[0066] Set the user to root, define the start, stop commands and restart policy to ensure that it can be restarted by the system in time when it exits abnormally. Specifically, ① User=root sets the user executing the gitea service to root, ② ExecStart= / usr / local / bin / gitea$Version starts with the specified gitea version, ③ ExecStartPre=- / usr / bin / docker rm -f gitea attempts to remove the existing gitea container before starting gitea to avoid conflicts, ④ ExecStop= / usr / bin / docker stop gitea defines the command to stop the gitea container, ⑤ Restart=always and RestartSec=15s ensure that the gitea service can be automatically restarted by the system when it exits abnormally, and the interval between two restarts is 15 seconds, ⑥TimeoutStartSec=30s sets the start timeout of the gitea service to 30 seconds;

[0067] S1.1.2. Run gitea in container mode and start it through the following Script 1. Use the docker run command to mount the local directories / var / gitea / app.ini and / var / gitea / data as the configuration file and data storage directory respectively, and at the same time set the version label, network, port mapping and restart policy.

[0068] Script 1:

[0069] / usr / bin / docker run\

[0070] --init\

[0071] --label version="$gitea_version"\

[0072] --restart=on-failure:5\

[0073] --network=gitea-postgres\

[0074] -p"$port_ssh_type":22\

[0075] -p"$port_http_type":3000\

[0076] -v / var / gitea / data: / data\

[0077] -v / var / gitea / app.ini: / app / gitea / app.ini\

[0078] -v / etc / hosts: / etc / hosts

[0079] --name=gitea

[0080] "$registry_url" / "$gitea_image"

[0081] Among them, --label version="$gitea_version" adds a version label to the gitea container, facilitating subsequent version management and maintenance; --restart=on-failure:5 means that when the container fails to start, it will be restarted at most 5 times; --network=gitea-postgres connects the gitea container to the gitea-postgres network to ensure communication with the postgres service; the port mappings -p "$port_ssh_type":22 and -p "$port_http_type":3000 map the 22 port (SSH) and 3000 port (HTTP) inside the container to the outside, facilitating user access; mounting / var / gitea / data as the data storage directory of gitea to store data such as component lists and chart packages; mounting / var / gitea / app.ini as the configuration file directory of gitea, which contains various configuration information of gitea; mounting / etc / hosts to ensure correct hostname resolution inside the container; --name=gitea specifies a name for the container for easy management; "$registry_url" / "$gitea_image" specifies the image source of the gitea container.

[0082] S1.2. Deploy postgres on the cloud platform node, and the specific operations include:

[0083] S1.2.1. Run postgres in the form of a system service, and the startup method includes pre-cleaning operations. Through the ExecStartPre and ExecStart commands, ensure that the old container is cleaned up before startup and started correctly; the code is as follows:

[0084] [Unit]

[0085] Description=Postgres docker wrapper

[0086] Wants=docker.socket

[0087] After=docker.service

[0088] [Service]

[0089] ExecStartPre=- / usr / bin / docker rm -f postgres

[0090] ExecStart= / usr / local / bin / postgres$Version

[0091] ExecStop= / usr / bin / docker stop postgres

[0092] Restart=always

[0093] RestartSec=15s

[0094] TimeoutStartSec=30s

[0095] The above [Unit] code part: Wants=docker.socket and After=docker.service ensure it starts after the docker service;

[0096] The above [Service] code part: ExecStartPre=- / usr / bin / docker rm -f postgres removes the possible existing old postgres container before startup; ExecStart= / usr / local / bin / postgres$Version starts postgres with the specified version; ExecStop= / usr / bin / docker stop postgres defines the command to stop the postgres container; Restart=always and RestartSec=15s ensure the postgres service restarts automatically when it exits abnormally, and the restart interval is 15 seconds; TimeoutStartSec=30s sets the startup timeout.

[0097] S1.2.2. Meanwhile, run postgres in container mode, use the docker run command, mount the local configuration file directory, adopt the host network, set the version tag and restart policy, so as to store the images required for the chart package and provide data support for the deployment and upgrade of the chart package; the code is as follows:

[0098] / usr / bin / docker run

[0099] --init

[0100] --label version="$postgres_version"

[0101] --restart=on-failure:5

[0102] --net host

[0103] -v / var / postgres / config: / etc / postgres / config

[0104] --name=postgres

[0105] "$registry_url" / "$postgres_image"

[0106] Among them, --label version="$postgres_version" adds a version label to the postgres container; --restart=on-failure:5 allows the postgres container to be restarted up to 5 times when the startup fails; --net host uses the host network, which is convenient for network configuration and communication, but may bring certain security risks and needs to be evaluated according to the actual situation; mounts / var / postgres / config as the configuration file directory of postgres to store the configuration information of the database; --name=postgres names the container; "$registry_url" / "$postgres_image" specifies the image source of the postgres container.

[0107] The postgres service mainly stores the image information required by the chart package, such as image metadata, version information, etc., providing necessary data support for the deployment and upgrade of the chart package. For example, it stores the information of the container images relied on by different versions of the chart package to ensure that the corresponding images can be obtained from here during the deployment and upgrade process.

[0108] S1.3. Deploy a container image repository on the cloud platform node. The specific operations include:

[0109] S1.3.1. Run the container image repository in the system service mode, and ensure that the startup and stop commands can be pulled up by the system in time when exiting abnormally; the code is as follows:

[0110] [Unit]

[0111] Description=Container Image Repository service

[0112] Wants = docker.socket

[0113] After = docker.service

[0114] [Service]

[0115] ExecStartPre = - / usr / bin / docker rm -f container_image_repository

[0116] ExecStart = / usr / local / bin / registry$Version

[0117] ExecStop = / usr / bin / docker stop container_image_repository

[0118] Restart = always

[0119] RestartSec = 15s

[0120] TimeoutStartSec = 30s

[0121] The above [Unit] code section: Wants = docker.socket and After = docker.service ensure it starts after the docker service;

[0122] The above [Service] code section: ExecStartPre = - / usr / bin / docker rm -f container_image_repository removes the potentially existing old container image repository container before starting; ExecStart = / usr / local / bin / registry$Version starts the container image repository with the specified version; ExecStop = / usr / bin / docker stop container_image_repository defines the command to stop the container image repository container; Restart = always and RestartSec = 15s ensure automatic restart when the service exits abnormally, with a restart interval of 15 seconds; TimeoutStartSec = 30s sets the start timeout.

[0123] S1.3.2. Run the container image repository in container mode. Use the docker run command to mount the local configuration file directory, adopt the host network, set the version label and restart policy, store the images required for the chart package, and provide image support for the deployment and upgrade of the chart package. The code is as follows:

[0124] / usr / bin / docker run\

[0125] --init\

[0126] --label version="$registry_version"\

[0127] --net host\

[0128] --restart=on-failure:5\

[0129] -v / etc / registry: / etc / registry\

[0130] --name=container_image_repository\

[0131] "$registry_url" / "$registry_image"

[0132] Among them, --label version="$registry_version" adds the version label of the container image repository; --restart=on-failure:5 allows the container to restart up to 5 times when the startup fails; --net host uses the host network, which is convenient for communicating with other services, but security factors need to be considered; mount / etc / registry as the configuration file directory of the container image repository to store the configuration information of the repository; --name=container_image_repository names the container; "$registry_url" / "$registry_image" specifies the image source of the container image repository.

[0133] The container image repository stores the images required for the chart package and provides image resources for the deployment and upgrade of the chart package, ensuring that the required images can be pulled from the repository during deployment or upgrade to guarantee the normal deployment and update operations of the chart package.

[0134] It should be added that: (i) The purpose of step S1 is to build a basic operating environment for the cloud platform. Gitea is used to manage the component list and the versions of chart packages. Postgres provides data storage services for Gitea to store relevant information. The container image repository stores the container images required by the chart packages. They cooperate with each other to jointly serve subsequent component management and platform upgrades. (ii) The running mode of the system service: Through the configuration of the system service, ensure the processing methods of each service during startup, shutdown, and abnormal situations, such as restart policies and dependency settings, so that the service can be better managed at the system level. (iii) The running mode of the container: Use docker containerization deployment to improve the portability and isolation of the service. Mount directories to store configurations and data, use network and port mapping to ensure communication between services and user access, and set version tags at the same time to facilitate version management and maintenance.

[0135] S2. Store the component list in the cloud platform in a specified file structure and format in a separate git repository, including the names, versions, and detailed address information of each chart package of the components, to achieve unified management of component information. Specifically, it includes:

[0136] S2.1. Create an xxx.yaml file in the git repository. This file is used to store the version information of each component in the cloud platform. In the xxx.yaml file, use the component name as the key and the corresponding component version as the value, and store them in the form of key-value pairs.

[0137] For example, chart1 and chart2 are the names of the chart packages respectively, and version is the version corresponding to the chart package.

[0138] chart1:

[0139] version: "1.0.0"

[0140] chart2:

[0141] version: "1.0.1"

[0142] This storage method can clearly display the current version information of each component, facilitating subsequent version management and upgrade operations.

[0143] S2.2. For each chart package, create a corresponding chart.yaml file, which is used to store the detailed information of the chart package, including the schema and metadata structure definitions, the information storage in the data section, and the address record in the source section. Specifically, the information storage in the data section includes the chart package name, the deployment instance name, and the deployment namespace. The address record in the source section includes the save address of the chart package in gitea, which is used to record the storage location of the chart package in gitea.

[0144] Use chart1.yaml to store the address information of chart1 for use during packaging.

[0145] schema:armada / Chart / v1

[0146] metadata:

[0147] name:chart1

[0148] data:

[0149] chart_name:chart1

[0150] release:chart1

[0151] namespace:namespace1

[0152] source:

[0153] location:ssh: / / git@{git_address} / charts / chart1.git

[0154] The main information is as follows: data.chart_name is the chart name, which is the name of the chart package used in the cloud platform; data.release is the deployment instance name, which is the name of the instance deployed through the chart package in the cloud platform; data.namespace is the chart deployment namespace, which is the namespace for deploying the instance through the chart package; source.location is the chart address, which is the save address of the chart package in gitea. Through this address, all the contents of the chart package can be obtained.

[0155] In the chart.yaml file, the schema section defines the structure specifications of the chart package, the metadata section stores the metadata about the chart package, which can help the system better understand and manage the chart package. The data section stores important information related to the deployment, and the source section stores the storage location of the chart package in Gitea for convenient subsequent operations.

[0156] S3. Utilize the version standards stored in the local Git repository. By tagging and analyzing the tag differences, extract the changed chart packages and container images, and package them together to generate an upgrade package. Specifically, it includes:

[0157] S3.1. In the local Git repository, according to the cloud platform component management model, store the component list information and chart address information to build the standard record of the current version. This step establishes a basic storage of version information as the starting point for subsequent operations, ensuring the integrity and accuracy of the version information. During this process, detailed component lists (including component names, version numbers, dependencies, etc.) and the address information of each chart package (e.g., information stored in xxx.yaml and chart.yaml files) are stored in the Git repository as an accurate record of the current system component status. This helps subsequent version management and update operations, ensuring the coherence and traceability of information between different versions.

[0158] S3.2. After the development of each version is completed, tag the component list information project and each chart project separately, with each tag corresponding to a set version. Specifically, for the component list information project, version tags such as v1.0.0, v1.1.0, etc. can be used, and a similar tag system is also used for the chart project. These tags not only represent the version number but can also contain some additional information, such as dates, feature characteristics, etc., to more clearly identify the characteristics of different versions. For example, for the component list, a tag like component_list_v1.0.0_20250114 can be used, and for the chart project, a tag like chart_package_foo_v1.1.0_feature_x can be used. These tags can be created manually or through automated tools, and they are the key basis for subsequent version comparison and update.

[0159] The tagging in this step is an effective version management method. Clear tags can conveniently mark the development achievements at different stages and provide clear identification for subsequent comparison and update operations.

[0160] S3.3. Develop a packaging tool. When packaging, the packaging tool obtains the differences between the component list information and project tags, and finds the changed chart packages and container images based on the tag differences.

[0161] It should be added that: The packaging tool developed in this step is the key to realizing automatic upgrade. It needs to have powerful comparison and analysis capabilities to accurately find the parts that need to be updated. The developed packaging tool needs to have the following functions:

[0162] First of all, it should be able to compare the component list information and chart information under different tags, and identify which component and chart package information has changed. This may involve comparing the xxx.yaml and chart.yaml files under different tags and checking the changes in information such as component names, version numbers, and chart package storage locations.

[0163] Secondly, according to the above comparison results, determine which chart package content has changed and whether the associated container images are updated. This may require in-depth analysis of the internal structure and dependencies of the chart packages, as well as the version information of the container images they are associated with. For example, if the version of a chart package is updated from v1.0.0 to v1.1.0, it is necessary to check whether the dependent container images have been updated, which may involve querying the metadata of the container image repository or using other methods to determine the changes in the images.

[0164] S3.4. Uniformly package the obtained differential chart packages and container images to form an upgrade package for cloud platform upgrade. In this step, the changed chart packages and container images found in the previous step are uniformly packaged. The packaging format can be a compressed file (such as.tar.gz) or a custom format, ensuring that it contains all the elements required for the update. The packaged upgrade package should include the following contents: ① Updated chart package files and related configuration files to ensure that these files can be correctly deployed and configured during the upgrade; ② Metadata and binary files of the new or updated container images so that the corresponding images in the container image repository can be updated when the upgrade package is deployed; ③ A manifest file listing the information of all components, chart packages, and container images included in the upgrade package, as well as their version update information, to facilitate users to view and verify the content of the upgrade package.

[0165] In short, the final packaging operation should ensure that the upgrade package contains complete update information and exists in a format that is convenient for deployment and management.

[0166] S4. Realize the comprehensive upgrade of the cloud platform by uploading the upgrade package, using the upgrade tool to push information and images, and then deploying the changed chart packages, specifically including:

[0167] S4.1. Upload the packaged upgrade package to the cloud platform to prepare the required resources for subsequent upgrade operations. This process specifically includes: First, determine the target location for uploading, which may be a specific storage location or storage service on the cloud platform. For example, the upgrade package can be transferred to the specified storage location on the cloud platform using the scp command, rsync tool, or API call. In the case of uploading using the API, the curl command or the HTTP library of the relevant programming language (such as the requests library in Python) can be used to send the upgrade package to the server according to the API interface provided by the cloud platform. At the same time, to ensure the security of the upload process, encrypted transmission (such as using the https protocol) and authentication mechanisms (such as API keys, OAuth tokens, etc.) can be adopted to prevent data leakage and unauthorized access.

[0168] S4.2. Develop an upgrade tool to push the component list information and chart package in the upgrade package to the git repository using this upgrade tool, and at the same time push the container image to the container image repository.

[0169] S4.3. Deploy the changed chart package to the cloud platform to complete the upgrade process of the cloud platform, where the chart package uses the chart package newly pushed to the git repository, and the container image uses the container image newly pushed to the container image repository.

[0170] When deploying the changed chart, it is necessary to call the deployment tool or API of the cloud platform. The helm command can be used (if Helm is used for chart package management) to perform the deployment according to the new information of the chart package.

[0171] Ensure that the chart package newly pushed to the git repository and the container image newly pushed to the container image repository are used during deployment. This may require updating the configuration file (such as values.yaml) in the chart package to reference the new container image address and version information.

[0172] During the deployment process, dependency relationships and deployment order should be considered. First, deploy the chart packages of the basic services, and then deploy the services that depend on them. For stateful services, data migration or data backup may be required to prevent data loss or damage.

[0173] After the deployment is completed, perform verification operations to ensure that the newly deployed services are running properly. Verification can be carried out through health checks, log viewing, or functional tests, etc.

[0174] Example 2:

[0175] Combined with the attached Figure 3 , this embodiment proposes a device for managing the component versions of the cloud platform based on gitea, which includes:

[0176] A deployment and construction module is used to deploy Gitea, Postgres, and a container image repository on cloud platform nodes, build a stable and interconnected basic operating environment, and provide support for subsequent component management and platform upgrade.

[0177] A unified management module is used to store the component list in the cloud platform in a specified file structure and format in a separate Git repository, including the names, versions, and detailed address information of each chart package of the components, so as to realize the unified management of component information.

[0178] An extraction and packaging module is used to utilize the version standard stored in the local Git repository, extract the changed chart packages and container images by tagging and analyzing tag differences, and uniformly package them to generate an upgrade package.

[0179] An upgrade and deployment module is used to comprehensively upgrade the cloud platform by uploading the upgrade package, using the upgrade tool to push information and images, and then deploying the changed chart packages.

[0180] In this embodiment, the deployment and construction module specifically includes:

[0181] A Gitea deployment unit is used to deploy Gitea on cloud platform nodes to store the component list and chart packages of the cloud platform, and perform version management on the stored component list and chart packages, so as to realize the standardized version management of the components deployed on the cloud platform. The specific operations for the Gitea deployment unit to deploy Gitea include: running Gitea in the system service mode, in the Unit configuration, setting the dependencies of Gitea on docker.socket, docker.service, and gitea - postgres.service through Wants, After, and Requires, and in the Service configuration, setting the user as root, defining the start, stop commands, and restart policy to ensure that it can be pulled up by the system in time when it exits abnormally; running Gitea in the container mode, starting through a script, using the docker run command to mount the local directories / var / gitea / app.ini and / var / gitea / data as the configuration file and data storage directory respectively, and at the same time setting the version tag, network, port mapping, and restart policy.

[0182] The postgres deployment unit is used to deploy postgres on cloud platform nodes. The specific operations include: running postgres in the form of a system service, and the startup method includes pre-cleaning operations. Through the ExecStartPre and ExecStart commands, it is ensured that the old containers are cleaned before startup and postgres is started correctly; at the same time, postgres is run in a container manner, using the docker run command, mounting the local configuration file directory, adopting the host network, setting version tags and restart policies, so as to store the images required for the chart package and provide data support for the deployment and upgrade of the chart package.

[0183] The container image repository deployment unit is used to deploy the container image repository on cloud platform nodes. The specific operations include: running the container image repository in the form of a system service, and the startup and stop commands ensure that it can be pulled up by the system in time when it exits abnormally; running the container image repository in a container manner, using the docker run command, mounting the local configuration file directory, adopting the host network, setting version tags and restart policies, storing the images required for the chart package, and providing image support for the deployment and upgrade of the chart package.

[0184] In this embodiment, the unified management module specifically includes:

[0185] The creation storage unit 1 is used to create a xxx.yaml file in the git repository, and store the version information of each component in the cloud platform through the xxx.yaml file. The xxx.yaml file takes the component name as the key and the corresponding component version as the value, and stores it in the form of key-value pairs.

[0186] The creation storage unit 2 is used to create a corresponding chart.yaml file for each chart package, and store the detailed information of the chart package through the chart.yaml file, including the schema and metadata structure definitions, the information storage in the data part, and the address record in the source part. Among them, the information storage in the data part specifically includes the chart package name, the deployment instance name, and the deployment namespace, and the address record in the source part specifically includes the save address of the chart package in gitea, which is used to record the storage location of the chart package in gitea.

[0187] In this embodiment, the extraction and packaging module specifically includes:

[0188] The record construction unit is used to store the component list information and the chart address information in the local git repository according to the cloud platform component management model, and construct the standard record of the current version.

[0189] A tagging unit, which is used to perform tagging operations on the component list information items and each chart item respectively after the development of each version is completed, and each tag corresponds to a set version;

[0190] A packaging development unit, which is used to develop a packaging tool. When packaging, the packaging tool obtains the differences between the tags of the component list information items, and finds out the changed chart packages and container images according to the tag differences;

[0191] A unified packaging unit, which is used to uniformly package the obtained differentiated chart packages and container images to form an upgrade package for cloud platform upgrade.

[0192] In this embodiment, the upgrade and deployment module specifically includes:

[0193] An upload unit, which is used to upload the packaged upgrade package to the cloud platform to prepare the required resources for subsequent upgrade operations;

[0194] An upgrade development unit, which is used to develop an upgrade tool, and use this upgrade tool to push the component list information and chart packages in the upgrade package to the git repository, and at the same time push the container image to the container image repository;

[0195] A deployment upgrade unit, which is used to deploy the changed chart packages to the cloud platform to complete the upgrade process of the cloud platform, where the chart packages use the chart packages newly pushed to the git repository, and the container images use the container images newly pushed to the container image repository.

[0196] In summary, by adopting the method and device for managing cloud platform component versions based on gitea of the present invention, effective management of cloud platform component versions and automation of upgrades can be achieved, the maintainability, scalability and stability of the cloud platform can be improved, and the errors and complexity of manual operations can be reduced.

[0197] The above applications use specific examples to elaborate in detail the principles and implementation manners of the present invention. These embodiments are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, those skilled in the art of this technology, without departing from the principle of the present invention, any improvements and modifications made to the present invention shall fall within the scope of patent protection of the present invention.

Claims

1. A method for managing cloud platform component versions based on gitea, characterized in that: The steps include: S1. By deploying gitea, postgres and container image repositories on cloud platform nodes, a stable and interconnected basic operating environment is built to support subsequent component management and platform upgrades. S2. In a separate git repository, store the component list in the cloud platform in a specified file structure and format, including the component name, version, and detailed address information of each chart package, to achieve unified management of component information; S3, using the version standard stored in the local git repository, extracts the changed chart packages and container images by tagging and analyzing tag differences, and uniformly packages them to generate upgrade packages; S4. Upload the upgrade package, use the upgrade tool to push information and images, and then deploy the changed chart package to achieve a comprehensive upgrade of the cloud platform.

2. According to a method for managing cloud platform component versions based on gitea according to claim 1, it is characterized in that: The step S1 specifically includes: S1.

1. Deploy gitea on the cloud platform node to store the component list and chart package of the cloud platform, and perform version management on the stored component list and chart package to achieve standardized version management of components deployed on the cloud platform; The specific operations for deploying gitea on the cloud platform node are as follows: Run gitea as a system service. In the Unit configuration, set gitea's dependency on docker.socket, docker.service, and gitea-postgres.service through Wants, After, and Requires. In the Service configuration, set the user to root, define the start, stop commands, and restart strategy to ensure that the system can be pulled up in time when an abnormal exit occurs; Run gitea as a container, start it through a script, and use the docker run command to mount the local directories / var / gitea / app.ini and / var / gitea / data as configuration files and data storage directories respectively, and set version tags, networks, port mappings, and restart strategies; S1.

2. Deploy postgres on the cloud platform node. The specific operations include: running postgres as a system service, and the startup method includes pre-cleaning operations. Through the ExecStartPre and ExecStart commands, ensure that the old container is cleaned before startup and started correctly; at the same time, run postgres in container mode, use the docker run command, mount the local configuration file directory, use the host network, set the version label and restart strategy, so as to store the image required by the chart package, and provide data support for the deployment and upgrade of the chart package; S1.

3. Deploy the container image repository on the cloud platform node. The specific operations include: running the container image repository as a system service, starting and stopping commands to ensure that the system can be pulled up in time when an abnormal exit occurs; running the container image repository as a container, using the docker run command, mounting the local configuration file directory, using the host network, setting version labels and restart policies, storing the images required for the chart package, and providing image support for the deployment and upgrade of the chart package.

3. According to a method for managing cloud platform component versions based on gitea according to claim 2, it is characterized in that: The step S2 specifically includes: S2.

1. Create a xxx.yaml file in the git repository. This file is used to store the version information of each component in the cloud platform. In the xxx.yaml file, use the component name as the key and the corresponding component version as the value, and store them in the form of key-value pairs. S2.

2. For each chart package, create a corresponding chart.yaml file. The chart.yaml file is used to store detailed information of the chart package, including schema and metadata structure definitions, information storage in the data part, and address records in the source part. The information storage in the data part specifically includes the chart package name, deployment instance name, and deployment namespace. The address record in the source part specifically includes the save address of the chart package in gitea, which is used to record the storage location of the chart package in gitea.

4. According to a method for managing cloud platform component versions based on gitea according to claim 3, it is characterized in that: The step S3 specifically includes: S3.

1. In the local git repository, store component list information and chart address information according to the cloud platform component management model, and build a standard record of the current version; S3.

2. When each version is developed, label the component list information items and each chart item respectively, and each label corresponds to the set version; S3.

3. Develop a packaging tool. When packaging, the packaging tool obtains the differences between the labels of the component list information items and finds the changed chart packages and container images based on the label differences. S3.

4. The obtained differentiated chart packages and container images are packaged together to form an upgrade package for cloud platform upgrade.

5. According to a method for managing cloud platform component versions based on gitea according to claim 4, it is characterized in that: The step S4 specifically includes: S4.

1. Upload the packaged upgrade package to the cloud platform and prepare the required resources for subsequent upgrade operations; S4.

2. Develop an upgrade tool, use the upgrade tool to push the component list information and chart package in the upgrade package to the git repository, and push the container image to the container image repository; S4.

3. Deploy the changed chart package to the cloud platform to complete the upgrade process of the cloud platform. The chart package uses the chart package newly pushed to the git repository, and the container image uses the container image newly pushed to the container image repository.

6. A device for managing cloud platform component versions based on gitea, characterized in that: It includes: Deployment building module, which is used to deploy gitea, postgres and container image warehouse on cloud platform nodes, build a stable and interrelated basic operating environment, and provide support for subsequent component management and platform upgrades; The unified management module is used to store the component list in the cloud platform in a separate git repository in a specified file structure and format, including the component name, version and detailed address information of each chart package, to achieve unified management of component information; The extraction and packaging module is used to use the version standard stored in the local git repository to extract the changed chart packages and container images by tagging and analyzing tag differences, and then unify the packages to generate upgrade packages. The upgrade deployment module is used to upload the upgrade package, push information and images using the upgrade tool, and then deploy the changed chart package to achieve a comprehensive upgrade of the cloud platform.

7. The device for managing cloud platform component versions based on gitea according to claim 6, characterized in that: The deployment building module specifically includes: The gitea deployment unit is used to deploy gitea on the cloud platform node to store the component list and chart package of the cloud platform, and to perform version management on the stored component list and chart package, so as to realize the standardized version management of the components deployed on the cloud platform; the specific operations of the gitea deployment unit to deploy gitea include: running gitea as a system service, setting the dependency of gitea on docker.socket, docker.service and gitea-postgres.service through Wants, After and Requires in the Unit configuration, setting the user as root in the Service configuration, defining the start, stop commands and restart strategy to ensure that the system can be pulled up in time when abnormal exit occurs; running gitea as a container, starting it through a script, and using the docker run command to mount the local directories / var / gitea / app.ini and / var / gitea / data as the configuration file and data storage directory respectively, and setting the version label, network, port mapping and restart strategy at the same time; The postgres deployment unit is used to deploy postgres on the cloud platform node. The specific operations include: running postgres as a system service, and the startup method includes pre-cleaning operations. The ExecStartPre and ExecStart commands are used to ensure that the old container is cleaned before startup and started correctly; at the same time, postgres is run in container mode, using the docker run command, mounting the local configuration file directory, using the host network, setting the version label and restart strategy, so as to store the images required by the chart package and provide data support for the deployment and upgrade of the chart package; The container image repository deployment unit is used to deploy the container image repository on the cloud platform node. The specific operations include: running the container image repository as a system service, starting and stopping commands to ensure that the system can be pulled up in time when an abnormal exit occurs; running the container image repository as a container, using the docker run command, mounting the local configuration file directory, using the host network, setting version labels and restart strategies, storing the images required by the chart package, and providing image support for the deployment and upgrade of the chart package.

8. The device for managing cloud platform component versions based on gitea according to claim 7, characterized in that: The unified management module specifically includes: Create storage unit 1, which is used to create a xxx.yaml file in the git repository. The xxx.yaml file is used to store the version information of each component in the cloud platform. The xxx.yaml file uses the component name as the key and the corresponding component version as the value, and is stored in the form of key-value pairs. Create storage unit 2, which is used to create a corresponding chart.yaml file for each chart package. The chart.yaml file is used to store detailed information of the chart package, including schema and metadata structure definitions, information storage in the data part, and address records in the source part. The information storage in the data part specifically includes the chart package name, deployment instance name, and deployment namespace. The address record in the source part specifically includes the save address of the chart package in gitea, which is used to record the storage location of the chart package in gitea.

9. The device for managing cloud platform component versions based on gitea according to claim 8, characterized in that: The extraction and packaging module specifically includes: The record building unit is used to store component list information and chart address information in the local git repository according to the cloud platform component management model, and build a standard record of the current version; The labeling unit is used to label the component list information items and chart items after each version is developed. Each label corresponds to a set version. The packaging development unit is used to develop packaging tools. During packaging, the packaging tool obtains the differences between the labels of the component list information items and finds the changed chart packages and container images based on the label differences. The unified packaging unit is used to package the obtained differentiated chart packages and container images in a unified manner to form an upgrade package for cloud platform upgrade.

10. The device for managing cloud platform component versions based on gitea according to claim 9, characterized in that: The upgrade deployment module specifically includes: The upload unit is used to upload the packaged upgrade package to the cloud platform to prepare the required resources for subsequent upgrade operations; The upgrade development unit is used to develop upgrade tools and use the upgrade tools to push the component list information and chart packages in the upgrade package to the git repository, and push the container image to the container image repository; The deployment upgrade unit is used to deploy the changed chart package to the cloud platform to complete the upgrade process of the cloud platform. The chart package uses the chart package newly pushed to the git repository, and the container image uses the container image newly pushed to the container image repository.

Images