Commit 7f32c287 authored by Rémy Coutable's avatar Rémy Coutable

Resolve conflict in doc/administration/high_availability/gitlab.md

Signed-off-by: default avatarRémy Coutable <remy@rymai.me>
parent 64dc6aa9
......@@ -76,7 +76,7 @@ for each GitLab application server in your environment.
servers should point to the external url that users will use to access GitLab.
In a typical HA setup, this will be the url of the load balancer which will
route traffic to all GitLab application servers in the HA cluster.
> **Note:** When you specify `https` in the `external_url`, as in the example
above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If
certificates are not present, Nginx will fail to start. See
......@@ -100,13 +100,9 @@ Additional GitLab servers (servers configured **after** the first GitLab server)
need some extra configuration.
1. Configure shared secrets. These values can be obtained from the primary
<<<<<<< HEAD
GitLab server in `/etc/gitlab/gitlab-secrets.json`. Copy this file to the
secondary servers **prior to** running the first `reconfigure` in the steps
above.
=======
GitLab server in `/etc/gitlab/gitlab-secrets.json`. Add these to
`/etc/gitlab/gitlab.rb` **prior to** running the first `reconfigure`.
```ruby
gitlab_shell['secret_token'] = 'fbfb19c355066a9afb030992231c4a363357f77345edd0f2e772359e5be59b02538e1fa6cae8f93f7d23355341cea2b93600dab6d6c3edcdced558fc6d739860'
......@@ -114,21 +110,17 @@ need some extra configuration.
gitlab_rails['secret_key_base'] = '6e657410d57c71b4fc3ed0d694e7842b1895a8b401d812c17fe61caf95b48a6d703cb53c112bc01ebd197a85da81b18e29682040e99b4f26594772a4a2c98c6d'
gitlab_rails['db_key_base'] = 'bf2e47b68d6cafaef1d767e628b619365becf27571e10f196f98dc85e7771042b9203199d39aff91fcb6837c8ed83f2a912b278da50999bb11a2fbc0fba52964'
```
>>>>>>> upstream/master
1. Run `touch /etc/gitlab/skip-auto-migrations` to prevent database migrations
from running on upgrade. Only the primary GitLab application server should
handle migrations.
<<<<<<< HEAD
1. **Optional** Configure host keys. Copy all contents(primary and public keys) inside `/etc/ssh/` on
the primary application server to `/ets/ssh` on all secondary servers. This
prevents false man-in-the-middle-attack alerts when accesing servers in your
1. **Optional** Configure host keys. Copy all contents(primary and public keys) inside `/etc/ssh/` on
the primary application server to `/ets/ssh` on all secondary servers. This
prevents false man-in-the-middle-attack alerts when accessing servers in your
High Availability cluster behind a load balancer.
=======
1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
>>>>>>> upstream/master
## Troubleshooting
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment