Quick Links: Roadmap | Want to Contribute? |
Gitaly is a Git RPC service for handling all the Git calls made by GitLab.
For documentation generated from the protobuf definitions (in proto/ directory),
see Gitaly RPC documentation.
To see where it fits in please look at GitLab's architecture.
Fault-tolerant horizontal scaling of Git storage in GitLab, and particularly, on GitLab.com.
All application code accesses Git repositories via Gitaly.
Besides "Git over RPC" functionality, Gitaly also offers an optional high-availability solution.
We are building features according to our roadmap.
Most users won't install Gitaly on its own. It is already included in your GitLab installation.
Gitaly requires Go 1.22. Run make to compile the executables
required by Gitaly.
Gitaly uses git. Versions 2.47.0 and newer are supported.
The administration and reference guide is documented in the GitLab project.
See CONTRIBUTING.md and a list of quick win issues.
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.
The Gitaly and Gitaly cluster documentation details the architecture and design of Gitaly, including a list of known Gitaly consumers.
Gitaly offers a High Availability solution known as Gitaly Cluster (product documentation).
- In its current iteration, client traffic goes through Praefect, which then replicates data to multiple Gitaly servers, and stores state in a PostgreSQL database (see Design above).
- We are working on a new distributed replication solution referred to as Raft, notably removing the need for Praefect and its database, and offering stricter consistency guarantees. See this epic for details on the new design and its progress.
More about the project and its processes is detailed in the docs.
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.tomlGitaly supports Continuous Profiling through LabKit using Stackdriver Profiler.
For more information on how to set it up, see the LabKit monitoring docs.
The Gitaly Training and Resources Playlist contains videos that give an overview into how Gitaly works, as well as dive deep into different parts of Gitaly and even Git.
- TheConf talk on Scaling GitLab Git storage with Gitaly, 2019-08-16
- Infrastructure Team Update 2017-05-11
- Gitaly Basics, 2017-05-01
- Git Paris meetup, 2017-02-22 a high-level overview of what our plans are and where we are.