Add latest changes from gitlab-org/gitlab@master

5 files changed, 275 insertions, 11 deletions

diff --git a/doc/solutions/cloud/aws/gitaly_sre_for_aws.md b/doc/solutions/cloud/aws/gitaly_sre_for_aws.md
new file mode 100644
index 00000000000..318316b95b8
--- /dev/null
+++ b/doc/solutions/cloud/aws/gitaly_sre_for_aws.md
@@ -0,0 +1,91 @@
+---
+stage: Solutions Architecture
+group: Solutions Architecture
+info: This page is owned by the Solutions Architecture team.
+description: Doing SRE for Gitaly instances on AWS.
+---
+
+# SRE Considerations for Gitaly on AWS **(FREE SELF)**
+
+## Gitaly SRE considerations
+
+Gitaly is an embedded service for Git Repository Storage. Gitaly and Gitaly Cluster have been engineered by GitLab to overcome fundamental challenges with horizontal scaling of the open source Git binaries that must be used on the service side of GitLab. Here is in-depth technical reading on the topic:
+
+### Why Gitaly was built
+
+If you would like to understand the underlying rationale on why GitLab had to invest in creating Gitaly, read the following minimal list of topics:
+
+- [Git characteristics that make horizontal scaling difficult](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#git-characteristics-that-make-horizontal-scaling-difficult)
+- [Git architectural characteristics and assumptions](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#git-architectural-characteristics-and-assumptions)
+- [Affects on horizontal compute architecture](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#affects-on-horizontal-compute-architecture)
+- [Evidence to back building a new horizontal layer to scale Git](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#evidence-to-back-building-a-new-horizontal-layer-to-scale-git)
+
+### Gitaly and Praefect elections
+
+As part of Gitaly cluster consistency, Praefect nodes must occasionally vote on what data copy is the most accurate. This requires an uneven number of Praefect nodes to avoid stalemates. This means that for HA, Gitaly and Praefect require a minimum of three nodes.
+
+### Gitaly performance monitoring
+
+Complete performance metrics should be collected for Gitaly instances for identification of bottlenecks, as they could have to do with disk IO, network IO, or memory.
+
+### Gitaly performance guidelines
+
+Gitaly functions as the primary Git Repository Storage in GitLab. However, it's not a streaming file server. It also does a lot of demanding computing work, such as preparing and caching Git packfiles which informs some of the performance recommendations below.
+
+NOTE:
+All recommendations are for production configurations, including performance testing. For test configurations, like training or functional testing, you can use less expensive options. However, you should adjust or rebuild if performance is an issue.
+
+#### Overall recommendations
+
+- Production-grade Gitaly must be implemented on instance compute due to all of the above and below characteristics.
+- Never use [burstable instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) (such as `t2`, `t3`, `t4g`) for Gitaly.
+- Always use at least the [AWS Nitro generation of instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) to ensure many of the below concerns are automatically handled.
+- Use Amazon Linux 2 to ensure that all [AWS oriented hardware and OS optimizations](https://aws.amazon.com/amazon-linux-2/faqs/) are maximized without additional configuration or SRE management.
+
+#### CPU and memory recommendations
+
+- The general GitLab Gitaly node recommendations for CPU and Memory assume relatively even loading across repositories. GitLab Performance Tool (GPT) testing of any non-characteristic repositories and/or SRE monitoring of Gitaly metrics may inform when to choose memory and/or CPU higher than general recommendations.
+
+**To accommodate:**
+
+- Git packfile operations are memory and CPU intensive.
+- If repository commit traffic is dense, large, or very frequent, then more CPU and Memory are required to handle the load. Patterns such as storing binaries and/or busy or large monorepos are examples that can cause high loading.
+
+#### Disk I/O recommendations
+
+- Use only SSD storage and the [class of Elastic Block Store (EBS) storage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) that suites your durability and speed requirements.
+- When not using provisioned EBS IO, EBS volume size determines the I/O level, so provisioning volumes that are much larger than needed can be the least expensive way to improve EBS IO.
+- If Gitaly performance monitoring shows signs of disk stress then one of the provisioned IOPS levels can be chosen. EBS IOPS levels also have enhanced durability which may be appealing for some implementations aside from performance considerations.
+
+**To accommodate:**
+
+- Gitaly storage is expected to be local (not NFS of any type including EFS).
+- Gitaly servers also need disk space for building and caching Git packfiles. This is above and beyond the permanent storage of your Git Repositories.
+- Git packfiles are cached in Gitaly. Creation of packfiles in temporary disk benefits from fast disk, and disk caching of packfiles benefits from ample disk space.
+
+#### Network I/O recommendations
+
+- Use only instance types [from the list of ones that support Elastic Network Adapter (ENA) advanced networking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-type-summary-table) to ensure that cluster replication latency is not due to instance level network I/O bottlenecks.
+- Choose instances with sizes with more than 10 Gbps - but only if needed and only when having proven a node level network bottleneck with monitoring and/or stress testing.
+
+**To accommodate:**
+
+- Gitaly nodes do the main work of streaming repositories for push and pull operations (to add development endpoints, and to CI/CD).
+- Gitaly servers need reasonable low latency between cluster nodes and with Praefect services in order for the cluster to maintain operational and data integrity.
+- Gitaly nodes should be selected with network bottleneck avoidance as a primary consideration.
+- Gitaly nodes should be monitored for network saturation.
+- Not all networking issues can be solved through optimizing the node level networking:
+  - Gitaly cluster node replication depends on all networking between nodes.
+  - Gitaly networking performance to pull and push endpoints depends on all networking in between.
+
+### AWS Gitaly backup
+
+Due to the nature of how Praefect tracks the replication metadata of Gitaly disk information, the best backup method is [the official backup and restore Rake tasks](../../../administration/backup_restore/index.md).
+
+### AWS Gitaly recovery
+
+Gitaly Cluster does not support snapshot backups as these can cause issues where the Praefect database becomes out of syn with the disk storage. Due to the nature of how Praefect rebuilds the replication metadata of Gitaly disk information during a restore, the best recovery method is [the official backup and restore Rake tasks](../../../administration/backup_restore/index.md).
+
+### Gitaly long term management
+
+Gitaly node disk sizes must be monitored and increased to accommodate Git repository growth and Gitaly temporary and caching storage needs. The storage configuration on all nodes should be kept identical.
diff --git a/doc/solutions/cloud/aws/gitlab_aws_integration.md b/doc/solutions/cloud/aws/gitlab_aws_integration.md
index 0e15b3dc9b2..ba0b9717562 100644
--- a/doc/solutions/cloud/aws/gitlab_aws_integration.md
+++ b/doc/solutions/cloud/aws/gitlab_aws_integration.md
@@ -23,14 +23,6 @@ This page attempts to index the ways in which GitLab can integrate with AWS. It
 | `[GitLab Solution]`  | Built as Solution Example by GitLab or GitLab Partners       | Community/Example   |
 | `[CI Solution]` | Built, at least in part, using GitLab CI and therefore <br />more customer customizable. | Items tagged `[CI Solution will]` <br />also carry one of the other tags <br />that indicates the maintenance status. |
 
-## Partnership Information
-
-### AWS known issues list
-
-Known issues are gathered from within GitLab and from customer reported issues. Customers successfully implement GitLab with a variety of “as a Service” components that GitLab has not specifically been designed for, nor has ongoing testing for. While GitLab does take partner technologies very seriously, the highlighting of known issues here is a convenience for implementers and it does not imply that GitLab has targeted compatibility with, nor carries any type of guarantee of running on the partner technology where the issues occur. Consult individual issues to understand the GitLab stance and plans on any given known issue.
-
-See the [GitLab AWS known issues list](https://gitlab.com/gitlab-com/alliances/aws/public-tracker/-/issues?label_name[]=AWS+Known+Issue) for a complete list.
-
 ## Integrations For Development Activities
 
 ### SCM Integrations
@@ -91,8 +83,8 @@ Generally solutions demonstrate end-to-end capabilities for the development fram
 
 - Installing GitLab Self-Managed on AWS
   - GitLab Single EC2 Instance. `[GitLab Built]`
-    - [Using 5 Seat AWS marketplace subscription](../../../install/aws/index.md#marketplace-subscription)
-    - [Using Prepared AMIs](../../../install/aws/index.md#official-gitlab-releases-as-amis) - Bring Your Own License for Enterprise Edition.
+    - [Using 5 Seat AWS marketplace subscription](gitlab_single_box_on_aws.md#marketplace-subscription)
+    - [Using Prepared AMIs](gitlab_single_box_on_aws.md#official-gitlab-releases-as-amis) - Bring Your Own License for Enterprise Edition.
 
   - GitLab Cloud Native Hybrid Scaled on AWS EKS and Paas. `[GitLab Built]`
     - Using GitLab Environment Toolkit (GET) - `[GitLab Solution]`
@@ -101,6 +93,9 @@ Generally solutions demonstrate end-to-end capabilities for the development fram
     - Using GitLab Environment Toolkit (GET) - `[GitLab Solution]`
 
 - [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/gitlab-AMG-datasource.html) for GitLab self-managed Prometheus metrics. `[AWS Built]`
+
+## GitLab Runner on AWS Compute
+
 - [Autoscaling GitLab Runner on AWS EC2](https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/). `[GitLab Built]`
 - [GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/). `[GitLab Solution]`
   - Runner vending machine training resources.
diff --git a/doc/solutions/cloud/aws/gitlab_instance_on_aws.md b/doc/solutions/cloud/aws/gitlab_instance_on_aws.md
new file mode 100644
index 00000000000..320c317d446
--- /dev/null
+++ b/doc/solutions/cloud/aws/gitlab_instance_on_aws.md
@@ -0,0 +1,55 @@
+---
+stage: Solutions Architecture
+group: Solutions Architecture
+info: This page is owned by the Solutions Architecture team.
+---
+
+{::options parse_block_html="true" /}
+
+# Provision GitLab Instances on AWS EKS **(FREE SELF)**
+
+## Available Infrastructure as Code for GitLab Instance Installation on AWS
+
+The [GitLab Environment Toolkit (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/README.md) is a set of opinionated Terraform and Ansible scripts. These scripts help with the deployment of Linux package or Cloud Native Hybrid environments on selected cloud providers and are used by GitLab developers for [GitLab Dedicated](../../../subscriptions/gitlab_dedicated/index.md) (for example).
+
+You can use the GitLab Environment Toolkit to deploy a Cloud Native Hybrid environment on AWS. However, it's not required and may not support every valid permutation. That said, the scripts are presented as-is and you can adapt them accordingly.
+
+### Two and Three Zone High Availability
+
+While GitLab Reference Architectures generally encourage three zone redundancy, AWS Quick Starts and AWS Well Architected consider two zone redundancy as AWS Well Architected. Individual implementations should weigh the costs of two and three zone configurations against their own high availability requirements for a final configuration.
+
+Gitaly Cluster uses a consistency voting system to implement strong consistency between synchronized nodes. Regardless of the number of availability zones implemented, there will always need to be a minimum of three Gitaly and three Praefect nodes in the cluster to avoid voting stalemates cause by an even number of nodes.
+
+## AWS PaaS qualified for all GitLab implementations
+
+For both implementations that used the Linux package or Cloud Native Hybrid implementations, the following GitLab Service roles can be performed by AWS Services (PaaS). Any PaaS solutions that require preconfigured sizing based on the scale of your instance will also be listed in the per-instance size Bill of Materials lists. Those PaaS that do not require specific sizing, are not repeated in the BOM lists (for example, AWS Certification Manager).
+
+These services have been tested with GitLab.
+
+Some services, such as log aggregation, outbound email are not specified by GitLab, but where provided are noted.
+
+| GitLab Services                                              | AWS PaaS (Tested)              | Provided by AWS Cloud <br />Native Hybrid Quick Start        |
+| ------------------------------------------------------------ | ------------------------------ | ------------------------------------------------------------ |
+| <u>Tested PaaS Mentioned in Reference Architectures</u>      |                                |                                                              |
+| **PostgreSQL Database**                                      | Amazon RDS PostgreSQL          | Yes.                                                         |
+| **Redis Caching**                                            | Redis ElastiCache              | Yes.                                                         |
+| **Gitaly Cluster (Git Repository Storage)**<br />(Including Praefect and PostgreSQL) | ASG and Instances              | Yes - ASG and Instances<br />**Note: Gitaly cannot be put into a Kubernetes Cluster.** |
+| **All GitLab storages besides Git Repository Storage**<br />(Includes Git-LFS which is S3 Compatible) | AWS S3                         | Yes                                                          |
+|                                                              |                                |                                                              |
+| <u>Tested PaaS for Supplemental Services</u>                 |                                |                                                              |
+| **Front End Load Balancing**                                 | AWS ELB                        | Yes                                                          |
+| **Internal Load Balancing**                                  | AWS ELB                        | Yes                                                          |
+| **Outbound Email Services**                                  | AWS Simple Email Service (SES) | Yes                                                          |
+| **Certificate Authority and Management**                     | AWS Certificate Manager (ACM)  | Yes                                                          |
+| **DNS**                                                      | AWS Route53 (tested)           | Yes                                                          |
+| **GitLab and Infrastructure Log Aggregation**                | AWS CloudWatch Logs            | Yes (ContainerInsights Agent for EKS)                        |
+| **Infrastructure Performance Metrics**                       | AWS CloudWatch Metrics         | Yes                                                          |
+|                                                              |                                |                                                              |
+| <u>Supplemental Services and Configurations (Tested)</u>     |                                |                                                              |
+| **Prometheus for GitLab**                                    | AWS EKS (Cloud Native Only)    | Yes                                                          |
+| **Grafana for GitLab**                                       | AWS EKS (Cloud Native Only)    | Yes                                                          |
+| **Administrative Access to GitLab Backend**                  | Bastion Host in VPC            | Yes - HA - Preconfigured for Cluster Management.             |
+| **Encryption (In Transit / At Rest)**                        | AWS KMS                        | Yes                                                          |
+| **Secrets Storage for Provisioning**                         | AWS Secrets Manager            | Yes                                                          |
+| **Configuration Data for Provisioning**                      | AWS Parameter Store            | Yes                                                          |
+| **AutoScaling Kubernetes**                                   | EKS AutoScaling Agent          | Yes                                                          |
diff --git a/doc/solutions/cloud/aws/gitlab_single_box_on_aws.md b/doc/solutions/cloud/aws/gitlab_single_box_on_aws.md
new file mode 100644
index 00000000000..7a647f1d8d7
--- /dev/null
+++ b/doc/solutions/cloud/aws/gitlab_single_box_on_aws.md
@@ -0,0 +1,51 @@
+---
+stage: Solutions Architecture
+group: Solutions Architecture
+info: This page is owned by the Solutions Architecture team.
+---
+
+{::options parse_block_html="true" /}
+
+# Provision GitLab on a single EC2 instance in AWS **(FREE SELF)**
+
+If you want to provision a single GitLab instance on AWS, you have two options:
+
+- The marketplace subscription
+- The official GitLab AMIs
+
+## Marketplace subscription
+
+GitLab provides a 5 user subscription as an AWS Marketplace subscription to help teams of all sizes to get started with an Ultimate licensed instance in record time. The Marketplace subscription can be easily upgraded to any GitLab licensing via an AWS Marketplace Private Offer, with the convenience of continued AWS billing. No migration is necessary to obtain a larger, non-time based license from GitLab. Per-minute licensing is automatically removed when you accept the private offer.
+
+For a tutorial on provisioning a GitLab Instance via a Marketplace Subscription, [use this tutorial](https://gitlab.awsworkshop.io/040_partner_setup.html). The tutorial links to the [GitLab Ultimate Marketplace Listing](https://aws.amazon.com/marketplace/pp/prodview-g6ktjmpuc33zk), but you can also use the [GitLab Premium Marketplace Listing](https://aws.amazon.com/marketplace/pp/prodview-amk6tacbois2k) to provision an instance.
+
+## Official GitLab releases as AMIs
+
+GitLab produces Amazon Machine Images (AMI) during the regular release process. The AMIs can be used for single instance GitLab installation or, by configuring `/etc/gitlab/gitlab.rb`, can be specialized for specific GitLab service roles (for example a Gitaly server). Older releases remain available and can be used to migrate an older GitLab server to AWS.
+
+Initial licensing can either be the Free Enterprise License (EE) or the open source Community Edition (CE). The Enterprise Edition provides the easiest path forward to a licensed version if the need arises.
+
+Currently the Amazon AMI uses the Amazon prepared Ubuntu AMI (x86 and ARM are available) as its starting point.
+
+NOTE:
+When deploying a GitLab instance using the official AMI, the root password to the instance is the EC2 **Instance** ID (not the AMI ID). This way of setting the root account password is specific to official GitLab published AMIs ONLY.
+
+Instances running on Community Edition (CE) require a migration to Enterprise Edition (EE) to subscribe to the GitLab Premium or Ultimate plan. If you want to pursue a subscription, using the Free-forever plan of Enterprise Edition is the least disruptive method.
+
+NOTE:
+Because any given GitLab upgrade might involve data disk updates or database schema upgrades, swapping out the AMI is not sufficient for taking upgrades.
+
+1. Log in to the AWS Web Console, so that selecting the links in the following step take you directly to the AMI list.
+1. Pick the edition you want:
+
+   - [GitLab Enterprise Edition](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;ownerAlias=782774275127;search=GitLab%20EE;sort=desc:name): If you want to unlock the enterprise features, a license is needed.
+   - [GitLab Community Edition](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;ownerAlias=782774275127;search=GitLab%20CE;sort=desc:name): The open source version of GitLab.
+   - [GitLab Premium or Ultimate Marketplace (pre-licensed)](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;source=Marketplace;search=GitLab%20EE;sort=desc:name): 5 user license built into per-minute billing.
+
+1. AMI IDs are unique per region. After you've loaded any of these editions, in the upper-right corner, select the desired target region of the console to see the appropriate AMIs.
+1. After the console is loaded, you can add additional search criteria to narrow further. For instance, type `13.` to find only 13.x versions.
+1. To launch an EC2 Machine with one of the listed AMIs, check the box at the start of the relevant row, and select **Launch** near the top of left of the page.
+
+NOTE:
+If you are trying to restore from an older version of GitLab while moving to AWS, find the
+[Enterprise and Community Editions before GitLab 11.10.3](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;ownerAlias=855262394183;sort=desc:name).
diff --git a/doc/solutions/cloud/aws/index.md b/doc/solutions/cloud/aws/index.md
index 3d5c777de30..81141b9907a 100644
--- a/doc/solutions/cloud/aws/index.md
+++ b/doc/solutions/cloud/aws/index.md
@@ -6,6 +6,78 @@ info: This page is owned by the Solutions Architecture team.
 
 # AWS Solutions
 
-This documentation covers solutions relating to Amazon Web Services (AWS).
+This documentation covers solutions relating to GitLab and Amazon Web Services (AWS).
 
 [GitLab AWS Integration Index](gitlab_aws_integration.md)
+[GitLab Instances on AWS EKS](gitlab_instance_on_aws.md)
+[SRE Considerations Gitaly on AWS](gitaly_sre_for_aws.md)
+[Provision GitLab on a single EC2 instance in AWS](gitlab_single_box_on_aws.md)
+
+## Cloud platform well architected compliance
+
+Testing-backed architectural qualification is a fundamental concept behind implementation patterns:
+
+- Implementation patterns maintain GitLab Reference Architecture compliance and provide [GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance) (GPT) reports to demonstrate adherence to them.
+- Implementation patterns may be qualified by and/or contributed to by the technology vendor. For instance, an implementation pattern for AWS may be officially reviewed by AWS.
+- Implementation patterns may specify and test Cloud Platform PaaS services for suitability for GitLab. This testing can be coordinated and help qualify these technologies for Reference Architectures. For instance, qualifying compatibility with and availability of runtime versions of top level PaaS such as those for PostgreSQL and Redis.
+- Implementation patterns can provided qualified testing for platform limitations, for example, ensuring Gitaly Cluster can work correctly on specific Cloud Platform availability zone latency and throughput characteristics or qualifying what levels of available platform partner local disk performance is workable for Gitaly server to operate with integrity.
+
+## AWS known issues list
+
+Known issues are gathered from within GitLab and from customer reported issues. Customers successfully implement GitLab with a variety of “as a Service” components that GitLab has not specifically been designed for, nor has ongoing testing for. While GitLab does take partner technologies very seriously, the highlighting of known issues here is a convenience for implementers and it does not imply that GitLab has targeted compatibility with, nor carries any type of guarantee of running on the partner technology where the issues occur. Consult individual issues to understand the GitLab stance and plans on any given known issue.
+
+See the [GitLab AWS known issues list](https://gitlab.com/gitlab-com/alliances/aws/public-tracker/-/issues?label_name[]=AWS+Known+Issue) for a complete list.
+
+## Patterns with working code examples for using GitLab with AWS
+
+[The Guided Explorations' subgroup for AWS](https://gitlab.com/guided-explorations/aws) contains a variety of working example projects.
+
+## Platform partner specificity
+
+Implementation patterns enable platform-specific terminology, best practice architecture, and platform-specific build manifests:
+
+- Implementation patterns are more vendor specific. For instance, advising specific compute instances / VMs / nodes instead of vCPUs or other generalized measures.
+- Implementation patterns are oriented to implementing good architecture for the vendor in view.
+- Implementation patterns are written to an audience who is familiar with building on the infrastructure that the implementation pattern targets. For example, if the implementation pattern is for GCP, the specific terminology of GCP is used - including using the specific names for PaaS services.
+- Implementation patterns can test and qualify if the versions of PaaS available are compatible with GitLab (for example, PostgreSQL, Redis, etc.).
+
+## Platform as a Service (PaaS) specification and usage
+
+Platform as a Service options are a huge portion of the value provided by Cloud Platforms as they simplify operational complexity and reduce the SRE and security skilling required to operate advanced, highly available technology services. Implementation patterns can be pre-qualified against the partner PaaS options.
+
+- Implementation patterns help implementers understand what PaaS options are known to work and how to choose between PaaS solutions when a single platform has more than one PaaS option for the same GitLab role.
+- For instance, where reference architectures do not have a specific recommendation on what technology is leveraged for GitLab outbound email services or what the sizing should be - a Reference Implementation may advise using a cloud providers Email as a Service (PaaS) and possibly even with specific settings.
+
+## Cost optimizing engineering
+
+Cost engineering is a fundamental aspect of Cloud Architecture and frequently the savings capabilities available on a platform exert strong influence on how to build out scaled computing.
+
+- Implementation patterns may engineer specifically for the savings models available on a platform provider. An AWS example would be maximizing the occurrence of a specific instance type for taking advantage of reserved instances.
+- Implementation patterns may leverage ephemeral compute where appropriate and with appropriate customer guidelines. For instance, a Kubernetes node group dedicated to runners on ephemeral compute (with appropriate GitLab Runner tagging to indicate the compute type).
+- Implementation patterns may include vendor specific cost calculators.
+
+## Actionability and automatability orientation
+
+Implementation patterns are one step closer to specifics that can be used as a source for build instructions and automation code:
+
+- Implementation patterns enable builders to generate a list of vendor specific resources required to implement GitLab for a given Reference Architecture.
+- Implementation patterns enable builders to use manual instructions or to create automation to build out the reference implementation.
+
+## Intended audiences and contributors
+
+The primary audiences for and contributors to this information is the GitLab **Implementation Eco System** which consists of at least:
+
+GitLab Implementation Community:
+
+- Customers
+- GitLab Channel Partners (Integrators)
+- Platform Partners
+
+GitLab Internal Implementation Teams:
+
+- Quality / Distribution / Self-Managed
+- Alliances
+- Training
+- Support
+- Professional Services
+- Public Sector