Deployment methods and systems for second-level mirror repositories of the global repository

Abstract

This application provides a method and system for deploying a secondary image repository of a global repository, belonging to the field of container image repository technology. The method includes: establishing SSH trust between the global repository and its associated repo nodes, and constructing storage space in each repo repository to obtain the repo repository as a secondary cluster image repository; wherein each repo node is a Linux server of a sub-cluster associated with the global repository; configuring yum sources in each repo repository, installing required dependencies, deploying customized Harbor instances, and periodically synchronizing metadata information from the global repository to each repo repository. The image address used by each sub-cluster application when creating containers needs to change the domain name of the global repository to the domain name of the repo repository, specifying that the image is pulled from the repo repository. This invention, by adding a secondary image repository in each cluster for image distribution, alleviates the request pressure faced by the primary repository, improves high availability in multi-cluster scenarios, and provides a performance buffer for horizontal / vertical scaling.

Description

Technical Field

[0001] This application relates to the field of mirror repository technology, specifically to a method for deploying a second-level mirror repository of a global repository and a system for deploying a second-level mirror repository of a global repository. Background Technology

[0002] Virtualization technology has become a widely accepted method for sharing server resources, providing system administrators with significant flexibility in building operating system instances on demand. However, hypervisor virtualization still faces performance and resource utilization efficiency issues, leading to the emergence of a new virtualization technology called containers to help address these problems. Container technology effectively divides the resources of a single operating system into isolated groups to better balance conflicting resource usage demands among these groups. A widely used application in container technology is Harbor (an enterprise-grade container image repository), an open-source container image repository project used to store cloud-native artifacts such as images and Helm charts. As a CNCF (Cloud Native Computing Foundation) graduate-level image repository project, Harbor provides user access control, policy management, vulnerability scanning, and other capabilities to help users securely and controllably manage artifacts on Kubernetes (container orchestration systems) or Docker.

[0003] In many fields, such as financial institutions, multi-cluster Kubernetes clusters are commonly used. When Harbor serves as the image repository for a Kubernetes cluster, images for all nodes (master, infrastructure, and node) within the cluster are pulled from the Harbor repository. The maximum number of nodes depends on the resource size of the master and infrastructure nodes, and can reach up to several hundred. In a multi-cluster financial environment, a single Harbor instance hosts multiple cluster nodes, leading to a surge in image pull requests. During peak periods, image pull failures may occur, causing pods in Kubernetes to malfunction and resulting in a series of availability issues. For multi-cluster scenarios, deployments and service changes may encounter problems where pods cannot be started due to the inability to pull images. Therefore, a new method for deploying a secondary image repository using a global repository is needed. Summary of the Invention

[0004] The purpose of this application is to provide a method and system for deploying a secondary image repository of a global repository, in order to solve the problem that pods may fail to start due to the inability to pull images in multi-cluster scenarios when deploying or changing services.

[0005] To achieve the above objectives, the first aspect of this application provides a method for deploying a secondary image repository of a global repository. Both the global repository and the secondary image repository are built on a Harbor architecture. The method includes: establishing SSH trust between the global repository and its associated repo nodes, and constructing storage space in each repo repository to obtain the repo repository as a secondary image repository; wherein each repo node is a Linux server of a sub-cluster associated with the global repository; deploying yum repositories in each repo repository, installing required dependencies, and deploying customized Harbor instances; periodically synchronizing metadata information between the global repository and each repo repository; and establishing a trust connection between each sub-cluster and its corresponding repo repository so that when an application in each sub-cluster creates a container, it can specify that the image should be pulled from the corresponding repo repository.

[0006] In this embodiment of the application, the construction of storage space on each repo node includes: creating an LVM on each repo node based on the Harbor persistent storage requirements; and allocating logical volume partitions based on the created LVMs to create corresponding logical volume partitions for the secondary image repository.

[0007] In this embodiment of the application, before deploying the yum source in each repository, the method further includes: adding domain name resolution to the network configuration files and system files in each repository, so that the global repository and each repository can communicate and access each other via the network.

[0008] In this embodiment, the synchronization of file information from the global repository to each repository based on the deployed yum repository includes: installing a preset component based on the yum repository; driving the preset component to run and copying the Harbor installation package image to each repository; reading the Harbor installation package image and enabling the registry container in the Harbor architecture to access the global repository through domain name resolution; starting the read Harbor and synchronizing the files from the global repository to each repository based on the registry container.

[0009] In this embodiment of the application, the preset components include at least: the docker component, the docker-compose component, and the nfs-utils component.

[0010] In this embodiment of the application, driving the preset component to run and copying the Harbor installation package image to each repository includes: driving the Docker component to copy the Harbor installation package image to each repository.

[0011] In this embodiment of the application, the step of enabling the registry container in the harbor architecture to access the global repository through domain name resolution includes: deploying a docker-compose file in the read harbor based on the docker-compose component; adding extra-hosts resolution of the global repository domain name for the registry container in the deployed docker-compose file, so that the registry container can access the global repository.

[0012] In this embodiment of the application, starting the read-after-harbor includes: adding a proxy configuration to the config.yml file in the registry container; wherein, the proxy configuration includes: the global repository domain name, the preset deployment account login name and login password; and starting the read-after-harbor based on the proxy configuration.

[0013] In this embodiment of the application, before synchronously copying the files in the global repository to each repository based on the registry container, the method further includes: configuring the authentication mode of each repository to LDAP, including: adding extra-hosts resolution for the LDAP domain name for the core container in the deployed docker-compose file, so that the core container can access the LDAP server; modifying the authentication mode of the harbor of the repository to LDAP, and configuring the LDAP configuration parameters to be consistent with those of the global repository.

[0014] In this embodiment, the periodic synchronization of file information between the global repository and each repository includes: at predetermined intervals, a synchronization script is executed, including: traversing the project information of the global repository and the repository, and deleting project information that exists in the repository but not in the global repository; if the project information in the repository does not exist in the global repository, then creating the corresponding project information in the global repository for the missing project information; traversing the member information under the global repository, and if the corresponding member information does not exist in the repository, then creating the corresponding member information in the global repository for the missing member information; and traversing the member information of the repository and the global repository in reverse order, and deleting member information that exists in the repository but not in the global repository in the repository.

[0015] In this embodiment of the application, the method further includes: logging information creation and deletion operations, and recording the corresponding execution time.

[0016] In this embodiment of the application, the method further includes: driving the execution of a capacity cleanup script once every predetermined time interval, including: checking the current usage of the storage directory of the registry container and comparing the current usage of the storage directory with a preset storage directory usage threshold; if the current usage of the storage directory is greater than the preset storage directory usage threshold, then performing a repo node reset operation.

[0017] The second aspect of this application provides a deployment system for a secondary image repository of a global repository. Both the global repository and the secondary image repository are built on the Harbor architecture. The system includes: a building unit, used to establish SSH trust between the global repository and its associated repo nodes, and to build storage space on each repo node to obtain the repo repository as a secondary image repository; a deployment unit, used to deploy yum sources in each repo repository, install the required dependencies, and deploy customized Harbor instances; an operation and maintenance unit, used to periodically synchronize the metadata information between the global repository and each repo repository; and to establish a mutual trust connection between each sub-cluster and its corresponding repo repository so that when an application in each sub-cluster creates a container, it can specify that the image should be pulled from the corresponding repo repository.

[0018] In this embodiment of the application, the operation and maintenance unit is further configured to: drive the execution of a capacity cleanup script once every predetermined time interval, including: checking the current usage of the storage directory of the registry container and comparing the current usage of the storage directory with a preset storage directory usage threshold; if the current usage of the storage directory is greater than the preset storage directory usage threshold, then perform a repo node reset operation.

[0019] A third aspect of this application provides a computer device, characterized in that the computer device is configured to perform the above-described method for deploying a secondary mirror repository of a global repository.

[0020] A fourth aspect of this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the above-described method for deploying a secondary mirror repository of a global repository.

[0021] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for deploying a second-level mirror repository of a global repository.

[0022] Through the above technical solution, the present invention distributes the request pressure faced by the primary warehouse by adding a secondary image repository in each cluster for image distribution, thereby improving high availability in multi-cluster scenarios and providing a performance buffer for horizontal / vertical scaling.

[0023] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0024] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings:

[0025] Figure 1 This schematically illustrates a flowchart of the steps of a method for deploying a second-level mirror repository of a global repository according to an embodiment of this application;

[0026] Figure 2 This schematically illustrates a system architecture diagram of a secondary mirror repository deployment system for a global repository according to an embodiment of this application;

[0027] Figure 3 The diagram illustrates the internal structure of a computer device according to an embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0029] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0030] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0031] Virtualization technology has become a widely accepted method for sharing server resources, providing system administrators with significant flexibility in building operating system instances on demand. However, hypervisor virtualization still faces performance and resource utilization efficiency issues. Therefore, a new virtualization technology called containers has emerged to help address these problems. Container technology effectively divides the resources of a single operating system into isolated groups to better balance conflicting resource usage demands among these groups.

[0032] In container technology, Harbor (an enterprise-grade container image repository) is widely used. It is an open-source container image repository project used to store cloud-native artifacts such as images and Helm charts. As a CNCF (Cloud Native Computing Foundation) graduate-level image repository project, Harbor provides users with multiple capabilities such as access control, policy management, and vulnerability scanning, helping users to manage artifacts on Kubernetes (container orchestration system) or Docker in a secure and controllable manner.

[0033] Kubernetes, or K8s for short, is an open-source application used to manage containerized applications across multiple hosts on a cloud platform. Kubernetes aims to make deploying containerized applications simple and powerful, providing a mechanism for application deployment, planning, updating, and maintenance. In Kubernetes, we can create multiple containers, each running an application instance, and then use built-in load balancing strategies to manage, discover, and access this group of application instances, all without requiring complex manual configuration and handling by operations personnel.

[0034] In many fields, such as financial institutions, multi-cluster Kubernetes clusters are commonly used. When Harbor serves as the image repository for a Kubernetes cluster, images for all nodes (master, infrastructure, and node) within the cluster are pulled from the Harbor repository. The maximum number of nodes depends on the resource size of the master and infrastructure nodes, and can reach up to several hundred. In financial-grade multi-cluster scenarios, a single Harbor instance handles the nodes of multiple clusters, leading to a surge in image pull requests. During peak periods, image pull failures may occur, causing pods in Kubernetes to malfunction and resulting in a series of availability issues. For real-world applications, an architecture where each container cloud platform corresponds to a single image repository may encounter performance bottlenecks. During deployments and service changes, pods may fail to start due to the inability to pull images.

[0035] Based on the above issues, cloud platforms must consider the pressure on the image repository when scaling horizontally or vertically, regardless of the number of clusters or nodes, which greatly increases the limitations on cluster size. This invention addresses the problem in existing solutions where, in multi-cluster scenarios, a single harbor handles multiple cluster nodes, leading to a surge in image pull requests. During peak periods, this can cause image pull failures, resulting in pods in Kubernetes failing to function properly. This invention creates a new method for deploying a secondary image repository within a global repository. By adding a secondary image repository in each cluster for image distribution, this method alleviates the request pressure on the primary repository, improves high availability in multi-cluster scenarios, and provides a performance buffer for horizontal / vertical scaling.

[0036] Figure 1 This illustration schematically depicts a flowchart of a method for deploying a second-level mirror repository of a global repository according to an embodiment of this application. Figure 1 As shown in one embodiment of this application, a method for deploying a second-level mirror repository of a global repository is provided, including the following steps:

[0037] Step S10: Establish SSH trust between the global repository and its associated repo nodes, and build storage space on each repo node to obtain the repo repository as a secondary mirror repository.

[0038] Specifically, the approach for building a secondary image repository in this invention is to apply for a Linux server in each sub-cluster as the deployment node for the secondary image repository of that sub-cluster, acting as a repo node. Then, corresponding storage space is configured on this repo node to build the secondary image repository, ensuring that both the left and right image data from the global repository are completely copied to the secondary image repository. In this way, when multiple clusters simultaneously extract images, this secondary image repository can assist the global repository in distributing the load, avoiding potential image pull failures during peak periods that could cause pods in Kubernetes to malfunction.

[0039] In one possible implementation, the configuration of the repo node should be based on the increasing number of nodes in the sub-cluster. For example, with 10 nodes as a baseline, the configuration should include at least 2 CPUs, at least 8GB of memory, and at least 100GB of data disk.

[0040] To demonstrate the technical effects achievable by the present invention, different implementation methods will be provided for the construction of the secondary mirror repository. From these different implementation methods, the optimal specific method for constructing the secondary mirror repository will be determined.

[0041] When deploying a secondary image repository, the goal is to maintain compatibility with the existing architecture as much as possible while implementing image caching functionality, and to resolve image distribution issues with minimal modifications. This means minimizing system changes and ensuring that image extraction is performed in the same way as traditional image extraction from the global repository, without altering the extraction process. This allows for seamless integration of the secondary image repository build process with the traditional architecture, reducing the workload for developers.

[0042] Furthermore, since most global image repositories in current multi-cluster container cloud platform architectures adopt Harbor, a CNCF-certified, industry-most mature, and widely used architecture, as their repository architecture, and its RBAC access and other functions are tightly integrated with Kubernetes, the baseline scenario for solution selection is a global repository based on the Harbor architecture. Then, several specific architectures for secondary image repositories are proposed:

[0043] 1) First, the file system storage used by the global layer image repository is synchronized to the repo nodes of each sub-cluster through the file system synchronization function, so as to achieve the effect of full replication in turn. This method has a major drawback because deadlock will occur when the persistent data in Harbor db is written by multiple database instances at the same time.

[0044] 2) Build a complete Harbor repository on each repo node. Then, based on Harbor's built-in replication rules, configure the source address as a global repository and replicate the full image from the global repository to the secondary repository in a pull-based manner. This essentially creates a completely new global layer image repository on each repo node. However, this method cannot synchronize account permission information existing in the global repository, limiting its application scenarios in the Kubernetes architecture and making it unable to achieve proper permission control for pulling images. In other words, for the secondary image repository, users who originally had access to the global repository may not be able to access the corresponding secondary image repository and therefore cannot extract the corresponding images.

[0045] 3) Set up a separate docker-registry container on each repo node, and configure the global repository as a mirror source using the proxy configuration provided by the registry. This solution does not involve synchronization operations, but it cannot perform project-based permission control on images, and it is inconsistent with the global repository architecture, which significantly increases the operation and maintenance costs.

[0046] 4) Set up a complete Harbor repository on the repo node, configure a proxy in the registry container within the Harbor architecture, configure the global repository as a mirror source, and have a script running periodically on the repo node call the global repository's API to synchronize project and member information. This solution does not involve synchronization-related operations; all communication with the global repository is handled by interfaces, and it maintains a consistent architecture with the global repository, facilitating management.

[0047] By describing the four possible architectures of secondary mirror repositories, it becomes clear that the fourth approach best meets the expectations of this invention. Specifically, while building a complete Harbor repository on the repo node, a proxy is configured in the registry container within the Harbor architecture, setting the global repository as the mirror source. A script running periodically on the repo node then calls the global repository's API to synchronize project and member information. This invention employs this method to build the secondary mirror repository.

[0048] Based on the above introduction, the connection information of each sub-cluster is first collected. Then, the Linux servers of each sub-cluster are retrieved, and one Linux server in each sub-cluster is selected as the hosting server for the secondary image repository. The selected Linux server is used as the corresponding sub-cluster repo node. Then, based on the Harbor persistent storage requirements, an LVM (Logical Volume Manager) is created on each repo node. Logical volume partitions are allocated based on the created LVM, creating corresponding logical volume partitions for the secondary image repository. LVM is a mechanism for managing disk partitions in a Linux environment. It is a logical layer built on top of hard drives and partitions to improve the flexibility of disk partition management. The working principle of LVM is actually quite simple: it abstracts and encapsulates the underlying physical hard drive and presents it to the upper-layer application as a logical volume. In traditional disk management mechanisms, our upper-layer application directly accesses the file system to read the underlying physical hard drive. However, in LVM, by encapsulating the underlying hard drive, when we operate on the underlying physical hard drive, it is no longer operating on the partitions, but rather through something called a logical volume to perform low-level disk management operations. For example, if I add a physical hard drive, the upper-layer services won't be aware of it because it's presented to them as a logical volume. LVM's biggest feature is its ability to dynamically manage disks. The size of a logical volume can be dynamically adjusted without losing existing data. If we add a new hard drive, it won't change the existing upper-layer logical volume. As a dynamic disk management mechanism, logical volume technology greatly improves the flexibility of disk management. This invention's solution, based on LVM's dynamic management capabilities, performs corresponding logical volume partitioning and allocation, ensuring the flexibility of Linux server volume allocation.

[0049] Step S20: Deploy yum sources in each repository, install the required dependencies, and deploy customized Harbor instances.

[0050] Specifically, after constructing the repository storage space, it's necessary to establish network trust communication between the global repository and each corresponding repository. Although each repository node has a network connection to the global repository while online, after LVM performs volume partitioning and allocation, the new volume needs to establish trust communication connections with the global repository and sub-clusters. Therefore, domain name resolution needs to be added to ` / etc / hosts` to grant the corresponding access permissions.

[0051] Furthermore, because a corresponding secondary repository needs to be built based on the Harbor architecture in the repo repository, after allocating storage space, the Harbor installation package needs to be read into that storage space to ensure that Harbor is installed correctly, thereby ensuring that the repo repository establishes a mirror repository of the Harbor architecture. Based on this, a yum (Yellowdog Updater, Modified, a package manager) source needs to be configured on the repo node. A yum source is essentially a directory entry. When we use the yum mechanism to install software, if it needs to install dependent software, the yum mechanism will search for the dependent software according to the paths defined in the yum source and install it. Its working principle is that all RPM packages are stored on the server, and then the dependencies of each RPM file are analyzed using relevant functions. This data is recorded in a file and stored in a specific directory on the server. If a certain software needs to be installed, the dependency relationship file recorded on the server is downloaded first (via WWW or FTP). By analyzing the data downloaded from the server, all related software is obtained and downloaded all at once for installation.

[0052] Based on the deployed yum, install the required components, such as docker components, docker-compose components, and nfs-utils components.

[0053] Docker, a type of Linux container, provides a simple and easy-to-use interface for container usage and is currently the most popular Linux container solution. Docker packages an application and its dependencies into a single file. Running this file generates a virtual container. The program runs within this virtual container just as if it were running on a real physical machine. With Docker, there's no need to worry about environment issues. Overall, Docker's interface is quite simple, allowing users to easily create and use containers and put their applications into them. Containers can also be version-managed, copied, shared, and modified, just like managing ordinary code. This invention primarily relies on the Docker component for Harbor reading.

[0054] Furthermore, Compose is a tool for orchestrating Docker containers, defining and running multi-container applications. Multiple containers can be started with a single command, eliminating the need for shell scripts to start containers. Compose manages multiple Docker containers through a configuration file, where all containers are defined using services. Docker-compose scripts are then used to start, stop, and restart the application, its services, and all containers that depend on those services. This makes it ideal for scenarios involving the combined use of multiple containers in development.

[0055] Furthermore, nfs-utils is a dependency component for NFS message transmission. It is deployed on the repo node to support subsequent file transfers.

[0056] After installing each component, start the Docker component, copy the Harbor installation package to each repo node, and read the Harbor installation package accordingly. Then modify the docker-compose file to add the necessary domain name resolution.

[0057] Specifically, in the docker-compose file deployed in Harbor, an extra_hosts resolution for the global repository domain name is added to the registry container, allowing the container to access the global repository via the domain name. The registry container is the backend component for storage artifacts. Harbor is a complete image repository service composed of multiple components, including the registry container. In addition, it includes a core container as an interface processor, a proxy as a front-end web page display, PostgreSQL as a database, and a jobservice as a task controller.

[0058] Furthermore, add proxy configuration to the registry's config.yml file and start Harbor. 2. In the Harbor main directory, modify the . / common / config / registry / config.yml configuration file, adding the proxy configuration at the end of the file, for example:

[0059] proxy:

[0060] remoteurl:http: / / global.harbor.io

[0061] username:admin

[0062] password:adminpasswd

[0063] Where remoteurl is the global repository domain and password is the admin account password. Preferably, to ensure that all images can be cached, i.e., to have corresponding access permissions to all image files, the account and password used here are the corresponding administrator account and password.

[0064] After completing the proxy configuration, start the corresponding harbor to synchronize data with the global repository. To ensure consistency with the global repository architecture and facilitate management, the authentication mode of the repository needs to be configured to match that of the global repository.

[0065] Specifically, in multi-cluster container cloud platform scenarios, the global harbor repository and Kubernetes share an external LDAP connection as the user authentication management component. Secondary repositories also need to connect to the same LDAP to maintain authentication consistency when receiving image pull requests from sub-cluster nodes. This involves configuring the authentication mode of each repository to LDAP, including: adding an extra_hosts resolution for the LDAP domain name to the core container in the deployed docker-compose file, enabling the core container to access the LDAP server; and modifying the authentication mode of the harbor repository to LDAP, configuring the LDAP configuration parameters to be consistent with those of the global repository.

[0066] In one possible implementation, add an extra_hosts resolution for the LDAP domain name to the docker-compose file of the Harbor deployment for the core container, allowing the container to access the LDAP server via the domain name. Then, select LDAP as the authentication mode in Harbor and configure the LDAP URL, DNS, password, search members, etc., keeping them consistent with the global repository.

[0067] In this embodiment of the invention, as a secondary repository solution based on container cloud-native Kubernetes, the Kubernetes side only needs minor modifications to the secondary repository image distribution scheme for adaptation. The `repo` node, as a Harbor repository deployed within the cluster, exposes its services externally via HTTP; therefore, the node nodes of the sub-cluster need to be configured with an `insecure-registry` for the `repo` domain name. After configuration, the node can pull images from the secondary repository; and the resolution of `repoIP` and `repo` domain name should be configured in ` / etc / hosts`. The image address used by each sub-cluster application when creating containers needs to have the global repository domain name changed to the `repo` repository domain name. The `imagePullSecret` content used to pull images distributed by Kubernetes and located in various namespaces needs to have the global repository domain name changed to the `repo` repository domain name. The username and password do not need to be changed since a unified LDAP server is used.

[0068] Step S30: Periodically synchronize the metadata information between the global repository and each repo repository.

[0069] Specifically, at predetermined intervals (e.g., every 5 minutes), the driver executes a synchronization script, which includes: traversing the project information in the global repository and the repo repository, and deleting project information that exists in the repo repository but not in the global repository; if the project information in the global repository does not exist in the repo repository, then creating the corresponding project information in the global repository for the missing project information; traversing the member information under the global repository, and if the corresponding member information does not exist in the repo repository, then creating the corresponding member information in the global repository for the missing member information; and traversing the member information in the repo repository and the global repository in reverse order, and deleting member information that exists in the repo repository but not in the global repository.

[0070] Furthermore, at predetermined intervals, a capacity cleanup script is executed, which includes: checking the current usage of the storage directory of the registry container and comparing the current usage of the storage directory with a preset storage directory usage threshold; if the current usage of the storage directory is greater than the preset storage directory usage threshold, then a repo node reset operation is performed.

[0071] In one possible implementation, the repo node is configured with a capacity cleanup script via crontab to periodically check the storage directory usage of the registry. It supports custom thresholds and clears the contents of the registry and harbor-db when the threshold is exceeded, which is equivalent to resetting the repo node without affecting functionality. This script is executed every five minutes.

[0072] Step S40: Establish a mutual trust connection between each sub-cluster and the corresponding repository, so that when each sub-cluster application creates a container, it can specify to pull the image from the corresponding repository.

[0073] Specifically, after synchronizing the metadata between the repo repository and the global repository, when applications create containers in each sub-cluster, the traditional approach of pulling images from the global repository can be abandoned. Instead, images can be pulled directly from the repo repository of each sub-cluster. Therefore, a mutual trust connection needs to be established between each sub-cluster and its corresponding repo repository. This mutual trust connection is based on the mutual trust relationship between each sub-cluster and the global repository, ensuring that each sub-cluster can directly maintain its original image pulling rules and pull corresponding images from the repo repository without any system changes. Furthermore, it also ensures that if an image pull fails in the repo repository, the sub-cluster can directly attempt to pull the image from the global repository without switching any image pulling rules. This, to a certain extent, can guarantee the success rate of image pulls and improve the flexibility of image pulls.

[0074] In this embodiment of the invention, the repository address for pulling images from nodes within each sub-cluster uniformly points to the secondary image repository. Upon receiving the request, the secondary image repository first searches for the image in its local registry. If the image already exists locally, it directly returns the requested image content; otherwise, it requests the image content from the global repository, stores it locally, and then returns the image content to the client. Compared to having only one image repository within the cluster, the secondary repository alleviates the pressure on the primary repository while consuming limited resources, making minimal changes to the original architecture, and not affecting existing functionality, thus reserving a performance buffer for cluster expansion.

[0075] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0076] In one embodiment, such as Figure 2 As shown, a secondary mirror repository deployment system for a global repository is provided. Both the global repository and the secondary mirror repository are built based on the Harbor architecture. The system includes: a building unit, used to establish SSH trust between the global repository and its associated repo nodes, and to build storage space on each repo node to obtain the repo repository as the secondary mirror repository; a deployment unit, used to deploy yum sources in each repo repository, and to synchronize the file information in the global repository to each repo repository based on the deployed yum sources; and an operation and maintenance unit, used to periodically synchronize the file information between the global repository and each repo repository.

[0077] In this embodiment of the application, the operation and maintenance unit is further configured to: drive the execution of a capacity cleanup script once every predetermined time interval, including: checking the current usage of the storage directory of the registry container and comparing the current usage of the storage directory with a preset storage directory usage threshold; if the current usage of the storage directory is greater than the preset storage directory usage threshold, then perform a repo node reset operation.

[0078] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0079] This application provides a storage medium storing a program that, when executed by a processor, implements the above-described method for deploying a secondary mirror repository of the global repository.

[0080] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 3As shown, the computer device includes a processor A01, a network interface A02, memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The network interface A02 is used for communication with external terminals via a network connection. When the computer program B02 is executed by the processor A01, it implements a method for deploying a two-level mirror repository of a global repository.

[0081] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0082] In one embodiment, the secondary mirror repository deployment system for the global repository provided in this application can be implemented as a computer program, which can be deployed in the form of, for example... Figure 3 The computer device shown runs on the computer. The computer device's memory can store various program modules that make up the secondary mirror repository deployment system of the global repository. The computer program composed of the various program modules causes the processor to execute the steps in the secondary mirror repository deployment method of the global repository described in the various embodiments of this application.

[0083] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing the above-described method for deploying a second-level mirror repository of a global repository.

[0084] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0085] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0086] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0087] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0088] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0089] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0090] Computer-readable media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0091] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0092] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A secondary mirror warehouse deployment method of a global warehouse, characterized by, The global repository and the secondary mirror repository are both built based on a Harbor architecture, and the method comprises: Establishing ssh mutual trust between the global repository and each repo node associated with the global repository, and constructing storage space in each repo repository to obtain the repo repository as a secondary mirror repository; each repo node is a linux server of each sub-cluster associated with the global repository; Deploying a yum source in each repo repository, installing required dependencies, and deploying a customized harbor instance; Periodically synchronizing metadata information of the global repository and each repo repository; Synchronizing file information in the global repository to each repo repository based on the deployed yum source, including: installing preset components based on the yum source; driving the preset components to run, copying harbor installation package images to each repo repository; reading the harbor installation package images, and enabling registry containers in the harbor architecture to access the global repository through domain name resolution processing; starting the read harbor, and establishing image cache authentication and configuration based on the registry containers and the global repository; The preset components at least include: a docker component, a docker-compose component, and an nfs-utils component; Establishing mutual trust connection between each sub-cluster and the corresponding repo repository, so that when each sub-cluster application creates a container, image pulling is specified from the corresponding repo repository.

2. The method of claim 1, wherein, The storage space construction in each repo node comprises: Creating lvm in each repo node based on the Harbor persistent storage requirement; Logical volume partition allocation based on the created lvm, and creating corresponding logical volume partitions for the secondary mirror repository.

3. The method of claim 1, wherein, Before the yum source deployment in each repo repository, the method further comprises: Adding domain name resolution to network configuration files and system files in each repo repository, so that the global repository and each repo repository realize network intercommunication access based on domain names.

4. The method of claim 1, wherein, The driving the preset components to run, and copying harbor installation package images to each repo repository, comprises: Driving the docker component to copy harbor installation package images to each repo repository.

5. The method of claim 1, wherein, The enabling registry containers in the harbor architecture to access the global repository through domain name resolution processing comprises: Deploying a docker-compose file in the read harbor based on the docker-compose component; Adding extra-hosts resolution of the global repository domain name to the registry container in the deployed docker-compose file, so that the registry container can access the global repository.

6. The method of claim 1, wherein, The starting the read harbor comprises: Adding proxy configuration to config.yml in the registry container; wherein the proxy configuration comprises: the global repository domain name, the preset deployment account login name and login password; Starting the read harbor based on the proxy configuration.

7. The method of claim 5, wherein, Before synchronously copying the files in the global repository to each repo repository based on the registry container, the method further comprises: Configuring the authentication mode of each repo repository as ldap, comprising: Adding extra-hosts resolution of the ldap domain name to the core container in the deployed docker-compose file, so that the core container can access the ldap server; Modifying the authentication mode of the harbor of the repo repository to ldap, and configuring the ldap configuration parameters consistent with the global repository.

8. The method of claim 1, wherein, The method further comprises: Driving to execute the synchronization script once every predetermined time, comprising: Traversing the project information of the global repository and the repo repository, and deleting the project information existing in the repo repository but not existing in the global repository; If the project information in the global repository does not exist in the repo repository, creating the corresponding project information in the global repository for the missing project information; Traversing the member information under the global repository, if the corresponding member information does not exist in the repo repository, creating the corresponding member information in the global repository for the missing member information; Traversing the member information of the repo repository and the member information of the global repository in reverse, and deleting the member information existing in the repo repository but not existing in the global repository.

9. The method of claim 8, wherein, The method further comprises: Performing information creation operation and information deletion operation log recording, and recording the corresponding execution time.

10. The method of claim 1, wherein, The method further comprises: Driving to execute the capacity cleaning script once every predetermined time, comprising: Checking the current usage of the storage directory of the registry container, and comparing the current usage of the storage directory with the preset storage directory usage threshold; If the current usage of the storage directory is greater than the preset storage directory usage threshold, performing repo node reset operation.

11. A secondary mirror warehouse deployment system for a global warehouse, characterized by, The global repository and the secondary mirror repository are both built based on the Harbor architecture, and the system is used to execute the secondary mirror repository deployment method of the global repository in any one of claims 1-10, and the system comprises: A construction unit is configured to establish ssh mutual trust between the global repository and the repo nodes associated therewith, and to construct storage space on each repo node to obtain the repo repository as a secondary mirror repository. A deployment unit is configured to deploy a yum source in each repo repository, install required dependencies, and deploy a customized harbor instance. An operation and maintenance unit is configured to: periodically synchronize metadata information of the global repository and each repo repository; establish mutual trust connections between each sub-cluster and corresponding repo repository, so as to specify image pulling from the corresponding repo repository when each sub-cluster application creates a container.

12. The system of claim 11, wherein, The operation and maintenance unit is further configured to: drive the execution of a capacity cleaning script at a predetermined time interval, including: checking the current usage of the storage directory of the registry container, and comparing the current usage of the storage directory with a preset storage directory usage threshold; if the current usage of the storage directory is greater than the preset storage directory usage threshold, performing a repo node reset operation.

13. A computer device, comprising: The computer device is configured to execute the secondary mirror repository deployment method of the global repository according to any one of claims 1-10.

14. A machine-readable storage medium having stored thereon instructions, the instructions being executable by a machine to cause the machine to: The instruction, when executed by the processor, causes the processor to be configured to execute the secondary mirror repository deployment method of the global repository according to any one of claims 1-10.

15. A computer program product comprising a computer program, characterized in that, The computer program, when executed by the processor, implements the secondary mirror repository deployment method of the global repository according to any one of claims 1-10.

Images