代码片段群组项目

Merge branch 'bm/dedicated-privatelink-zones' into 'master'

Lysanne Pinto 编辑于 5 months ago

docs: clarify Dedicated Availability Zones

See merge request https://gitlab.com/gitlab-org/gitlab/-/merge_requests/167427



Merged-by: Lysanne Pinto <lpinto@gitlab.com>
Approved-by: Ermia Qasemi <eqasemi@gitlab.com>
Approved-by: Lysanne Pinto <lpinto@gitlab.com>
Co-authored-by: bmckitrick <bmckitrick@gitlab.com>

d7739877

d7739877 5 months ago

代码所有者

将用户和群组指定为特定文件更改的核准人。了解更多。

名称	最后提交	最后更新
..
img
configure_instance.md
create_instance.md
hosted_runners.md
index.md

stage: SaaS Platforms
group: GitLab Dedicated
description: Get started with GitLab Dedicated.
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments

GitLab Dedicated

DETAILS: Tier: Ultimate Offering: GitLab Dedicated

GitLab Dedicated is a single-tenant SaaS solution, fully managed and hosted by GitLab. GitLab Dedicated operators and tenant administrators can use Switchboard to provision, configure, and maintain their tenant environments.

For more information about this offering, see the subscription page.

Architecture

This page collects a set of architectural documents and diagrams for GitLab Dedicated.

High-level overview

The following diagram shows a high-level overview of the architecture for GitLab Dedicated, where various AWS accounts managed by GitLab and customers are controlled by a Switchboard application.

When managing GitLab Dedicated tenant instances:

Switchboard is responsible for managing global configuration shared between the AWS cloud providers, accessible by tenants.
Amp is responsible for the interaction with the customer tenant accounts, such as configuring expected roles and policies, enabling the required services, and provisioning environments.

GitLab team members with edit access can update the source files for the diagram in Lucidchart.

Tenant network

The customer tenant account is a single AWS cloud provider account. The single account provides full tenancy isolation, in its own VPC, and with its own resource quotas.

The cloud provider account is where a highly resilient GitLab installation resides, in its own isolated VPC. On provisioning, the customer tenant gets access to a High Availability (HA) GitLab primary site and a GitLab Geo secondary site.

GitLab team members with edit access can update the source files for the diagram in Lucidchart.

Gitaly setup

GitLab Dedicated deploys Gitaly in a sharded setup, not a Gitaly Cluster. In this setup:

Customer repositories are spread across multiple virtual machines.
GitLab manages storage weights on behalf of the customer.

Geo setup

GitLab Dedicated leverages GitLab Geo for disaster recovery.

Geo does not use an active-active failover configuration. For more information, see Geo.

AWS PrivateLink connection (optional)

Optionally, private connectivity is available for your GitLab Dedicated instance, using AWS PrivateLink as a connection gateway.

Both inbound and outbound private links are supported.

GitLab team members with edit access can update the source files for the diagram in Lucidchart.

Hosted runners for GitLab Dedicated

The following diagram illustrates a GitLab-managed AWS account that contains GitLab runners, which are interconnected to a GitLab Dedicated instance, the public internet, and optionally a customer AWS account that uses AWS PrivateLink.

For more information on how runners authenticate and execute the job payload, see Runner execution flow.

GitLab team members with edit access can update the source files for the diagram in Lucidchart.

Get started

To get started with GitLab Dedicated, use Switchboard to: