At this point, your GitLab instance should be up and running. Verify you are
At this point, your GitLab instance should be up and running. Verify you are
able to login, and create issues and merge requests. If you have troubles check the [Troubleshooting section](#troubleshooting).
able to login, and create issues and merge requests. If you have troubles check the [Troubleshooting section](#troubleshooting).
### Example configuration
Here we'll show you some fully expanded example configurations.
#### Example recommended setup
This example uses 3 consul servers, 3 postgresql servers, and 1 application node.
We start with all servers on the same 10.6.0.0/16 private network range, they
can connect to each freely other on those addresses.
Here is a list and description of each machine and the assigned IP:
*`10.6.0.11`: Consul 1
*`10.6.0.12`: Consul 2
*`10.6.0.13`: Consul 3
*`10.6.0.21`: PostgreSQL master
*`10.6.0.22`: PostgreSQL secondary
*`10.6.0.23`: PostgreSQL secondary
*`10.6.0.31`: GitLab application
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
The external_url for GitLab is `http://gitlab.example.com`
Please note that after the initial configuration, if a failover occurs, the PostgresSQL master will change to one of the available secondaries until it is failed back.
##### Example recommended setup for Consul servers
On each server edit `/etc/gitlab/gitlab.rb`:
```ruby
# Disable all components except Consul
bootstrap['enable']=false
gitlab_rails['auto_migrate']=false
gitaly['enable']=false
gitlab_workhorse['enable']=false
mailroom['enable']=false
nginx['enable']=false
postgresql['enable']=false
redis['enable']=false
sidekiq['enable']=false
prometheus['enable']=false
unicorn['enable']=false
consul['enable']=true
consul['configuration']={
server: true,
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
```
[Reconfigure Omnibus GitLab][reconfigure Gitlab] for the changes to take effect.
##### Example recommended setup for PostgreSQL servers
On each server edit `/etc/gitlab/gitlab.rb`:
```ruby
# Disable all components except PostgreSQL and Repmgr and Consul
This example uses 3 postgresql servers, and 1 application node.
It differs from the [recommended setup](#example_recommended_setup) by moving the consul servers into the same servers we use for PostgreSQL.
The trade-off is between reducing server counts, against the increased operational complexity of needing to deal with postgres [failover](#failover_procedure) and [restore](#restore_procedure) procedures in addition to [consul outage recovery](consul.md#outage_recovery) on the same set of machines.
In this example we start with all servers on the same 10.6.0.0/16 private network range, they can connect to each freely other on those addresses.
Here is a list and description of each machine and the assigned IP:
*`10.6.0.21`: PostgreSQL master
*`10.6.0.22`: PostgreSQL secondary
*`10.6.0.23`: PostgreSQL secondary
*`10.6.0.31`: GitLab application
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
The external_url for GitLab is `http://gitlab.example.com`
Please note that after the initial configuration, if a failover occurs, the PostgresSQL master will change to one of the available secondaries until it is failed back.
##### Example minimal configuration for database servers
On each server edit `/etc/gitlab/gitlab.rb`:
```ruby
# Disable all components except PostgreSQL, Repmgr, and Consul