Skip to content

G
gitlab-ce
Commit b49fab30 authored by Rémy Coutable's avatar Rémy Coutable
Browse files
Options

Merge remote-tracking branch 'origin/master' into ce-to-ee-2017-11-22 

Signed-off-by: default avatarRémy Coutable <remy@rymai.me>
parents 7e67ed69 78dcafe8
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 531 additions and 362 deletions
CHANGELOG-EE.md
View file @ b49fab30
Please view this file on the master branch, on stable branches it's out of date.
## 10.2.1 (2017-11-22)
- No changes.
## 10.2.0 (2017-11-22)
### Fixed (17 changes)
......
CHANGELOG.md
View file @ b49fab30
......@@ -2,6 +2,13 @@
documentation](doc/development/changelog.md) for instructions on adding your own
entry.
## 10.2.1 (2017-11-22)
### Fixed (1 change)
- Force disable Prometheus metrics.
## 10.2.0 (2017-11-22)
### Security (4 changes)
......
doc/gitlab-geo/README.md
View file @ b49fab30
......@@ -39,9 +39,9 @@ and the replicated read-only ones as **secondaries**.
Keep in mind that:
- Secondaries talk to primary to get user data for logins (API), to
clone/pull from repositories (SSH) and to retrieve LFS Objects and Attachments
clone/pull from repositories (SSH) and to retrieve LFS Objects and Attachments
(HTTPS + JWT).
- Since GitLab Enterprise Edition Premium 10.0, the primary no longer talks to
- Since GitLab Enterprise Edition Premium 10.0, the primary no longer talks to
secondaries to notify for changes (API).
## Use-cases
......@@ -123,7 +123,7 @@ update the state.
This new architecture allows us to be resilient to connectivity issues between the
nodes. It doesn't matter if it was just a few minutes or days. The secondary
instance will be able to replay all the events in the correct order and get in
instance will be able to replay all the events in the correct order and get in
sync again.
## Setup instructions
......@@ -141,10 +141,10 @@ If you installed GitLab using the Omnibus packages (highly recommended):
secondary node for the moment.
1. [Upload the GitLab License](../user/admin_area/license.md) on the **primary** Geo Node to unlock GitLab Geo.
1. [Setup the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology).
1. [Configure SSH authorizations to use the database](ssh.md)
1. [Lookup authorized SSH keys in the database](../administration/operations/speed_up_ssh.html), do this step for both primary AND secondary nodes.
1. [Configure GitLab](configuration.md) to set the primary and secondary nodes.
1. Optional: [Configure a secondary LDAP server](../administration/auth/ldap.md) for the secondary. See [notes on LDAP](#ldap).
1. [Follow the after setup steps](after_setup.md).
1. [Follow the "Using a Geo Server" guide](using_a_geo_server.md).
[install-ee]: https://about.gitlab.com/downloads-ee/ "GitLab Enterprise Edition Omnibus packages downloads page"
......@@ -157,10 +157,10 @@ If you installed GitLab from source:
else in the secondary node for the moment.
1. [Upload the GitLab License](../user/admin_area/license.md) on the **primary** Geo Node to unlock GitLab Geo.
1. [Setup the database replication](database_source.md) (`primary (read-write) <-> secondary (read-only)` topology).
1. [Configure SSH authorizations to use the database](ssh.md)
1. [Lookup authorized SSH keys in the database](../administration/operations/speed_up_ssh.html), do this step for both primary AND secondary nodes.
1. [Configure GitLab](configuration_source.md) to set the primary and secondary
nodes.
1. [Follow the after setup steps](after_setup.md).
1. [Follow the "Using a Geo Server" guide](using_a_geo_server.md).
[install-ee-source]: https://docs.gitlab.com/ee/install/installation.html "GitLab Enterprise Edition installation from source"
......
doc/gitlab-geo/configuration.md
View file @ b49fab30
......@@ -157,7 +157,7 @@ correctly identified as a secondary Geo node and if Geo is enabled.
If your installation isn't working properly, check the
[troubleshooting](#troubleshooting) section.
Point your users to the [after setup steps](after_setup.md).
Point your users to the ["Using a Geo Server" guide](using_a_geo_server.md).
## Selective replication
......
doc/gitlab-geo/configuration_source.md
View file @ b49fab30
......@@ -176,7 +176,7 @@ correctly identified as a secondary Geo node and if Geo is enabled.
If your installation isn't working properly, check the
[troubleshooting](configuration.md#troubleshooting) section.
Point your users to the [after setup steps](after_setup.md).
Point your users to the ["Using a Geo Server" guide](using_a_geo_server.md).
## Selective replication
......
doc/gitlab-geo/database.md
View file @ b49fab30
......@@ -479,13 +479,6 @@ Geo secondary nodes use a tracking database to keep track of replication
status and recover automatically from some replication issues. Follow the
instructions for [enabling tracking database on the secondary server][tracking].
### Next steps
Now that the database replication is done, the next step is to configure SSH
authorizations to use the database.
[➤ Configure SSH authorizations to use the database](ssh.md)
## MySQL replication
We don't support MySQL replication for GitLab Geo.
......
doc/gitlab-geo/database_source.md
View file @ b49fab30
......@@ -462,13 +462,6 @@ data before running `pg_basebackup`.
The replication process is now over.
### Next steps
Now that the database replication is done, the next step is to configure SSH
authorizations to use the database.
[➤ Configure SSH authorizations to use the database](ssh.md)
## MySQL replication
We don't support MySQL replication for GitLab Geo.
......
doc/gitlab-geo/ssh.md
View file @ b49fab30
......@@ -14,21 +14,9 @@ Note this feature is only available on operating systems that support OpenSSH
version of OpenSSH for your server]
(../administration/operations/speed_up_ssh.html#compiling-a-custom-version-of-openssh-for-centos-6).
For both primary AND secondary nodes, follow the instructions on [configuring
SSH authorization via database
lookups](../administration/operations/speed_up_ssh.html).
For both primary AND secondary nodes, follow the instructions on
[looking up authorized SSH keys in the database](../administration/operations/speed_up_ssh.html).
Note that the 'Write to "authorized keys" file' checkbox only needs
to be unchecked on the primary node since it will be reflected automatically
in the secondary if database replication is working.
### Next steps
Now that SSH authorizations are configured to use the database, the next step
is to configure GitLab.
[➤ GitLab Geo configuration](configuration.md)
If you are running GitLab installed from source:
[➤ GitLab Geo configuration (source)](configuration_source.md)
doc/gitlab-geo/after_setup.md → doc/gitlab-geo/using_a_geo_server.md
View file @ b49fab30
# After setup
# Using a Geo Server
After you set up the [database replication and configure the GitLab Geo nodes][req],
there are a few things to consider:
......@@ -6,13 +6,13 @@ there are a few things to consider:
1. Users need an extra step to be able to fetch code from the secondary and push
to primary:
1. Clone the repository as normal do from the secondary node:
1. Clone the repository as you would normally do, but from the secondary node:
```bash
git clone git@secondary.gitlab.example.com:user/repo.git
```
1. Change the remote push URL following this example:
1. Change the remote push URL to always push to primary, following this example:
```bash
git remote set-url --push origin git@primary.gitlab.example.com:user/repo.git
......
yarn.lock
View file @ b49fab30
This diff is collapsed.
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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7