gitaly

README

Quick Links: Roadmap | Want to Contribute? | GitLab Gitaly Issues | GitLab Gitaly Merge Requests |

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.

For performance reasons some RPCs can be performed through NFS still. An effort is made to mitigate performance issues by removing Gitaly N+1. Once that is no longer necessary we can conclude the migration project by removing the Git repository storage paths from GitLab Rails 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, read about our observability story!

Overall

Dashboard (The link can be accessed by GitLab team members.)

By Feature

Dashboard (The link can be accessed by GitLab team members.)

Installation

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

Gitaly requires Go 1.18 or Go 1.19.7. Run make to compile the executables required by Gitaly.

Gitaly uses git. Versions 2.38.0 and newer are supported.

Configuration

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

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

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

We are working on a high-availability (HA) solution for Gitaly based on asynchronous replication. A Gitaly server would be made highly available by assigning one or more standby servers ("secondaries") to it, each of which contains a full copy of all the repository data on the primary Gitaly server.

To implement this we are building a new GitLab component called Praefect, which is hosted alongside the rest of Gitaly in this repository. As we currently envision it, Praefect will have four responsibilities:

• route RPC traffic to the primary Gitaly server
• inspect RPC traffic and mark repositories as dirty if the RPC is a "mutator"
• ensure dirty repositories have their changes replicated to the secondary Gitaly servers
• in the event of a failure on the primary, demote it to secondary and elect a new primary

Praefect has internal state: it needs to be able to "remember" which repositories are in need of replication, and which Gitaly server is the primary. We will use Postgres to store Praefect's internal state.

As of December 2019 we are busy rolling out the Postgres integration in Praefect. The minimum supported Postgres version is 9.6, just like the rest of GitLab.

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.

Presentations

• Praefect code walkthrough

  A walkthrough of the Praefect codebase.

• How to configure backpressure in Gitaly

  An overview of the knobs in the Gitaly config to set limits on incoming traffic. There is also written documentation.

• How Gitaly fits into GitLab (Youtube) - a series of 1-hour training videos for contributors new to GitLab and Gitaly.

  • Part 1: the Gitaly client in gitlab-ce, 2019-02-21

    Overview of GitLab backend processes, GitLab Rails deep dive: Gitaly config in GitLab Rails, SQL data model, overview of how Gitaly calls get made via GitalyClient.call.

  • Part 2: Git SSH, 2019-02-28

    What is in a gitaly-proto Repository message, legacy vs hashed storage (repository directories), git clone via SSH, gitlab-shell, authorized_keys and forced commands, what happens during git push.

  • Part 3: Git push, 2019-03-07

    A closer look at the final stage of git push where the Git hooks run and the refs get updated. Interaction between the Git hooks and GitLab internal API. The Git object quarantine mechanism. Preview of Git HTTP (to be discussed next time).

  • Part 4: Git HTTP, 2019-03-14

    Intercepting Git HTTP traffic with mitmproxy, overview of Git HTTP clone steps, code walk in gitlab-workhorse and gitlab-ce, investigating internal workhorse API messages used for Git HTTP.

  • Part 5: Merge Requests across Forks, 2019-03-21

    Fixing a locally broken Ruby gem C extension by recompiling, demo of how creating a MR across forks causes new commits to suddenly appear in the fork parent repository, deep dive into the FetchSourceBranch RPC, adding debug code to see how address and authentication metadata is passed down to gitaly-ruby, failed attempt to log gitaly-ssh arguments, comparison of gitaly-ssh and gitlab-shell, a Gitaly server can end up making RPC calls to itself.

  • Part 6: Creating Git commits on behalf of Git users, 2019-03-21

    Demonstrate how usually Git hooks are run by git-receive-pack, but sometimes by gitaly-ruby. Deep dive into UserCommitFiles: where do those hooks actually get run? A look at UserMerge. How does Gitaly make merge commits. A look at the implementation of the special feature where users are not allowed push to a branch, but are allowed to merge into it.

  • Part 7: How Gitaly uses Prometheus monitoring, 2019-07-09

    What is Prometheus. Reconstructing a Grafana dashboard panel with PromQL. Adding a new counter to Gitaly. Querying Prometheus in Gitaly during development. Comparing latency calculation with ELK. GRPC Prometheus middleware in Gitaly.

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