Update Gitaly docs now NFS isn't required anymore
This commit is contained in:
parent
cd8ca13d14
commit
6e92cbe711
|
|
@ -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](https://gitlab.com/gitlab-org/gitlab-elasticsearch-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](https://gitlab.com/gitlab-org/gitlab-elasticsearch-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
|
|||
fail.
|
||||
|
||||
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:
|
||||
|
||||
```ruby
|
||||
# /etc/gitlab/gitlab.rb
|
||||
git_data_dirs({
|
||||
'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:
|
|||
repositories:
|
||||
storages:
|
||||
default:
|
||||
path: /mnt/gitlab/default/repositories
|
||||
gitaly_address: tcp://gitaly.internal:8075
|
||||
storage1:
|
||||
path: /mnt/gitlab/storage1/repositories
|
||||
gitaly_address: tcp://gitaly.internal:8075
|
||||
|
||||
gitaly:
|
||||
|
|
@ -236,7 +239,7 @@ repository from your GitLab server over HTTP.
|
|||
|
||||
## TLS support
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22602) in GitLab 11.7.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22602) 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
|
||||
Gitaly.
|
||||
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue