summaryrefslogtreecommitdiff
path: root/doc/install
diff options
context:
space:
mode:
Diffstat (limited to 'doc/install')
-rw-r--r--doc/install/README.md2
-rw-r--r--doc/install/aws/index.md141
-rw-r--r--doc/install/azure/index.md31
-rw-r--r--doc/install/digitaloceandocker.md32
-rw-r--r--doc/install/google_cloud_platform/index.md46
-rw-r--r--doc/install/installation.md95
-rw-r--r--doc/install/openshift_and_gitlab/index.md117
-rw-r--r--doc/install/pivotal/index.md2
-rw-r--r--doc/install/relative_url.md82
-rw-r--r--doc/install/requirements.md2
10 files changed, 277 insertions, 273 deletions
diff --git a/doc/install/README.md b/doc/install/README.md
index 9cc21412898..af98791c8e9 100644
--- a/doc/install/README.md
+++ b/doc/install/README.md
@@ -4,7 +4,7 @@ description: Read through the GitLab installation methods.
type: index
---
-# Installation **[CORE ONLY]**
+# Installation **(CORE ONLY)**
GitLab can be installed in most GNU/Linux distributions and in a number
of cloud providers. To get the best experience from GitLab you need to balance
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index 73eaf758923..fed3b1ca595 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -59,10 +59,11 @@ Here's a list of the AWS services we will use, with links to pricing information
- **ElastiCache**: An in-memory cache environment will be used to provide a
High Availability Redis configuration. See the
[Amazon ElastiCache pricing](https://aws.amazon.com/elasticache/pricing/).
-
+
NOTE: **Note:** Please note that while we will be using EBS for storage, we do not recommend using EFS as it may negatively impact GitLab's performance. You can review the [relevant documentation](../../administration/high_availability/nfs.md#avoid-using-awss-elastic-file-system-efs) for more details.
## Creating an IAM EC2 instance role and profile
+
To minimize the permissions of the user, we'll create a new [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)
role with limited access:
@@ -90,7 +91,7 @@ We'll now create a VPC, a virtual networking environment that you'll control:
`10.0.0.0/16`. If you don't require dedicated hardware, you can leave
"Tenancy" as default. Click **Yes, Create** when ready.
- ![Create VPC](img/create_vpc.png)
+ ![Create VPC](img/create_vpc.png)
### Subnets
@@ -107,16 +108,16 @@ RDS instances as well:
for example `gitlab-public-10.0.0.0`, select the VPC we created previously,
and at the IPv4 CIDR block let's give it a 24 subnet `10.0.0.0/24`:
- ![Create subnet](img/create_subnet.png)
+ ![Create subnet](img/create_subnet.png)
1. Follow the same steps to create all subnets:
- | Name tag | Type |Availability Zone | CIDR block |
- | -------- | ---- | ---------------- | ---------- |
- | gitlab-public-10.0.0.0 | public | us-west-2a | 10.0.0.0 |
- | gitlab-private-10.0.1.0 | private | us-west-2a | 10.0.1.0 |
- | gitlab-public-10.0.2.0 | public | us-west-2b | 10.0.2.0 |
- | gitlab-private-10.0.3.0 | private | us-west-2b | 10.0.3.0 |
+ | Name tag | Type |Availability Zone | CIDR block |
+ | -------- | ---- | ---------------- | ---------- |
+ | gitlab-public-10.0.0.0 | public | us-west-2a | 10.0.0.0 |
+ | gitlab-private-10.0.1.0 | private | us-west-2a | 10.0.1.0 |
+ | gitlab-public-10.0.2.0 | public | us-west-2b | 10.0.2.0 |
+ | gitlab-private-10.0.3.0 | private | us-west-2b | 10.0.3.0 |
### Route Table
@@ -139,7 +140,7 @@ create a new one:
1. Select it from the table, and then under the **Actions** dropdown choose
"Attach to VPC".
- ![Create gateway](img/create_gateway.png)
+ ![Create gateway](img/create_gateway.png)
1. Choose `gitlab-vpc` from the list and hit **Attach**.
@@ -154,14 +155,14 @@ it receive traffic from any destination.
as destination. In the target, select the `gitlab-gateway` we created previously.
Hit **Save** once done.
- ![Associate subnet with gateway](img/associate_subnet_gateway.png)
+ ![Associate subnet with gateway](img/associate_subnet_gateway.png)
Next, we must associate the **public** subnets to the route table:
1. Select the **Subnet Associations** tab and hit **Edit**.
1. Check only the public subnet and hit **Save**.
- ![Associate subnet with gateway](img/associate_subnet_gateway_2.png)
+ ![Associate subnet with gateway](img/associate_subnet_gateway_2.png)
---
@@ -178,12 +179,12 @@ The security group is basically the firewall:
Inbound Rules tab. You will need to open the SSH, HTTP, and HTTPS ports. Set
the source to `0.0.0.0/0`.
- ![Create security group](img/create_security_group.png)
+ ![Create security group](img/create_security_group.png)
- TIP: **Tip:**
- Based on best practices, you should allow SSH traffic from only a known
- host or CIDR block. In that case, change the SSH source to be custom and give
- it the IP you want to SSH from.
+ TIP: **Tip:**
+ Based on best practices, you should allow SSH traffic from only a known
+ host or CIDR block. In that case, change the SSH source to be custom and give
+ it the IP you want to SSH from.
1. When done, click **Save**.
@@ -204,7 +205,7 @@ create the actual RDS instance.
we defined them in the [subnets section](#subnets)).
Click **Create** when ready.
- ![RDS Subnet Group](img/rds_subnet_group.png)
+ ![RDS Subnet Group](img/rds_subnet_group.png)
### Creating the database
@@ -214,27 +215,27 @@ Now, it's time to create the database:
1. Select PostgreSQL and click **Next**.
1. Since this is a production server, let's choose "Production". Click **Next**.
1. Let's see the instance specifications:
- 1. Leave the license model as is (`postgresql-license`).
- 1. For the version, select the latest of the 9.6 series (check the
- [database requirements](../../install/requirements.md#postgresql-requirements))
- if there are any updates on this).
- 1. For the size, let's select a `t2.medium` instance.
- 1. Multi-AZ-deployment is recommended as redundancy, so choose "Create
- replica in different zone". Read more at
- [High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html).
- 1. A Provisioned IOPS (SSD) storage type is best suited for HA (though you can
- choose a General Purpose (SSD) to reduce the costs). Read more about it at
- [Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
-
-1. The rest of the settings on this page request a DB isntance identifier, username
+ 1. Leave the license model as is (`postgresql-license`).
+ 1. For the version, select the latest of the 9.6 series (check the
+ [database requirements](../../install/requirements.md#postgresql-requirements))
+ if there are any updates on this).
+ 1. For the size, let's select a `t2.medium` instance.
+ 1. Multi-AZ-deployment is recommended as redundancy, so choose "Create
+ replica in different zone". Read more at
+ [High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html).
+ 1. A Provisioned IOPS (SSD) storage type is best suited for HA (though you can
+ choose a General Purpose (SSD) to reduce the costs). Read more about it at
+ [Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
+
+1. The rest of the settings on this page request a DB instance identifier, username
and a master password. We've chosen to use `gitlab-db-ha`, `gitlab` and a
very secure password respectively. Keep these in hand for later.
1. Click **Next** to proceed to the advanced settings.
1. Make sure to choose our gitlab VPC, our subnet group, set public accessibility to
**No**, and to leave it to create a new security group. The only additional
- change which will be helpful is the database name for which we can use
- `gitlabhq_production`. At the very bottom, there's an option to enable
- auto updates to minor versions. You may want to turn it off.
+ change which will be helpful is the database name for which we can use
+ `gitlabhq_production`. At the very bottom, there's an option to enable
+ auto updates to minor versions. You may want to turn it off.
1. When done, click **Create database**.
### Installing the `pg_trgm` extension for PostgreSQL
@@ -276,7 +277,7 @@ To set up Redis:
Make sure to select our VPC and its [private subnets](#subnets). Click
**Create** when ready.
- ![ElastiCache subnet](img/ec_subnet.png)
+ ![ElastiCache subnet](img/ec_subnet.png)
1. Select **Redis** on the left menu and click **Create** to create a new
Redis cluster. Depending on your load, you can choose whether to enable
@@ -284,16 +285,16 @@ To set up Redis:
chance to deploy Redis in multi availability zones. In this guide, we chose
not to enable it.
1. In the settings section:
- 1. Give the cluster a name (`gitlab-redis`) and a description.
- 1. For the version, select the latest of `3.2` series (e.g., `3.2.10`).
- 1. Select the node type and the number of replicas.
+ 1. Give the cluster a name (`gitlab-redis`) and a description.
+ 1. For the version, select the latest of `3.2` series (e.g., `3.2.10`).
+ 1. Select the node type and the number of replicas.
1. In the advanced settings section:
1. Select the multi-AZ auto-failover option.
1. Select the subnet group we created previously.
1. Manually select the preferred availability zones, and under "Replica 2"
choose a different zone than the other two.
- ![Redis availability zones](img/ec_az.png)
+ ![Redis availability zones](img/ec_az.png)
1. In the security settings, edit the security groups and choose the
`gitlab-security-group` we had previously created.
@@ -316,11 +317,11 @@ and add a custom TCP rule for port `6379` accessible within itself.
On the EC2 dashboard, look for Load Balancer on the left column:
1. Click the **Create Load Balancer** button.
- 1. Choose the Application Load Balancer.
- 1. Give it a name (`gitlab-loadbalancer`) and set the scheme to "internet-facing".
- 1. In the "Listeners" section, make sure it has HTTP and HTTPS.
- 1. In the "Availability Zones" section, select the `gitlab-vpc` we have created
- and associate the **public subnets**.
+ 1. Choose the Application Load Balancer.
+ 1. Give it a name (`gitlab-loadbalancer`) and set the scheme to "internet-facing".
+ 1. In the "Listeners" section, make sure it has HTTP and HTTPS.
+ 1. In the "Availability Zones" section, select the `gitlab-vpc` we have created
+ and associate the **public subnets**.
1. Click **Configure Security Settings** to go to the next section to
select the TLS certificate. When done, go to the next step.
1. In the "Security Groups" section, create a new one by giving it a name
@@ -355,7 +356,7 @@ Choose the AMI:
where `<version>` the latest version as seen on the
[releases page](https://about.gitlab.com/releases/).
- ![Choose AMI](img/choose_ami.png)
+ ![Choose AMI](img/choose_ami.png)
### Choose an instance type
@@ -504,19 +505,19 @@ The EBS volume will host the Git repositories data:
1. Tell GitLab to store its data in the new directory by editing
`/etc/gitlab/gitlab.rb` with your editor:
- ```ruby
- git_data_dirs({
- "default" => { "path" => "/mnt/gitlab-data" }
- })
- ```
+ ```ruby
+ git_data_dirs({
+ "default" => { "path" => "/mnt/gitlab-data" }
+ })
+ ```
- where `/mnt/gitlab-data` the location where you will store the Git data.
+ where `/mnt/gitlab-data` the location where you will store the Git data.
1. Save the file and reconfigure GitLab:
- ```sh
- sudo gitlab-ctl reconfigure
- ```
+ ```sh
+ sudo gitlab-ctl reconfigure
+ ```
TIP: **Tip:**
If you wish to add more than one data volumes to store the Git repositories,
@@ -549,15 +550,15 @@ After you SSH into the instance, configure the domain name:
1. Open `/etc/gitlab/gitlab.rb` with your preferred editor.
1. Edit the `external_url` value:
- ```ruby
- external_url 'http://example.com'
- ```
+ ```ruby
+ external_url 'http://example.com'
+ ```
1. Reconfigure GitLab:
- ```sh
- sudo gitlab-ctl reconfigure
- ```
+ ```sh
+ sudo gitlab-ctl reconfigure
+ ```
You should now be able to reach GitLab at the URL you defined. To use HTTPS
(recommended), see the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
@@ -608,9 +609,9 @@ To back up GitLab:
1. SSH into your instance.
1. Take a backup:
- ```sh
- sudo gitlab-rake gitlab:backup:create
- ```
+ ```sh
+ sudo gitlab-rake gitlab:backup:create
+ ```
### Restoring GitLab from a backup
@@ -626,16 +627,16 @@ released, you can update your GitLab instance:
1. SSH into your instance
1. Take a backup:
- ```sh
- sudo gitlab-rake gitlab:backup:create
- ```
+ ```sh
+ sudo gitlab-rake gitlab:backup:create
+ ```
1. Update the repositories and install GitLab:
- ```sh
- sudo apt update
- sudo apt install gitlab-ee
- ```
+ ```sh
+ sudo apt update
+ sudo apt install gitlab-ee
+ ```
After a few minutes, the new version should be up and running.
diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md
index b1f79893baf..c0e1b0ebbc8 100644
--- a/doc/install/azure/index.md
+++ b/doc/install/azure/index.md
@@ -67,18 +67,19 @@ The first items we need to configure are the basic settings of the underlying vi
1. Enter a `User name` - e.g. **"gitlab-admin"**
1. Select an `Authentication type`, either **SSH public key** or **Password**:
- > **Note:** if you're unsure which authentication type to use, select **Password**
+ > **Note:** if you're unsure which authentication type to use, select **Password**
+
+ 1. If you chose **SSH public key** - enter your `SSH public key` into the field provided
+ _(read the [SSH documentation][GitLab-Docs-SSH] to learn more about how to set up SSH
+ public keys)_
+ 1. If you chose **Password** - enter the password you wish to use _(this is the password that you
+ will use later in this tutorial to [SSH] into the VM, so make sure it's a strong password/passphrase)_
- 1. If you chose **SSH public key** - enter your `SSH public key` into the field provided
- _(read the [SSH documentation][GitLab-Docs-SSH] to learn more about how to set up SSH
- public keys)_
- 1. If you chose **Password** - enter the password you wish to use _(this is the password that you
- will use later in this tutorial to [SSH] into the VM, so make sure it's a strong password/passphrase)_
1. Choose the appropriate `Subscription` tier for your Azure account
1. Choose an existing `Resource Group` or create a new one - e.g. **"GitLab-CE-Azure"**
- > **Note:** a "Resource group" is a way to group related resources together for easier administration.
- > We chose "GitLab-CE-Azure", but your resource group can have the same name as your VM.
+ > **Note:** a "Resource group" is a way to group related resources together for easier administration.
+ > We chose "GitLab-CE-Azure", but your resource group can have the same name as your VM.
1. Choose a `Location` - if you're unsure, select the default location
@@ -248,6 +249,7 @@ rules in the list:
![Azure - Inbound security rules - List](img/azure-inbound-sec-rules-list.png)
## Connecting to GitLab
+
Use the domain name you set up earlier (or the public IP address) to visit your new GitLab instance
in your browser. If everything has gone according to plan you should be presented with the
following page, asking you to set a _new_ password for the administrator account automatically
@@ -348,6 +350,7 @@ your VM, you can use the IP address in its place in the following command:
```bash
ssh username@your-azure-domain-name.com
```
+
Provide your password at the prompt to authenticate.
#### SSH from Windows (PuTTY)
@@ -411,12 +414,12 @@ Check out our other [Technical Articles][GitLab-Technical-Articles] or browse th
- [GitLab Community Edition][CE]
- [GitLab Enterprise Edition][EE]
- [Microsoft Azure][Azure]
- - [Azure - Free Account FAQ][Azure-Free-Account-FAQ]
- - [Azure - Marketplace][Azure-Marketplace]
- - [Azure Portal][Azure-Portal]
- - [Azure - Pricing Calculator][Azure-Pricing-Calculator]
- - [Azure - Troubleshoot SSH Connections to an Azure Linux VM][Azure-Troubleshoot-SSH-Connection]
- - [Azure - Properly Shutdown an Azure VM][Azure-Properly-Shutdown-VM]
+ - [Azure - Free Account FAQ][Azure-Free-Account-FAQ]
+ - [Azure - Marketplace][Azure-Marketplace]
+ - [Azure Portal][Azure-Portal]
+ - [Azure - Pricing Calculator][Azure-Pricing-Calculator]
+ - [Azure - Troubleshoot SSH Connections to an Azure Linux VM][Azure-Troubleshoot-SSH-Connection]
+ - [Azure - Properly Shutdown an Azure VM][Azure-Properly-Shutdown-VM]
- [SSH], [PuTTY] and [Using SSH in PuTTY][Using-SSH-In-Putty]
[Original-Blog-Post]: https://about.gitlab.com/2016/07/13/how-to-setup-a-gitlab-instance-on-microsoft-azure/ "How to Set up a GitLab Instance on Microsoft Azure"
diff --git a/doc/install/digitaloceandocker.md b/doc/install/digitaloceandocker.md
index 63bb941ad47..b6bf7c95527 100644
--- a/doc/install/digitaloceandocker.md
+++ b/doc/install/digitaloceandocker.md
@@ -36,30 +36,30 @@ The rest of the steps are identical for macOS and Linux.
1. Login to Digital Ocean.
1. Generate a new API token at <https://cloud.digitalocean.com/settings/api/tokens>.
- This command will create a new DO droplet called `gitlab-test-env-do` that will act as a docker host.
+ This command will create a new DO droplet called `gitlab-test-env-do` that will act as a docker host.
- NOTE: **Note:**
- 4GB is the minimum requirement for a Docker host that will run more than one GitLab instance.
+ NOTE: **Note:**
+ 4GB is the minimum requirement for a Docker host that will run more than one GitLab instance.
- - RAM: 4GB
- - Name: `gitlab-test-env-do`
- - Driver: `digitalocean`
+ - RAM: 4GB
+ - Name: `gitlab-test-env-do`
+ - Driver: `digitalocean`
1. Set the DO token:
- ```sh
- export DOTOKEN=<your generated token>
- ```
+ ```sh
+ export DOTOKEN=<your generated token>
+ ```
1. Create the machine:
- ```sh
- docker-machine create \
- --driver digitalocean \
- --digitalocean-access-token=$DOTOKEN \
- --digitalocean-size "4gb" \
- gitlab-test-env-do
- ```
+ ```sh
+ docker-machine create \
+ --driver digitalocean \
+ --digitalocean-access-token=$DOTOKEN \
+ --digitalocean-size "4gb" \
+ gitlab-test-env-do
+ ```
Resource: <https://docs.docker.com/machine/drivers/digital-ocean/>.
diff --git a/doc/install/google_cloud_platform/index.md b/doc/install/google_cloud_platform/index.md
index 77c61acbfd4..be29bcc7cd7 100644
--- a/doc/install/google_cloud_platform/index.md
+++ b/doc/install/google_cloud_platform/index.md
@@ -30,16 +30,16 @@ To deploy GitLab on GCP you first need to create a virtual machine:
1. Go to <https://console.cloud.google.com/compute/instances> and log in with your Google credentials.
1. Click on **Create**
- ![Search for GitLab](img/launch_vm.png)
+ ![Search for GitLab](img/launch_vm.png)
-1. On the next page, you can select the type of VM as well as the
+1. On the next page, you can select the type of VM as well as the
estimated costs. Provide the name of the instance, desired datacenter, and machine type. Note that GitLab recommends at least 2 vCPU's and 4GB of RAM.
- ![Launch on Compute Engine](img/vm_details.png)
+ ![Launch on Compute Engine](img/vm_details.png)
1. Click **Change** under Boot disk to select the size, type, and desired operating system. GitLab supports a [variety of linux operating systems][req], including Ubuntu and Debian. Click **Select** when finished.
- ![Deploy in progress](img/boot_disk.png)
+ ![Deploy in progress](img/boot_disk.png)
1. As a last step allow HTTP and HTTPS traffic, then click **Create**. The process will finish in a few seconds.
@@ -53,13 +53,13 @@ After a few seconds, the instance will be created and available to log in. The n
1. Click on the SSH button to connect to the instance.
1. A new window will appear, with you logged into the instance.
- ![GitLab first sign in](img/ssh_terminal.png)
+ ![GitLab first sign in](img/ssh_terminal.png)
-1. Next, follow the instructions for installing GitLab for the operating system you choose, at <https://about.gitlab.com/installation/>. You can use the IP address from the step above, as the hostname.
+1. Next, follow the instructions for installing GitLab for the operating system you choose, at <https://about.gitlab.com/install/>. You can use the IP address from the step above, as the hostname.
1. Congratulations! GitLab is now installed and you can access it via your browser. To finish installation, open the URL in your browser and provide the initial administrator password. The username for this account is `root`.
- ![GitLab first sign in](img/first_signin.png)
+ ![GitLab first sign in](img/first_signin.png)
## Next steps
@@ -83,31 +83,31 @@ here's how you configure GitLab to be aware of the change:
1. SSH into the VM. You can easily use the **SSH** button in the Google console
and a new window will pop up.
- ![SSH button](img/vm_created.png)
+ ![SSH button](img/vm_created.png)
- In the future you might want to set up [connecting with an SSH key][ssh]
- instead.
+ In the future you might want to set up [connecting with an SSH key][ssh]
+ instead.
1. Edit the config file of Omnibus GitLab using your favorite text editor:
- ```
- sudo vim /etc/gitlab/gitlab.rb
- ```
+ ```
+ sudo vim /etc/gitlab/gitlab.rb
+ ```
1. Set the `external_url` value to the domain name you wish GitLab to have
**without** `https`:
- ```
- external_url 'http://gitlab.example.com'
- ```
+ ```
+ external_url 'http://gitlab.example.com'
+ ```
- We will set up HTTPS in the next step, no need to do this now.
+ We will set up HTTPS in the next step, no need to do this now.
1. Reconfigure GitLab for the changes to take effect:
- ```
- sudo gitlab-ctl reconfigure
- ```
+ ```
+ sudo gitlab-ctl reconfigure
+ ```
1. You can now visit GitLab using the domain name.
@@ -128,9 +128,9 @@ GitLab can be configured to authenticate with other OAuth providers, LDAP, SAML,
Kerberos, etc. Here are some documents you might be interested in reading:
- [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/)
-- [Integration documentation](https://docs.gitlab.com/ce/integration/)
-- [GitLab Pages configuration](https://docs.gitlab.com/ce/administration/pages/index.html)
-- [GitLab Container Registry configuration](https://docs.gitlab.com/ce/administration/container_registry.html)
+- [Integration documentation](../../integration/README.md)
+- [GitLab Pages configuration](../../administration/pages/index.md)
+- [GitLab Container Registry configuration](../../administration/container_registry.md)
[freetrial]: https://console.cloud.google.com/freetrial "GCP free trial"
[ip]: https://cloud.google.com/compute/docs/configure-instance-ip-addresses#promote_ephemeral_ip "Configuring an Instance's IP Addresses"
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 70e5ab28931..06ec00cecc4 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -167,7 +167,7 @@ cd pcre2-10.33
chmod +x configure
./configure --prefix=/usr --enable-jit
make
-make install
+sudo make install
# Download and compile from source
cd /tmp
@@ -299,57 +299,57 @@ use of extensions and concurrent index removal, you need at least PostgreSQL 9.2
1. Install the database packages:
- ```sh
- sudo apt-get install -y postgresql postgresql-client libpq-dev postgresql-contrib
- ```
+ ```sh
+ sudo apt-get install -y postgresql postgresql-client libpq-dev postgresql-contrib
+ ```
1. Create a database user for GitLab:
- ```sh
- sudo -u postgres psql -d template1 -c "CREATE USER git CREATEDB;"
- ```
+ ```sh
+ sudo -u postgres psql -d template1 -c "CREATE USER git CREATEDB;"
+ ```
1. Create the `pg_trgm` extension (required for GitLab 8.6+):
- ```sh
- sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"
- ```
+ ```sh
+ sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"
+ ```
1. Create the GitLab production database and grant all privileges on database:
- ```sh
- sudo -u postgres psql -d template1 -c "CREATE DATABASE gitlabhq_production OWNER git;"
- ```
+ ```sh
+ sudo -u postgres psql -d template1 -c "CREATE DATABASE gitlabhq_production OWNER git;"
+ ```
1. Try connecting to the new database with the new user:
- ```sh
- sudo -u git -H psql -d gitlabhq_production
- ```
+ ```sh
+ sudo -u git -H psql -d gitlabhq_production
+ ```
1. Check if the `pg_trgm` extension is enabled:
- ```sh
- SELECT true AS enabled
- FROM pg_available_extensions
- WHERE name = 'pg_trgm'
- AND installed_version IS NOT NULL;
- ```
+ ```sh
+ SELECT true AS enabled
+ FROM pg_available_extensions
+ WHERE name = 'pg_trgm'
+ AND installed_version IS NOT NULL;
+ ```
- If the extension is enabled this will produce the following output:
+ If the extension is enabled this will produce the following output:
- ```
- enabled
- ---------
- t
- (1 row)
- ```
+ ```
+ enabled
+ ---------
+ t
+ (1 row)
+ ```
1. Quit the database session:
- ```sh
- gitlabhq_production> \q
- ```
+ ```sh
+ gitlabhq_production> \q
+ ```
## 7. Redis
@@ -634,8 +634,8 @@ Gitaly must be running for the next section.
gitlab_path=/home/git/gitlab
gitaly_path=/home/git/gitaly
-sudo -u git -H $gitlab_path/bin/daemon_with_pidfile $gitlab_path/tmp/pids/gitaly.pid \
- $gitaly_path/gitaly $gitaly_path/config.toml >> $gitlab_path/log/gitaly.log 2>&1 &
+sudo -u git -H sh -c "$gitlab_path/bin/daemon_with_pidfile $gitlab_path/tmp/pids/gitaly.pid \
+ $gitaly_path/gitaly $gitaly_path/config.toml >> $gitlab_path/log/gitaly.log 2>&1 &"
```
### Initialize Database and Activate Advanced Features
@@ -831,26 +831,27 @@ how to configure GitLab with a relative URL.
To use GitLab with HTTPS:
1. In `gitlab.yml`:
- 1. Set the `port` option in section 1 to `443`.
- 1. Set the `https` option in section 1 to `true`.
+ 1. Set the `port` option in section 1 to `443`.
+ 1. Set the `https` option in section 1 to `true`.
1. In the `config.yml` of gitlab-shell:
- 1. Set `gitlab_url` option to the HTTPS endpoint of GitLab (e.g. `https://git.example.com`).
- 1. Set the certificates using either the `ca_file` or `ca_path` option.
+ 1. Set `gitlab_url` option to the HTTPS endpoint of GitLab (e.g. `https://git.example.com`).
+ 1. Set the certificates using either the `ca_file` or `ca_path` option.
1. Use the `gitlab-ssl` Nginx example config instead of the `gitlab` config.
- 1. Update `YOUR_SERVER_FQDN`.
- 1. Update `ssl_certificate` and `ssl_certificate_key`.
- 1. Review the configuration file and consider applying other security and performance enhancing features.
+ 1. Update `YOUR_SERVER_FQDN`.
+ 1. Update `ssl_certificate` and `ssl_certificate_key`.
+ 1. Review the configuration file and consider applying other security and performance enhancing features.
Using a self-signed certificate is discouraged but if you must use it, follow the normal directions. Then:
1. Generate a self-signed SSL certificate:
- ```sh
- mkdir -p /etc/nginx/ssl/
- cd /etc/nginx/ssl/
- sudo openssl req -newkey rsa:2048 -x509 -nodes -days 3560 -out gitlab.crt -keyout gitlab.key
- sudo chmod o-r gitlab.key
- ```
+ ```sh
+ mkdir -p /etc/nginx/ssl/
+ cd /etc/nginx/ssl/
+ sudo openssl req -newkey rsa:2048 -x509 -nodes -days 3560 -out gitlab.crt -keyout gitlab.key
+ sudo chmod o-r gitlab.key
+ ```
+
1. In the `config.yml` of gitlab-shell set `self_signed_cert` to `true`.
### Enable Reply by email
diff --git a/doc/install/openshift_and_gitlab/index.md b/doc/install/openshift_and_gitlab/index.md
index 45d07ec5d11..fbbe2a34952 100644
--- a/doc/install/openshift_and_gitlab/index.md
+++ b/doc/install/openshift_and_gitlab/index.md
@@ -13,8 +13,8 @@ for details.
## Introduction
-[OpenShift Origin][openshift] is an open source container application
-platform created by [RedHat], based on [kubernetes] and [Docker]. That means
+[OpenShift Origin](https://www.okd.io/) (**Note:** renamed to OKD in Aug 2018) is an open source container application
+platform created by [RedHat], based on [kubernetes](https://kubernetes.io/) and [Docker]. That means
you can host your own PaaS for free and almost with no hassle.
In this tutorial, we will see how to deploy GitLab in OpenShift using GitLab's
@@ -27,8 +27,11 @@ For a video demonstration on installing GitLab on OpenShift, check the article [
## Prerequisites
-OpenShift 3 is not yet deployed on RedHat's offered Online platform ([openshift.com]),
-so in order to test it, we will use an [all-in-one Virtualbox image][vm] that is
+CAUTION: **Caution:** This information is no longer up to date, as the current versions
+have changed and products have been renamed.
+
+OpenShift 3 is not yet deployed on RedHat's offered Online platform, [openshift.com](https://www.openshift.com/),
+so in order to test it, we will use an [all-in-one Virtualbox image](https://www.okd.io/minishift/) that is
offered by the OpenShift developers and managed by Vagrant. If you haven't done
already, go ahead and install the following components as they are essential to
test OpenShift easily:
@@ -67,17 +70,17 @@ In short:
1. Open a terminal and in a new directory run:
- ```sh
- vagrant init openshift/origin-all-in-one
- ```
+ ```sh
+ vagrant init openshift/origin-all-in-one
+ ```
1. This will generate a Vagrantfile based on the all-in-one VM image
1. In the same directory where you generated the Vagrantfile
enter:
- ```sh
- vagrant up
- ```
+ ```sh
+ vagrant up
+ ```
This will download the VirtualBox image and fire up the VM with some preconfigured
values as you can see in the Vagrantfile. As you may have noticed, you need
@@ -192,22 +195,22 @@ In that case, the OpenShift service might not be running, so in order to fix it:
1. SSH into the VM by going to the directory where the Vagrantfile is and then
run:
- ```sh
- vagrant ssh
- ```
+ ```sh
+ vagrant ssh
+ ```
1. Run `systemctl` and verify by the output that the `openshift` service is not
running (it will be in red color). If that's the case start the service with:
- ```sh
- sudo systemctl start openshift
- ```
+ ```sh
+ sudo systemctl start openshift
+ ```
1. Verify the service is up with:
- ```sh
- systemctl status openshift -l
- ```
+ ```sh
+ systemctl status openshift -l
+ ```
Now you will be able to login using `oc` (like we did before) and visit the web
console.
@@ -390,55 +393,55 @@ Let's see how to do that using the following steps.
1. Make sure you are in the `gitlab` project:
- ```sh
- oc project gitlab
- ```
+ ```sh
+ oc project gitlab
+ ```
1. See what services are used for this project:
- ```sh
- oc get svc
- ```
+ ```sh
+ oc get svc
+ ```
- The output will be similar to:
+ The output will be similar to:
- ```
- NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
- gitlab-ce 172.30.243.177 <none> 22/TCP,80/TCP 5d
- gitlab-ce-postgresql 172.30.116.75 <none> 5432/TCP 5d
- gitlab-ce-redis 172.30.105.88 <none> 6379/TCP 5d
- ```
+ ```
+ NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+ gitlab-ce 172.30.243.177 <none> 22/TCP,80/TCP 5d
+ gitlab-ce-postgresql 172.30.116.75 <none> 5432/TCP 5d
+ gitlab-ce-redis 172.30.105.88 <none> 6379/TCP 5d
+ ```
1. We need to see the replication controllers of the `gitlab-ce` service.
Get a detailed view of the current ones:
- ```sh
- oc describe rc gitlab-ce
- ```
+ ```sh
+ oc describe rc gitlab-ce
+ ```
- This will return a large detailed list of the current replication controllers.
- Search for the name of the GitLab controller, usually `gitlab-ce-1` or if
- that failed at some point and you spawned another one, it will be named
- `gitlab-ce-2`.
+ This will return a large detailed list of the current replication controllers.
+ Search for the name of the GitLab controller, usually `gitlab-ce-1` or if
+ that failed at some point and you spawned another one, it will be named
+ `gitlab-ce-2`.
1. Scale GitLab using the previous information:
- ```sh
- oc scale --replicas=2 replicationcontrollers gitlab-ce-2
- ```
+ ```sh
+ oc scale --replicas=2 replicationcontrollers gitlab-ce-2
+ ```
1. Get the new replicas number to make sure scaling worked:
- ```sh
- oc get rc gitlab-ce-2
- ```
+ ```sh
+ oc get rc gitlab-ce-2
+ ```
- which will return something like:
+ which will return something like:
- ```
- NAME DESIRED CURRENT AGE
- gitlab-ce-2 2 2 5d
- ```
+ ```
+ NAME DESIRED CURRENT AGE
+ gitlab-ce-2 2 2 5d
+ ```
And that's it! We successfully scaled the replicas to 2 using the CLI.
@@ -458,7 +461,7 @@ OpenShift's website about [autoscaling].
## Current limitations
-As stated in the [all-in-one VM][vm] page:
+As stated in the [all-in-one VM](https://www.okd.io/minishift/) page:
> By default, OpenShift will not allow a container to run as root or even a
non-random container assigned userid. Most Docker images in the Dockerhub do not
@@ -475,13 +478,13 @@ For OpenShift v3.0, you will need to do this manually:
1. Edit the Security Context:
- ```sh
- oc edit scc anyuid
- ```
+ ```sh
+ oc edit scc anyuid
+ ```
1. Add `system:serviceaccount:<project>:gitlab-ce-user` to the `users` section.
If you changed the Application Name from the default the user will
- will be `<app-name>-user` instead of `gitlab-ce-user`
+ will be `<app-name>-user` instead of `gitlab-ce-user`
1. Save and exit the editor
@@ -506,12 +509,8 @@ is capable of. As always, you can refer to the detailed
PaaS and managing your applications with the ease of containers.
[RedHat]: https://www.redhat.com/en "RedHat website"
-[openshift]: https://www.openshift.org "OpenShift Origin website"
-[vm]: https://www.openshift.org/vm/ "OpenShift All-in-one VM"
[vm-new]: https://app.vagrantup.com/openshift/boxes/origin-all-in-one "Official OpenShift Vagrant box on Vagrant Cloud"
[template]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/docker/openshift-template.json "OpenShift template for GitLab"
-[openshift.com]: https://openshift.com "OpenShift Online"
-[kubernetes]: http://kubernetes.io/ "Kubernetes website"
[Docker]: https://www.docker.com "Docker website"
[oc]: https://docs.openshift.org/latest/cli_reference/get_started_cli.html "Documentation - oc CLI documentation"
[VirtualBox]: https://www.virtualbox.org/wiki/Downloads "VirtualBox downloads"
diff --git a/doc/install/pivotal/index.md b/doc/install/pivotal/index.md
index f068572f1e9..6a4b361c842 100644
--- a/doc/install/pivotal/index.md
+++ b/doc/install/pivotal/index.md
@@ -1,4 +1,4 @@
-# GitLab Pivotal Tile **[PREMIUM ONLY]**
+# GitLab Pivotal Tile **(PREMIUM ONLY)**
CAUTION: **Discontinued:**
As of September 13, 2017, the GitLab Enterprise Plus for Pivotal Cloud Foundry
diff --git a/doc/install/relative_url.md b/doc/install/relative_url.md
index b53624a33bf..bc6364f57f7 100644
--- a/doc/install/relative_url.md
+++ b/doc/install/relative_url.md
@@ -58,59 +58,59 @@ assumptions are made:
Make sure to follow all steps below:
-1. (Optional) If you run short on resources, you can temporarily free up some
- memory by shutting down the GitLab service with the following command:
+1. (Optional) If you run short on resources, you can temporarily free up some
+ memory by shutting down the GitLab service with the following command:
- ```shell
- sudo service gitlab stop
- ```
+ ```shell
+ sudo service gitlab stop
+ ```
-1. Create `/home/git/gitlab/config/initializers/relative_url.rb`
+1. Create `/home/git/gitlab/config/initializers/relative_url.rb`
- ```shell
- cp /home/git/gitlab/config/initializers/relative_url.rb.sample \
- /home/git/gitlab/config/initializers/relative_url.rb
- ```
+ ```shell
+ cp /home/git/gitlab/config/initializers/relative_url.rb.sample \
+ /home/git/gitlab/config/initializers/relative_url.rb
+ ```
- and change the following line:
+ and change the following line:
- ```ruby
- config.relative_url_root = "/gitlab"
- ```
+ ```ruby
+ config.relative_url_root = "/gitlab"
+ ```
-1. Edit `/home/git/gitlab/config/gitlab.yml` and uncomment/change the
- following line:
+1. Edit `/home/git/gitlab/config/gitlab.yml` and uncomment/change the
+ following line:
- ```yaml
- relative_url_root: /gitlab
- ```
+ ```yaml
+ relative_url_root: /gitlab
+ ```
-1. Edit `/home/git/gitlab/config/unicorn.rb` and uncomment/change the
- following line:
+1. Edit `/home/git/gitlab/config/unicorn.rb` and uncomment/change the
+ following line:
- ```ruby
- ENV['RAILS_RELATIVE_URL_ROOT'] = "/gitlab"
- ```
+ ```ruby
+ ENV['RAILS_RELATIVE_URL_ROOT'] = "/gitlab"
+ ```
-1. Edit `/home/git/gitlab-shell/config.yml` and append the relative path to
- the following line:
+1. Edit `/home/git/gitlab-shell/config.yml` and append the relative path to
+ the following line:
- ```yaml
- gitlab_url: http://127.0.0.1/gitlab
- ```
+ ```yaml
+ gitlab_url: http://127.0.0.1/gitlab
+ ```
-1. Make sure you have copied the supplied init script and the defaults file
- as stated in the [installation guide](installation.md#install-init-script).
- Then, edit `/etc/default/gitlab` and set in `gitlab_workhorse_options` the
- `-authBackend` setting to read like:
+1. Make sure you have copied the supplied init script and the defaults file
+ as stated in the [installation guide](installation.md#install-init-script).
+ Then, edit `/etc/default/gitlab` and set in `gitlab_workhorse_options` the
+ `-authBackend` setting to read like:
- ```shell
- -authBackend http://127.0.0.1:8080/gitlab
- ```
+ ```shell
+ -authBackend http://127.0.0.1:8080/gitlab
+ ```
- **Note:**
- If you are using a custom init script, make sure to edit the above
- gitlab-workhorse setting as needed.
+ **Note:**
+ If you are using a custom init script, make sure to edit the above
+ gitlab-workhorse setting as needed.
1. [Restart GitLab][] for the changes to take effect.
@@ -118,9 +118,9 @@ Make sure to follow all steps below:
To disable the relative URL:
-1. Remove `/home/git/gitlab/config/initializers/relative_url.rb`
+1. Remove `/home/git/gitlab/config/initializers/relative_url.rb`
-1. Follow the same as above starting from 2. and set up the
+1. Follow the same as above starting from 2. and set up the
GitLab URL to one that doesn't contain a relative path.
[omnibus-rel]: https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-a-relative-url-for-gitlab "How to set up relative URL in Omnibus GitLab"
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 68c1bcbc801..25ab608de3a 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -30,7 +30,7 @@ For the installations options, see [the main installation page](README.md).
- macOS
Installation of GitLab on these operating systems is possible, but not supported.
-Please see the [installation from source guide](installation.md) and the [installation guides](https://about.gitlab.com/installation/) for more information.
+Please see the [installation from source guide](installation.md) and the [installation guides](https://about.gitlab.com/install/) for more information.
### Microsoft Windows