From 18a42b827a4a28e33f99441a0335ac8a98e0e827 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Thu, 26 Jan 2023 10:38:16 +0000 Subject: [PATCH 1/3] Add Ref Arch notes on NFS and SSH Also restore NFS guidance for data objects --- .../reference_architectures/10k_users.md | 34 +++++++++++------- .../reference_architectures/25k_users.md | 34 +++++++++++------- .../reference_architectures/2k_users.md | 15 +++----- .../reference_architectures/3k_users.md | 36 ++++++++++++------- .../reference_architectures/50k_users.md | 30 +++++++++------- .../reference_architectures/5k_users.md | 36 ++++++++++++------- 6 files changed, 112 insertions(+), 73 deletions(-) diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index bb50f66aff0c69..21fb9e1d0fbec5 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -1216,6 +1216,9 @@ NOTE: Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. +NOTE: +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). + NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large repositories or monorepos not following these practices can significantly @@ -1756,7 +1759,10 @@ To configure Praefect with TLS: Sidekiq requires connection to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. - `10.6.0.101`: Sidekiq 1 @@ -1925,7 +1931,13 @@ run [multiple Sidekiq processes](../sidekiq/extra_sidekiq_processes.md). ## Configure GitLab Rails This section describes how to configure the GitLab application (Rails) component. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following + +Rails requires connections to the [Redis](#configure-redis), +[PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. The following IPs will be used as an example: @@ -2065,6 +2077,10 @@ On each node perform the following: 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step. +1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and + add or replace the files of the same name on this server. This is to ensure host mismatch errors aren't thrown + for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring + then you can skip this step. 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: ```shell @@ -2200,16 +2216,10 @@ To configure the Monitoring node: ## Configure the object storage -GitLab supports using an object storage service for holding numerous types of data. - -GitLab has been tested on a number of object storage providers: - -- [Amazon S3](https://aws.amazon.com/s3/) -- [Google Cloud Storage](https://cloud.google.com/storage) -- [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces) -- [Oracle Cloud Infrastructure](https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm) -- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html) -- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation. +GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. +It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +in larger setups as object storage is typically much more performant, reliable, +and scalable. There are two ways of specifying object storage configuration in GitLab: diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 02739904f5e604..fdafe5a5440477 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -1236,6 +1236,9 @@ NOTE: Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. +NOTE: +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). + NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large repositories or monorepos not following these practices can significantly @@ -1774,7 +1777,10 @@ To configure Praefect with TLS: Sidekiq requires connection to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. - `10.6.0.101`: Sidekiq 1 @@ -1943,7 +1949,13 @@ run [multiple Sidekiq processes](../sidekiq/extra_sidekiq_processes.md). ## Configure GitLab Rails This section describes how to configure the GitLab application (Rails) component. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following + +Rails requires connections to the [Redis](#configure-redis), +[PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. The following IPs will be used as an example: @@ -2085,6 +2097,10 @@ On each node perform the following: 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step. +1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and + add or replace the files of the same name on this server. This is to ensure host mismatch errors aren't thrown + for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring + then you can skip this step. 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: ```shell @@ -2219,16 +2235,10 @@ To configure the Monitoring node: ## Configure the object storage -GitLab supports using an object storage service for holding numerous types of data. - -GitLab has been tested on a number of object storage providers: - -- [Amazon S3](https://aws.amazon.com/s3/) -- [Google Cloud Storage](https://cloud.google.com/storage) -- [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces) -- [Oracle Cloud Infrastructure](https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm) -- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html) -- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation. +GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. +It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +in larger setups as object storage is typically much more performant, reliable, +and scalable. There are two ways of specifying object storage configuration in GitLab: diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index f41c8e9cb246bc..e093ae9c181cfe 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -924,17 +924,10 @@ running [Prometheus](../monitoring/prometheus/index.md) and ## Configure the object storage -GitLab supports using an object storage service for holding numerous types of data. - -GitLab has been tested on a number of object storage providers: - -- [Amazon S3](https://aws.amazon.com/s3/) -- [Google Cloud Storage](https://cloud.google.com/storage) -- [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces) -- [Oracle Cloud Infrastructure](https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm) -- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html) -- [Azure Blob storage](https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction) -- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation. +GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. +It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +in larger setups as object storage is typically much more performant, reliable, +and scalable. There are two ways of specifying object storage configuration in GitLab: diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index 008b5ffcc0ea83..19458bbe6172eb 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -1171,6 +1171,9 @@ NOTE: Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. +NOTE: +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). + NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large repositories or monorepos not following these practices can significantly @@ -1708,8 +1711,11 @@ To configure Praefect with TLS: Sidekiq requires connection to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following -examples include the Object storage configuration. +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following +examples The following IPs will be used as an example: @@ -1876,7 +1882,13 @@ run [multiple Sidekiq processes](../sidekiq/extra_sidekiq_processes.md). ## Configure GitLab Rails This section describes how to configure the GitLab application (Rails) component. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following + +Rails requires connections to the [Redis](#configure-redis), +[PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. On each node perform the following: @@ -2016,6 +2028,10 @@ On each node perform the following: 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step. +1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and + add or replace the files of the same name on this server. This is to ensure host mismatch errors aren't thrown + for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring + then you can skip this step. 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: ```shell @@ -2165,16 +2181,10 @@ running [Prometheus](../monitoring/prometheus/index.md) and ## Configure the object storage -GitLab supports using an object storage service for holding numerous types of data. - -GitLab has been tested on a number of object storage providers: - -- [Amazon S3](https://aws.amazon.com/s3/) -- [Google Cloud Storage](https://cloud.google.com/storage) -- [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces) -- [Oracle Cloud Infrastructure](https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm) -- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html) -- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation. +GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. +It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +in larger setups as object storage is typically much more performant, reliable, +and scalable. There are two ways of specifying object storage configuration in GitLab: diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index 87d1408b5688e1..1fb61e43eb75a1 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -1229,6 +1229,9 @@ NOTE: Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. +NOTE: +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). + NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large repositories or monorepos not following these practices can significantly @@ -1769,7 +1772,10 @@ To configure Praefect with TLS: Sidekiq requires connection to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. - `10.6.0.101`: Sidekiq 1 @@ -1938,7 +1944,13 @@ run [multiple Sidekiq processes](../sidekiq/extra_sidekiq_processes.md). ## Configure GitLab Rails This section describes how to configure the GitLab application (Rails) component. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following + +Rails requires connections to the [Redis](#configure-redis), +[PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. The following IPs will be used as an example: @@ -2221,16 +2233,10 @@ To configure the Monitoring node: ## Configure the object storage -GitLab supports using an object storage service for holding numerous types of data. - -GitLab has been tested on a number of object storage providers: - -- [Amazon S3](https://aws.amazon.com/s3/) -- [Google Cloud Storage](https://cloud.google.com/storage) -- [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces) -- [Oracle Cloud Infrastructure](https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm) -- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html) -- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation. +GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. +It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +in larger setups as object storage is typically much more performant, reliable, +and scalable. There are two ways of specifying object storage configuration in GitLab: diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 182edb82b5ff63..1d7cb610977b23 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -1167,6 +1167,9 @@ NOTE: Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. +NOTE: +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). + NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large repositories or monorepos not following these practices can significantly @@ -1703,9 +1706,12 @@ To configure Praefect with TLS: ## Configure Sidekiq -Sidekiq requires connection to the [Redis](#configure-redis), +Sidekiq requires connections to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. - `10.6.0.71`: Sidekiq 1 @@ -1872,7 +1878,13 @@ run [multiple Sidekiq processes](../sidekiq/extra_sidekiq_processes.md). ## Configure GitLab Rails This section describes how to configure the GitLab application (Rails) component. -Because you must use [Object storage](#configure-the-object-storage) instead of NFS for data objects, the following + +Rails requires connections to the [Redis](#configure-redis), +[PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. +It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. + +Note: +[Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. On each node perform the following: @@ -2015,6 +2027,10 @@ On each node perform the following: 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step. +1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and + add or replace the files of the same name on this server. This is to ensure host mismatch errors aren't thrown + for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring + then you can skip this step. 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: ```shell @@ -2164,16 +2180,10 @@ running [Prometheus](../monitoring/prometheus/index.md) and ## Configure the object storage -GitLab supports using an object storage service for holding numerous types of data. - -GitLab has been tested on a number of object storage providers: - -- [Amazon S3](https://aws.amazon.com/s3/) -- [Google Cloud Storage](https://cloud.google.com/storage) -- [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces) -- [Oracle Cloud Infrastructure](https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm) -- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html) -- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation. +GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. +It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +in larger setups as object storage is typically much more performant, reliable, +and scalable. There are two ways of specifying object storage configuration in GitLab: -- GitLab From 4d41142434bb7df235edcbfc0d5afb3675721977 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Thu, 26 Jan 2023 11:21:37 +0000 Subject: [PATCH 2/3] Lint fixes --- doc/administration/reference_architectures/10k_users.md | 6 +++--- doc/administration/reference_architectures/25k_users.md | 6 +++--- doc/administration/reference_architectures/2k_users.md | 2 +- doc/administration/reference_architectures/3k_users.md | 6 +++--- doc/administration/reference_architectures/50k_users.md | 6 +++--- doc/administration/reference_architectures/5k_users.md | 6 +++--- 6 files changed, 16 insertions(+), 16 deletions(-) diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index 21fb9e1d0fbec5..25209e1e54f82b 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -1761,7 +1761,7 @@ Sidekiq requires connection to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -1936,7 +1936,7 @@ Rails requires connections to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -2217,7 +2217,7 @@ To configure the Monitoring node: ## Configure the object storage GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. -It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +It's recommended over [NFS](../nfs.md) for data objects and in general it's better in larger setups as object storage is typically much more performant, reliable, and scalable. diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index fdafe5a5440477..c49964e6bcb8a2 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -1779,7 +1779,7 @@ Sidekiq requires connection to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -1954,7 +1954,7 @@ Rails requires connections to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -2236,7 +2236,7 @@ To configure the Monitoring node: ## Configure the object storage GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. -It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +It's recommended over [NFS](../nfs.md) for data objects and in general it's better in larger setups as object storage is typically much more performant, reliable, and scalable. diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index e093ae9c181cfe..3d9f91b22c38b4 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -925,7 +925,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and ## Configure the object storage GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. -It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +It's recommended over [NFS](../nfs.md) for data objects and in general it's better in larger setups as object storage is typically much more performant, reliable, and scalable. diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index 19458bbe6172eb..3551599a9ec16c 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -1713,7 +1713,7 @@ Sidekiq requires connection to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples @@ -1887,7 +1887,7 @@ Rails requires connections to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -2182,7 +2182,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and ## Configure the object storage GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. -It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +It's recommended over [NFS](../nfs.md) for data objects and in general it's better in larger setups as object storage is typically much more performant, reliable, and scalable. diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index 1fb61e43eb75a1..decb16d064044f 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -1774,7 +1774,7 @@ Sidekiq requires connection to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -1949,7 +1949,7 @@ Rails requires connections to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -2234,7 +2234,7 @@ To configure the Monitoring node: ## Configure the object storage GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. -It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +It's recommended over [NFS](../nfs.md) for data objects and in general it's better in larger setups as object storage is typically much more performant, reliable, and scalable. diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 1d7cb610977b23..afdd6edfc9bfa4 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -1710,7 +1710,7 @@ Sidekiq requires connections to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -1883,7 +1883,7 @@ Rails requires connections to the [Redis](#configure-redis), [PostgreSQL](#configure-postgresql) and [Gitaly](#configure-gitaly) instances. It also requires a connection to [Object Storage](#configure-the-object-storage) as recommended. -Note: +NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following examples include the Object storage configuration. @@ -2181,7 +2181,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and ## Configure the object storage GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data. -It's recommended over [NFS](#configure-nfs-optional) for data objects and in general it's better +It's recommended over [NFS](../nfs.md) for data objects and in general it's better in larger setups as object storage is typically much more performant, reliable, and scalable. -- GitLab From 0a7b2fc13ab0ab060a73fb7ea7a3e97e1741221a Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 26 Jan 2023 21:20:38 +0000 Subject: [PATCH 3/3] Apply 10 suggestion(s) to 5 file(s) --- doc/administration/reference_architectures/10k_users.md | 6 +++--- doc/administration/reference_architectures/25k_users.md | 6 +++--- doc/administration/reference_architectures/3k_users.md | 8 ++++---- doc/administration/reference_architectures/50k_users.md | 2 +- doc/administration/reference_architectures/5k_users.md | 6 +++--- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index 25209e1e54f82b..a5be29266d3e4f 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -1217,7 +1217,7 @@ Gitaly Cluster provides the benefits of fault tolerance, but comes with addition For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. NOTE: -For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster). NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. @@ -2078,8 +2078,8 @@ On each node perform the following: 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step. 1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and - add or replace the files of the same name on this server. This is to ensure host mismatch errors aren't thrown - for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring + add or replace the files of the same name on this server. This ensures host mismatch errors aren't thrown + for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring, then you can skip this step. 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index c49964e6bcb8a2..3884b55b358a7f 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -1237,7 +1237,7 @@ Gitaly Cluster provides the benefits of fault tolerance, but comes with addition For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. NOTE: -For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster). NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. @@ -2098,8 +2098,8 @@ On each node perform the following: 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step. 1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and - add or replace the files of the same name on this server. This is to ensure host mismatch errors aren't thrown - for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring + add or replace the files of the same name on this server. This ensures host mismatch errors aren't thrown + for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring, then you can skip this step. 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index 3551599a9ec16c..eef7a9d08ce9ee 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -1172,7 +1172,7 @@ Gitaly Cluster provides the benefits of fault tolerance, but comes with addition For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. NOTE: -For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster). NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. @@ -1715,7 +1715,7 @@ It also requires a connection to [Object Storage](#configure-the-object-storage) NOTE: [Because it's recommended to use Object storage](../object_storage.md) instead of NFS for data objects, the following -examples +examples include the Object storage configuration. The following IPs will be used as an example: @@ -2029,8 +2029,8 @@ On each node perform the following: 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step. 1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and - add or replace the files of the same name on this server. This is to ensure host mismatch errors aren't thrown - for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring + add or replace the files of the same name on this server. This ensures host mismatch errors aren't thrown + for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring, then you can skip this step. 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index decb16d064044f..acd5ff92da610c 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -1230,7 +1230,7 @@ Gitaly Cluster provides the benefits of fault tolerance, but comes with addition For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. NOTE: -For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster). NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index afdd6edfc9bfa4..2ddfb662be7bb9 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -1168,7 +1168,7 @@ Gitaly Cluster provides the benefits of fault tolerance, but comes with addition For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section. NOTE: -For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/#migrate-to-gitaly-cluster). +For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster). NOTE: Gitaly has been designed and tested with repositories of varying sizes that follow best practices. @@ -2028,8 +2028,8 @@ On each node perform the following: 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step. 1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and - add or replace the files of the same name on this server. This is to ensure host mismatch errors aren't thrown - for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring + add or replace the files of the same name on this server. This ensures host mismatch errors aren't thrown + for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring, then you can skip this step. 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: -- GitLab