Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
1
Merge Requests
1
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
gitlab-ce
Commits
7f32c287
Commit
7f32c287
authored
May 29, 2018
by
Rémy Coutable
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Resolve conflict in doc/administration/high_availability/gitlab.md
Signed-off-by:
Rémy Coutable
<
remy@rymai.me
>
parent
64dc6aa9
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
4 additions
and
12 deletions
+4
-12
doc/administration/high_availability/gitlab.md
doc/administration/high_availability/gitlab.md
+4
-12
No files found.
doc/administration/high_availability/gitlab.md
View file @
7f32c287
...
...
@@ -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
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment