kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity
gitlab-org--gitlab-foss/doc/administration/high_availability/gitaly.md
Cindy Pallares 054f869f6b
Add note to collect CONSUL_SERVER_NODES in HA docs 
There are several instances in our HA docs where an example of
`Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z` is given,
but this value isn't explicitly stated. It should be
the IP addresses or DNS records of the Consul server nodes.
2019-06-26 17:39:58 -05:00

2 KiB
Raw Blame History

Configuring Gitaly for Scaled and High Availability

Gitaly does not yet support full high availability. However, Gitaly is quite stable and is in use on GitLab.com. Scaled and highly available GitLab environments should consider using Gitaly on a separate node.

See the Gitaly HA Epic to track plans and progress toward high availability support.

This document is relevant for Scaled Architecture environments and High Availability Architecture.

Running Gitaly on its own server

See Running Gitaly on its own server in Gitaly documentation.

Continue configuration of other components by going back to:

Enable Monitoring

Introduced in GitLab 12.0.

  1. Make sure to collect CONSUL_SERVER_NODES, which are the IP addresses or DNS records of the Consul server nodes, for the next step. Note they are presented as Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z

  2. Create/edit /etc/gitlab/gitlab.rb and add the following configuration:

    # Enable service discovery for Prometheus
consul['enable'] = true
consul['monitoring_service_discovery'] =  true

# Replace placeholders
# Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
# with the addresses of the Consul server nodes
consul['configuration'] = {
   retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
}

# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
gitaly['prometheus_listen_addr'] = "0.0.0.0:9236"

  3. Run sudo gitlab-ctl reconfigure to compile the configuration.