A Common Gitlab Deployment Scenario
GitLab is an open DevOps platform used by many companies and organizations both small and large. While GitLab has a cloud based SaaS offering, it is often deployed and hosted on-premise using self-managed GitLab instances.
Let us focus on a simple, yet common GitLab high availability setup and deployment scenario. Consider a small to mid-market sized business with approximately 100 GitLab users. GitLab’s own installation documentation recommends a single machine installation for under 2,000 users:
For GitLab instances with less than 2,000 users, it’s recommended that you use the default setup by installing GitLab on a single machine to minimize maintenance and resource costs.
A single machine deployment is both simple and straight forward with reduced maintenance and resources required for operation.
GitLab as One Service, Multiple Processes
GitLab is comprised of much more than just a simple web application. Omnibus GitLab bundles all required services and tools needed to run and manage a GitLab instance easily. Conceptually, think of GitLab running as a typical single service with systemd for process management. Behind the scenes however, many processes such as NGINX, PostgreSQL, Redis, and many more are actively running.
Currently we have one machine (one node) and one service, GitLab. With a slight increase in complexity (and twice the system resources), we can turn a single machine deployment into a highly available (HA) GitLab Cluster.
Hello High Availability: Pacemaker and DRBD
Let’s put it all together:
Pacemaker is a high availability cluster resource management platform. Pacemaker will be responsible for managing GitLab, it’s data, and all required resources such as mounted filesystems and virtual IP addresses.
DRBD® is a software-based, shared-nothing, replicated storage solution mirroring the content of block devices. Here we will be using DRBD to replicate a mounted filesystem containing GitLab’s data such as a PostgreSQL database and any git repositories.
GitLab will be managed by Pacemaker as a resource. It can only run as a single instance on one node at a time. If there is a system failure, GitLab can immediately failover to an available node.
Try it Out
Building a GitLab cluster managed by Pacemaker while leveraging DRBD as the backing storage device is a simple solution for achieving high availability and increasing the uptime of your GitLab environment in the event of a system failure.
If you’re interested in making your GitLab instance highly available, please have a look at our HA GitLab Using DRBD and Pacemaker tech guide. This guide will walk you through configuring a highly available GitLab Community Edition environment.
A Quick Note on HA Solutions for GitLab
While Pacemaker and DRBD are widely used open source tools often used together to create a vast array of HA software stack configurations, there are other HA and disaster recovery (DR) solutions available from GitLab.
For example, GitLab supports multiple application nodes for scaling as well as replicating entire instances using GitLab Geo. These solutions are beyond the scope of this blog post and accompanying tech guide.
