GitLab bereitstellen, um CI-/CD-Pipelines in OCI zu aktivieren

Architektur

Diese Referenzarchitektur verfügt über zwei Deployment-Optionen: ein eigenständiges Deployment und ein verteiltes Deployment.

Standalone (<1,000 Benutzer)
Die Standalone-Architektur ist die einfachste Option für GitLab. Es stellt alle GitLab-Komponenten in einer einzelnen Compute-Instanz in Ihrem OCI-Mandanten bereit. Wenn Sie bis zu 1,000 Benutzer bedienen müssen und keine strengen Verfügbarkeitsanforderungen haben, ist eine Standalone-Lösung mit häufigen Backups für viele Organisationen geeignet. Ein einzelner Mandant kann mehrere GitLab-Server hosten. Das folgende Diagramm veranschaulicht diese Referenzarchitektur:

Beschreibung der Abbildung deploy_gitlab_sa.png
Verteilt (1000-2000 Benutzer)
Die verteilte Lösung ist eine mehrstufige Architektur, die die verschiedenen Komponenten eines dedizierten GitLab-Servers in separate Instanzen trennt, die jeweils einer bestimmten Aufgabe zugewiesen sind. Insbesondere verfügt die verteilte Architektur über einen dedizierten PostgreSQL-Server, Redis Server, Gitaly-Server und Prometheus-Überwachungsinstanz, die alle für ein voll funktionsfähiges GitLab-Deployment erforderlich sind. Pro GitLab-Empfehlung unterstützt dieses verteilte Deployment etwa 2,000 Benutzer. Sie hat eine höhere Performance als das Standalone-Deployment und eine höhere Fehlertoleranz aufgrund von einigen integrierten Redundanzen. Das verteilte Deployment ist jedoch nicht sehr verfügbar.

Beschreibung der Abbildung deploy_gitlab_dist.png

Diese Architekturen verfügen über folgende Komponenten:

Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Rechenzentrum (Availability-Domains) enthält. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).
Verfügbarkeitsdomains
Verfügbarkeitsdomains sind eigenständige, unabhängige Rechenzentren innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain werden von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Verfügbarkeitsdomänen teilen keine Infrastruktur wie Strom oder Kühlung oder das interne Availability-Domänennetzwerk. Somit ist es unwahrscheinlich, dass ein Fehler bei einer Availability-Domain die anderen Availability-Domains in der Region beeinträchtigt. Die Instanzen, die als Teil dieser GitLab-Referenzarchitekturen bereitgestellt werden, gehen alle in eine einzelne Availability-Domain.
Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein softwaredefiniertes Netzwerk, das Sie in einer OCI-Region eingerichtet haben. VCNs können in Subnetze segmentiert werden, die für eine Region oder eine Availability-Domain spezifisch sein können. Sowohl regionsspezifische als auch verfügbarkeitsdomainspezifische Subnetze können in demselben VCN nebeneinander bestehen. Ein Subnetz kann öffentlich oder privat sein. Sie können diese GitLab-Architektur in einem vorhandenen VCN bereitstellen, das ein öffentliches und privates Subnetz enthält, oder es so konfigurieren, dass ein VCN mit den erforderlichen Subnetzen erstellt wird.
- Bastions-Hostsubnetz
  Das Bastion Host-Subnetz ist ein dediziertes öffentliches Subnetz, das die Bastion Host-Instanz enthält. Der Bastionshost ist eine optionale Komponente dieser Architektur und ist nicht erforderlich, wenn GitLab direkt mit dem Internet oder öffentlichen Subnetz verbunden ist.
- Load Balancer-Subnetz
  Das Load Balancer-Subnetz ist ein dediziertes öffentliches Subnetz, das den Load Balancer enthält.
- Privates GitLab-Subnetz
  Das private GitLab-Subnetz enthält die beiden GitLab-Server, die Gitaly-Server, den Redis-Server, den Postgres-Server, den Prometheus-Grafana (Überwachungs-) Server und alle optionalen GitLab-Laufer.
Load Balancer
Der Load Balancer enthält die öffentlich zugängliche IP, mit der eine Verbindung zu den GitLab-Instanzen hergestellt wird. Wenn Sie einen benutzerdefinierten Domainnamen für Ihre GitLab-Instanz möchten, registrieren Sie die IP-Adresse des Load Balancers beim DNS-Provider. Der Load Balancer verwendet eine Round Robin Health Check-Policy zur Überwachung der GitLab-Server.
Berechnen
Für GitLab wird nur eine einzelne Compute-Instanz des GitLab-Servers erstellt. Für die verteilte Architektur werden insgesamt acht Compute-Instanzen erstellt. Jede dieser Instanzen bietet die folgenden Services:
- GitLab-Server
  Die primäre webbasierte GitLab-Anwendung wird auf den beiden GitLab-Servern installiert. Die Administration von GitLab wird für diese Instanzen ausgeführt, und der Load Balancer fungiert als Frontend.
- PostgreSQL-Server
  Speichert persistente Datenbankinformationen für die GitLab-Anwendung. Beispiel: Benutzer, Berechtigungen, Probleme oder andere Metadaten werden in der PostgreSQL-Datenbank gespeichert.
- Redis-Server
  Die GitLab-Anwendung verwendet Redis als nicht-persistentes Datenbank-Backend für Jobinformationen, Metadaten und eingehende Jobs.
- Gitaly-Server
  Der Gitaly-Service bietet Dateispeicher für Git-Repositorys. Alle Dateien, die Teil eines Repositorys in GitLab sind, werden auf den Gitaly-Servern gespeichert. Zwei Gitaly-Instanzen werden erstellt, um eine zusätzliche Kapazität zu beweisen. Sie können anpassen, welcher Server die Daten für ein bestimmtes Projekt pro Standort speichert.
- PostgreSQL-Server
  GitLab speichert persistente Datenbankinformationen auf dem PostgreSQL-Server. Beispiele für persistente Daten sind Benutzer, Berechtigungen, Probleme und andere Projektmetadaten.
- Redis-Server
  Die GitLab-Anwendung verwendet Redis als nicht-persistentes Datenbank-Backend für Jobinformationen, bestimmte Metadatentypen und eingehende Jobs.
- Prometheus + Grafana (Monitoring)-Server
  Der Prometheus + Grafana-Server ist ein System- und Serviceüberwachungsserver. Sie erfasst Metriken aus konfigurierten Zielen in bestimmten Intervallen, wertet Regelausdrücke aus, zeigt die Ergebnisse an und kann Alerts auslösen, wenn bestimmte Bedingungen beobachtet werden.
- Läufer
  GitLab-Laufer sind dedizierte Rechner, die mit GitLab CI/CD arbeiten, um Jobs in einer Pipeline auszuführen. Sie werden normalerweise in Ihrer GitLab-Umgebung bereitgestellt, nachdem GitLab-Instanzen hochgefahren und ausgeführt und getestet wurden. Sie werden nicht als Teil des Deployments erstellt.
Objektspeicher
Das verteilte Deployment erstellt eine Reihe von Objects Storage-Buckets in Ihrem OCI-Mandanten, mit denen verschiedene Datentypen gespeichert werden, die mit Ihren GitLab-Projekten verknüpft sind, einschließlich Backups.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für das Deployment von GitLab, um CI-/CD-Pipelines in Oracle Cloud Infrastructure zu aktivieren. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.

Compute Shapes

Diese Architektur verwendet ein Oracle Linux OS-Image und unterstützt alle Familien von Compute-Formen, Standard oder flexibel. GitLab empfiehlt die folgenden Konfigurationsparameter für das eigenständige und verteilte Deployment:

Standalone

Service

Konfiguration

GitLab-Server

4 OCPU, 8-GB-RAHMEN

GitLab-Läufer (N optional)

1 OCPU, 4-GB-RAHMEN

Verteilt

Service

Konfiguration

Bastionsserver (optional)

1 OCPU, 2-GB-RAHMEN

GitLab-Server (2)

4 OCPU, 8-GB-RAHMEN

PostgreSQL

1 OCPU, 8-GB-RAHMEN

Redis

1 OCPU, 4-GB-RAHMEN

Gitaly (1 erforderlich, 2 optional)

2 OCPU, 16-GB-WIDDER

Überwachungsknoten

1 OCPU, 2-GB-RAHMEN

GitLab-Läufer (N optional)

1 OCPU, 4-GB-RAHMEN

GitLab empfiehlt diese Konfigurationen, Sie können sie jedoch zur Deployment-Zeit anpassen.

VCN
Wenn Sie VCN und Subnetze erstellen, verwenden Sie CIDR-Blöcke, die sich nicht mit einem anderen Netzwerk überschneiden (in OCI, Ihrem On-Premise-Rechenzentrum oder einem anderen Cloud-Provider), zu dem Sie private Verbindungen einrichten möchten. VCN CIDR-Blöcke können nach der Erstellung bearbeitet werden.

Wenn Sie die Subnetze entwerfen, berücksichtigen Sie Ihre Verkehrsfluss- und Sicherheitsanforderungen. Ordnen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz zu, das als Sicherheitsgrenze dienen kann.
Sicherheit
Mit Oracle Cloud Guard können Sie die Sicherheit Ihrer Ressourcen in OCI proaktiv überwachen und verwalten. Cloud Guard verwendet Detektorrezepte, die Sie definieren können, um Ihre Ressourcen auf Sicherheitsschwächen zu untersuchen und Operatoren und Benutzer auf riskante Aktivitäten zu überwachen. Wenn eine Fehlkonfiguration oder unsichere Aktivität erkannt wird, empfiehlt Cloud Guard Korrekturmaßnahmen und unterstützt diese Aktionen basierend auf Antwortrezepten, die Sie definieren können.

Für Ressourcen, die maximale Sicherheit erfordern, empfiehlt Oracle, Sicherheitszonen zu verwenden. Eine Sicherheitszone ist ein Compartment, das einem von Oracledefinierten Rezept von Sicherheits-Policys zugeordnet ist, die auf Best Practices basieren. Beispielsweise dürfen die Ressourcen in einer Sicherheitszone nicht über das öffentliche Internet zugänglich sein und müssen mit kundenverwalteten Schlüsseln verschlüsselt werden. Wenn Sie Ressourcen in einer Sicherheitszone erstellen und aktualisieren, validiert OCI die Vorgänge für die Policys im Rezept der Sicherheitszone und verweigert Vorgänge, die gegen eine der Policys verstoßen.
Läufer
Sie können GitLab-Laufer in demselben privaten Subnetz wie die vorhandenen GitLab-Instanzen oder in einem dedizierten VCN oder Subnetz bereitstellen.

Überlegungen

Beachten Sie die folgenden Punkte beim Deployment dieser Referenzarchitektur.

Performance
Alle als Teil dieser Architektur gestarteten Standard-Compute-Formen folgen den Empfehlungen in der GitLab-Dokumentation. Wenn jedoch ein Partikelknoten mehr Ressourcen benötigt, können Sie die Compute-Formen skalieren. Die verteilte Architektur hat eine höhere Performance als ein eigenständiges Deployment. Die Architekturen haben die folgenden Optionen für erwartete Performancemetriken.
Sicherheit
Außer dem Load Balancer und Bastion-Host befinden sich, falls vorhanden, alle Komponenten der GitLab-Architektur im privaten Subnetz. Für die Compute-Instanzen in der verteilten Architektur ist alle Firewall aktiviert, wobei iptables on und nur die erforderlichen Ports geöffnet sind, um die Kommunikation zwischen den Knoten zu ermöglichen.
Verfügbarkeit
Die GitLab-Server werden als Paar bereitgestellt und vom Load Balancer ausgeglichen. Alle Instanzen werden in einer einzelnen Availability-Domain bereitgestellt. Diese Referenzarchitektur erstellt auch mehrere Object Storage-Buckets zur Speicherung verschiedener Datentypen. Object Storage ist ein regionaler Service und ist nicht an eine bestimmte Compute-Instanz oder Availability-Domain gebunden. Solange Sie mit dem Internet verbunden sind und auf einen der Object Storage-Endpunkte zugreifen können, können Sie von überall innerhalb oder außerhalb von OCI auf Daten zugreifen. Dieses Deployment verwendet ein Servicegateway, um eine Verbindung zu den Object Storage-Buckets herzustellen. Ein Servicegateway ermöglicht die Verbindung zu den öffentlichen Object Storage-Endpunkten von privaten IP-Adressen in privaten Subnetzen
Backups und Restore
Das verteilte Deployment erstellt einen Object Storage-Bucket zum Speichern von Backups und legt alle Konfigurationseinstellungen fest, die für das Hochladen von Daten in diesen Bucket erforderlich sind. Außerdem wird ein Cron-Job auf der primären GitLab-Serverinstanz erstellt, der tägliche Backups der GitLab-Daten erstellt, in den Bucket hochgeladen und eine Kopie auf dem Rechner gespeichert. Die Datei gitlab-secrets.json enthält sensible Daten und ist in diesem Backup nicht enthalten. Wir empfehlen, dass Sie eine Kopie des Verzeichnisses /etc/gitlab oder der /etc/gitlab/gitlab-secrets.json-Datei an einem sicheren Ort aufbewahren, der außerhalb dieses Deployments von einem Administrator vorhanden ist. Überlegen Sie, ob Sie häufigere Backups möchten, und legen Sie entsprechende Aufbewahrungs-Policys für den Object Storage-Bucket fest.
```
## Run a backup everyday at 1am.
0 1 * * * sudo gitlab-backup create
 
## Run a separate backup for configuration settings (creates a tar archive in /etc/gitlab/config_backup)
0 2 * * * sudo gitlab-ctl backup-etc
```
Sie können nicht nur GitLab-Daten, sondern auch den gesamten GitLab-Server sichern. Mit dem OCI Block Volume Service können Sie Block-Volume-Backups automatisch nach einem Zeitplan durchführen und diese basierend auf der ausgewählten Backup-Policy aufbewahren. Weitere Einzelheiten finden Sie in der Policy-basierten Backup-Dokumentation.
Kostenfaktor
Die Kosten dieser Architektur beziehen sich auf jede OCI-bereitgestellte Infrastruktur, wie Compute-Instanzen, Network Load Balancer und Datenspeicher sowie auf Lizenzkäufe von GitLab. Weitere Informationen zu den Kosten für OCI-Services finden Sie auf der Seite "Cloud Proce List" von Oracles.
Öffentliche URL
Verwenden Sie DNS-Provider, um die öffentliche IP-Adresse der GitLab-Instanz einem benutzerdefinierten Domainnamen zuzuordnen. In der verteilten Architektur sollte die benutzerdefinierte URL der öffentlichen IP-Adresse des Load Balancers zugeordnet werden. Sie können den externen URL-Domainnamen beim Deployment festlegen und anschließend die URL mit der IP-Adresse im GitLab-Deployment verknüpfen. Sie können die benutzerdefinierte URL nach der Tatsache immer ändern.

Bereitstellen

Der Terraform-Code für diese Referenzarchitektur ist als Beispielstapel in Oracle Cloud Infrastructure Resource Manager verfügbar. Sie können den Code auch von GitLab herunterladen und an Ihre spezifischen Anforderungen anpassen.

Deployment mit dem Beispielstack in Oracle Cloud Infrastructure Resource Manager:
1. Klicken Sie auf.
  Wenn Sie noch nicht angemeldet sind, geben Sie die Mandanten- und Benutzerzugangsdaten ein.
2. Wählen Sie den Bereich, in dem Sie den Stack bereitstellen möchten.
3. Befolgen Sie die Anweisungen und Aufforderungen auf dem Bildschirm, um den Stack zu erstellen.
4. Klicken Sie nach dem Erstellen des Stacks auf Terraform-Aktionen, und wählen Sie Plan aus.
5. Warten Sie, bis der Job abgeschlossen ist, und prüfen Sie den Plan.
  Um Änderungen vorzunehmen, kehren Sie zur Seite "Stackdetails" zurück, klicken auf Stack bearbeiten, und nehmen Sie die erforderlichen Änderungen vor. Führen Sie dann die Planaktion erneut aus.
6. Wenn keine weiteren Änderungen erforderlich sind, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Terraform-Aktionen, und wählen Sie Anwenden aus.
Deployment mit dem Terraform-Code in GitLab:
1. Gehen Sie zu GitLab.
2. Klonen oder laden Sie das Repository auf Ihren lokalen Computer herunter.
3. Befolgen Sie die Anweisungen im Dokument README.

Mehr erfahren

Erfahren Sie mehr über das Deployment von GitLab, um CI-/CD-Pipelines in Oracle Cloud Infrastructure zu aktivieren.

Prüfen Sie diese zusätzlichen Ressourcen: