Distribuire GitLab per abilitare le pipeline CI/CD su OCI

Architettura

Questa architettura di riferimento dispone di due opzioni di distribuzione: una distribuzione standalone e una distribuzione distribuita.

Standalone (<1,000 utenti)
L'architettura standalone è l'opzione più semplice per GitLab. Distribuisce tutti i componenti GitLab in un'unica istanza di calcolo all'interno della tenancy OCI. Se è necessario servire fino a 1,000 utenti e non si dispone di severi requisiti di disponibilità, per molte organizzazioni è appropriata una soluzione standalone con backup frequenti. Una singola tenancy può ospitare più server GitLab. Il seguente diagramma illustra questa architettura di riferimento:

Descrizione dell'immagine deploy_gitlab_sa.png
Distribuito (1000- 2000 utenti)
La soluzione distribuita è un'architettura a più livelli che separa i vari componenti di un server GitLab dedicato in istanze separate, ciascuna assegnata per eseguire un task specifico. In particolare, l'architettura distribuita dispone di un server PostgreSQL dedicato, di Redis Server, di server Gitaly e di un'istanza di monitoraggio Prometheus, tutti necessari per una distribuzione GitLab completamente funzionale. Per il suggerimento GitLab, questa distribuzione distribuita supporta circa 2,000 utenti. Ha prestazioni superiori a quelle della distribuzione standalone e una maggiore tolleranza agli errori a causa di alcuni ridondanti incorporati. Tuttavia, la distribuzione distribuita non è altamente disponibile.

Descrizione dell'immagine deploy_gitlab_dist.png

Queste architetture hanno i seguenti componenti:

Area
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni, e vaste distanze possono separarle (tra paesi o anche continenti).
Domini di disponibilità
I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce la tolleranza agli errori. I domini di disponibilità non condividono infrastrutture quali l'alimentazione o il raffreddamento o la rete di dominio di disponibilità interna. È quindi improbabile che un errore a un dominio di disponibilità influenzi gli altri domini di disponibilità nell'area. Le istanze distribuite nell'ambito di queste architetture di riferimento GitLab vanno tutte in un singolo dominio di disponibilità.
Rete cloud virtuale (VCN) e subnet
Un VCN è una rete definita dal software impostata in un'area OCI. I VCN possono essere segmentati in subnet, che possono essere specifiche di un'area o di un dominio di disponibilità. Sia le subnet specifiche dell'area che quelle specifiche del dominio di disponibilità possono coesistere nello stesso VCN. Una subnet può essere pubblica o privata. È possibile distribuire questa architettura GitLab in un VCN esistente contenente una subnet pubblica e privata oppure configurarla per creare un VCN con le subnet richieste.
- Subnet host di base
  La subnet host bastion è una subnet pubblica dedicata che contiene l'istanza host bastion. L'host bastion è un componente facoltativo di questa architettura e non è necessario se GitLab è direttamente connesso a Internet o alla subnet pubblica.
- Subnet load balancer
  La subnet load balancer è una subnet pubblica dedicata che contiene il load balancer.
- Subnet privata GitLab
  La subnet privata di GitLab contiene i due server GitLab, i server Gitaly, il server Redis, il server Postgres, il server Prometheus-Grafana (monitoraggio) e qualsiasi runner GitLab facoltativo.
Load balancer
Il load balancer contiene l'IP lato pubblico utilizzato per connettersi alle istanze di GitLab. Se si desidera un nome di dominio personalizzato per l'istanza di GitLab, registrare l'indirizzo IP del load balancer con il provider DNS. Il load balancer utilizza un criterio di controllo dello stato del robot rotondo per monitorare i server GitLab.
Calcola
Per GitLab viene creata solo una singola istanza di calcolo del server GitLab. Per l'architettura distribuita viene creato un totale di otto istanze di calcolo. Ciascuna di queste istanze fornisce i servizi riportati di seguito.
- Server GitLab
  L'applicazione basata sul Web GitLab principale viene installata sui due server GitLab. L'amministrazione di GitLab viene eseguita su queste istanze e il load balancer funge da frontend.
- Server PostgreSQL
  Memorizza le informazioni sul database persistente per l'applicazione GitLab. Ad esempio, utenti, autorizzazioni, problemi o altri metadati vengono memorizzati nel database PostgreSQL.
- Server Redis
  L'applicazione GitLab utilizza Redis come backend di database non coerente per informazioni sul job, metadati e job in entrata.
- Server Gitaly
  Il servizio Gitaly fornisce la memorizzazione file per i repository Git. Tutti i file che fanno parte di un repository in GitLab vengono memorizzati nei server Gitaly. Vengono create due istanze Gitaly per dimostrare un livello di capacità extra. È possibile personalizzare il server in cui vengono memorizzati i dati per un determinato progetto in base alla posizione.
- Server PostgreSQL
  GitLab memorizza le informazioni sul database persistente sul server PostgreSQL. Esempi di dati persistenti includono utenti, autorizzazioni, problemi e altri metadati del progetto.
- Server Redis
  L'applicazione GitLab utilizza Redis come backend di database non coerente per informazioni sul job, determinati tipi di metadati e job in entrata.
- Server Prometeus + Grafana (monitoraggio)
  Il server Prometheus + Grafana è un server di monitoraggio di sistemi e servizi. Raccoglie le metriche dalle destinazioni configurate a intervalli specificati, valuta le espressioni delle regole, visualizza i risultati e può attivare gli avvisi quando vengono osservate le condizioni specificate.
- Runner
  I runner GitLab sono computer dedicati che utilizzano GitLab CI/CD per eseguire i job in una pipeline. In genere vengono distribuiti nell'ambiente GitLab dopo che le istanze di GitLab sono attive, in esecuzione e testate. Non vengono creati come parte della distribuzione.
Memorizzazione oggetti
La distribuzione distribuita crea una serie di bucket di memorizzazione oggetti all'interno della tenancy OCI, progettati per memorizzare vari tipi di dati associati ai progetti GitLab, inclusi i backup.

Suggerimenti

Utilizzare i suggerimenti riportati di seguito come punto di partenza durante la distribuzione di GitLab per abilitare le pipeline CI/CD su Oracle Cloud Infrastructure. Le vostre esigenze potrebbero differire dall'architettura descritta qui.

Calcola forme

Questa architettura utilizza un'immagine del sistema operativo Oracle Linux e supporta tutte le famiglie di forme di calcolo, standard o flessibili. GitLab consiglia i seguenti parametri di configurazione per la distribuzione standalone e distribuita:

Autonoma.

Servizio

Configurazione

Server GitLab

4 OCPU, RAM 8-GB

runner GitLab (N facoltativo)

1 OCPU, RAM 4-GB

Distribuito

Servizio

Configurazione

Server di base (facoltativo)

1 OCPU, RAM 2-GB

Server GitLab (2)

4 OCPU, RAM 8-GB

PostgreSQL

1 OCPU, RAM 8-GB

Redis

1 OCPU, RAM 4-GB

Gitaly (1 obbligatorio, 2 facoltativo)

2 OCPU, RAM 16-GB

Nodo di monitoraggio

1 OCPU, RAM 2-GB

runner GitLab (N facoltativo)

1 OCPU, RAM 4-GB

GitLab consiglia queste configurazioni, ma è possibile personalizzarle al momento della distribuzione.

VCN
Quando si creano VCN e subnet, utilizzare blocchi CIDR che non si sovrappongono a nessun'altra rete (in OCI, nel data center in locale o in un altro provider cloud) a cui si intende impostare connessioni private. I blocchi CIDR di VCN sono modificabili dopo la creazione.

Quando si progettano le subnet, prendere in considerazione il flusso di traffico e i requisiti di sicurezza. Allegare tutte le risorse all'interno di uno specifico livello o ruolo alla stessa subnet, che può fungere da limite di sicurezza.
Sicurezza
Utilizzare Oracle Cloud Guard per monitorare e mantenere proattivamente la sicurezza delle risorse in OCI. Cloud Guard utilizza ricette di detector che è possibile definire per esaminare le risorse per individuare le debolezze della sicurezza e monitorare gli operatori e gli utenti per attività rischiose. Quando viene rilevata una configurazione errata o un'attività non sicura, Cloud Guard consiglia azioni correttive e assiste tali azioni in base alle ricette del rispondente che è possibile definire.

Per le risorse che richiedono la massima sicurezza, Oracle consiglia di utilizzare le zone di sicurezza. Una zona di sicurezza è un compartimento associato a una ricetta definita da Oracle di criteri di sicurezza basati sulle best practice. Ad esempio, le risorse in una zona di sicurezza non devono essere accessibili da Internet pubblico e devono essere cifrate utilizzando chiavi gestite dal cliente. Quando si creano e aggiornano le risorse in una zona di sicurezza, OCI convalida le operazioni rispetto ai criteri nella composizione della zona di sicurezza e nega le operazioni che violano uno qualsiasi dei criteri.
Runner
È possibile distribuire i runner GitLab nella stessa subnet privata delle istanze GitLab esistenti o in una VCN o subnet dedicata.

Considerazioni

Quando si distribuisce questa architettura di riferimento, prendere in considerazione i seguenti punti.

Prestazioni
Tutte le forme di calcolo predefinite avviate nell'ambito di questa architettura seguono i suggerimenti forniti nella documentazione di GitLab. Tuttavia, se un nodo di particelle necessita di più risorse, è possibile scalare le forme di calcolo. L'architettura distribuita ha prestazioni superiori a una distribuzione standalone. Le architetture dispongono delle seguenti opzioni previste per le metriche delle prestazioni.
Sicurezza
Ad eccezione del load balancer e dell'host bastion, se presente, tutti i componenti dell'architettura GitLab si trovano nella subnet privata. Tutte le istanze di calcolo nell'architettura distribuita dispongono di firewall abilitato, con iptables attivo e solo le porte necessarie aperte per abilitare la comunicazione tra i nodi.
Disponibilità
I server GitLab vengono distribuiti come coppia e bilanciati dal load balancer. Tutte le istanze vengono distribuite in un singolo dominio di disponibilità. Questa architettura di riferimento crea inoltre diversi bucket di storage degli oggetti per la memorizzazione di vari tipi di dati. Lo storage degli oggetti è un servizio regionale e non è collegato a un'istanza di calcolo o a un dominio di disponibilità specifici. È possibile accedere ai dati da qualsiasi punto all'interno o all'esterno del contesto di OCI, purché si disponga della connettività a Internet e sia possibile accedere a uno degli endpoint di storage degli oggetti. Questa distribuzione utilizza un gateway di servizio per connettersi ai bucket di memorizzazione degli oggetti. Un gateway di servizio consente la connettività agli endpoint pubblici di storage degli oggetti dagli indirizzi IP privati nelle subnet private
Backup e ripristino
La distribuzione distribuita crea un bucket di storage degli oggetti per la memorizzazione dei backup e imposta tutte le impostazioni di configurazione necessarie per caricare i dati in tale bucket. Crea inoltre un job cron sull'istanza primaria del server GitLab, che crea backup giornalieri dei dati GitLab, carica nel bucket e memorizza una copia sul computer. Il file gitlab-secrets.json contiene dati sensibili e non è incluso in questo backup. Si consiglia di conservare una copia della directory /etc/gitlab o del file /etc/gitlab/gitlab-secrets.json in un luogo sicuro che esiste al di fuori di questa distribuzione da parte di un amministratore. Considerare se si desidera eseguire backup più frequenti e impostare i criteri di conservazione appropriati nel bucket di storage degli oggetti.
```
## 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
```
È possibile eseguire il backup non solo dei dati GitLab, ma dell'intero server GitLab. Il servizio Volume a blocchi OCI consente di eseguire automaticamente i backup dei volumi a blocchi in una pianificazione e di mantenerli in base al criterio di backup selezionato. Per ulteriori dettagli, vedere la documentazione sui backup basati su criteri.
Costo
Il costo di questa architettura è correlato a qualsiasi infrastruttura distribuita OCI, ad esempio istanze di calcolo, load balancer di rete e memorizzazione dei dati, oltre a qualsiasi acquisto di licenze da GitLab. Per ulteriori informazioni sul costo dei servizi OCI, vedere la pagina Elenco processi di Oracles Cloud.
URL pubblico
Utilizzare il provider DNS per associare l'indirizzo IP pubblico dell'istanza GitLab a un nome di dominio personalizzato. Nell'architettura distribuita, l'URL personalizzato deve essere associato all'indirizzo IP pubblico del load balancer. È possibile impostare il nome dominio URL esterno al momento della distribuzione, quindi associare l'URL all'indirizzo IP nella distribuzione di GitLab dopo. È sempre possibile modificare l'URL personalizzato dopo il fact.

Distribuisci

Il codice Terraform per questa architettura di riferimento è disponibile come stack di esempio in Oracle Cloud Infrastructure Resource Manager. È inoltre possibile scaricare il codice da GitLab e personalizzarlo in base alle specifiche esigenze.

Distribuire utilizzando lo stack di esempio in Oracle Cloud Infrastructure Resource Manager:
1. Fare clic su.
  Se non si è già connessi, immettere la tenancy e le credenziali utente.
2. Selezionare l'area in cui distribuire lo stack.
3. Seguire le istruzioni e i prompt sullo schermo per creare lo stack.
4. Dopo aver creato lo stack, fare clic su Azioni Terraform e selezionare Piano.
5. Attendere il completamento del job e rivedere il piano.
  Per apportare eventuali modifiche, tornare alla pagina Dettagli stack, fare clic su Modifica stack e apportare le modifiche necessarie. Quindi, eseguire di nuovo l'azione Piano.
6. Se non sono necessarie ulteriori modifiche, tornare alla pagina Dettagli stack, fare clic su Azioni Terraform e selezionare Applica.
Distribuire utilizzando il codice Terraform in GitLab:
1. Andare a GitLab.
2. Duplicare o scaricare il repository nel computer locale.
3. Seguire le istruzioni contenute nel documento README.

Scopri di più

Ulteriori informazioni sulla distribuzione di GitLab per abilitare le pipeline CI/CD su Oracle Cloud Infrastructure.

Esaminare queste risorse aggiuntive: