GitLab Server HA
With work on Postgres HA progressing, we need to start looking at other areas of the larger High Availability solution. One of these key aspects is the ability for the actual GitLab servers themselves to also be redundant. In the event one of them goes down, another should be ready to automatically take over and continue serving users.
There are two main components to this:
- Ensuring the configuration is as straight forward as possible.
- Centralizing the configuration required to spin up and deploy multiple GitLab app nodes.
- Any shared secrets are properly passed from initially configured node to others.
- Configuration of shared Redis, Postgres services.
- Population of the load balancer.
With the addition of Consul for PG HA, we could leverage this to also help reduce the amount of manual duplication of configuration across the GitLab nodes within