Distributed high-availability code warehouse management method and system and medium

Abstract

The invention relates to a distributed high-availability code warehouse management method and system and a medium, and relates to the technical field of version control and code management.The method comprises the steps that a pre-configured external load balancer, a plurality of GitLab Web nodes, an internal load balancer, a PostgreSQL database cluster, a Redis cluster, a Gitaly cluster and object storage or file storage are obtained; carrying out load balancing on the plurality of GitLab Web nodes through the external load balancer; performing load balancing on the internal connection of the GitLab application program through the internal load balancer; the data of the GitLab Web and the data of the GitLab Pracect are stored through the PostgreSQL database cluster, and the data of the GitLab Web and the data of the GitLab Pracect are And providing access to a Git warehouse by using the Gitaly cluster. According to the invention, high availability, high performance and expandability of code warehouse management are realized through a distributed architecture and redundancy configuration.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of version control and code management, and particularly relates to a distributed high-availability code repository management method, system and medium. BACKGROUND

[0002] In a general code repository management system, a single-node architecture is usually adopted as shown in FIG. 1. The architecture includes a GitLab Web server running components such as Nginx, Workhorse, GitLab Rails, GitLab Shell, etc. for handling user requests and Git operations. A single PostgreSQL database and a Redis server are used for data storage. The storage and access of Git repositories are provided by the Gitaly service. All services of the entire system run on the same server, forming a tightly coupled monolithic application. Figure 1

[0003] However, this single-node architecture faces many challenges when the enterprise scale expands. First, all services concentrated on one server are prone to performance bottlenecks and difficult to handle high concurrency access. Second, the risk of single point of failure is high, and once the server has a problem, the entire system will be unavailable. Third, the storage capacity is limited by the single machine hardware, making it difficult to meet the long-term storage needs of large teams. In addition, system maintenance and upgrades usually require downtime, affecting business continuity. Finally, the security of single-node deployment is poor, and once it is broken, the entire system will be threatened. These problems seriously restrict the application of code repository management systems in large-scale enterprise environments.

[0004] Therefore, how to build a high-availability distributed code repository management system suitable for medium and large enterprises has become a problem to be solved. SUMMARY

[0005] In view of the above-mentioned shortcomings of the prior art, the purpose of the present application is to provide a distributed high-availability code repository management method, system and medium, which realizes high availability, high performance and scalability of code repository management through distributed architecture and redundant configuration.

[0006] To achieve the above-mentioned purpose, the present application adopts the following technical solutions.

[0007] In a first aspect, the present application provides a distributed high-availability code repository management method, which adopts the following technical solutions: obtaining a pre-configured external load balancer, a plurality of GitLab Web nodes, an internal load balancer, a PostgreSQL database cluster, a Redis cluster, a Gitaly cluster, and object storage or file storage; ​load balancing the plurality of GitLab Web nodes by the external load balancer; load balancing GitLab application internal connections by the internal load balancer; storing data of GitLab Web and GitLab Praefect by the PostgreSQL database cluster; and, providing access to Git repositories by the Gitaly cluster.

[0008] Further, in the code repository management method, the load balancing the plurality of GitLab Web nodes by the external load balancer comprises: receiving an external access request; distributing the external access request to one of the plurality of GitLab Web nodes according to a preset load balancing algorithm; and, processing the external access request by the GitLab Web node.

[0009] Further, in the code repository management method, the preset load balancing algorithm is a consistent hashing algorithm based on a four-tuple.

[0010] Further, in the code repository management method, the load balancing GitLab application internal connections by the internal load balancer comprises: receiving a GitLab application internal connection request; distributing the internal connection request to one of the plurality of Praefect nodes according to a preset load balancing algorithm; and, processing the internal connection request by the Praefect node.

[0011] Further, in the code repository management method, the storing data of GitLab Web and GitLab Praefect by the PostgreSQL database cluster comprises: storing application layer metadata and business data of GitLab Web in the PostgreSQL database cluster; and, storing Gitaly cluster metadata of GitLab Praefect in the PostgreSQL database cluster.

[0012] Further, in the code repository management method, the providing access to Git repositories by the Gitaly cluster comprises: receiving an access request to a Git repository; routing, by a Praefect node, the access request to a corresponding Gitaly node; and processing, by the Gitaly node, the access request.

[0013] Further, the code repository management method further includes: storing session data, cache information, and background job queues using the Redis cluster.

[0014] Further, the code repository management method further includes: sharing data objects using the object storage or file storage.

[0015] Further, the code repository management method further includes that each of the plurality of GitLab Web nodes runs Nginx, Workhorse, GitLab Rails, GitLab Shell, and Sidekiq queue service.

[0016] Further, the code repository management method further includes that the Gitaly cluster includes a plurality of Praefect nodes and a plurality of Gitaly nodes, wherein each Git repository has one master node and a plurality of slave nodes in a group of Gitaly nodes.

[0017] Further, the code repository management method further includes upgrading the distributed high-availability code repository management system; wherein the entire system is not interrupted in service during the upgrading process, and the upgrading the distributed high-availability code repository management system includes: upgrading the Gitaly nodes, the Praefect nodes, and the GitLab Web nodes in order from back end to front end.

[0018] Further, the code repository management method further includes that the upgrading the distributed high-availability code repository management system further includes: dynamically adjusting the number of Gitaly nodes, Praefect nodes, and GitLab Web nodes according to system load conditions to realize elastic scaling of the system.

[0019] Further, the code repository management method further includes that the upgrading the GitLab Web nodes includes: removing the GitLab Web node to be upgraded from the load balancer; installing a new version of software package on the GitLab Web node to be upgraded; and re-adding the upgraded GitLab Web node to the load balancer.

[0020] In a second aspect, the present application provides a distributed high-availability code repository management, which adopts the following technical solution: A configuration module is configured to obtain a pre-configured external load balancer, a plurality of GitLab Web nodes, an internal load balancer, a PostgreSQL database cluster, a Redis cluster, a Gitaly cluster, and object storage or file storage. An external load balancing module is configured to balance the load of the plurality of GitLab Web nodes. An internal load balancing module is configured to balance the internal connection of the GitLab application. A data storage module is configured to store the data of the GitLab Web and GitLab Praefect using the PostgreSQL database cluster. A repository access module is configured to provide access to the Git repository using the Gitaly cluster.

[0021] In a third aspect, the present application provides a readable storage medium, which adopts the following technical solution: A readable storage medium stores computer instructions, which are executed by a processor to implement the code repository management method of any one of the above first aspects.

[0022] In summary, compared with the prior art, the present application has at least one of the following beneficial technical effects: By adopting a distributed architecture and multi-node deployment, the performance bottleneck problem faced by single-node deployment is solved, and the overall performance and scalability of the system are improved; by introducing external and internal load balancers, the reasonable distribution of requests is realized, and the availability and stability of the system are improved; by using high-availability database clusters and Redis clusters, the reliability and consistency of data are enhanced; by the design of the Gitaly cluster, the efficiency and reliability of Git repository access are improved; by supporting zero downtime upgrade, the continuous availability of the system during the upgrade process is ensured, and the impact on business is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0024] Figure 1 is a topology diagram of a specific embodiment of the prior code repository management method.

[0025] Figure 2 is a flow chart of a specific embodiment of a distributed high-availability code repository management method of the present application.

[0026] Figure 3 is a topological graph of a specific embodiment of a distributed high-availability code repository management method of the present application.

[0027] Figure 4 is a flow chart of a specific embodiment of a distributed high-availability code repository management method of the present application.

[0028] Figure 5 is a structural schematic diagram of a specific embodiment of a distributed high-availability code repository management system of the present application. DETAILED DESCRIPTION

[0029] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application. In addition, it should be understood that the specific embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application.

[0030] It should be noted that the description order of the following embodiments is not as a limitation on the preferred order of the embodiments of the present application. And in the following embodiments, the description of each embodiment has its own emphasis, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0031] The execution order of the method steps described in the embodiments of the present application can be executed in the order described in the specific embodiments, or the execution order of each step can be adjusted on the premise of solving the technical problems according to actual needs, which is not listed one by one here.

[0032] Referring to Figure 2 , the present application provides a distributed high-availability code repository management method, comprising the following steps.

[0033] S1, obtaining a pre-configured external load balancer, a plurality of GitLab Web nodes, an internal load balancer, a PostgreSQL database cluster, a Redis cluster, a Gitaly cluster, and an object storage or a file storage.

[0034] Specifically, referring to Figure 3As shown in Table 1, the external load balancer uses the load balancing service provided by the cloud service provider. The external load balancer is configured with 2 vCPUs and 4 GB of memory to handle the load balancing of the GitLab Web service nodes. The external load balancer distributes requests based on node load to avoid overloading a single node and can automatically shield failed nodes through health checks.

[0035] The GitLab Web nodes are deployed with multiple instances, each configured with 8 vCPUs and 16 GB of memory. These nodes mainly run Nginx, Workhorse, GitLab Rails, GitLab Shell, and Sidekiq queue services. By deploying multiple nodes, the system can be scaled up or down based on the size of the enterprise user base and performance requirements.

[0036] The internal load balancer also uses the load balancing service provided by the cloud service provider and is configured with 2 vCPUs and 4 GB of memory. This internal load balancer is used to handle the load balancing of internal connections within the GitLab application and distributes requests to the various GitLab Praefect nodes.

[0037] The PostgreSQL database cluster uses the high-availability PostgreSQL instance provided by the cloud service provider. This database cluster is used to store the application layer metadata and business data of GitLab Web and the Gitaly cluster metadata of GitLab Praefect. The database cluster uses a master-slave architecture and supports automatic failover, allowing any standby node to be switched to the master node.

[0038] The Redis cluster also uses the high-availability Redis cluster service provided by the cloud service provider. The Redis cluster is used to store session data, cache information, and background job queues. When the master node fails, the cluster automatically switches to the standby node to ensure service high availability and data high reliability.

[0039] The Gitaly cluster is composed of multiple Praefect nodes and Gitaly nodes. The Praefect nodes are configured with 4 vCPUs and 8 GB of memory to manage and coordinate multiple Gitaly nodes. The Gitaly nodes are configured with 8 vCPUs and 16 GB of memory to handle the storage, access, and management operations of Git repositories.

[0040] Object storage or file storage uses the object storage service or file storage service provided by the cloud service provider. This is used to share data objects such as CI / CD Artifacts, LFS Objects, Uploads, Merge Request Diffs, Packages, etc.

[0041] Table 1: Service Node Configuration External Load Balancer 1 2 vCPUs, 4 GB memory Internal Load Balancer 1 2 vCPUs, 4 GB memory PostgreSQL 1 4 vCPUs, 8 GB memory Redis 1 2 vCPUs, 8 GB memory Praefect 3 4 vCPUs, 8 GB memory Gitaly 3 8 vCPUs, 16 GB memory Gitlab Web 3 8 vCPUs, 16 GB memory Object Storage - - S2, load balancing multiple GitLab Web nodes through an external load balancer, can use the load balancing service provided by the cloud service provider. The external load balancer can distribute requests according to node load to avoid single node overload, and can automatically shield failed nodes through health checks. This way can improve the overall performance and availability of the system.

[0042] S3, load balancing internal connections of the GitLab application through the internal load balancer, also can use the load balancing service provided by the cloud service provider. The internal load balancer is used to handle the load balancing of internal connections of the GitLab application, and distribute requests to each GitLab Praefect node. This design can achieve reasonable distribution of internal connections of the GitLab application, improve the stability and reliability of the system.

[0043] S4, use the PostgreSQL database cluster to store data of GitLab Web and GitLab Praefect. Through the high-availability PostgreSQL instance provided by the cloud service provider, store the application layer metadata and business data of GitLab Web and the Gitaly cluster metadata of GitLab Praefect.

[0044] S5, use the Gitaly cluster to provide access to Git repositories. The Gitaly cluster is composed of multiple Praefect nodes and Gitaly nodes. The Gitaly node is responsible for handling storage, access and management operations of Git repositories. Through the design of the Gitaly cluster, the efficiency and reliability of Git repository access can be improved, and the long-term storage needs of large-scale teams can be met.

[0045] Compared with the single-node deployment shown in Figure 1 The distributed high-availability code repository management method of the embodiment of the application solves a plurality of problems: 1. Performance problem: through multi-node deployment and load balancing, the CPU, memory and disk I / O bottlenecks of single node are avoided; 2. Reliability and availability: through redundant configuration, even if a node fails, other nodes can still continue to provide services; 3. Storage capacity: using distributed storage and object storage / file storage can meet the long-term storage needs of large-scale teams; 4. Scalability: the number of nodes can be dynamically increased or decreased according to demand, flexibly coping with traffic peaks and business growth; 5. Maintenance and upgrade: rolling upgrades can be performed, upgrading one node at a time without having to take the entire service offline; 6. Security: distributing services across multiple nodes reduces the risk of a single point being compromised.

[0046] With this distributed high-availability code repository management method, medium and large enterprises can obtain higher performance, more reliable, and more flexible code repository management services.

[0047] Further, as an embodiment of the present application, step S2, load balancing the plurality of GitLab Web nodes through the external load balancer, comprises: receiving an external access request; distributing the external access request to one of the plurality of GitLab Web nodes according to a preset load balancing algorithm; and, processing the external access request by the GitLab Web node.

[0048] Specifically, when a user or other external system initiates an access request to the code repository, the request first reaches the external load balancer.

[0049] Distribute the external access request to one of the plurality of GitLab Web nodes according to a preset load balancing algorithm. The external load balancer uses a consistent hashing algorithm based on four-tuple as the preset load balancing algorithm. This algorithm takes into account the source IP, destination IP, source port and destination port four factors, to ensure that the same traffic will be distributed to the same GitLab Web node, thereby improving cache hit rate and session consistency.

[0050] The external access request is processed by the GitLab Web node. The selected GitLab Web node receives the request and performs corresponding processing, such as user authentication, code repository operation, CI / CD task, etc.

[0051] Referring to Table 2, the specific configuration of the external load balancer is as follows: LB port Backend port Protocol Scheduling algorithm 80 80 HTTP tch 443 443 HTTPS tch 22 22 TCP tch Among them, for HTTP protocol, the external load balancer port is 80, and the backend port is 80; for HTTPS protocol, the external load balancer port is 443, and the backend port is 443; for TCP protocol, the load balancer port is 22, and the backend port is 22. The scheduling algorithm of all protocols uses a consistent hashing algorithm based on four-tuple (tch).

[0052] This load balancing method avoids performance bottlenecks by distributing requests across multiple GitLab web nodes. When a GitLab web node fails, the load balancer can automatically redirect traffic to other functioning nodes, ensuring service continuity. Additionally, the number of GitLab web nodes can be dynamically increased or decreased based on actual demand, allowing for different load scenarios. By distributing requests appropriately, resources are fully utilized across all GitLab web nodes, reducing individual node stress and thus lowering response times and improving user access smoothness.

[0053] Furthermore, in some embodiments, the preset load balancing algorithm is a consistent hashing algorithm based on four-tuple. This algorithm uses the source IP address, destination IP address, source port, and destination port as inputs to calculate a hash value using a hash function. This hash value is used to determine which GitLab web service node the request should be distributed to.

[0054] The working principle of the consistent hashing algorithm based on four-tuple is as follows: First, each GitLab web service node is assigned one or more points in the hash space. When a request arrives, the algorithm calculates the four-tuple hash value of the request, then finds the nearest node point in the hash space clockwise, and distributes the request to that node. This method ensures that the same network stream (with the same source IP, destination IP, source port, and destination port) will be consistently distributed to the same GitLab web service node.

[0055] This load balancing algorithm has several advantages in the GitLab system. First, by ensuring that the same traffic is distributed to the same node, it improves cache hit rates and reduces the need for cross-node data synchronization, thereby improving system performance. Second, when nodes are added or removed, only the adjacent part of the hash ring is affected, and most requests remain unchanged, ensuring system stability. In addition, the four-tuple-based hash also considers port information, allowing for more granular differentiation between connections and more balanced load distribution compared to IP-based hash algorithms.

[0056] In the GitLab system, this algorithm is particularly important for maintaining user session continuity. Since multiple requests from a user are continuously distributed to the same GitLab web service node, the need for session data migration between nodes is reduced, improving response speed and user experience. For users performing code submission, code review, or CI / CD pipeline operations, this continuity ensures consistency and efficiency in operations.

[0057] The consistent hashing algorithm based on four-tuple also provides good scalability for the GitLab system. When new GitLab web service nodes need to be added to cope with increasing load, only need to allocate points on the hash ring for the new nodes, the system can automatically disperse part of the load to the new nodes, without causing significant disturbance to the overall system. This smooth expansion capability enables the GitLab system to flexibly cope with the changing needs of teams of different sizes.

[0058] In some embodiments, the process of load balancing internal connections of the GitLab application by the internal load balancer in step S3 includes the following steps: receiving an internal connection request of the GitLab application; distributing the internal connection request to one of the Praefect nodes according to a preset load balancing algorithm; and processing the internal connection request by the Praefect node.

[0059] Specifically, when internal communication is needed between different components of the GitLab application, these requests first arrive at the internal load balancer.

[0060] The internal load balancer can also use the consistent hashing algorithm based on four-tuple as the preset load balancing algorithm. This algorithm considers four factors: source IP, destination IP, source port, and destination port, to ensure that the same internal connection is distributed to the same Praefect node, thereby improving cache hit rate and connection consistency.

[0061] After the selected Praefect node receives the request, it will perform corresponding processing, such as managing and coordinating Gitaly nodes, processing access requests for Git repositories, etc.

[0062] Referring to Table 3, the specific configuration of the internal load balancer is as follows: LB port Backend port Protocol Scheduling algorithm 2305 2305 TCP tch Among them, for the TCP protocol, the internal load balancer port is 2305, and the backend port is 2305. The scheduling algorithm uses the consistent hashing algorithm based on four-tuple.

[0063] This internal load balancing approach avoids a single node becoming a performance bottleneck by distributing internal connection requests across multiple Praefect nodes. When a Praefect node fails, the load balancer automatically redirects traffic to other normally operating nodes, ensuring service continuity. At the same time, this internal load balancing approach can dynamically increase or decrease the number of Praefect nodes according to actual needs to cope with different load situations, thereby ensuring that the resources of each Praefect node are fully utilized. Thus, ultimately reducing the pressure on a single node, thereby reducing response time and improving the efficiency of internal communication of the GitLab application.

[0064] Further, as an embodiment of the present application, step S4, using the PostgreSQL database cluster to store the data of GitLab Web and GitLab Praefect, includes: storing the application layer metadata and business data of GitLab Web in the PostgreSQL database cluster; and, storing the Gitaly cluster metadata of GitLab Praefect in the PostgreSQL database cluster.

[0065] Specifically, the application layer metadata and business data stored by the GitLab Web database include user information, project data, permission settings, CI / CD configuration, and all information directly related to GitLab functions. These data cover various data required by user accounts, project repositories, access control, continuous integration and continuous deployment processes, and other core functions.

[0066] The GitLab Praefect database stores the metadata of the Gitaly cluster, including repository replica distribution information, node state data, and replication logic. These metadata are used to manage and coordinate multiple nodes in the Gitaly cluster, ensuring the reliability, consistency, and high availability of Git repository data.

[0067] The steps to configure and use a high-availability PostgreSQL instance are as follows: 1. Create a database, execute the following SQL command in the PostgreSQL instance to create the required database: CREATE DATABASE gitlab_ha_prod; CREATE DATABASE gitlab_praefect_prod; 2. Install the necessary extensions, connect to the PostgreSQL database, and execute the following SQL command to install the required extensions: CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE EXTENSION IF NOT EXISTS btree_gist; CREATE EXTENSION IF NOT EXISTS plpgsql; 3. Set the database owner, if the database owner is incorrect, use the following SQL command to change the owner: ALTER DATABASE gitlab_ha_prod OWNER TO gitlab_prod_dml; ALTER DATABASE gitlab_praefect_prod OWNER TO gitlab_prod_dml; 4. Verify the extension installation, execute the following SQL query to confirm that the extension has been installed correctly: SELECT true AS enabled FROM pg_available_extensions WHERE name = 'pg_trgm' AND installed_version IS NOT NULL; SELECT true AS enabled FROM pg_available_extensions WHERE name = 'btree_gist' AND installed_version IS NOT NULL; SELECT true AS enabled FROM pg_available_extensions WHERE name = 'plpgsql' AND installed_version IS NOT NULL。

[0068] By using a high-availability PostgreSQL instance, the GitLab system can achieve high reliability and consistency of data. The database cluster adopts a one-master-multiple-backup architecture, supports automatic failover, and any backup node can be switched to a master node, thereby ensuring the continuity of the GitLab service and the safety of the data.

[0069] Further, as an embodiment of the present application, step S5, utilizing the Gitaly cluster to provide access to the Git repository, includes: receiving an access request for the Git repository; routing the access request to the corresponding Gitaly node by the Praefect node; and, processing the access request by the Gitaly node.

[0070] In particular, referring to Figure 3 When a user or system initiates an operation request for a Git repository, the request first reaches the Gitaly cluster.

[0071] The Praefect node, as a management component of the Gitaly cluster, is responsible for managing and coordinating multiple Gitaly nodes. The Praefect node decides which Gitaly node to route the request to based on the content of the request and the current state of the Gitaly nodes. For write operations, the Praefect node routes the request to the master Gitaly node; for read operations, the Praefect node may route the request to any available Gitaly node to achieve load balancing.

[0072] The selected Gitaly node receives the request and performs the corresponding Git operation, such as reading file content, creating branches, committing changes, etc. For write operations, the master Gitaly node will synchronize the changes to the slave nodes after processing the request to ensure data consistency.

[0073] In this architecture, the Praefect node acts as an intelligent router, ensuring the reliability, consistency of Git repository data, and high availability of services. By distributing Git repositories across multiple Gitaly nodes, higher concurrent processing capability and better fault recovery capability can be achieved.

[0074] Each Git repository has a configuration of one master node and multiple slave nodes in a set of Gitaly nodes, which provides the following advantages: 1. High availability: even if the master node fails, a new master node can be selected from the slave nodes to continue providing services; 2. Read-write separation: write operations are concentrated on the master node, while read operations can be distributed to multiple slave nodes, improving overall performance; 3. Data redundancy: By storing the same data on multiple nodes, the risk of data loss is reduced; 4. Load balancing: Read operations can be distributed to multiple slave nodes, avoiding a single node becoming a performance bottleneck; 5. Flexible expansion: The number of slave nodes can be dynamically increased or decreased according to demand, to adapt to different sizes of teams and projects.

[0075] Through this design, the Gitaly cluster can provide stable and efficient Git repository access services for large-scale and high-concurrency code repository management systems.

[0076] Further, as an embodiment of the present application, the code repository management method further comprises: Using the Redis cluster to store session data, cache information and background job queues.

[0077] Specifically, the Redis cluster is used to store session data, cache information and background job queues. The Redis cluster uses the high-availability Redis cluster service provided by the cloud service provider. This Redis cluster plays an important role in the distributed high-availability code repository management method, significantly improving overall performance and reliability by improving data access speed, supporting distributed session management and task queue processing.

[0078] The Redis cluster stores session data, realizing distributed session management. This allows multiple GitLab Web nodes to share user session information, ensuring that users remain logged in when switching between different nodes, providing a seamless user experience. Cache information is stored in the Redis cluster, speeding up the read speed of frequently accessed data, reducing database load and improving response speed. Background job queues are also stored in the Redis cluster, used to manage and schedule asynchronous tasks such as sending email notifications, executing CI / CD tasks, etc., improving task processing efficiency.

[0079] The high-availability Redis cluster service configuration includes multiple Redis nodes, usually using a master-slave replication architecture. In this architecture, a master node is responsible for handling write operations, and multiple slave nodes are responsible for handling read operations. When the master node fails, the cluster will automatically elect a slave node to upgrade to a new master node, ensuring service continuity. This automatic failover mechanism ensures the high availability of the Redis service, even in the event of node failure, ensuring continuous service.

[0080] The configuration process of Redis cluster includes setting appropriate memory size, persistence strategy, network timeout parameters, etc. To improve data reliability, the AOF (Append Only File) persistence mechanism is usually enabled to periodically write data in memory to disk. In addition, configure appropriate memory eviction policy, such as LRU (Least Recently Used) algorithm, to automatically delete infrequently used data when the memory reaches the upper limit.

[0081] By using Redis cluster, the distributed high-availability code repository management method realizes efficient data caching and session management, improves overall performance and user experience. The high availability design of Redis cluster ensures the continuity of service and the reliability of data even in the case of partial node failure.

[0082] Further, as an embodiment of the present application, the code repository management method further comprises: Utilize the object storage or file storage to share data objects.

[0083] Specifically, object storage or file storage can use object storage services or file storage services provided by cloud service providers. These storage services are used to share CI / CD Artifacts, LFS Objects, Uploads, Merge Request Diffs, Packages and other data objects.

[0084] In the distributed high-availability code repository management method, file storage is chosen as the way to share data objects, which has many advantages. File storage performs well in handling frequent small file read-write operations, has lower latency, and can provide better performance. This feature is particularly important for code repository management systems, as developers often need to perform a large number of small file operations during daily development, such as code submission, branch merging, etc.

[0085] File storage also has real-time synchronization function, ensuring data consistency and timeliness. In a distributed environment, data synchronization between multiple nodes is crucial. By using file storage, each GitLab Web node can access the latest shared data in real time without additional synchronization mechanisms, simplifying the system architecture and improving overall efficiency.

[0086] In actual deployment, the file storage service can be mounted to the / mnt / data / gitlab directory of each GitLab web node. In this way, all GitLab web nodes can share access to the same data objects, including CI / CD build artifacts, large file storage objects, uploaded files, merge request diffs, and software packages. This sharing mechanism ensures that no matter which GitLab web node the request is routed to, it can access complete and consistent data.

[0087] The method of sharing data objects using file storage not only improves data access efficiency, but also enhances system scalability. When new GitLab web nodes are needed, simply mount the file storage to the corresponding directory of the new node, and the new node can immediately access all shared data without complex data migration or synchronization processes.

[0088] In addition, file storage usually provides powerful backup and recovery functions, further improving data security and reliability. In the event of a failure or data loss, shared data can be quickly recovered, minimizing the impact on the code repository management service.

[0089] By utilizing file storage to share data objects, the distributed high-availability code repository management method implements an efficient and reliable data sharing mechanism, providing a solid technical foundation for large-scale team collaboration.

[0090] Further, each of the plurality of GitLab web nodes runs Nginx, Workhorse, GitLab Rails, GitLab Shell, and Sidekiq queue service. These services work together to provide users with complete code repository management functions.

[0091] Nginx, as a reverse proxy server, handles HTTP and HTTPS requests from users. Nginx receives external requests and forwards them to the appropriate internal services, while also being responsible for static file service and SSL termination. Through the configuration of Nginx, load balancing, caching, and security enhancement functions can be achieved.

[0092] Workhorse is a lightweight reverse proxy specifically designed to optimize the performance of GitLab. Workhorse mainly handles large file uploads and Git operations, reducing the burden on GitLab Rails. By directly handling certain request types, Workhorse can significantly improve the response speed and efficiency of the system.

[0093] GitLab Rails is the core application of GitLab, running the main business logic. GitLab Rails uses Puma as the application server, handling dynamic requests, user authentication, permission management, and other functions. GitLab Rails is also responsible for interacting with the database, handling data storage and retrieval.

[0094] GitLab Shell handles SSH operations, allowing users to interact with Git repositories through the SSH protocol. GitLabShell verifies user identity and executes corresponding Git commands based on user permissions. This enables users to securely push and pull code.

[0095] Sidekiq is a background task processing system used to handle asynchronous tasks. In GitLab, Sidekiq is responsible for handling email sending, webhook triggering, CI / CD tasks, and other operations that need to be executed in the background. By using Sidekiq, GitLab can efficiently handle a large number of concurrent tasks and improve overall performance.

[0096] The process of installing and configuring these services includes downloading the GitLab installation package, configuring the gitlab.rb file, and executing the installation command. In the gitlab.rb file, specific configurations for each service can be defined, such as port settings, SSL certificate paths, database connection information, and more. After configuration is complete, execute the gitlab-ctl reconfigure command to make the configuration take effect, and GitLab will automatically install and configure all required services.

[0097] By running these services on each GitLab Web node, load balancing and high availability can be achieved. Multiple nodes provide services simultaneously, not only improving the system's concurrent processing capacity but also enhancing fault recovery capabilities. If a node fails, other nodes can continue to provide services, ensuring the stable operation of the entire system.

[0098] This design enables GitLab to meet the needs of large-scale teams and provide high-performance, reliable code repository management services. By properly configuring and optimizing these services, GitLab's performance and user experience can be further improved.

[0099] Furthermore, the Gitaly cluster includes multiple Praefect nodes and multiple Gitaly nodes, where each Git repository has a master node and multiple slave nodes in a group of Gitaly nodes.

[0100] Specifically, the configuration of the Gitaly cluster involves the installation and setup of Praefect nodes and Gitaly nodes. For Praefect nodes, download the GitLab CE version installation package and upload it to the server, then execute the installation command. After installation, modify the / etc / gitlab / gitlab.rb configuration file and set Praefect-related parameters such as listening address, port, database connection information, etc. For Gitaly nodes, also download and install the GitLab CE version installation package, then modify the / etc / gitlab / gitlab.rb configuration file and set Gitaly-related parameters such as storage path, listening address, etc. After configuration, execute the gitlab-ctl reconfigure command on each node to make the configuration take effect.

[0101] In the Gitaly cluster, each Git repository has a master node and multiple slave nodes in a group of Gitaly nodes. The master node is responsible for handling all write operations, while the slave nodes are mainly used for read operations and data backup. When the master node receives a write request, it first performs the operation locally and then synchronizes the changes to the slave nodes. The slave nodes periodically synchronize data from the master node to ensure data consistency. This mechanism achieves high availability and data replication for Git repositories.

[0102] The Praefect node acts as the coordinator of the Gitaly cluster, responsible for managing the state of Gitaly nodes and routing requests. When receiving a Git operation request, Praefect routes the request to the appropriate Gitaly node based on load balancing strategies and node health status. In actual deployment, multiple virtual storages can be predefined in the gitlab.rb configuration file of the Praefect node, each corresponding to the configuration of several Gitaly nodes, thereby achieving logical grouping and access scheduling for different Git repositories. For write operations, Praefect sends the request to the master node; for read operations, any healthy node can be selected for processing. Praefect also monitors the health status of Gitaly nodes and automatically promotes a slave node to a new master node when detecting master node failure, ensuring service continuity.

[0103] With this configuration, the Gitaly cluster can provide high-availability Git repository storage and access services. The deployment of multiple Praefect nodes and Gitaly nodes enhances the reliability and performance of the entire cluster. Even if a node fails, other nodes can continue to provide services, minimizing the risk of service interruption. In addition, this architecture also supports horizontal expansion mechanisms based on virtual storage. Each virtual storage is composed of multiple Gitaly nodes, which can be mapped to different virtual storages according to the storage path of the Git repository (as shown in Figure 3 ), thereby realizing distributed management and load sharing of repository data. By increasing the number of virtual storages, not only can the storage capacity and processing capacity of the system be improved, but also the growing business demands can be met.

[0104] Further, as an embodiment of the present application, the code repository management method further comprises: upgrading the distributed high-availability code repository management system; wherein the entire system is not interrupted in service during the upgrading process, and the upgrading of the distributed high-availability code repository management system comprises: upgrading the Gitaly nodes, the Praefect nodes and the GitLab Web nodes in order from the back end to the front end.

[0105] Specifically, when upgrading the distributed high-availability code repository management system, the external service will not be interrupted during the entire upgrading process. The upgrading process is carried out in order from the back end to the front end, that is, the Gitaly nodes are upgraded first, then the Praefect nodes are upgraded, and finally the GitLab Web nodes are upgraded.

[0106] The upgrading of the Gitaly nodes includes the following steps: installing a new version of the software package on each Gitaly node, modifying the configuration file to adapt to the requirements of the new version, and executing a reconfiguration command to make the new configuration effective. During the upgrading process, the load balancer will temporarily transfer requests to other un-upgraded Gitaly nodes to ensure the continuity of the service.

[0107] The upgrading process of the Praefect nodes is similar to that of the Gitaly nodes. A new version of the software package is installed on each Praefect node, the configuration file is adjusted, and a reconfiguration command is executed. During the upgrading, other Praefect nodes will take over the workload to ensure that the access to the Git repository is not affected.

[0108] The upgrade of GitLab Web nodes is the last step. For each GitLab Web node, the upgrade process includes removing the node from the load balancer, installing the new version of the software package, adjusting the configuration file, executing the reconfiguration command, and finally rejoining the node to the load balancer. When upgrading individual nodes, other GitLab Web nodes continue to handle user requests, ensuring continuous availability of services.

[0109] Through this step-by-step upgrade method, the distributed high-availability code repository management system can complete version updates without interrupting services. Each type of node has multiple instances, and during the upgrade process, some nodes are always available, achieving zero downtime upgrade. This upgrade strategy not only ensures the continuous operation of the system, but also reduces the risk during the upgrade process, providing users with stable and reliable code repository management services.

[0110] Further, as an embodiment of the present application, the upgrade of the distributed high-availability code repository management system further includes: According to the system load, dynamically adjust the number of Gitaly nodes, Praefect nodes, and GitLab Web nodes to achieve elastic scaling of the system.

[0111] Specifically, the distributed high-availability code repository management method includes dynamically adjusting the number of Gitaly nodes, Praefect nodes, and GitLab Web nodes according to the load to achieve elastic scaling. This method assesses the load level by monitoring the resource usage of each node. Monitoring indicators include CPU usage, memory usage, disk I / O, network traffic, etc. When these indicators exceed the preset threshold, the adjustment of the number of nodes is triggered.

[0112] When the load is high, the corresponding type of node can be increased. For example, when the CPU usage of GitLab Web nodes continuously exceeds 80%, new GitLab Web nodes can be added. The addition process of new nodes includes configuring new servers, installing necessary software, copying configuration files, and joining the nodes to the load balancer. After the addition is completed, the load balancer automatically distributes part of the requests to the new nodes, reducing the pressure on existing nodes.

[0113] Conversely, when the load is low, the number of nodes can be reduced to save resources. For example, when the average CPU usage of Gitaly nodes is below 20% for a long time, some nodes can be removed. When removing nodes, the load balancer stops distributing new requests to the node, and after the existing requests are processed, the node is removed from the cluster.

[0114] For Praefect nodes, the number can be adjusted according to the number of Git operation requests processed. When the number of requests surges, increasing the Praefect nodes can improve routing efficiency. Conversely, during periods of low request volume, the number of Praefect nodes can be reduced.

[0115] The adjustment of the number of nodes is achieved through an automated script that makes decisions based on monitoring data and performs corresponding operations. When adding or removing nodes, a rolling approach is taken, adjusting one node at a time to ensure service continuity. After a new node is added, health checks and performance tests are conducted to ensure it is functioning properly before it begins receiving actual traffic.

[0116] Through this dynamic adjustment mechanism, the distributed high-availability code repository management method can flexibly adjust resource configuration according to actual needs, optimizing resource utilization while ensuring performance.

[0117] Further, the upgrading of the GitLab Web node includes: removing the GitLab Web node to be upgraded from the load balancer; installing a new version of the software package on the GitLab Web node to be upgraded; and, rejoining the upgraded GitLab Web node to the load balancer.

[0118] Specifically, the process of upgrading the GitLab Web node includes removing the node from the load balancer, installing a new version of the software package, and rejoining the load balancer. During the upgrade process, the load balancer dynamically adjusts traffic distribution to ensure the continuous availability of the entire code repository management service.

[0119] When upgrading the GitLab Web node, stop the Nginx and Git SSH services. Execute the following command to stop the Nginx service: sudo gitlab-ctl stop nginx. Execute the following command to stop the Git SSH service: sudo systemctl stopgitlab_sshd. After stopping these services, the node no longer receives new requests, and the load balancer distributes traffic to other available GitLab Web nodes.

[0120] Next, install the new version of the software package. Use the following command to install the new version: sudo rpm -Uvh <package_name>. After installation, execute the reconfigure command to make the new configuration take effect: sudo gitlab-ctl reconfigure. After the reconfigure process is complete, restart the Nginx and Git SSH services. Execute the following command to start the Nginx service: sudo gitlab-ctl start nginx. Execute the following command to start the Git SSH service: sudo systemctl start gitlab_sshd. After the services are restarted, rejoin the GitLab Web node to the load balancer. The load balancer will gradually distribute traffic to the upgraded node, ensuring a smooth transition.

[0121] By upgrading the GitLab Web node in this way, during the entire upgrade process, other nodes that have not been upgraded continue to handle user requests, ensuring uninterrupted operation of the code repository management service. The dynamic adjustment of the load balancer ensures reasonable distribution of traffic, minimizing the impact of the upgrade on users. This upgrade strategy not only maintains the continuous availability of the service, but also reduces the risk during the upgrade process, providing users with a stable and reliable code repository management service.

[0122] For example, the implementation process of a specific embodiment of a distributed high-availability code repository management method of the present application is as follows Figure 4The system entry is an external load balancer that receives requests from users and distributes them to multiple GitLab web nodes. These web nodes run services such as Nginx, Workhorse, GitLab Rails, GitLab Shell, and Sidekiq, which collectively handle user interactions with the web interface, API calls, and Git operations. Behind the web layer is an internal load balancer that is responsible for load balancing internal connections within the GitLab application, distributing requests to multiple Praefect nodes. The Praefect nodes act as coordinators for the Gitaly cluster, managing the state of multiple Gitaly nodes and routing Git repository access requests. The Gitaly nodes are responsible for actual Git repository storage and operations, with each repository having a primary node and multiple secondary nodes in a set of Gitaly nodes to achieve high availability and read-write separation. The system also includes a PostgreSQL database cluster for storing metadata and business data for the GitLab web application layer and Gitaly cluster metadata for GitLab Praefect. A Redis cluster is used to store session data, cache information, and background job queues, improving system response speed and task processing efficiency. Object storage or file storage is used for sharing large data objects such as CI / CD Artifacts and LFS Objects.

[0123] The workflow is as follows: user requests first arrive at the external load balancer and are then distributed to a certain GitLab web node. The web node processes the request, which may require access to Git repository data, at which point the request is routed to a Praefect node through the internal load balancer. The Praefect node forwards the request to the appropriate Gitaly node based on the request type and load conditions. The Gitaly node performs the actual Git operation and returns the result to the Praefect node, which then returns it to the user along the request path. In this process, the PostgreSQL database and Redis cluster are frequently accessed to obtain or store necessary data. This multi-level, distributed architecture design enables the system to handle large-scale concurrent requests while ensuring high availability through redundant configuration. The multi-node deployment and load balancing of each layer ensure that even if a node fails, the entire system can continue to provide services.

[0124] In addition, this architecture also supports flexible horizontal expansion, which can dynamically increase or decrease the number of various nodes according to actual needs. The upgrade and maintenance of the system can also be carried out in a rolling manner, ensuring that the service does not interrupt during the upgrade process. In general, the architecture design of this distributed high-availability code repository management system fully considers the needs of large-scale team collaboration and provides excellent solutions in terms of performance, reliability, scalability, and maintainability.

[0125] The embodiment of the application also discloses a distributed high-availability code repository management system.

[0126] Reference Figure 5 The distributed high-availability code repository management system comprises a configuration module 1, an external load balancing module 2, an internal load balancing module 3, a data storage module 4 and a repository access module 5. These modules cooperate with each other to form a high-performance and reliable code repository management system.

[0127] The configuration module 1 is responsible for managing the configuration information of the whole system. The configuration module 1 obtains the configuration parameters of the pre-configured external load balancer, multiple GitLab Web nodes, internal load balancer, PostgreSQL database cluster, Redis cluster, Gitaly cluster and object storage or file storage. The configuration module 1 ensures the configuration consistency of each component, facilitating the unified management and maintenance of the system.

[0128] The external load balancing module 2 receives external requests from users and distributes these requests to multiple GitLab Web nodes. The external load balancing module 2 uses a preset load balancing algorithm, such as a consistent hashing algorithm based on a four-tuple, to ensure that the same network stream is distributed to the same GitLab Web node, improving cache hit rate and session consistency. The external load balancing module 2 also automatically shields faulty nodes through a health check mechanism, improving the availability of the system.

[0129] The internal load balancing module 3 handles connection requests within the GitLab application. The internal load balancing module 3 distributes these requests to multiple Praefect nodes to achieve load balancing of the Gitaly cluster. The internal load balancing module 3 uses a similar load balancing algorithm as the external load balancing module 2 to ensure efficient distribution and processing of internal connections.

[0130] The data storage module 4 manages the data storage requirements of the system. The data storage module 4 stores the application layer metadata and business data of the GitLab Web using a PostgreSQL database cluster, and the Gitaly cluster metadata of the GitLab Praefect. The data storage module 4 also stores session data, cache information, and background job queues using a Redis cluster, improving data access speed and system response performance.

[0131] The repository access module 5 provides access services to Git repositories through the Gitaly cluster. The repository access module 5 receives access requests to Git repositories and routes the requests to corresponding Gitaly nodes by Praefect nodes. The repository access module 5 implements high availability and data replication for Git repositories, with each Git repository having a master node and multiple slave nodes in a group of Gitaly nodes.

[0132] Through this distributed high-availability architecture, the code repository management system can handle large-scale concurrent requests while ensuring high availability. Even if a node fails, the entire system can continue to provide services. The system upgrades and maintenance can also be carried out in a rolling manner, ensuring that services are not interrupted during the upgrade process. This design fully considers the needs of large-scale team collaboration and provides excellent solutions in terms of performance, reliability, scalability, and maintainability.

[0133] The embodiment of the application further discloses a readable storage medium.

[0134] A readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the distributed high-availability code repository management method described in any one of the above embodiments. The computer readable storage medium can include any entity or device capable of carrying the computer program, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution medium. The computer program includes computer program code. The computer program code can be in the form of source code, object code, executable file, or some intermediate form. The computer readable storage medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution medium.

[0135] Any procedural or methodological descriptions in flow charts or otherwise described herein can be understood as representing modules, segments or portions of code that include one or more executable instructions for implementing the specified logical function or process and that the scope of the preferred embodiments of the present application includes additional implementations that can not be in the order shown or discussed, including performing functions in substantially simultaneous fashion or in reverse order according to the involved functionality, as will be understood by those skilled in the art to which embodiments of the present application pertain.

[0136] The logic and / or steps represented in flow charts or otherwise described herein, for example, can be considered as a list of executable instructions for implementing the logic function, which can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor- containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions, or a combination of these.

[0137] The above embodiments are only used to illustrate the technical solutions of the present application, not limit it; although the above-mentioned embodiments of the present application are described in detail, those skilled in the art should understand: it can still modify the technical solutions recorded in the above-mentioned embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A distributed high-availability code repository management method, characterized in that, The method comprises: acquiring a pre-configured external load balancer, a plurality of GitLab Web nodes, an internal load balancer, a PostgreSQL database cluster, a Redis cluster, a Gitaly cluster, and an object storage or file storage; load balancing the plurality of GitLab Web nodes by the external load balancer; load balancing GitLab application internal connections by the internal load balancer; storing data of GitLab Web and GitLab Praefect by the PostgreSQL database cluster; and providing access to Git repositories by the Gitaly cluster.

2. The code repository management method according to claim 1, characterized by, The load balancing the plurality of GitLab Web nodes by the external load balancer comprises: receiving an external access request; distributing the external access request to one of the plurality of GitLab Web nodes according to a preset load balancing algorithm; and processing the external access request by the GitLab Web node.

3. The code repository management method according to claim 2, characterized by, The preset load balancing algorithm is a consistent hashing algorithm based on a four-tuple.

4. The code repository management method according to claim 1, characterized by, The load balancing GitLab application internal connections by the internal load balancer comprises: receiving a GitLab application internal connection request; distributing the internal connection request to one of the plurality of Praefect nodes according to a preset load balancing algorithm; and processing the internal connection request by the Praefect node.

5. The code repository management method according to claim 1, characterized by, The storing data of GitLab Web and GitLab Praefect by the PostgreSQL database cluster comprises: storing application layer metadata and business data of GitLab Web in the PostgreSQL database cluster; and storing Gitaly cluster metadata of GitLab Praefect in the PostgreSQL database cluster.

6. The code repository management method according to claim 1, characterized by, The providing access to Git repositories by the Gitaly cluster comprises: receiving an access request to a Git repository; routing the access request to a corresponding Gitaly node by a Praefect node; and processing the access request by the Gitaly node.

7. The code repository management method according to claim 1, characterized by, Further comprising: storing session data, cache information, and background job queues by the Redis cluster.

8. The code repository management method according to claim 1, characterized by, Further comprising: sharing data objects by the object storage or file storage.

9. The code repository management method according to claim 1, characterized by, Each of the plurality of GitLab Web nodes runs Nginx, Workhorse, GitLab Rails, GitLab Shell, and Sidekiq queue service.

10. The code repository management method according to claim 1, characterized by, The Gitaly cluster comprises a plurality of Praefect nodes and a plurality of Gitaly nodes, wherein each Git repository has one master node and a plurality of slave nodes in a group of Gitaly nodes.

11. The code repository management method according to claim 1, characterized by, Further comprising: upgrading the distributed high-availability code repository management system; The whole system is not interrupted in the upgrading process, and the distributed high-availability code repository management system is upgraded, including: The Gitaly node, the Praefect node and the GitLab Web node are upgraded in turn from the back end to the front end.

12. The code repository management method according to claim 11, wherein, The distributed high-availability code repository management system is upgraded, further including: According to the system load condition, the number of Gitaly nodes, Praefect nodes and GitLab Web nodes is dynamically adjusted to realize the elastic scaling of the system.

13. The code repository management method according to claim 11, characterized by, The GitLab Web node is upgraded, including: The GitLab Web node to be upgraded is removed from the load balancer; The new version of the software package is installed on the GitLab Web node to be upgraded; and The upgraded GitLab Web node is re-joined to the load balancer.

14. A distributed high-availability code repository management, characterized by, The system includes: A configuration module is configured to obtain a pre-configured external load balancer, a plurality of GitLab Web nodes, an internal load balancer, a PostgreSQL database cluster, a Redis cluster, a Gitaly cluster and an object storage or file storage; An external load balancing module is configured to balance the load of the plurality of GitLab Web nodes; An internal load balancing module is configured to balance the internal connection of the GitLab application; A data storage module is configured to store the data of the GitLab Web and the GitLab Praefect by using the PostgreSQL database cluster; and A repository access module is configured to provide access to the Git repository by using the Gitaly cluster.

15. A readable storage medium, characterized by, The readable storage medium stores computer instructions, and the computer instructions are executed by the processor to implement the code repository management method in any one of claims 1-13.

Images