summaryrefslogtreecommitdiff
path: root/doc/install
diff options
context:
space:
mode:
Diffstat (limited to 'doc/install')
-rw-r--r--doc/install/aws/index.md6
-rw-r--r--doc/install/azure/index.md50
-rw-r--r--doc/install/google_cloud_platform/index.md21
-rw-r--r--doc/install/index.md34
-rw-r--r--doc/install/installation.md32
-rw-r--r--doc/install/next_steps.md63
-rw-r--r--doc/install/openshift_and_gitlab/index.md20
-rw-r--r--doc/install/requirements.md17
8 files changed, 135 insertions, 108 deletions
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index 7fde3915bf5..9444c16f7ad 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -838,3 +838,9 @@ You may have to set a password on the `root` user to prevent automatic redirects
### "The change you requested was rejected (422)"
If you see this page when trying to set a password via the web interface, make sure `external_url` in `gitlab.rb` matches the domain you are making a request from, and run `sudo gitlab-ctl reconfigure` after making any changes to it.
+
+### Some job logs are not uploaded to object storage
+
+When the GitLab deployment is scaled up to more than one node, some job logs may not be uploaded to [object storage](../../administration/object_storage.md) properly. [Incremental logging is required](../../administration/object_storage.md#incremental-logging-is-required-for-ci-to-use-object-storage) for CI to use object storage.
+
+Enable [incremental logging](../../administration/job_logs.md#enable-or-disable-incremental-logging) if it has not already been enabled.
diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md
index 8fb400c796e..2fca70fd07a 100644
--- a/doc/install/azure/index.md
+++ b/doc/install/azure/index.md
@@ -31,20 +31,20 @@ Because GitLab is already installed in a pre-configured image, all you have to d
create a new VM:
1. [Visit the GitLab offering in the marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/gitlabinc1586447921813.gitlabee?tab=Overview)
-1. Select **Get it now** and you will be presented with the **Create this app in Azure** window.
+1. Select **Get it now** and the **Create this app in Azure** window opens.
Select **Continue**.
1. Select one of the following options from the Azure portal:
- Select **Create** to create a VM from scratch.
- Select **Start with a pre-set configuration** to get started with some
pre-configured options. You can modify these configurations at any time.
-For the sake of this guide, we'll create the VM from scratch, so
+For the sake of this guide, let's create the VM from scratch, so
select **Create**.
NOTE:
-Be aware that while your VM is active (known as "allocated"), it incurs
-compute charges for which you'll be billed. Even if you're using the
-free trial credits, you'll want to know
+Be aware that Azure incurs compute charges whenever your VM is
+active (known as "allocated"), even if you're using free trial
+credits.
[how to properly shutdown an Azure VM to save money](https://build5nines.com/properly-shutdown-azure-vm-to-save-money/).
See the [Azure pricing calculator](https://azure.microsoft.com/en-us/pricing/calculator/)
to learn how much resources can cost.
@@ -68,7 +68,7 @@ The first items you need to configure are the basic settings of the underlying v
is covered by the `D4s_v3` size, select that option.
1. Set the authentication type to **SSH public key**.
1. Enter a user name or leave the one that is automatically created. This is
- the user you'll use to connect to the VM through SSH. By default, the user
+ the user Azure uses to connect to the VM through SSH. By default, the user
has root access.
1. Determine if you want to provide your own SSH key or let Azure create one for you.
Read the [SSH documentation](../../ssh/README.md) to learn more about how to set up SSH
@@ -103,7 +103,7 @@ The GitLab image in the marketplace has the following ports open by default:
| 22 | Enable our VM to respond to SSH connection requests, allowing public access (with authentication) to remote terminal sessions. |
If you want to change the ports or add any rules, you can do it
-after the VM is created by going to the Networking settings in the left sidebar,
+after the VM is created by selecting Networking settings in the left sidebar,
while in the VM dashboard.
### Configure the Management tab
@@ -126,13 +126,13 @@ resources. You don't need to change the default settings.
The final tab presents you with all of your selected options,
where you can review and modify your choices from the
-previous steps. Azure will run validation tests in the background,
+previous steps. Azure runs validation tests in the background,
and if you provided all of the required settings, you can
create the VM.
After you select **Create**, if you had opted for Azure to create an SSH key pair
-for you, you'll be asked to download the private SSH key. Download the key, as you'll
-need it to SSH into the VM.
+for you, a prompt appears to download the private SSH key. Download the key, as it's
+needed to SSH into the VM.
After you download the key, the deployment begins.
@@ -153,11 +153,11 @@ to assign a descriptive DNS name to the VM:
1. From the VM dashboard, select **Configure** under **DNS name**.
1. Enter a descriptive DNS name for your instance in the **DNS name label** field,
- for example `gitlab-prod`. This will make the VM accessible at
+ for example `gitlab-prod`. This makes the VM accessible at
`gitlab-prod.eastus.cloudapp.azure.com`.
1. Select **Save** for the changes to take effect.
-Eventually, you'll want to use your own domain name. To do this, you need to add a DNS `A` record
+Eventually, most users want to use their own domain name. For you to do this, you need to add a DNS `A` record
with your domain registrar that points to the public IP address of your Azure VM.
You can use [Azure's DNS](https://docs.microsoft.com/en-us/azure/dns/dns-delegate-domain-azure-dns)
or some [other registrar](https://docs.gitlab.com/omnibus/settings/dns.html).
@@ -165,15 +165,15 @@ or some [other registrar](https://docs.gitlab.com/omnibus/settings/dns.html).
### Change the GitLab external URL
GitLab uses `external_url` in its configuration file to set up the domain name.
-If you don't set this up, when you visit the Azure friendly name, you'll
-instead be redirected to the public IP.
+If you don't set this up, when you visit the Azure friendly name, the browser will
+redirect you to the public IP.
To set up the GitLab external URL:
1. Connect to GitLab through SSH by going to **Settings > Connect** from the VM
dashboard, and follow the instructions. Remember to sign in with the username
and SSH key you specified when you [created the VM](#configure-the-basics-tab).
- The Azure VM domain name will be the one you
+ The Azure VM domain name is the one you
[set up previously](#set-up-a-domain-name). If you didn't set up a domain name for
your VM, you can use the IP address in its place.
@@ -189,10 +189,10 @@ To set up the GitLab external URL:
1. Open `/etc/gitlab/gitlab.rb` with your editor.
1. Find `external_url` and replace it with your own domain name. For the sake
- of this example, we'll use the friendly domain name that Azure set up.
- If you use `https` in the URL, Let's Encrypt will be
- [automatically enabled](https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration),
- and you'll have HTTPS by default:
+ of this example, use the default domain name Azure sets up.
+ Using `https` in the URL
+ [automatically enables](https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration),
+ Let's Encrypt, and sets HTTPS by default:
```ruby
external_url 'https://gitlab-prod.eastus.cloudapp.azure.com'
@@ -221,7 +221,7 @@ You can now visit GitLab with your browser at the new external URL.
Use the domain name you set up earlier to visit your new GitLab instance
in your browser. In this example, it's `https://gitlab-prod.eastus.cloudapp.azure.com`.
-The first thing you'll see is the sign-in page. GitLab creates an admin user by default.
+The first thing that appears is the sign-in page. GitLab creates an admin user by default.
The credentials are:
- Username: `root`
@@ -239,7 +239,7 @@ in this section whenever you need to update GitLab.
### Check the current version
To determine the version of GitLab you're currently running,
-go to the **{admin}** **Admin Area**, and you will find the version
+go to the **{admin}** **Admin Area**, and find the version
under the **Components** table.
If there's a newer available version of GitLab that contains one or more
@@ -259,7 +259,7 @@ To update GitLab to the latest version:
```
This command updates GitLab and its associated components to the latest versions,
- and can take time to complete. You'll see various update tasks being
+ and can take time to complete. During this time, the terminal shows various update tasks being
completed in your terminal.
NOTE:
@@ -267,8 +267,8 @@ To update GitLab to the latest version:
`E: The repository 'https://packages.gitlab.com/gitlab/gitlab-ee/debian buster InRelease' is not signed.`,
see the [troubleshooting section](#update-the-gpg-key-for-the-gitlab-repositories).
-1. After the update process is complete, you'll see a message like the
- following:
+1. After the update process is complete, a message like the
+ following appears:
```plaintext
Upgrade complete! If your GitLab server is misbehaving try running
@@ -300,7 +300,7 @@ GPG key.
The pre-configured GitLab image in Azure (provided by Bitnami) uses
a GPG key [deprecated in April 2020](https://about.gitlab.com/blog/2020/03/30/gpg-key-for-gitlab-package-repositories-metadata-changing/).
-If you try to update the repositories, you'll get the following error:
+If you try to update the repositories, the system returns the following error:
<!-- vale gitlab.ReferenceLinks = NO -->
diff --git a/doc/install/google_cloud_platform/index.md b/doc/install/google_cloud_platform/index.md
index 766788da061..1b232c361ee 100644
--- a/doc/install/google_cloud_platform/index.md
+++ b/doc/install/google_cloud_platform/index.md
@@ -44,17 +44,17 @@ To deploy GitLab on GCP you first need to create a virtual machine:
1. To select the size, type, and desired [operating system](../requirements.md#supported-linux-distributions),
click **Change** under `Boot disk`. Click **Select** when finished.
-1. As a last step allow HTTP and HTTPS traffic, then click **Create**. The process will finish in a few seconds.
+1. As a last step allow HTTP and HTTPS traffic, then click **Create**. The process finishes in a few seconds.
## Installing GitLab
-After a few seconds, the instance will be created and available to log in. The next step is to install GitLab onto the instance.
+After a few seconds, the instance is created and available to log in. The next step is to install GitLab onto the instance.
![Deploy settings](img/vm_created.png)
-1. Make a note of the IP address of the instance, as you will need that in a later step.
+1. Make a note of the IP address of the instance, as you will need that in a later step. <!-- using future tense is okay here -->
1. Click on the SSH button to connect to the instance.
-1. A new window will appear, with you logged into the instance.
+1. A new window appears, with you logged into the instance.
![GitLab first sign in](img/ssh_terminal.png)
@@ -72,8 +72,8 @@ the first time.
### Assigning a static IP
By default, Google assigns an ephemeral IP to your instance. It is strongly
-recommended to assign a static IP if you are going to use GitLab in production
-and use a domain name as we'll see below.
+recommended to assign a static IP if you are using GitLab in production
+and use a domain name as shown below.
Read Google's documentation on how to [promote an ephemeral IP address](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip).
@@ -84,7 +84,7 @@ set up DNS to point to the static IP you configured in the previous step,
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.
+ and a new window pops up.
![SSH button](img/vm_created.png)
@@ -104,7 +104,7 @@ here's how you configure GitLab to be aware of the change:
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. <!-- using future tense is okay here -->
1. Reconfigure GitLab for the changes to take effect:
@@ -121,8 +121,7 @@ certificate. Follow the steps in the [Omnibus documentation](https://docs.gitlab
### Configuring the email SMTP settings
-You need to configure the email SMTP settings correctly otherwise GitLab will
-not be able to send notification emails, like comments, and password changes.
+You need to configure the email SMTP settings correctly otherwise GitLab cannot send notification emails, like comments, and password changes.
Check the [Omnibus documentation](https://docs.gitlab.com/omnibus/settings/smtp.html#smtp-settings) how to do so.
## Further reading
@@ -131,7 +130,7 @@ 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](../../integration/README.md)
+- [Integration documentation](../../integration/index.md)
- [GitLab Pages configuration](../../administration/pages/index.md)
- [GitLab Container Registry configuration](../../administration/packages/container_registry.md)
diff --git a/doc/install/index.md b/doc/install/index.md
index 1e6f0bb95c2..8e34ac24b71 100644
--- a/doc/install/index.md
+++ b/doc/install/index.md
@@ -48,35 +48,5 @@ methods, the majority which use the Linux packages:
## Next steps
-Here are a few resources you might want to check out after completing the
-installation:
-
-- [Upload a license](../user/admin_area/license.md) or [start a free trial](https://about.gitlab.com/free-trial/):
- Activate all GitLab Enterprise Edition functionality with a license.
-- [Set up runners](https://docs.gitlab.com/runner/): Set up one or more GitLab
- Runners, the agents that are responsible for all of the GitLab CI/CD features.
-- [GitLab Pages](../administration/pages/index.md): Configure GitLab Pages to
- allow hosting of static sites.
-- [GitLab Registry](../administration/packages/container_registry.md): With the
- GitLab Container Registry, every project can have its own space to store Docker
- images.
-- [Secure GitLab](../security/README.md#securing-your-gitlab-installation):
- Recommended practices to secure your GitLab instance.
-- [SMTP](https://docs.gitlab.com/omnibus/settings/smtp.html): Configure SMTP
- for proper email notifications support.
-- [LDAP](../administration/auth/ldap/index.md): Configure LDAP to be used as
- an authentication mechanism for GitLab.
-- [Back up and restore GitLab](../raketasks/backup_restore.md): Learn the different
- ways you can back up or restore GitLab.
-- [Upgrade GitLab](../update/index.md): Every 22nd of the month, a new feature-rich GitLab version
- is released. Learn how to upgrade to it, or to an interim release that contains a security fix.
-- [Scaling GitLab](../administration/reference_architectures/index.md):
- GitLab supports several different types of clustering.
-- [Advanced Search](../integration/elasticsearch.md): Leverage Elasticsearch for
- faster, more advanced code search across your entire GitLab instance.
-- [Geo replication](../administration/geo/index.md):
- Geo is the solution for widely distributed development teams.
-- [Release and maintenance policy](../policy/maintenance.md): Learn about GitLab
- policies governing version naming, as well as release pace for major, minor, patch,
- and security releases.
-- [Pricing](https://about.gitlab.com/pricing/): Pricing for the different tiers.
+After you complete the steps for installing GitLab, you can
+[configure your instance](next_steps.md).
diff --git a/doc/install/installation.md b/doc/install/installation.md
index eb8c3784cfa..3af3d2bfe7a 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -112,9 +112,6 @@ sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdb
libcurl4-openssl-dev libicu-dev logrotate rsync python-docutils pkg-config cmake runit-systemd
```
-Ubuntu 14.04 (Trusty Tahr) doesn't have the `libre2-dev` package available, but
-you can [install re2 manually](https://github.com/google/re2/wiki/Install).
-
If you want to use Kerberos for user authentication, install `libkrb5-dev`
(if you don't know what Kerberos is, you can assume you don't need it):
@@ -221,12 +218,6 @@ below to use a system Ruby.
Linux distributions generally have older versions of Ruby available, so these
instructions are designed to install Ruby from the official source code.
-Remove the old Ruby 1.8 if present:
-
-```shell
-sudo apt-get remove ruby1.8
-```
-
Download Ruby and compile it:
```shell
@@ -242,7 +233,7 @@ sudo make install
## 3. Go
-In GitLab 8.0 and later, GitLab has several daemons written in Go. To install
+GitLab has several daemons written in Go. To install
GitLab we need a Go compiler. The instructions below assume you use 64-bit
Linux. You can find downloads for other platforms at the [Go download
page](https://golang.org/dl).
@@ -251,21 +242,21 @@ page](https://golang.org/dl).
# Remove former Go installation folder
sudo rm -rf /usr/local/go
-curl --remote-name --progress-bar "https://dl.google.com/go/go1.13.5.linux-amd64.tar.gz"
-echo '512103d7ad296467814a6e3f635631bd35574cab3369a97a323c9a585ccaa569 go1.13.5.linux-amd64.tar.gz' | shasum -a256 -c - && \
- sudo tar -C /usr/local -xzf go1.13.5.linux-amd64.tar.gz
+curl --remote-name --progress-bar "https://dl.google.com/go/go1.15.12.linux-amd64.tar.gz"
+echo 'bbdb935699e0b24d90e2451346da76121b2412d30930eabcd80907c230d098b7 go1.15.12.linux-amd64.tar.gz' | shasum -a256 -c - && \
+ sudo tar -C /usr/local -xzf go1.15.12.linux-amd64.tar.gz
sudo ln -sf /usr/local/go/bin/{go,godoc,gofmt} /usr/local/bin/
-rm go1.13.5.linux-amd64.tar.gz
+rm go1.15.12.linux-amd64.tar.gz
```
## 4. Node
-In GitLab 8.17 and later, GitLab requires the use of Node to compile JavaScript
+GitLab requires the use of Node to compile JavaScript
assets, and Yarn to manage JavaScript dependencies. The current minimum
requirements for these are:
-- `node` >= v10.14.2. (We recommend node 14.x as it is faster)
-- `yarn` >= v1.10.0.
+- `node` >= v12.22.1. (We recommend node 14.x as it is faster)
+- `yarn` = v1.22.x (Yarn 2 is not supported yet)
In many distributions,
the versions provided by the official package repositories are out of date, so
@@ -276,10 +267,7 @@ we need to install through the following commands:
curl --location "https://deb.nodesource.com/setup_14.x" | sudo bash -
sudo apt-get install -y nodejs
-curl --silent --show-error "https://dl.yarnpkg.com/debian/pubkey.gpg" | sudo apt-key add -
-echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
-sudo apt-get update
-sudo apt-get install yarn
+npm install --global yarn
```
Visit the official websites for [node](https://nodejs.org/en/download/package-manager/) and [yarn](https://classic.yarnpkg.com/en/docs/install/) if you have any trouble with these steps.
@@ -831,6 +819,8 @@ to use. Read all about the needed configuration at the
If you want to use HTTPS, replace the `gitlab` NGINX configuration with `gitlab-ssl`. See [Using HTTPS](#using-https) for HTTPS configuration details.
+For the NGINX to be able to read the GitLab-Workhorse socket, you need to make sure, that the `www-data` user can read the socket, which will be owned by the GitLab user. This is most easily achieved, if it is world-readable, for example that it has permissions `0755`, which is the default. `www-data` also needs to be able to list the parent directories.
+
### Test Configuration
Validate your `gitlab` or `gitlab-ssl` NGINX configuration file with the following command:
diff --git a/doc/install/next_steps.md b/doc/install/next_steps.md
new file mode 100644
index 00000000000..3e73da123fb
--- /dev/null
+++ b/doc/install/next_steps.md
@@ -0,0 +1,63 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Steps after installing GitLab
+
+Here are a few resources you might want to check out after completing the
+installation.
+
+## License
+
+- [Upload a license](../user/admin_area/license.md) or [start a free trial](https://about.gitlab.com/free-trial/):
+ Activate all GitLab Enterprise Edition functionality with a license.
+- [Pricing](https://about.gitlab.com/pricing/): Pricing for the different tiers.
+
+## Security
+
+- [Secure GitLab](../security/README.md#securing-your-gitlab-installation):
+ Recommended practices to secure your GitLab instance.
+
+## Authentication
+
+- [LDAP](../administration/auth/ldap/index.md): Configure LDAP to be used as
+ an authentication mechanism for GitLab.
+
+## Email and notifications
+
+- [SMTP](https://docs.gitlab.com/omnibus/settings/smtp.html): Configure SMTP
+ for proper email notifications support.
+
+## Backup and upgrade
+
+- [Back up and restore GitLab](../raketasks/backup_restore.md): Learn the different
+ ways you can back up or restore GitLab.
+- [Upgrade GitLab](../update/index.md): Every 22nd of the month, a new feature-rich GitLab version
+ is released. Learn how to upgrade to it, or to an interim release that contains a security fix.
+- [Release and maintenance policy](../policy/maintenance.md): Learn about GitLab
+ policies governing version naming, as well as release pace for major, minor, patch,
+ and security releases.
+
+## CI/CD
+
+- [Set up runners](https://docs.gitlab.com/runner/): Set up one or more GitLab
+ Runners, the agents that are responsible for all of the GitLab CI/CD features.
+- [GitLab Pages](../administration/pages/index.md): Configure GitLab Pages to
+ allow hosting of static sites.
+- [GitLab Registry](../administration/packages/container_registry.md): With the
+ GitLab Container Registry, every project can have its own space to store Docker
+ images.
+
+## Scaling and replication
+
+- [Scaling GitLab](../administration/reference_architectures/index.md):
+ GitLab supports several different types of clustering.
+- [Geo replication](../administration/geo/index.md):
+ Geo is the solution for widely distributed development teams.
+
+## Search
+
+- [Advanced Search](../integration/elasticsearch.md): Leverage Elasticsearch for
+ faster, more advanced code search across your entire GitLab instance.
diff --git a/doc/install/openshift_and_gitlab/index.md b/doc/install/openshift_and_gitlab/index.md
index 3dbcbcfc90c..31c3ca60b84 100644
--- a/doc/install/openshift_and_gitlab/index.md
+++ b/doc/install/openshift_and_gitlab/index.md
@@ -21,7 +21,7 @@ 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 the GitLab
official Docker image while getting familiar with the web interface and CLI
-tools that will help us achieve our goal.
+tools that help us achieve our goal.
For a video demonstration on installing GitLab on OpenShift, check the article [In 13 minutes from Kubernetes to a complete application development tool](https://about.gitlab.com/blog/2016/11/14/idea-to-production/).
@@ -32,7 +32,7 @@ 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](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
+so in order to test it, we 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:
@@ -65,7 +65,7 @@ the tools needed pre-installed, including Docker, Kubernetes, and OpenShift.
### Test OpenShift using Vagrant
As of this writing, the all-in-one VM is at version 1.3, and that's
-what we will use in this tutorial.
+what we use in this tutorial.
In short:
@@ -75,7 +75,7 @@ In short:
vagrant init openshift/origin-all-in-one
```
-1. This will generate a Vagrantfile based on the all-in-one VM image
+1. This generates a Vagrantfile based on the all-in-one VM image
1. In the same directory where you generated the Vagrantfile
enter:
@@ -83,7 +83,7 @@ In short:
vagrant up
```
-This will download the VirtualBox image and fire up the VM with some preconfigured
+This downloads 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
plenty of RAM (5GB in our example), so make sure you have enough.
@@ -91,7 +91,7 @@ Now that OpenShift is set up, let's see how the web console looks like.
### Explore the OpenShift web console
-Once Vagrant finishes its thing with the VM, you will be presented with a
+Once Vagrant finishes its thing with the VM, you are presented with a
message which has some important information. One of them is the IP address
of the deployed OpenShift platform and in particular `https://10.2.2.2:8443/console/`.
Open this link with your browser and accept the self-signed certificate in
@@ -109,7 +109,7 @@ respective pods are there to explore.
![OpenShift web console](img/openshift-infra-project.png)
-We are not going to explore the whole interface, but if you want to learn about
+We are not exploring the whole interface, but if you want to learn about
the key concepts of OpenShift, read the [core concepts reference](https://docs.okd.io/3.11/architecture/core_concepts/index.html)
in the official documentation.
@@ -193,7 +193,7 @@ The connection to the server 10.2.2.2:8443 was refused - did you specify the rig
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
+1. SSH into the VM by selecting the directory where the Vagrantfile is and then
run:
```shell
@@ -201,7 +201,7 @@ In that case, the OpenShift service might not be running, so in order to fix it:
```
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:
+ running (it is in red color). If that's the case start the service with:
```shell
sudo systemctl start openshift
@@ -221,7 +221,7 @@ Now that you got a taste of what OpenShift looks like, let's deploy GitLab!
### Create a new project
-First, we will create a new project to host our application. You can do this
+First, create a new project to host our application. You can do this
either by running the CLI client:
```shell
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 70e95e284a3..926af1795b9 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -113,7 +113,7 @@ If you want to be flexible about growing your hard drive space in the future con
Apart from a local hard drive you can also mount a volume that supports the network file system (NFS) protocol. This volume might be located on a file server, a network attached storage (NAS) device, a storage area network (SAN) or on an Amazon Web Services (AWS) Elastic Block Store (EBS) volume.
-If you have enough RAM and a recent CPU the speed of GitLab is mainly limited by hard drive seek times. Having a fast drive (7200 RPM and up) or a solid state drive (SSD) will improve the responsiveness of GitLab.
+If you have enough RAM and a recent CPU the speed of GitLab is mainly limited by hard drive seek times. Having a fast drive (7200 RPM and up) or a solid state drive (SSD) improves the responsiveness of GitLab.
NOTE:
Since file system performance may affect the overall performance of GitLab,
@@ -141,7 +141,7 @@ The following is the recommended minimum Memory hardware guidance for a handful
- More users? Consult the [reference architectures page](../administration/reference_architectures/index.md)
In addition to the above, we generally recommend having at least 2GB of swap on your server,
-even if you currently have enough available RAM. Having swap will help reduce the chance of errors occurring
+even if you currently have enough available RAM. Having swap helps to reduce the chance of errors occurring
if your available memory changes. We also recommend configuring the kernel's swappiness setting
to a low value like `10` to make the most of your RAM while still having the swap
available when needed.
@@ -204,7 +204,7 @@ The recommended number of workers is calculated as the highest of the following:
For example a node with 4 cores should be configured with 3 Puma workers.
You can increase the number of Puma workers, providing enough CPU and memory capacity is available.
-A higher number of Puma workers will usually help to reduce the response time of the application
+A higher number of Puma workers usually helps to reduce the response time of the application
and increase the ability to handle parallel requests. You must perform testing to verify the
optimal settings for your infrastructure.
@@ -214,7 +214,7 @@ The recommended number of threads is dependent on several factors, including tot
of [legacy Rugged code](../administration/gitaly/index.md#direct-access-to-git-in-gitlab).
- If the operating system has a maximum 2 GB of memory, the recommended number of threads is `1`.
- A higher value will result in excess swapping, and decrease performance.
+ A higher value results in excess swapping, and decrease performance.
- If legacy Rugged code is in use, the recommended number of threads is `1`.
- In all other cases, the recommended number of threads is `4`. We don't recommend setting this
higher, due to how [Ruby MRI multi-threading](https://en.wikipedia.org/wiki/Global_interpreter_lock)
@@ -230,7 +230,7 @@ If you have a 1GB machine we recommend to configure only two Unicorn workers to
swapping.
As long as you have enough available CPU and memory capacity, it's okay to increase the number of
-Unicorn workers and this will usually help to reduce the response time of the applications and
+Unicorn workers and this usually helps to reduce the response time of the applications and
increase the ability to handle parallel requests.
To change the Unicorn workers when you have the Omnibus package (which defaults to the
@@ -248,8 +248,7 @@ On a very active server (10,000 billable users) the Sidekiq process can use 1GB+
As of Omnibus GitLab 9.0, [Prometheus](https://prometheus.io) and its related
exporters are enabled by default, to enable easy and in depth monitoring of
-GitLab. Approximately 200MB of memory will be consumed by these processes, with
-default settings.
+GitLab. With default settings, these processes consume approximately 200MB of memory.
If you would like to disable Prometheus and it's exporters or read more information
about it, check the [Prometheus documentation](../administration/monitoring/prometheus/index.md).
@@ -277,9 +276,9 @@ The GitLab Runner server requirements depend on:
- Resources required to run build jobs.
- Job concurrency settings.
-Since the nature of the jobs varies for each use case, you will need to experiment by adjusting the job concurrency to get the optimum setting.
+Since the nature of the jobs varies for each use case, you need to experiment by adjusting the job concurrency to get the optimum setting.
-For reference, GitLab.com's [auto-scaling shared runner](../user/gitlab_com/index.md#shared-runners) is configured so that a **single job** will run in a **single instance** with:
+For reference, GitLab.com's [auto-scaling shared runner](../user/gitlab_com/index.md#shared-runners) is configured so that a **single job** runs in a **single instance** with:
- 1vCPU.
- 3.75GB of RAM.
View Lorry Controller Status