Commit 6e92cbe7 authored by Zeger-Jan van de Weg's avatar Zeger-Jan van de Weg Committed by Douwe Maan

Update Gitaly docs now NFS isn't required anymore

parent cd8ca13d
......@@ -45,9 +45,13 @@ installations that are larger than a single machine. Most
installations will be better served with the default configuration
used by Omnibus and the GitLab source installation guide.
Starting with GitLab 11.4, Gitaly is a replacement for NFS except
when the [Elastic Search indexer](
is used.
Starting with GitLab 11.4, Gitaly is able to serve all Git requests without
needed a shared NFS mount for Git repository data.
Between 11.4 and 11.8 the exception was the
[Elastic Search indexer](
But since 11.8 the indexer uses Gitaly for data access as well. NFS can still
be leveraged for redudancy on block level of the Git data. But only has to
be mounted on the Gitaly server.
### Network architecture
......@@ -62,14 +66,16 @@ is used.
- Gitaly addresses must be specified in such a way that they resolve
correctly for ALL Gitaly clients
- Gitaly clients are: unicorn, sidekiq, gitlab-workhorse,
gitlab-shell, and Gitaly itself
gitlab-shell, Elasticsearch Indexer, and Gitaly itself
- special case: a Gitaly server must be able to make RPC calls **to
itself** via its own (Gitaly address, Gitaly token) pair as
specified in `gitlab-rails/config/gitlab.yml`
- Gitaly servers must not be exposed to the public internet
Gitaly network traffic is unencrypted so you should use a firewall to
restrict access to your Gitaly server.
Gitaly network traffic is unencrypted by default, but supports
[TLS](#tls-support). Authentication is done through a static token. For
security in depth, its recommended to use a firewall to restrict access
to your Gitaly server.
Below we describe how to configure a Gitaly server at address
`gitaly.internal:8075` with secret token `abc123secret`. We assume
......@@ -194,17 +200,16 @@ server from reaching the Gitaly server then all Gitaly requests will
We assume that your Gitaly server can be reached at
`gitaly.internal:8075` from your GitLab server, and that your GitLab
NFS shares are mounted at `/mnt/gitlab/default` and
`/mnt/gitlab/storage1` respectively.
`gitaly.internal:8075` from your GitLab server, and that Gitaly can read and
write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1` respectively.
Omnibus installations:
# /etc/gitlab/gitlab.rb
'default' => { 'path' => '/mnt/gitlab/default', 'gitaly_address' => 'tcp://gitaly.internal:8075' },
'storage1' => { 'path' => '/mnt/gitlab/storage1', 'gitaly_address' => 'tcp://gitaly.internal:8075' },
'default' => { 'gitaly_address' => 'tcp://gitaly.internal:8075' },
'storage1' => { 'gitaly_address' => 'tcp://gitaly.internal:8075' },
gitlab_rails['gitaly_token'] = 'abc123secret'
......@@ -218,10 +223,8 @@ gitlab:
path: /mnt/gitlab/default/repositories
gitaly_address: tcp://gitaly.internal:8075
path: /mnt/gitlab/storage1/repositories
gitaly_address: tcp://gitaly.internal:8075
......@@ -236,7 +239,7 @@ repository from your GitLab server over HTTP.
## TLS support
> [Introduced]( in GitLab 11.7.
> [Introduced]( in GitLab 11.8.
Gitaly supports TLS credentials for GRPC authentication. To be able to communicate
with a Gitaly instance that listens for secure connections you will need to use `tls://` url
......@@ -5,8 +5,9 @@ Workhorse and GitLab-Shell.
## Developing new Git features
Starting with GitLab 10.8, all new Git features should be developed in
To read or write Git data, a request has to be made to Gitaly. This means that
if you're developing a new feature where you need data that's not yet available
in `lib/gitlab/git` changes have to be made to Gitaly.
> This is a new process that is not clearly defined yet. If you want
to contribute a Git feature and you're getting stuck, reach out to the
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment