Architecture de GitLab Dedicated

{{< details >}}

• Niveau : Ultimate
• Offre : GitLab Dedicated

{{< /details >}}

Cette page fournit un ensemble de documents architecturaux et de diagrammes pour GitLab Dedicated.

Vue d'ensemble de haut niveau {#high-level-overview}

Le diagramme suivant présente une vue d'ensemble de haut niveau de l'architecture de GitLab Dedicated, où divers comptes AWS gérés par GitLab et par les clients sont contrôlés par l'application Switchboard.

Lors de la gestion des instances de locataires GitLab Dedicated :

• Switchboard est responsable de la gestion de la configuration globale partagée entre les fournisseurs cloud AWS, accessible par les locataires.
• Amp est responsable de l'interaction avec les comptes des locataires clients, notamment la configuration des rôles et des politiques attendus, l'activation des services requis et le provisionnement des environnements.

Les membres de l'équipe GitLab disposant d'un accès en modification peuvent mettre à jour les fichiers source du diagramme dans Lucidchart.

Réseau du locataire {#tenant-network}

Le compte du locataire client est un compte unique de fournisseur cloud AWS. Le compte unique assure une isolation complète de la location, dans son propre VPC, et avec ses propres quotas de ressources.

Le compte du fournisseur cloud est l'endroit où réside une installation GitLab hautement résiliente, dans son propre VPC isolé. Lors du provisionnement, le locataire client obtient accès à un site principal GitLab en haute disponibilité (HA) et à un site secondaire GitLab Geo.

Les membres de l'équipe GitLab disposant d'un accès en modification peuvent mettre à jour les fichiers source du diagramme dans Lucidchart.

Configuration de Gitaly {#gitaly-setup}

GitLab Dedicated déploie Gitaly dans une configuration fragmentée (sharded), et non dans une configuration Gitaly Cluster (Praefect).

• Les référentiels des clients sont répartis sur plusieurs machines virtuelles.
• GitLab gère les poids de stockage au nom du client.

Configuration de Geo {#geo-setup}

GitLab Dedicated exploite Geo pour la reprise après sinistre.

Geo n'utilise pas de configuration de basculement actif-actif. Pour plus d'informations, consultez Geo.

Connexion AWS PrivateLink {#aws-privatelink-connection}

[!note] Obligatoire pour les migrations Geo vers Dedicated. Sinon, facultatif.

En option, une connectivité privée est disponible pour votre instance GitLab Dedicated, en utilisant AWS PrivateLink comme passerelle de connexion.

Les connexions PrivateLink entrantes et sortantes sont toutes deux prises en charge.

Entrante {#inbound}

Les membres de l'équipe GitLab disposant d'un accès en modification peuvent mettre à jour les fichiers source du diagramme dans Lucidchart.

Sortante {#outbound}

Les membres de l'équipe GitLab disposant d'un accès en modification peuvent mettre à jour les fichiers source du diagramme dans Lucidchart.

AWS PrivateLink pour la migration {#aws-privatelink-for-migration}

De plus, AWS PrivateLink est également utilisé à des fins de migration. L'instance GitLab Dedicated du client peut utiliser AWS PrivateLink pour extraire des données en vue d'une migration vers GitLab Dedicated.

Les membres de l'équipe GitLab disposant d'un accès en modification peuvent mettre à jour les fichiers source du diagramme dans Lucidchart.

Runners hébergés pour GitLab Dedicated {#hosted-runners-for-gitlab-dedicated}

Le diagramme suivant illustre un compte AWS géré par GitLab qui contient des runners GitLab, interconnectés à une instance GitLab Dedicated, à l'internet public et, en option, à un compte AWS client utilisant AWS PrivateLink.

Pour plus d'informations sur la façon dont les runners s'authentifient et exécutent la charge utile du job, consultez le flux d'exécution du runner.

Les membres de l'équipe GitLab disposant d'un accès en modification peuvent mettre à jour les fichiers source du diagramme dans Lucidchart.