From 2e506546adc793e719ea05acc900b29213a6d520 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 12:01:57 +0000 Subject: [PATCH 01/11] Add further guidance for Reference Architectures Calls out other GitLab offerings and more guidance for smaller setups --- .../reference_architectures/index.md | 51 +++++++++++++++---- 1 file changed, 40 insertions(+), 11 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index b53355f8297ba6..fe8177c0e1cdc2 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -43,6 +43,14 @@ The following Cloud Native Hybrid reference architectures, where select recommen - [Up to 25,000 users](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) - [Up to 50,000 users](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) +## Before you start + +The first choice to consider is whether a Self Managed approach is correct for you and your requirements. + +Running any application in production is complex, and the same is very much for GitLab. While we aim to make this as smooth as possible there are still complexities. This depends on the design chosen but with most you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. + +As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to explore our other offerings in [GitLab SaaS](https://docs.gitlab.com/ee/subscriptions/gitlab_com/) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). + ## Deciding which architecture to use The Reference Architectures are designed to strike a balance between two important factors--performance and resilience. @@ -53,13 +61,11 @@ As a general guide, **the more performant and/or resilient you want your environ This section explains the designs you can choose from. It begins with the least complexity, goes to the most, and ends with a decision tree. -### Backups +### Standalone (Non-HA) -For environments serving 2,000 or fewer users we generally recommend that an [automated backup](../../raketasks/backup_gitlab.md#configuring-cron-to-make-daily-backups) strategy is used instead of HA. +For environments serving 2,000 or fewer users we generally recommend a standalone approach. With this approach you can deploy a non-HA single or multi node environment, instead employing strategies such as [automated backups](../../raketasks/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery to provide a good level of RPO / RTO while avoiding the complexities that come with HA. -Depending on your setup and requirements, this can include configuring backups on any external services you may be using, such as Object Storage (AWS S3 / Google Cloud Storage) or Postgres (AWS RDS / Google Cloud SQL) backups for further resilience. - -Backups can provide a good level of RPO / RTO while avoiding the complexities that come with HA. +With standalone setups, especially single node environments, there are [various options available for installation](https://about.gitlab.com/install/) and management including [the ability to deploy directly via select cloud provider marketplaces](https://page.gitlab.com/cloud-partner-marketplaces.html) that reduce the complexity a little further. ### High Availability (HA) @@ -100,6 +106,12 @@ With [GitLab Geo](../geo/index.md) you can have both distributed environments in This is an **advanced and complex** setup and should only be undertaken if you have DR as a key requirement. Decisions then on how each environment are configured would also need to be taken, such as if each environment itself would be the full size and / or have HA. +### Cloud Provider services + +For all the strategies above you can run select GitLab components on equivalent Cloud Provider services such as the Postgres database or Redis. + +[Head to this section for more information on recommended services](#recommended-cloud-providers-and-services). + ### Decision Tree Below you can find the above guidance in the form of a decision tree. It's recommended you read through the above guidance in full first before though. @@ -107,12 +119,29 @@ Below you can find the above guidance in the form of a decision tree. It's recom ```mermaid %%{init: { 'theme': 'base' } }%% graph TD - L1A(What Reference Architecture should I use?) --> L2A(More than 3000 users?) - L2A -->|No| L3A("Do you need HA?
(or Zero-Downtime Upgrades)") --> |Yes| L4A>Recommendation

3K architecture with HA
including supported modifications] - L3A -->|No| L4B>Recommendation

Architecture closest to user
count with Backups] - L2A -->|Yes| L3B[Do you have experience with
and want additional resilience
with select components in Kubernetes?] - L3B -->|No| L4C>Recommendation

Architecture closest to user
count with HA] - L3B -->|Yes| L4D>Recommendation

Cloud Native Hybrid architecture
closest to user count] + L1A(What Reference Architecture should I use?) + + L2A(3,000 users or more?) + L2B(2,000 users or less?) + + L3A("Do you need HA?
(or Zero-Downtime Upgrades)") + L3B[Do you have experience with
and want additional resilience
with select components in Kubernetes?] + + L4A>Recommendation

3K architecture with HA
with supported reductions] + L4B>Recommendation

Architecture closest to user
count with HA] + L4C>Recommendation

Cloud Native Hybrid architecture
closest to user count] + L4D>"Recommendation

Standalone 1K or 2K
architecture with Backups"] + + L1A --> L2A + L1A --> L2B + + L2A -->|Yes| L3B + L3B -->|Yes| L4C + L3B -->|No| L4B + + L2B --> L3A + L3A -->|Yes| L4A + L3A -->|No| L4D L5A("Do you need cross regional distribution or disaster recovery?") --> |Yes| L6A>Additional Recommendation

GitLab Geo] L4A -.- L5A -- GitLab From 9d300fb5b47b584c75a236cc1efbe9fd2991b91b Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 12:21:21 +0000 Subject: [PATCH 02/11] Further tweaks --- doc/administration/reference_architectures/1k_users.md | 6 +++--- doc/administration/reference_architectures/2k_users.md | 3 --- doc/administration/reference_architectures/index.md | 4 ++-- doc/install/install_methods.md | 2 +- 4 files changed, 6 insertions(+), 9 deletions(-) diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md index e63d3c0cc2335f..d3aa6fef51e017 100644 --- a/doc/administration/reference_architectures/1k_users.md +++ b/doc/administration/reference_architectures/1k_users.md @@ -10,9 +10,9 @@ This page describes GitLab reference architecture for up to 1,000 users. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). -If you are serving up to 1,000 users and you don't have strict availability -requirements, a single-node solution with -[frequent backups](index.md#backups) is appropriate for +If you are serving up to 1,000 users, and you don't have strict availability +requirements, a [standalone](index.md#standalone-non-ha) single-node solution with +frequent backups is appropriate for many organizations. > - **Supported users (approximate):** 1,000 diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index b102842068a0a5..ed4b5d9ddb2633 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -47,9 +47,6 @@ For a full list of reference architectures, see [Large repositories](index.md#large-repositories) for more information. -NOTE: -For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices. - ```plantuml @startuml 2k skinparam linetype ortho diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index fe8177c0e1cdc2..1c776f6f35c834 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -49,7 +49,7 @@ The first choice to consider is whether a Self Managed approach is correct for y Running any application in production is complex, and the same is very much for GitLab. While we aim to make this as smooth as possible there are still complexities. This depends on the design chosen but with most you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. -As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to explore our other offerings in [GitLab SaaS](https://docs.gitlab.com/ee/subscriptions/gitlab_com/) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). +As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to explore our other offerings in [GitLab SaaS](../../subscriptions/gitlab_com/) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). ## Deciding which architecture to use @@ -65,7 +65,7 @@ This section explains the designs you can choose from. It begins with the least For environments serving 2,000 or fewer users we generally recommend a standalone approach. With this approach you can deploy a non-HA single or multi node environment, instead employing strategies such as [automated backups](../../raketasks/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery to provide a good level of RPO / RTO while avoiding the complexities that come with HA. -With standalone setups, especially single node environments, there are [various options available for installation](https://about.gitlab.com/install/) and management including [the ability to deploy directly via select cloud provider marketplaces](https://page.gitlab.com/cloud-partner-marketplaces.html) that reduce the complexity a little further. +With standalone setups, especially single node environments, there are [various options available for installation](../../install/index.md) and management including [the ability to deploy directly via select cloud provider marketplaces](https://page.gitlab.com/cloud-partner-marketplaces.html) that reduce the complexity a little further. ### High Availability (HA) diff --git a/doc/install/install_methods.md b/doc/install/install_methods.md index a872941dfaf89f..af15dc3f0857f2 100644 --- a/doc/install/install_methods.md +++ b/doc/install/install_methods.md @@ -26,7 +26,7 @@ You can install GitLab on several cloud providers. | Cloud provider | Description | |---------------------------------------------------------------|-------------| -| [AWS (HA)](aws/index.md) | Install GitLab on AWS using the community AMIs provided by GitLab. | +| [AWS](aws/index.md) | Install GitLab on AWS using the community AMIs provided by GitLab. | | [Google Cloud Platform (GCP)](google_cloud_platform/index.md) | Install GitLab on a VM in GCP. | | [Azure](azure/index.md) | Install GitLab from Azure Marketplace. | -- GitLab From f91cd389715a11134f170fbfb22421496f20c8ca Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 12:25:45 +0000 Subject: [PATCH 03/11] Adjust note for non HA cloud provider services --- doc/administration/reference_architectures/2k_users.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index ed4b5d9ddb2633..a590da5e4e5ba8 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -30,6 +30,9 @@ For a full list of reference architectures, see | Monitoring node | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | | Object storage4 | - | - | - | - | - | +NOTE: +For all PaaS solutions that involve configuring instances, it's recommended to deploy them over multiple availability zones for resilience if desired. + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. -- GitLab From c53887ca9f6751eb624c6eb1d41e81af0f80f781 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 12:29:09 +0000 Subject: [PATCH 04/11] Correct note placement --- doc/administration/reference_architectures/2k_users.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index a590da5e4e5ba8..ee26504902c5e4 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -30,9 +30,6 @@ For a full list of reference architectures, see | Monitoring node | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | | Object storage4 | - | - | - | - | - | -NOTE: -For all PaaS solutions that involve configuring instances, it's recommended to deploy them over multiple availability zones for resilience if desired. - 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. @@ -50,6 +47,9 @@ For all PaaS solutions that involve configuring instances, it's recommended to d [Large repositories](index.md#large-repositories) for more information. +NOTE: +For all PaaS solutions that involve configuring instances, it's recommended to deploy them over multiple availability zones for resilience if desired. + ```plantuml @startuml 2k skinparam linetype ortho -- GitLab From 82421ab0456f773e1477d3a9c3f467e98eca9b28 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 12:33:41 +0000 Subject: [PATCH 05/11] Adjust text further --- doc/administration/reference_architectures/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 1c776f6f35c834..df5a2c815ee941 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -47,9 +47,9 @@ The following Cloud Native Hybrid reference architectures, where select recommen The first choice to consider is whether a Self Managed approach is correct for you and your requirements. -Running any application in production is complex, and the same is very much for GitLab. While we aim to make this as smooth as possible there are still complexities. This depends on the design chosen but with most you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. +Running any application in production is complex, and the same applies for GitLab. While we aim to make this as smooth as possible throughout there are still complexities. This depends on the design chosen but with most you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. -As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to explore our other offerings in [GitLab SaaS](../../subscriptions/gitlab_com/) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). +As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to instead explore our other offerings such as [GitLab SaaS](../../subscriptions/gitlab_com/) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). ## Deciding which architecture to use -- GitLab From ed8f5f74422957e5be7d5c606d784a5aa365cb4c Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 12:41:52 +0000 Subject: [PATCH 06/11] Fix grammar and links in diagram --- doc/administration/reference_architectures/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index df5a2c815ee941..d1d7adefc5e8fb 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -127,11 +127,11 @@ graph TD L3A("Do you need HA?
(or Zero-Downtime Upgrades)") L3B[Do you have experience with
and want additional resilience
with select components in Kubernetes?] - L4A>Recommendation

3K architecture with HA
with supported reductions] + L4A>Recommendation

3K architecture with HA
and supported reductions] L4B>Recommendation

Architecture closest to user
count with HA] L4C>Recommendation

Cloud Native Hybrid architecture
closest to user count] L4D>"Recommendation

Standalone 1K or 2K
architecture with Backups"] - + L1A --> L2A L1A --> L2B @@ -143,7 +143,7 @@ graph TD L3A -->|Yes| L4A L3A -->|No| L4D - L5A("Do you need cross regional distribution or disaster recovery?") --> |Yes| L6A>Additional Recommendation

GitLab Geo] + L5A("Do you need cross regional distribution or disaster recovery?") --> |Yes| L6A>Additional Recommendation

GitLab Geo] L4A -.- L5A L4B -.- L5A L4C -.- L5A -- GitLab From 322490957159b2fd7b4e878b64eaf2a5c2c15df4 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 12:46:02 +0000 Subject: [PATCH 07/11] Further tweaks --- doc/administration/reference_architectures/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index d1d7adefc5e8fb..ac5813562c7b77 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -47,7 +47,7 @@ The following Cloud Native Hybrid reference architectures, where select recommen The first choice to consider is whether a Self Managed approach is correct for you and your requirements. -Running any application in production is complex, and the same applies for GitLab. While we aim to make this as smooth as possible throughout there are still complexities. This depends on the design chosen but with most you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. +Running any application in production is complex, and the same applies for GitLab. While we aim to make this as smooth as possible throughout there are still the genral complexities. This depends on the design chosen but with most you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to instead explore our other offerings such as [GitLab SaaS](../../subscriptions/gitlab_com/) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). @@ -127,7 +127,7 @@ graph TD L3A("Do you need HA?
(or Zero-Downtime Upgrades)") L3B[Do you have experience with
and want additional resilience
with select components in Kubernetes?] - L4A>Recommendation

3K architecture with HA
and supported reductions] + L4A>Recommendation

3K architecture with HA
and supported reductions] L4B>Recommendation

Architecture closest to user
count with HA] L4C>Recommendation

Cloud Native Hybrid architecture
closest to user count] L4D>"Recommendation

Standalone 1K or 2K
architecture with Backups"] -- GitLab From 076587ecb92b41be34ec8f0f12371ee836b6e5d6 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 12:49:55 +0000 Subject: [PATCH 08/11] Lint fix --- doc/administration/reference_architectures/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index ac5813562c7b77..fa2e55e866b5ee 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -49,7 +49,7 @@ The first choice to consider is whether a Self Managed approach is correct for y Running any application in production is complex, and the same applies for GitLab. While we aim to make this as smooth as possible throughout there are still the genral complexities. This depends on the design chosen but with most you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. -As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to instead explore our other offerings such as [GitLab SaaS](../../subscriptions/gitlab_com/) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). +As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to instead explore our other offerings such as [GitLab SaaS](../../subscriptions/gitlab_com/index.md) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). ## Deciding which architecture to use -- GitLab From 15980433f8b949508f42361e9e2e12cbf0ac5d51 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 13:22:36 +0000 Subject: [PATCH 09/11] Fix spelling mistake --- doc/administration/reference_architectures/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index fa2e55e866b5ee..d35aa44e67cd39 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -47,9 +47,9 @@ The following Cloud Native Hybrid reference architectures, where select recommen The first choice to consider is whether a Self Managed approach is correct for you and your requirements. -Running any application in production is complex, and the same applies for GitLab. While we aim to make this as smooth as possible throughout there are still the genral complexities. This depends on the design chosen but with most you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. +Running any application in production is complex, and the same applies for GitLab. While we aim to make this as smooth as possible throughout there are still the general complexities. This depends on the design chosen, but typically you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. -As such, it is recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to instead explore our other offerings such as [GitLab SaaS](../../subscriptions/gitlab_com/index.md) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). +As such, it's recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to instead explore our other offerings such as [GitLab SaaS](../../subscriptions/gitlab_com/index.md) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). ## Deciding which architecture to use @@ -63,7 +63,7 @@ This section explains the designs you can choose from. It begins with the least ### Standalone (Non-HA) -For environments serving 2,000 or fewer users we generally recommend a standalone approach. With this approach you can deploy a non-HA single or multi node environment, instead employing strategies such as [automated backups](../../raketasks/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery to provide a good level of RPO / RTO while avoiding the complexities that come with HA. +For environments serving 2,000 or fewer users we generally recommend a standalone approach. With this approach you can deploy a non-HA single or multi node environment, instead employing strategies such as [automated backups](../../raketasks/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery to provide a good level of [RPO / RTO](https://www.enterprisestorageforum.com/management/rpo-and-rto-understanding-the-differences/) while avoiding the complexities that come with HA. With standalone setups, especially single node environments, there are [various options available for installation](../../install/index.md) and management including [the ability to deploy directly via select cloud provider marketplaces](https://page.gitlab.com/cloud-partner-marketplaces.html) that reduce the complexity a little further. -- GitLab From 25ad31fef371a7f2a34b8f697b476cb9a3efa576 Mon Sep 17 00:00:00 2001 From: Grant Young Date: Fri, 3 Feb 2023 13:58:36 +0000 Subject: [PATCH 10/11] Remove link Causing problems with linters in mermaid --- doc/administration/reference_architectures/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index d35aa44e67cd39..5f6d3dfa6d174e 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -127,7 +127,7 @@ graph TD L3A("Do you need HA?
(or Zero-Downtime Upgrades)") L3B[Do you have experience with
and want additional resilience
with select components in Kubernetes?] - L4A>Recommendation

3K architecture with HA
and supported reductions] + L4A>Recommendation

3K architecture with HA
and supported reductions] L4B>Recommendation

Architecture closest to user
count with HA] L4C>Recommendation

Cloud Native Hybrid architecture
closest to user count] L4D>"Recommendation

Standalone 1K or 2K
architecture with Backups"] -- GitLab From 8c1d970d348ede2749b09058ed5b36a303676ab8 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Mon, 6 Feb 2023 17:05:05 +0000 Subject: [PATCH 11/11] Apply 6 suggestion(s) to 1 file(s) --- .../reference_architectures/index.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 5f6d3dfa6d174e..cfb076449c8674 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -47,9 +47,9 @@ The following Cloud Native Hybrid reference architectures, where select recommen The first choice to consider is whether a Self Managed approach is correct for you and your requirements. -Running any application in production is complex, and the same applies for GitLab. While we aim to make this as smooth as possible throughout there are still the general complexities. This depends on the design chosen, but typically you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself and more. +Running any application in production is complex, and the same applies for GitLab. While we aim to make this as smooth as possible, there are still the general complexities. This depends on the design chosen, but typically you'll need to manage all aspects such as hardware, operating systems, networking, storage, security, GitLab itself, and more. -As such, it's recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to instead explore our other offerings such as [GitLab SaaS](../../subscriptions/gitlab_com/index.md) or [GitLab Dedicated](https://about.gitlab.com/dedicated/). +As such, it's recommended that you have a working knowledge of running applications in production when deciding on going down this route. For users who want a more managed solution it's recommended to instead explore our other offerings such as [GitLab SaaS](../../subscriptions/gitlab_com/index.md) or [GitLab Dedicated](../../subscriptions/gitlab_dedicated/index.md). ## Deciding which architecture to use @@ -61,9 +61,12 @@ As a general guide, **the more performant and/or resilient you want your environ This section explains the designs you can choose from. It begins with the least complexity, goes to the most, and ends with a decision tree. -### Standalone (Non-HA) +### Standalone (non-HA) -For environments serving 2,000 or fewer users we generally recommend a standalone approach. With this approach you can deploy a non-HA single or multi node environment, instead employing strategies such as [automated backups](../../raketasks/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery to provide a good level of [RPO / RTO](https://www.enterprisestorageforum.com/management/rpo-and-rto-understanding-the-differences/) while avoiding the complexities that come with HA. +For environments serving 2,000 or fewer users, we generally recommend a standalone approach by deploying a non-highly available single or multi-node environment. With this approach, you can employ strategies such as [automated backups](../../raketasks/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery to provide a good level of RPO / RTO while avoiding the complexities that come with HA. + +*[RTO]: Recovery time objective +*[RPO]: Recovery point objective With standalone setups, especially single node environments, there are [various options available for installation](../../install/index.md) and management including [the ability to deploy directly via select cloud provider marketplaces](https://page.gitlab.com/cloud-partner-marketplaces.html) that reduce the complexity a little further. @@ -106,11 +109,11 @@ With [GitLab Geo](../geo/index.md) you can have both distributed environments in This is an **advanced and complex** setup and should only be undertaken if you have DR as a key requirement. Decisions then on how each environment are configured would also need to be taken, such as if each environment itself would be the full size and / or have HA. -### Cloud Provider services +### Cloud provider services -For all the strategies above you can run select GitLab components on equivalent Cloud Provider services such as the Postgres database or Redis. +For all the previously described strategies, you can run select GitLab components on equivalent cloud provider services such as the PostgreSQL database or Redis. -[Head to this section for more information on recommended services](#recommended-cloud-providers-and-services). +[For more information, see the recommended cloud providers and services](#recommended-cloud-providers-and-services). ### Decision Tree @@ -134,7 +137,6 @@ graph TD L1A --> L2A L1A --> L2B - L2A -->|Yes| L3B L3B -->|Yes| L4C L3B -->|No| L4B -- GitLab