From b57e99295a2758174eca2c204faa52d4f8da99f7 Mon Sep 17 00:00:00 2001 From: Mayra Cabrera Date: Sun, 18 Aug 2019 23:56:50 +0000 Subject: Mentions related log on Rate limit docs Requests over the rate limit are logged into `auth.log` --- doc/administration/logs.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/logs.md b/doc/administration/logs.md index 306d611f6bf..a57ef8ddc7d 100644 --- a/doc/administration/logs.md +++ b/doc/administration/logs.md @@ -284,13 +284,16 @@ Introduced in GitLab 11.3. This file lives in `/var/log/gitlab/gitlab-rails/impo Omnibus GitLab packages or in `/home/git/gitlab/log/importer.log` for installations from source. -## `auth.log` +## `auth.log` Introduced in GitLab 12.0. This file lives in `/var/log/gitlab/gitlab-rails/auth.log` for Omnibus GitLab packages or in `/home/git/gitlab/log/auth.log` for installations from source. -It logs information whenever [Rack Attack] registers an abusive request. +This log records: + +- Information whenever [Rack Attack] registers an abusive request. +- Requests over the [Rate Limit] on raw endpoints. NOTE: **Note:** From [%12.1](https://gitlab.com/gitlab-org/gitlab-ce/issues/62756), user id and username are available on this log. @@ -334,3 +337,4 @@ installations from source. [repocheck]: repository_checks.md [Rack Attack]: ../security/rack_attack.md +[Rate Limit]: ../user/admin_area/settings/rate_limits_on_raw_endpoints.md -- cgit v1.2.1 From 0dcb9d21efc1db97765d82ee39a0f0905ba945ba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Diego=20Louz=C3=A1n?= Date: Wed, 10 Jul 2019 21:40:28 +0200 Subject: feat: SMIME signed notification emails - Add mail interceptor the signs outgoing email with SMIME - Add lib and helpers to work with SMIME data - New configuration params for setting up SMIME key and cert files --- doc/administration/index.md | 1 + doc/administration/smime_signing_email.md | 49 +++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+) create mode 100644 doc/administration/smime_signing_email.md (limited to 'doc/administration') diff --git a/doc/administration/index.md b/doc/administration/index.md index f7f9d753e58..6aedd390125 100644 --- a/doc/administration/index.md +++ b/doc/administration/index.md @@ -64,6 +64,7 @@ Learn how to install, configure, update, and maintain your GitLab instance. - [External Classification Policy Authorization](../user/admin_area/settings/external_authorization.md) **(PREMIUM ONLY)** - [Upload a license](../user/admin_area/license.md): Upload a license to unlock features that are in paid tiers of GitLab. **(STARTER ONLY)** - [Admin Area](../user/admin_area/index.md): for self-managed instance-wide configuration and maintenance. +- [S/MIME Signing](smime_signing_email.md): how to sign all outgoing notification emails with S/MIME #### Customizing GitLab's appearance diff --git a/doc/administration/smime_signing_email.md b/doc/administration/smime_signing_email.md new file mode 100644 index 00000000000..9f719088f25 --- /dev/null +++ b/doc/administration/smime_signing_email.md @@ -0,0 +1,49 @@ +# Signing outgoing email with S/MIME + +Notification emails sent by Gitlab can be signed with S/MIME for improved +security. + +> **Note:** +Please be aware that S/MIME certificates and TLS/SSL certificates are not the +same and are used for different purposes: TLS creates a secure channel, whereas +S/MIME signs and/or encrypts the message itself + +## Enable S/MIME signing + +This setting must be explicitly enabled and a single pair of key and certificate +files must be provided in `gitlab.rb` or `gitlab.yml` if you are using Omnibus +GitLab or installed GitLab from source respectively: + +```yaml +email_smime: + enabled: true + key_file: /etc/pki/smime/private/gitlab.key + cert_file: /etc/pki/smime/certs/gitlab.crt +``` + +- Both files must be provided PEM-encoded. +- The key file must be unencrypted so that Gitlab can read it without user + intervention. + +NOTE: **Note:** Be mindful of the access levels for your private keys and visibility to +third parties. + +### How to convert S/MIME PKCS#12 / PFX format to PEM encoding + +Typically S/MIME certificates are handled in binary PKCS#12 format (`.pfx` or `.p12` +extensions), which contain the following in a single encrypted file: + +- Server certificate +- Intermediate certificates (if any) +- Private key + +In order to export the required files in PEM encoding from the PKCS#12 file, +the `openssl` command can be used: + +```bash +#-- Extract private key in PEM encoding (no password, unencrypted) +$ openssl pkcs12 -in gitlab.p12 -nocerts -nodes -out gitlab.key + +#-- Extract certificates in PEM encoding (full certs chain including CA) +$ openssl pkcs12 -in gitlab.p12 -nokeys -out gitlab.crt +``` -- cgit v1.2.1 From 8ff6003b0d0edc1048087766d254ffe1d837f359 Mon Sep 17 00:00:00 2001 From: Evan Read Date: Tue, 20 Aug 2019 18:02:33 +0000 Subject: Harmonizes titles between two Geo landing pages Menu entries in global navigation will be updated to match. --- doc/administration/geo/disaster_recovery/index.md | 2 +- doc/administration/geo/replication/index.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md index d44e141b66b..ba95843b0b0 100644 --- a/doc/administration/geo/disaster_recovery/index.md +++ b/doc/administration/geo/disaster_recovery/index.md @@ -1,4 +1,4 @@ -# Disaster Recovery **(PREMIUM ONLY)** +# Disaster Recovery (Geo) **(PREMIUM ONLY)** Geo replicates your database, your Git repositories, and few other assets. We will support and replicate more data in the future, that will enable you to diff --git a/doc/administration/geo/replication/index.md b/doc/administration/geo/replication/index.md index 5aedb665935..dbd466b906d 100644 --- a/doc/administration/geo/replication/index.md +++ b/doc/administration/geo/replication/index.md @@ -1,4 +1,4 @@ -# Geo Replication **(PREMIUM ONLY)** +# Replication (Geo) **(PREMIUM ONLY)** > - Introduced in GitLab Enterprise Edition 8.9. > - Using Geo in combination with @@ -6,7 +6,7 @@ > is considered **Generally Available** (GA) in > [GitLab Premium](https://about.gitlab.com/pricing/) 10.4. -Geo is the solution for widely distributed development teams. +Replication with Geo is the solution for widely distributed development teams. ## Overview -- cgit v1.2.1 From e632ae80845f849f93e4d85ef9f836a4792844c9 Mon Sep 17 00:00:00 2001 From: Stan Hu Date: Tue, 20 Aug 2019 18:12:28 +0000 Subject: Standardize remote_ip and path keys for auth.log and api_json.log Current `auth.log` uses `fullpath` and `ip`, while `api_json.log` uses `remote_ip` and `path` for the same fields. Let's standardize these namings to make it easier for people working with the data. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66167 --- doc/administration/logs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/administration') diff --git a/doc/administration/logs.md b/doc/administration/logs.md index a57ef8ddc7d..9030c941cad 100644 --- a/doc/administration/logs.md +++ b/doc/administration/logs.md @@ -88,7 +88,7 @@ Introduced in GitLab 10.0, this file lives in It helps you see requests made directly to the API. For example: ```json -{"time":"2018-10-29T12:49:42.123Z","severity":"INFO","duration":709.08,"db":14.59,"view":694.49,"status":200,"method":"GET","path":"/api/v4/projects","params":[{"key":"action","value":"git-upload-pack"},{"key":"changes","value":"_any"},{"key":"key_id","value":"secret"},{"key":"secret_token","value":"[FILTERED]"}],"host":"localhost","ip":"::1","ua":"Ruby","route":"/api/:version/projects","user_id":1,"username":"root","queue_duration":100.31,"gitaly_calls":30,"gitaly_duration":5.36} +{"time":"2018-10-29T12:49:42.123Z","severity":"INFO","duration":709.08,"db":14.59,"view":694.49,"status":200,"method":"GET","path":"/api/v4/projects","params":[{"key":"action","value":"git-upload-pack"},{"key":"changes","value":"_any"},{"key":"key_id","value":"secret"},{"key":"secret_token","value":"[FILTERED]"}],"host":"localhost","remote_ip":"::1","ua":"Ruby","route":"/api/:version/projects","user_id":1,"username":"root","queue_duration":100.31,"gitaly_calls":30,"gitaly_duration":5.36} ``` This entry above shows an access to an internal endpoint to check whether an -- cgit v1.2.1 From a07efbdfd0ccb332df124b6c40287bdccb26fd89 Mon Sep 17 00:00:00 2001 From: manojmj Date: Wed, 21 Aug 2019 09:12:48 +0530 Subject: CE: Audit event for archiving and unarchiving projects --- doc/administration/audit_events.md | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/administration') diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md index 02de2caf558..8075a40cae7 100644 --- a/doc/administration/audit_events.md +++ b/doc/administration/audit_events.md @@ -75,6 +75,8 @@ From there, you can see the following actions: - User was removed from project - Project export was downloaded - Project repository was downloaded +- Project was archived +- Project was unarchived ### Instance events **(PREMIUM ONLY)** -- cgit v1.2.1 From 6e3cd4c560572decf7b75ed79c69a483d8cae974 Mon Sep 17 00:00:00 2001 From: Marcel Amirault Date: Wed, 21 Aug 2019 06:49:23 +0000 Subject: Update capitalization in k8s cheat sheet --- .../troubleshooting/kubernetes_cheat_sheet.md | 28 +++++++++++----------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md index 95cdb1508fa..238c522a0ee 100644 --- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md +++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md @@ -29,7 +29,7 @@ and they will assist you with any issues you are having. ```bash # for minikube: minikube dashboard —url - # for non-local installations if access via kubectl is configured: + # for non-local installations if access via Kubectl is configured: kubectl proxy ``` @@ -49,7 +49,7 @@ and they will assist you with any issues you are having. - What to do with pods in `CrashLoopBackoff` status: - Check logs via Kubernetes dashboard. - - Check logs via `kubectl`: + - Check logs via Kubectl: ```bash kubectl logs -c dependencies @@ -72,7 +72,7 @@ and they will assist you with any issues you are having. This is the principle of Kubernetes, read [Twelve-factor app](https://12factor.net/) for details. -## Gitlab-specific kubernetes information +## GitLab-specific kubernetes information - Minimal config that can be used to test a Kubernetes helm chart can be found [here](https://gitlab.com/charts/gitlab/issues/620). @@ -83,7 +83,7 @@ and they will assist you with any issues you are having. kubectl logs gitlab-unicorn-7656fdd6bf-jqzfs -c unicorn ``` -- It is not possible to get all the logs via `kubectl` at once, like with `gitlab-ctl tail`, +- It is not possible to get all the logs via Kubectl at once, like with `gitlab-ctl tail`, but a number of third-party tools can be used to do it: - [Kubetail](https://github.com/johanhaleby/kubetail) @@ -131,7 +131,7 @@ and they will assist you with any issues you are having. - Check the output of `kubectl get events -w --all-namespaces`. - Check the logs of pods within `gitlab-managed-apps` namespace. - On the side of GitLab check sidekiq log and kubernetes log. When GitLab is installed - via helm chart, kubernetes.log can be found inside the sidekiq pod. + via Helm Chart, `kubernetes.log` can be found inside the sidekiq pod. - How to get your initial admin password : @@ -142,19 +142,19 @@ and they will assist you with any issues you are having. kubectl get secret -ojsonpath={.data.password} | base64 --decode ; echo ``` -- How to connect to a GitLab postgres database: +- How to connect to a GitLab Postgres database: ```bash kubectl exec -it -- /srv/gitlab/bin/rails dbconsole -p ``` -- How to get info about helm installation status: +- How to get info about Helm installation status: ```bash helm status name-of-installation ``` -- How to update GitLab installed using helm chart: +- How to update GitLab installed using Helm Chart: ```bash helm repo upgrade @@ -179,25 +179,25 @@ and they will assist you with any issues you are having. helm upgrade -f gitlab.yaml ``` -## Installation of minimal GitLab config via minukube on macOS +## Installation of minimal GitLab config via Minukube on macOS This section is based on [Developing for Kubernetes with Minikube](https://gitlab.com/charts/gitlab/blob/master/doc/minikube/index.md) and [Helm](https://gitlab.com/charts/gitlab/blob/master/doc/helm/index.md). Refer to those documents for details. -- Install kubectl via Homebrew: +- Install Kubectl via Homebrew: ```bash brew install kubernetes-cli ``` -- Install minikube via Homebrew: +- Install Minikube via Homebrew: ```bash brew cask install minikube ``` -- Start minikube and configure it. If minikube cannot start, try running `minikube delete && minikube start` +- Start Minikube and configure it. If Minikube cannot start, try running `minikube delete && minikube start` and repeat the steps: ```bash @@ -206,7 +206,7 @@ to those documents for details. minikube addons enable kube-dns ``` -- Install helm via Homebrew and initialize it: +- Install Helm via Homebrew and initialize it: ```bash brew install kubernetes-helm @@ -219,7 +219,7 @@ to those documents for details. - Find the IP address in the output of `minikube ip` and update the yaml file with this IP address. -- Install the GitLab helm chart: +- Install the GitLab Helm Chart: ```bash helm repo add gitlab https://charts.gitlab.io -- cgit v1.2.1 From 869bce99af3018d0dedd9fda85ef580e7b27a733 Mon Sep 17 00:00:00 2001 From: Marcel Amirault Date: Wed, 21 Aug 2019 09:20:03 +0000 Subject: Update container_registry.md to handle CA Bundle certs and validation --- doc/administration/container_registry.md | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/administration') diff --git a/doc/administration/container_registry.md b/doc/administration/container_registry.md index d0adeb89543..c90a633ec5a 100644 --- a/doc/administration/container_registry.md +++ b/doc/administration/container_registry.md @@ -137,6 +137,15 @@ otherwise you will run into conflicts. 1. Save the file and [reconfigure GitLab][] for the changes to take effect. +1. Validate using: + + ```sh + openssl s_client -showcerts -servername gitlab.example.com -connect gitlab.example.com:443 > cacert.pem + ``` + +NOTE: **Note:** +If your certificate provider provides the CA Bundle certificates, append them to the TLS certificate file. + **Installations from source** 1. Open `/home/git/gitlab/config/gitlab.yml`, find the `registry` entry and -- cgit v1.2.1 From 8627131929293949ed1918b713fd947615f9743c Mon Sep 17 00:00:00 2001 From: Marcel Amirault Date: Wed, 21 Aug 2019 09:53:06 +0000 Subject: Add let's encrypt omnibus guide link --- doc/administration/container_registry.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'doc/administration') diff --git a/doc/administration/container_registry.md b/doc/administration/container_registry.md index c90a633ec5a..d43b3718bf9 100644 --- a/doc/administration/container_registry.md +++ b/doc/administration/container_registry.md @@ -172,9 +172,13 @@ docker login gitlab.example.com:4567 If the Registry is configured to use its own domain, you will need a TLS certificate for that specific domain (e.g., `registry.example.com`) or maybe -a wildcard certificate if hosted under a subdomain of your existing GitLab +a wildcard certificate if hosted under a subdomain of your existing GitLab domain (e.g., `registry.gitlab.example.com`). +NOTE: **Note:** +As well as manually generated SSL certificates (explained here), certificates automatically +generated by Let's Encrypt are also [supported in Omnibus installs](https://docs.gitlab.com/omnibus/settings/ssl.html#host-services). + Let's assume that you want the container Registry to be accessible at `https://registry.gitlab.example.com`. -- cgit v1.2.1 From c2cbfc5c4afbe8385659f97769db8450284639cf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kamil=20Trzci=C5=84ski?= Date: Tue, 20 Aug 2019 17:25:04 +0200 Subject: Rework `Sidekiq::JobsThreads` into `Monitor` This makes: - very shallow `Middleware::Monitor` to only request tracking of sidekiq jobs, - `SidekiqStatus::Monitor` to be responsible to maintain persistent connection to receive messages, - `SidekiqStatus::Monitor` to always use structured logging and instance variables --- doc/administration/troubleshooting/sidekiq.md | 118 ++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) (limited to 'doc/administration') diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md index 7067958ecb4..9b016c64e29 100644 --- a/doc/administration/troubleshooting/sidekiq.md +++ b/doc/administration/troubleshooting/sidekiq.md @@ -169,3 +169,121 @@ The PostgreSQL wiki has details on the query you can run to see blocking queries. The query is different based on PostgreSQL version. See [Lock Monitoring](https://wiki.postgresql.org/wiki/Lock_Monitoring) for the query details. + +## Managing Sidekiq queues + +It is possible to use [Sidekiq API](https://github.com/mperham/sidekiq/wiki/API) +to perform a number of troubleshoting on Sidekiq. + +These are the administrative commands and it should only be used if currently +admin interface is not suitable due to scale of installation. + +All this commands should be run using `gitlab-rails console`. + +### View the queue size + +```ruby +Sidekiq::Queue.new("pipeline_processing:build_queue").size +``` + +### Enumerate all enqueued jobs + +```ruby +queue = Sidekiq::Queue.new("chaos:chaos_sleep") +queue.each do |job| + # job.klass # => 'MyWorker' + # job.args # => [1, 2, 3] + # job.jid # => jid + # job.queue # => chaos:chaos_sleep + # job["retry"] # => 3 + # job.item # => { + # "class"=>"Chaos::SleepWorker", + # "args"=>[1000], + # "retry"=>3, + # "queue"=>"chaos:chaos_sleep", + # "backtrace"=>true, + # "queue_namespace"=>"chaos", + # "jid"=>"39bc482b823cceaf07213523", + # "created_at"=>1566317076.266069, + # "correlation_id"=>"c323b832-a857-4858-b695-672de6f0e1af", + # "enqueued_at"=>1566317076.26761}, + # } + + # job.delete if job.jid == 'abcdef1234567890' +end +``` + +### Enumerate currently running jobs + +```ruby +workers = Sidekiq::Workers.new +workers.each do |process_id, thread_id, work| + # process_id is a unique identifier per Sidekiq process + # thread_id is a unique identifier per thread + # work is a Hash which looks like: + # {"queue"=>"chaos:chaos_sleep", + # "payload"=> + # { "class"=>"Chaos::SleepWorker", + # "args"=>[1000], + # "retry"=>3, + # "queue"=>"chaos:chaos_sleep", + # "backtrace"=>true, + # "queue_namespace"=>"chaos", + # "jid"=>"b2a31e3eac7b1a99ff235869", + # "created_at"=>1566316974.9215662, + # "correlation_id"=>"e484fb26-7576-45f9-bf21-b99389e1c53c", + # "enqueued_at"=>1566316974.9229589}, + # "run_at"=>1566316974}], +end +``` + +### Remove sidekiq jobs for given parameters (destructive) + +```ruby +# for jobs like this: +# RepositoryImportWorker.new.perform_async(100) +id_list = [100] + +queue = Sidekiq::Queue.new('repository_import') +queue.each do |job| + job.delete if id_list.include?(job.args[0]) +end +``` + +### Remove specific job ID (destructive) + +```ruby +queue = Sidekiq::Queue.new('repository_import') +queue.each do |job| + job.delete if job.jid == 'my-job-id' +end +``` + +## Canceling running jobs (destructive) + +> Introduced in GitLab 12.3. + +This is highly risky operation and use it as last resort. +Doing that might result in data corruption, as the job +is interrupted mid-execution and it is not guaranteed +that proper rollback of transactions is implemented. + +```ruby +Gitlab::SidekiqMonitor.cancel_job('job-id') +``` + +> This requires the Sidekiq to be run with `SIDEKIQ_MONITOR_WORKER=1` +> environment variable. + +To perform of the interrupt we use `Thread.raise` which +has number of drawbacks, as mentioned in [Why Ruby’s Timeout is dangerous (and Thread.raise is terrifying)](https://jvns.ca/blog/2015/11/27/why-rubys-timeout-is-dangerous-and-thread-dot-raise-is-terrifying/): + +> This is where the implications get interesting, and terrifying. This means that an exception can get raised: +> +> * during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error) +> * during the cleanup for the network request +> * during a rescue block +> * while creating an object to save to the database afterwards +> * in any of your code, regardless of whether it could have possibly raised an exception before +> +> Nobody writes code to defend against an exception being raised on literally any line. That’s not even possible. So Thread.raise is basically like a sneak attack on your code that could result in almost anything. It would probably be okay if it were pure-functional code that did not modify any state. But this is Ruby, so that’s unlikely :) -- cgit v1.2.1 From fffba04a0da9d0bb920c89f75b003931f2f051fc Mon Sep 17 00:00:00 2001 From: Ben Bodenmiller Date: Wed, 21 Aug 2019 12:55:37 +0000 Subject: Clarify how to setup and use multiple Gitaly servers --- doc/administration/gitaly/index.md | 82 ++++++++++++++++++++++++++++---------- 1 file changed, 61 insertions(+), 21 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 150494c47e5..878f0ef842d 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -64,6 +64,7 @@ The following list depicts what the network architecture of Gitaly is: topology. - A `(Gitaly address, Gitaly token)` corresponds to a Gitaly server. - A Gitaly server hosts one or more storages. +- A GitLab server can use one or more Gitaly servers. - Gitaly addresses must be specified in such a way that they resolve correctly for ALL Gitaly clients. - Gitaly clients are: Unicorn, Sidekiq, gitlab-workhorse, @@ -77,14 +78,16 @@ The following list depicts what the network architecture of Gitaly is: - Authentication is done through a static token which is shared among the Gitaly and GitLab Rails nodes. -Below we describe how to configure a Gitaly server at address -`gitaly.internal:8075` with secret token `abc123secret`. We assume -your GitLab installation has two repository storages, `default` and -`storage1`. +Below we describe how to configure two Gitaly servers one at +`gitaly1.internal` and the other at `gitaly2.internal` +with secret token `abc123secret`. We assume +your GitLab installation has three repository storages: `default`, +`storage1` and `storage2`. ### 1. Installation -First install Gitaly using either Omnibus GitLab or install it from source: +First install Gitaly on each Gitaly server using either +Omnibus GitLab or install it from source: - For Omnibus GitLab: [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab package you want using **steps 1 and 2** from the GitLab downloads page but @@ -119,7 +122,7 @@ Configure a token on the instance that runs the GitLab Rails application. ### 3. Gitaly server configuration -Next, on the Gitaly server, you need to configure storage paths, enable +Next, on the Gitaly servers, you need to configure storage paths, enable the network listener and configure the token. NOTE: **Note:** if you want to reduce the risk of downtime when you enable @@ -175,15 +178,29 @@ Check the directory layout on your Gitaly server to be sure. gitaly['listen_addr'] = "0.0.0.0:8075" gitaly['auth_token'] = 'abc123secret' + # To use TLS for Gitaly you need to add + gitaly['tls_listen_addr'] = "0.0.0.0:9999" + gitaly['certificate_path'] = "path/to/cert.pem" + gitaly['key_path'] = "path/to/key.pem" + ``` + +1. Append the following to `/etc/gitlab/gitlab.rb` for each respective server: + + For `gitaly1.internal`: + + ``` gitaly['storage'] = [ { 'name' => 'default' }, { 'name' => 'storage1' }, ] + ``` + + For `gitaly2.internal`: - # To use TLS for Gitaly you need to add - gitaly['tls_listen_addr'] = "0.0.0.0:9999" - gitaly['certificate_path'] = "path/to/cert.pem" - gitaly['key_path'] = "path/to/key.pem" + ``` + gitaly['storage'] = [ + { 'name' => 'storage2' }, + ] ``` NOTE: **Note:** @@ -206,13 +223,26 @@ Check the directory layout on your Gitaly server to be sure. [auth] token = 'abc123secret' + ``` + +1. Append the following to `/home/git/gitaly/config.toml` for each respective server: + + For `gitaly1.internal`: + ```toml [[storage]] name = 'default' [[storage]] name = 'storage1' ``` + + For `gitaly2.internal`: + + ```toml + [[storage]] + name = 'storage2' + ``` NOTE: **Note:** In some cases, you'll have to set `path` for each `[[storage]]` in the @@ -231,9 +261,13 @@ then all Gitaly requests will fail. Additionally, you need to [disable Rugged if previously manually enabled](../high_availability/nfs.md#improving-nfs-performance-with-gitlab). -We assume that your Gitaly server can be reached at -`gitaly.internal:8075` from your GitLab server, and that Gitaly can read and -write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1` respectively. +We assume that your `gitaly1.internal` Gitaly server can be reached at +`gitaly1.internal:8075` from your GitLab server, and that Gitaly server +can read and write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1`. + +We assume also that your `gitaly2.internal` Gitaly server can be reached at +`gitaly2.internal:8075` from your GitLab server, and that Gitaly server +can read and write to `/mnt/gitlab/storage2`. **For Omnibus GitLab** @@ -241,8 +275,9 @@ write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1` respectively. ```ruby git_data_dirs({ - 'default' => { 'gitaly_address' => 'tcp://gitaly.internal:8075' }, - 'storage1' => { 'gitaly_address' => 'tcp://gitaly.internal:8075' }, + 'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' }, + 'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' }, + 'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' }, }) gitlab_rails['gitaly_token'] = 'abc123secret' @@ -268,9 +303,11 @@ write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1` respectively. repositories: storages: default: - gitaly_address: tcp://gitaly.internal:8075 + gitaly_address: tcp://gitaly1.internal:8075 storage1: - gitaly_address: tcp://gitaly.internal:8075 + gitaly_address: tcp://gitaly1.internal:8075 + storage2: + gitaly_address: tcp://gitaly2.internal:8075 gitaly: token: 'abc123secret' @@ -350,8 +387,9 @@ To configure Gitaly with TLS: ```ruby git_data_dirs({ - 'default' => { 'gitaly_address' => 'tls://gitaly.internal:9999' }, - 'storage1' => { 'gitaly_address' => 'tls://gitaly.internal:9999' }, + 'default' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' }, + 'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' }, + 'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' }, }) gitlab_rails['gitaly_token'] = 'abc123secret' @@ -377,9 +415,11 @@ To configure Gitaly with TLS: repositories: storages: default: - gitaly_address: tls://gitaly.internal:9999 + gitaly_address: tls://gitaly1.internal:9999 storage1: - gitaly_address: tls://gitaly.internal:9999 + gitaly_address: tls://gitaly1.internal:9999 + storage2: + gitaly_address: tls://gitaly2.internal:9999 gitaly: token: 'abc123secret' -- cgit v1.2.1 From e2d4fadbf83381b7ed3fbb3a00b5dee28e0817d9 Mon Sep 17 00:00:00 2001 From: Marcel Amirault Date: Wed, 21 Aug 2019 13:50:22 +0000 Subject: Fix markdown causing kramdown warnings Use of square brackets can cause kramdown warnings, as well as angle brackets, so they should be removed or put in backticks --- .../high_availability/load_balancer.md | 57 +++++++++++----------- .../index.md | 2 +- .../monitoring/performance/request_profiling.md | 2 +- 3 files changed, 30 insertions(+), 31 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/load_balancer.md b/doc/administration/high_availability/load_balancer.md index 9e9f604317a..f11d27487d1 100644 --- a/doc/administration/high_availability/load_balancer.md +++ b/doc/administration/high_availability/load_balancer.md @@ -60,11 +60,21 @@ for details on managing SSL certificates and configuring Nginx. ### Basic ports -| LB Port | Backend Port | Protocol | -| ------- | ------------ | --------------- | -| 80 | 80 | HTTP [^1] | -| 443 | 443 | TCP or HTTPS [^1] [^2] | -| 22 | 22 | TCP | +| LB Port | Backend Port | Protocol | +| ------- | ------------ | ------------------------ | +| 80 | 80 | HTTP (*1*) | +| 443 | 443 | TCP or HTTPS (*1*) (*2*) | +| 22 | 22 | TCP | + +- (*1*): [Web terminal](../../ci/environments.md#web-terminals) support requires + your load balancer to correctly handle WebSocket connections. When using + HTTP or HTTPS proxying, this means your load balancer must be configured + to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the + [web terminal](../integration/terminal.md) integration guide for + more details. +- (*2*): When using HTTPS protocol for port 443, you will need to add an SSL + certificate to the load balancers. If you wish to terminate SSL at the + GitLab application server instead, use TCP protocol. ### GitLab Pages Ports @@ -72,12 +82,19 @@ If you're using GitLab Pages with custom domain support you will need some additional port configurations. GitLab Pages requires a separate virtual IP address. Configure DNS to point the `pages_external_url` from `/etc/gitlab/gitlab.rb` at the new virtual IP address. See the -[GitLab Pages documentation][gitlab-pages] for more information. +[GitLab Pages documentation](../pages/index.md) for more information. -| LB Port | Backend Port | Protocol | -| ------- | ------------ | -------- | -| 80 | Varies [^3] | HTTP | -| 443 | Varies [^3] | TCP [^4] | +| LB Port | Backend Port | Protocol | +| ------- | ------------- | --------- | +| 80 | Varies (*1*) | HTTP | +| 443 | Varies (*1*) | TCP (*2*) | + +- (*1*): The backend port for GitLab Pages depends on the + `gitlab_pages['external_http']` and `gitlab_pages['external_https']` + setting. See [GitLab Pages documentation](../pages/index.md) for more details. +- (*2*): Port 443 for GitLab Pages should always use the TCP protocol. Users can + configure custom domains with custom SSL, which would not be possible + if SSL was terminated at the load balancer. ### Alternate SSH Port @@ -86,7 +103,7 @@ it may be helpful to configure an alternate SSH hostname that allows users to use SSH on port 443. An alternate SSH hostname will require a new virtual IP address compared to the other GitLab HTTP configuration above. -Configure DNS for an alternate SSH hostname such as altssh.gitlab.example.com. +Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`. | LB Port | Backend Port | Protocol | | ------- | ------------ | -------- | @@ -101,24 +118,6 @@ Read more on high-availability configuration: 1. [Configure NFS](nfs.md) 1. [Configure the GitLab application servers](gitlab.md) -[^1]: [Web terminal](../../ci/environments.md#web-terminals) support requires - your load balancer to correctly handle WebSocket connections. When using - HTTP or HTTPS proxying, this means your load balancer must be configured - to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the - [web terminal](../integration/terminal.md) integration guide for - more details. -[^2]: When using HTTPS protocol for port 443, you will need to add an SSL - certificate to the load balancers. If you wish to terminate SSL at the - GitLab application server instead, use TCP protocol. -[^3]: The backend port for GitLab Pages depends on the - `gitlab_pages['external_http']` and `gitlab_pages['external_https']` - setting. See [GitLab Pages documentation][gitlab-pages] for more details. -[^4]: Port 443 for GitLab Pages should always use the TCP protocol. Users can - configure custom domains with custom SSL, which would not be possible - if SSL was terminated at the load balancer. - -[gitlab-pages]: ../pages/index.md -