gitaly

README

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.

Project Goals

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

Current Status

Almost all application code accesses Git repositories via Gitaly (with the exception of Rugged which we're working on removing).

Besides "Git over RPC" functionality, Gitaly also offers an optional high-availability solution.

We are building features according to our roadmap.

Installation

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

Gitaly requires Go 1.20. Run make to compile the executables required by Gitaly.

Gitaly uses git. Versions 2.42.0 and newer are supported.

Configuration

The administration and reference guide is documented in the GitLab project.

Contributing

See CONTRIBUTING.md and a list of quick win issues.

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:

graph LR

  subgraph "Gitaly Service"
  Gitaly == git ==> Filesystem
  end

  subgraph "Clients"
    Rails[gitlab-rails] --> Gitaly
    Workhorse --> Gitaly
    Shell[gitlab-shell] -- command-line\nclient --> Gitaly
    Gitaly -. Authorization .-> Rails
  end

  Rails -. Rugged .-> Filesystem

In High Availability mode, the current implementation looks like this (some details omitted):

graph LR

  subgraph "Gitaly Nodes"
  Gitaly == git ==> Filesystem
  end

  subgraph "Praefects"
    LB[typical setup uses a loadbalancer] --> P1
    LB --> P2
    P1[Praefect 1]
    P2[Praefect N]
    P1 --> PG[(PostgreSQL)]
    P2 --> PG
  end

  subgraph "Clients"
    Rails[gitlab-rails]
    Workhorse
    Shell[gitlab-shell]
  end

Clients --> Praefects --> Gitaly

Gitaly clients

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

• gitlab: 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.
• gitaly-ssh: for internal Git data transfers between Gitaly servers.

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

High Availability

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.

Further reading

More about the project and its processes is detailed in the docs.

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

Continuous Profiling

Gitaly supports Continuous Profiling through LabKit using Stackdriver Profiler.

For more information on how to set it up, see the LabKit monitoring docs.

Training Videos

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.

Presentations

• 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.

Documentation

Index

• func UnpackAuxiliaryBinaries(destinationDir string) error

Functions

func UnpackAuxiliaryBinaries

func UnpackAuxiliaryBinaries(destinationDir string) error

UnpackAuxiliaryBinaries unpacks the packed auxiliary binaries of Gitaly into destination directory.

Gitaly invoking auxiliary binaries across different releases is a source of backwards compatibility issues. The calling protocol may change and cause issues if we don't carefully maintain the compatibility. Major version changing the module path also causes problems for gob encoding as it effectively changes the name of every type. To avoid having to maintain backwards compatibility between the different Gitaly binaries, we want to pin a given gitaly binary to only ever call the auxiliary binaries of the same build. We achieve this by packing the auxiliary binaries in the main gitaly binary and unpacking them on start to a temporary directory we can call them from. This way updating the gitaly binaries on the disk is atomic and a running gitaly can't call auxiliary binaries from a different version.