`gitaly['my_setting']` in `/etc/gitlab/gitlab.rb`. Changes will be applied
when you run `gitlab-ctl reconfigure`.
In case you want to change some of its settings:
```ruby
gitaly['prometheus_listen_addr']='localhost:9236'
```
To change a Gitaly setting in installations from source you can edit
`/home/git/gitaly/config.toml`. Changes will be applied when you run
`service gitlab restart`.
**For Omnibus GitLab**
```toml
prometheus_listen_addr="localhost:9236"
```
1. Edit `/etc/gitlab/gitlab.rb` and add or change the [Gitaly settings](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/1dd07197c7e5ae23626aad5a4a070a800b670380/files/gitlab-config-template/gitlab.rb.template#L1622-1676).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
## Client-side GRPC logs
**For installations from source**
Gitaly uses the [gRPC](https://grpc.io/) RPC framework. The Ruby gRPC
client has its own log file which may contain useful information when
you are seeing Gitaly errors. You can control the log level of the
gRPC client with the `GRPC_LOG_LEVEL` environment variable. The
default level is `WARN`.
1. Edit `/home/git/gitaly/config.toml` and add or change the [Gitaly settings](https://gitlab.com/gitlab-org/gitaly/blob/master/config.toml.example).
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
## Running Gitaly on its own server
> This is an optional way to deploy Gitaly which can benefit GitLab
This is an optional way to deploy Gitaly which can benefit GitLab
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.
...
...
@@ -53,76 +43,78 @@ 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.
NOTE: **Note:** While Gitaly can be used as a replacement for NFS, we do not recommend
using EFS as it may impact GitLab's performance. Please review the [relevant documentation](../high_availability/nfs.md#avoid-using-awss-elastic-file-system-efs)
NOTE: **Note:** While Gitaly can be used as a replacement for NFS, it's not recommended
to use EFS as it may impact GitLab's performance. Review the [relevant documentation](../high_availability/nfs.md#avoid-using-awss-elastic-file-system-efs)
for more details.
### Network architecture
- gitlab-rails shards repositories into "repository storages"
-`gitlab-rails/config/gitlab.yml` contains a map from storage names to
(Gitaly address, Gitaly token) pairs
- the `storage name` -\>`(Gitaly address, Gitaly token)` map in
`gitlab.yml` is the single source of truth for the Gitaly network
topology
- a (Gitaly address, Gitaly token) corresponds to a Gitaly server
- a Gitaly server hosts one or more storages
- Gitaly addresses must be specified in such a way that they resolve
Now reconfigure (Omnibus) or restart (source). When you tail the
Gitaly logs on your Gitaly server (`sudo gitlab-ctl tail gitaly` or
`tail -f /home/git/gitlab/log/gitaly.log`) you should see requests
coming in. One sure way to trigger a Gitaly request is to clone a
repository from your GitLab server over HTTP.
NOTE: **Note:**
In some cases, you'll have to set `path` for each `git_data_dirs` in the
format `'path' => '/mnt/gitlab/<storage name>'`.
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Tail the logs to see the requests:
```sh
sudo gitlab-ctl tail gitaly
```
**For installations from source**
1. Edit `/home/git/gitlab/config/gitlab.yml`:
```yaml
gitlab:
repositories:
storages:
default:
gitaly_address:tcp://gitaly.internal:8075
storage1:
gitaly_address:tcp://gitaly.internal:8075
gitaly:
token:'abc123secret'
```
NOTE: **Note:**
In some cases, you'll have to set `path` for each of the `storages` in the
format `path: /mnt/gitlab/<storage name>/repositories`.
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
1. Tail the logs to see the requests:
```sh
tail-f /home/git/gitlab/log/gitaly.log
```
When you tail the Gitaly logs on your Gitaly server you should see requests
coming in. One sure way to trigger a Gitaly request is to clone a repository
from your GitLab server over HTTP.
### Disabling the Gitaly service in a cluster environment
If you are running Gitaly [as a remote
service](#running-gitaly-on-its-own-server) you may want to disable
the local Gitaly service that runs on your GitLab server by default.
Disabling Gitaly only makes sense when you run GitLab in a custom
cluster configuration, where different services run on different
machines. Disabling Gitaly on all machines in the cluster is not a
valid configuration.
To disable Gitaly on a client node:
**For Omnibus GitLab**
1. Edit `/etc/gitlab/gitlab.rb`:
```ruby
gitaly['enable']=false
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
**For installations from source**
1. Edit `/etc/default/gitlab`:
```shell
gitaly_enabled=false
```
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
## TLS support
...
...
@@ -271,168 +326,128 @@ Gitaly supports TLS encryption. To be able to communicate
with a Gitaly instance that listens for secure connections you will need to use `tls://` url
scheme in the `gitaly_address` of the corresponding storage entry in the GitLab configuration.
The admin needs to bring their own certificate as we do not provide that automatically.
The certificate to be used needs to be installed on all Gitaly nodes and on all client nodes that communicate with it following procedures described in [GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
You will need to bring your own certificates as this isn't provided automatically.
The certificate to be used needs to be installed on all Gitaly nodes and on all
client nodes that communicate with it following the procedure described in
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. On the Gitaly server nodes, edit `/etc/gitlab/gitlab.rb`:
#### On Gitaly server nodes:
```ruby
gitaly['tls_listen_addr']="0.0.0.0:9999"
gitaly['certificate_path']="path/to/cert.pem"
gitaly['key_path']="path/to/key.pem"
```
```ruby
gitaly['tls_listen_addr']="0.0.0.0:9999"
gitaly['certificate_path']="path/to/cert.pem"
gitaly['key_path']="path/to/key.pem"
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
### Source installations:
**For installations from source**
#### On client nodes:
1. On the client nodes, edit `/home/git/gitlab/config/gitlab.yml`:
```yaml
# /home/git/gitlab/config/gitlab.yml
gitlab:
repositories:
storages:
default:
path:/mnt/gitlab/default/repositories
gitaly_address:tls://gitaly.internal:9999
storage1:
path:/mnt/gitlab/storage1/repositories
gitaly_address:tls://gitaly.internal:9999
```yaml
gitlab:
repositories:
storages:
default:
gitaly_address: tls://gitaly.internal:9999
storage1:
gitaly_address: tls://gitaly.internal:9999
gitaly:
token:'abc123secret'
```
gitaly:
token: 'abc123secret'
```
#### On Gitaly server nodes:
NOTE: **Note:**
In some cases, you'll have to set `path` for each of the `storages` in the
format `path: /mnt/gitlab/<storage name>/repositories`.
```toml
# /home/git/gitaly/config.toml
tls_listen_addr='0.0.0.0:9999'
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
1. On the Gitaly server nodes, edit `/home/git/gitaly/config.toml`:
[tls]
certificate_path='/path/to/cert.pem'
key_path='/path/to/key.pem'
```
```toml
tls_listen_addr = '0.0.0.0:9999'
## Gitaly-ruby
[tls]
certificate_path = '/path/to/cert.pem'
key_path = '/path/to/key.pem'
```
Gitaly was developed to replace Ruby application code in gitlab-ce/ee.
In order to save time and/or avoid the risk of rewriting existing
application logic, in some cases we chose to copy some application code
from gitlab-ce into Gitaly almost as-is. To be able to run that code, we
made gitaly-ruby, which is a sidecar process for the main Gitaly Go
process. Some examples of things that are implemented in gitaly-ruby are
RPC's that deal with wiki's, and RPC's that create commits on behalf of
a user, such as merge commits.
### Number of gitaly-ruby workers
Gitaly-ruby has much less capacity than Gitaly itself. If your Gitaly
server has to handle a lot of request, the default setting of having
just 1 active gitaly-ruby sidecar might not be enough. If you see
ResourceExhausted errors from Gitaly it's very likely that you have not
enough gitaly-ruby capacity.
You can increase the number of gitaly-ruby processes on your Gitaly
server with the following settings.
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
Omnibus:
To observe what type of connections are actually being used in a
production environment you can use the following Prometheus query:
```ruby
# /etc/gitlab/gitlab.rb
# Default is 2 workers. The minimum is 2; 1 worker is always reserved as
# a passive stand-by.
gitaly['ruby_num_workers']=4
```
Source:
```toml
# /home/git/gitaly/config.toml
[gitaly-ruby]
num_workers=4
sum(rate(gitaly_connections_total[5m])) by (type)
```
### Observing gitaly-ruby traffic
Gitaly-ruby is a somewhat hidden, internal implementation detail of
Gitaly. There is not that much visibility into what goes on inside
gitaly-ruby processes.
## `gitaly-ruby`
If you have Prometheus set up to scrape your Gitaly process, you can see
request rates and error codes for individual RPC's in gitaly-ruby by
querying `grpc_client_handled_total`. Strictly speaking this metric does
not differentiate between gitaly-ruby and other RPC's, but in practice
(as of GitLab 11.9), all gRPC calls made by Gitaly itself are internal
calls from the main Gitaly process to one of its gitaly-ruby sidecars.
Gitaly was developed to replace the Ruby application code in GitLab.
In order to save time and/or avoid the risk of rewriting existing
application logic, in some cases we chose to copy some application code
from GitLab into Gitaly almost as-is. To be able to run that code,
`gitaly-ruby` was created, which is a "sidecar" process for the main Gitaly Go
process. Some examples of things that are implemented in `gitaly-ruby` are
RPCs that deal with wikis, and RPCs that create commits on behalf of
a user, such as merge commits.
Assuming your `grpc_client_handled_total` counter only observes Gitaly,
the following query shows you RPC's are (most likely) internally
implemented as calls to gitaly-ruby.
### Number of `gitaly-ruby` workers
```
sum(rate(grpc_client_handled_total[5m])) by (grpc_method) > 0
```
`gitaly-ruby` has much less capacity than Gitaly itself. If your Gitaly
server has to handle a lot of requests, the default setting of having
just one active `gitaly-ruby` sidecar might not be enough. If you see
`ResourceExhausted` errors from Gitaly, it's very likely that you have not
enough `gitaly-ruby` capacity.
## Disabling or enabling the Gitaly service in a cluster environment
You can increase the number of `gitaly-ruby` processes on your Gitaly
server with the following settings.
If you are running Gitaly [as a remote
service](#running-gitaly-on-its-own-server) you may want to disable
the local Gitaly service that runs on your GitLab server by default.
**For Omnibus GitLab**
> 'Disabling Gitaly' only makes sense when you run GitLab in a custom
cluster configuration, where different services run on different
machines. Disabling Gitaly on all machines in the cluster is not a
valid configuration.
1. Edit `/etc/gitlab/gitlab.rb`:
If you are setting up a GitLab cluster where Gitaly does not need to
run on all machines, you can disable the Gitaly service in your
Omnibus installation, add the following line to `/etc/gitlab/gitlab.rb`:
```ruby
# Default is 2 workers. The minimum is 2; 1 worker is always reserved as
# a passive stand-by.
gitaly['ruby_num_workers'] = 4
```
```ruby
gitaly['enable']=false
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
When you run `gitlab-ctl reconfigure` the Gitaly service will be
disabled.
**For installations from source**
To disable the Gitaly service in a GitLab cluster where you installed
GitLab from source, add the following to `/etc/default/gitlab` on the
machine where you want to disable Gitaly.
1. Edit `/home/git/gitaly/config.toml`:
```shell
gitaly_enabled=false
```
```toml
[gitaly-ruby]
num_workers = 4
```
When you run `service gitlab restart` Gitaly will be disabled on this
particular machine.
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
## Eliminating NFS altogether
...
...
@@ -440,19 +455,23 @@ If you are planning to use Gitaly without NFS for your storage needs
and want to eliminate NFS from your environment altogether, there are
a few things that you need to do:
1. Make sure the [`git` user home directory](https://docs.gitlab.com/omnibus/settings/configuration.html#moving-the-home-directory-for-a-user) is on local disk.
1. Configure [database lookup of SSH keys](../operations/fast_ssh_key_lookup.md)
to eliminate the need for a shared authorized_keys file.
1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
including [live tracing](../job_traces.md#new-live-trace-architecture).
1. Configure [object storage for LFS objects](../../workflow/lfs/lfs_administration.md#storing-lfs-objects-in-remote-object-storage).
1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
NOTE: **Note:** One current feature of GitLab still requires a shared directory (NFS): [GitLab Pages](../../user/project/pages/index.md).
1. Make sure the [`git` user home directory](https://docs.gitlab.com/omnibus/settings/configuration.html#moving-the-home-directory-for-a-user) is on local disk.
1. Configure [database lookup of SSH keys](../operations/fast_ssh_key_lookup.md)
to eliminate the need for a shared authorized_keys file.
1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
including [live tracing](../job_traces.md#new-live-trace-architecture).
1. Configure [object storage for LFS objects](../../workflow/lfs/lfs_administration.md#storing-lfs-objects-in-remote-object-storage).
1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
NOTE: **Note:**
One current feature of GitLab that still requires a shared directory (NFS) is
