gitaly

README

Quick Links: Roadmap | Want to Contribute? | GitLab Gitaly Issues | GitLab Gitaly Merge Requests | gitlab.com monitoring dashboard |

---

Gitaly is a Git RPC service for handling all the git calls made by GitLab.

To see where it fits in please look at GitLab's architecture.

Project Goals

Fault-tolerant horizontal scaling of Git storage in GitLab, and particularly, on gitlab.com.

This will be achieved by focusing on two areas (in this order):

1. Migrate from repository access via NFS to gitaly-proto, GitLab's new Git RPC protocol
2. Evolve from large Gitaly servers managed as "pets" to smaller Gitaly servers that are "cattle"

Current Status

As of GitLab 11.5, almost all application code accesses Git repositories through Gitaly instead of direct disk access. GitLab.com production no longer uses direct disk access to touch Git repositories; the NFS mounts have been removed.

The last feature that remains to be migrated is the Elasticsearch indexer. Once that is done we can conclude the migration project by removing the Git repository storage paths from gitlab-rails's configuration.

In the meantime we are building features according to our roadmap.

If you're interested in seeing how well Gitaly is performing on GitLab.com, we have dashboards!

Overall

By Feature

Installation

Most users won't install Gitaly on its own. It is already included in your GitLab installation.

Gitaly requires Go 1.10 or newer and Ruby 2.5. Run make to download and compile Ruby dependencies, and to compile the Gitaly Go executable.

Gitaly uses git. Version 2.18.0 or higher is required.

Configuration

See configuration documentation.

Contributing

See CONTRIBUTING.md.

Name

Gitaly is a tribute to git and the town of Aly. Where the town of Aly has zero inhabitants most of the year we would like to reduce the number of disk operations to zero for most actions. It doesn't hurt that it sounds like Italy, the capital of which is the destination of all roads. All git actions in GitLab end up in Gitaly.

Design

High-level architecture overview:

Edit this diagram directly in Google Drawings

Gitaly clients

As of Q4 2018, the following GitLab components act as Gitaly clients:

• gitlab-rails: the main GitLab Rails application.
• gitlab-shell: for git clone, git push etc. via SSH.
• gitlab-workhorse: for git clone via HTTPS and for slow requests that serve raw Git data. (example)
• gitaly-ssh: for internal Git data transfers between Gitaly servers.
• gitaly-ruby: for RPC's that interact with more than one repository, such as merging a branch.

The clients written in Go (gitlab-shell, gitlab-workhorse, gitaly-ssh) use library code from the gitlab.com/gitlab-org/gitaly/client package.

Distributed Tracing

Gitaly supports distributed tracing through LabKit using OpenTracing APIs.

By default, no tracing implementation is linked into the binary, but different OpenTracing providers can be linked in using build tags/build constraints. This can be done by setting the BUILD_TAGS make variable.

For more details of the supported providers, see LabKit, but as an example, for Jaeger tracing support, include the tags: BUILD_TAGS="tracer_static tracer_static_jaeger".

$ make BUILD_TAGS="tracer_static tracer_static_jaeger"

Once Gitaly is compiled with an opentracing provider, the tracing configuration is configured via the GITLAB_TRACING environment variable.

For example, to configure Jaeger, you could use the following command:

GITLAB_TRACING=opentracing://jaeger ./gitaly config.toml

Presentations

• Git Paris meetup, 2017-02-22 a high-level overview of what our plans are and where we are.
• Gitaly Basics, 2017-05-01
• Infrastructure Team Update 2017-05-11