Le organizzazioni che utilizzano un'istanza GitLab autogestita di solito fanno affidamento su di essa per mantenere i propri codice sorgente, gestione del progetto e strumenti operativi. È fondamentale disporre di backup funzionanti in modo che i tuoi dati siano protetti in caso di guasto hardware, aggiornamento del server non riuscito o compromissione dannosa.
GitLab ha un componente di backup integrato che può creare un archivio completo dei dati della tua installazione. L'archivio può essere ripristinato su un nuovo server che esegue la stessa versione di GitLab.
Ecco come configurare i backup sul filesystem locale o su un bucket Amazon S3. Questi passaggi sono destinati all'uso con le edizioni omnibus di GitLab. Dovrai modificare i comandi della CLI di GitLab anteponendoli a bundle exec rake se la tua istanza è stata creata dal sorgente.
Creazione di un On -Richiedi backup
Il modo più semplice per creare un backup è con il comando di creazione su richiesta. Esegui il seguente comando nella tua shell:
sudo gitlab-backup create
Funziona su GitLab 12.2 e successivi. Le versioni precedenti dovrebbero invece utilizzare una versione alternativa:
sudo gitlab-rake gitlab:backup:create Advertisement
Il backup verrà salvato come archivio tar nella directory definita dal file di configurazione di GitLab. Le installazioni Omnibus utilizzano per impostazione predefinita /var/opt/gitlab/backups. Ogni archivio di backup è denominato con il timestamp di creazione e la versione di GitLab.
Cosa è incluso in un backup?
L'utility di backup integrata di GitLab esporta i dati creati dagli utenti sulla tua istanza GitLab. Ciò include tutto il database GitLab e i tuoi repository Git su disco.
Il ripristino del backup ripristinerà i tuoi progetti, gruppi, utenti, problemi, file allegati caricati e registri di lavoro CI/CD. Il backup copre anche i siti Web di GitLab Pages e le immagini Docker caricate nel registro dei contenitori integrato.
I pacchetti aggiunti ai registri dei pacchetti di GitLab non sono supportati. Dovresti configurare la tua installazione per salvare i pacchetti su un provider di archiviazione oggetti esterno se hai bisogno che siano recuperabili senza una ricostruzione manuale.
Creazione di una pianificazione di backup
h2>
Non esiste un meccanismo integrato per definire una pianificazione di backup automatizzata. Dovresti configurare la tua attività cron per eseguire il comando di backup mostrato sopra.
Esegui sudo crontab -e per aprire il crontab di root, quindi aggiungi i seguenti contenuti al file:
0 21 * * * /opt/gitlab/bin/gitlab-backup create CRON=1 Annuncio
Salva e chiudi il file per applicare la modifica del crontab. Questo esempio creerà un nuovo backup ogni giorno alle 21:00. L'impostazione della variabile di ambiente CRON indica a GitLab di nascondere la visualizzazione dell'avanzamento del backup in modo da non ricevere email cron ridondanti con l'output del lavoro.
L'utilizzo di questa attività così com'è manterrà ogni backup a tempo indeterminato fino a quando non lo pulirai manualmente. Questo può consumare rapidamente molto spazio di archiviazione se stai eseguendo un'istanza GitLab attiva contenente progetti di grandi dimensioni.
Una chiave di configurazione opzionale ti consente di eliminare i vecchi archivi come parte dello script di creazione del backup. Apri il file di configurazione di GitLab su /etc/gitlab/gitlab.rb. Cerca backup_keep_time, decommenta la riga e imposta il numero di secondi per cui vuoi conservare ogni backup.
gitlab_rails['backup_keep_time'] = 432000
Qui i backup vengono conservati per cinque giorni. GitLab eliminerà tutti gli archivi idonei nella directory di backup ogni volta che viene eseguito il comando di creazione del backup.
È necessario riconfigurare GitLab ogni volta che il file di configurazione cambia. Esegui sudo gitlab-ctl reconfigure per applicare la tua nuova impostazione.
Esclusione dei tipi di dati
A volte potresti voler eseguire un backup con un sottoinsieme dei tipi di dati supportati. Definire la variabile d'ambiente SKIP ti consente di escludere operazioni specifiche dall'esecuzione, snellendo il tuo archivio finale.
Pubblicità
La variabile d'ambiente accetta un elenco di tipi di dati separati da virgole. Puoi trovare le opzioni attualmente supportate nel wiki di GitLab.
Ecco come eseguire il backup di tutto tranne le immagini del registro del contenitore:
sudo gitlab-backup create SKIP=registry
L'esclusione del contenuto del registro è spesso un modo semplice per ridurre significativamente le dimensioni del backup e accelerarne la velocità di creazione. Un team con diversi progetti attivi che creano più immagini Docker al giorno può accumulare rapidamente gigabyte di dati di registro. Escluderli dal backup non è necessariamente un rischio troppo grande, poiché puoi sempre ricostruire le immagini utilizzando il Dockerfile nel tuo repository.
Backup su S3
GitLab può salvare automaticamente i tuoi backup su provider di storage di oggetti compatibili con S3. Decommenta le righe backup_upload_connection e aggiungi i dettagli della tua connessione:
gitlab_rails['backup_upload_connection'] = { "fornitore" => "AWS", "regione" => "eu-west-1", "aws_access_key_id" => "access_key", "aws_secret_access_key" => "chiave_segreta", # "endpoint" => "https://…" }
Aggiungi la tua chiave di accesso, la chiave segreta e l'ID regione AWS per completare la connessione. Dovresti impostare anche il campo dell'endpoint se ti stai connettendo a un provider diverso da AWS. Fornisci l'URL del tuo server di archiviazione oggetti in modo che GitLab possa caricarlo su di esso.
Devi anche impostare una chiave backup_upload_remote_directory. Trova questa riga nel file di configurazione, decommentala e imposta un nome di bucket S3 per caricare i backup in:
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backup';
Esegui sudo gitlab-ctl reconfigure per applicare le modifiche.
Il comando di creazione del backup ora caricherà i suoi archivi nel bucket S3 configurato. Questo ti dà una ridondanza molto maggiore archiviando i tuoi backup fuori sede, proteggendoti da guasti fisici dell'hardware.
Pubblicità
Attenzione che l'impostazione backup_keep_time non è supportata quando stai utilizzando Memoria S3. Si applica solo agli archivi di backup archiviati localmente. Puoi ottenere qualcosa di simile utilizzando i criteri di scadenza incorporati di S3 per eliminare automaticamente i caricamenti dopo che è trascorso un periodo di tempo prestabilito.
The Copy Backup Strategia
La strategia di backup predefinita di GitLab consiste nel trasmettere continuamente i dati all'archivio tar. In genere funziona bene, ma può presentare problemi su istanze GitLab molto attive. I dati potrebbero cambiare nella directory di origine prima che finisca di raggiungere l'archivio, facendo sì che tar lo salti con un file modificato mentre lo leggiamo errore.
Per combattere questo, GitLab ha introdotto una strategia di copia opzionale. Questo copia tutti i dati di backup idonei in una directory temporanea, quindi trasmette il contenuto copiato nell'archivio tar finale. Ciò garantisce che tar non stia leggendo da un'istanza GitLab attiva, ma ha l'effetto collaterale di aumentare temporaneamente il consumo di spazio di archiviazione di GitLab. Anche le prestazioni di backup possono subire un notevole calo, soprattutto sui dispositivi di archiviazione più lenti.
La strategia di copia viene attivata impostando la variabile di ambiente STRATEGY durante l'esecuzione del comando backup. Dovresti assicurarti di avere abbastanza spazio su disco disponibile. GitLab eseguirà il backup nelle fasi del tipo di dati, quindi hai solo bisogno del doppio della dimensione del tuo tipo di dati più grande. Ad esempio, se hai 5 GB di repository Git e 10 GB di registri contenitori, dovresti avere 10 GB di spazio extra disponibile, non 15 GB.
sudo gitlab-backup create STRATEGY=copy
Non dimenticare: esegui il backup del tuo file di configurazione!
Lo script di backup di GitLab gestisce solo i dati creati dall'utente. Ci sono altri due file critici essenziali per il funzionamento del tuo server GitLab. Anche questi devono essere sottoposti a backup per garantire il corretto ripristino della tua istanza.
- /etc/gitlab/gitlab.rb – Questo è il tuo file di configurazione di GitLab. Tutte le installazioni, tranne le più basilari, di solito acquisiscono molte modifiche nel tempo. Il backup di questo file ti consente di rilasciarlo in una nuova installazione di GitLab senza dover ricominciare da capo.
- /etc/gitlab/gitlab-secrets.json– È necessario eseguire il backup di questo file. Include la chiave di crittografia del database, i segreti utilizzati per l'autenticazione a due fattori e altri dati sensibili non recuperabili. L'errata posizione di questo file potrebbe rendere impossibile qualsiasi sforzo di ripristino, anche se disponi di un archivio di backup funzionante.
Potresti utilizzare un'altra attività cron per eseguire il backup di questi due file. Dovrebbero essere copiati dal tuo server in modo che tu possa ancora accedervi in caso di guasto hardware.
Conclusione
I backup sono vitali per qualsiasi amministratore di GitLab. Il software è solitamente fondamentale per ogni team di un'organizzazione, quindi eventuali tempi di inattività imprevisti potrebbero causare gravi problemi operativi.
Pubblicità
GitLab viene fornito con tutto il necessario per eseguire backup regolari. L'approccio migliore consiste nel creare un'attività cron che esegua lo script integrato a intervalli regolari. Salva i tuoi archivi di backup su uno storage di oggetti esterno per proteggerti da perdite, guasti o danni hardware. Ricorda di eseguire manualmente il backup anche dei file di configurazione e segreti di GitLab, altrimenti il processo di ripristino sarà notevolmente più complicato.