ContextQMD
Back to Gitlabhq

GitLab Dedicated architecture

doc/administration/dedicated/architecture.md

18.11.24.9 KB
Original Source

{{< details >}}

  • Tier: Ultimate
  • Offering: GitLab Dedicated

{{< /details >}}

This page provides 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 the 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 in a Gitaly Cluster (Praefect) configuration.

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

Geo setup

GitLab Dedicated leverages Geo for disaster recovery.

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

[!note] Required for Geo migrations to Dedicated. Otherwise, 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.

Inbound

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

Outbound

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

AWS PrivateLink for migration

Additionally, AWS PrivateLink is also used for migration purposes. The customer's Dedicated GitLab instance can use AWS PrivateLink to pull data for a migration to GitLab Dedicated.

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.