rsync è una popolare utility di sincronizzazione file che utilizza un algoritmo efficiente per ridurre al minimo il consumo di larghezza di banda. Uno dei ruoli comuni di rsync è la distribuzione di una build di sito Web su un server di produzione remoto. Ecco come combinare la versatilità di rsync con l'automazione fornita dalle pipeline CI di GitLab.
Esecutori di pipeline
GitLab CI supporta diversi tipi di esecutori di pipeline. Questi definiscono l'ambiente in cui verrà eseguito il tuo lavoro. La shell executor è l'impostazione predefinita ed esegue bare metal sulla macchina host. Consente alle pipeline di utilizzare qualsiasi comando disponibile sull'host senza ulteriore configurazione. Poiché le distribuzioni Linux più popolari vengono fornite con rsync installato, questo approccio è facile da gestire.
Sfortunatamente, la shell executor non fornisce un forte isolamento e può inquinare l'ambiente del tuo host nel tempo. Un'alternativa migliore è la docker executor, che crea un nuovo contenitore Docker per ogni processo CI. Tutti i lavori vengono eseguiti in un ambiente pulito che non può influire sull'host.
Lo svantaggio qui è che le immagini di base Docker generalmente non includono rsync o ssh . Anche immagini ufficiali del sistema operativo come ubuntu:latest spedire come build minime senza questi comandi. Questo rende uno script della pipeline leggermente più complesso per aggiungere le dipendenze e rsync i tuoi file.
Ecco come aggiungere rsync alla tua pipeline. Assicurati di avere a disposizione un GitLab Runner basato su Docker prima di continuare. Assumiamo anche che tu abbia un progetto GitLab pronto per l'uso.
Preparazione
Avrai bisogno di una coppia di chiavi SSH disponibile se utilizzerai rsync per connetterti a un host SSH remoto. Puoi generare chiavi pubbliche e private eseguendo ssh-keygen -t rsa . Copia la chiave pubblica sul server a cui ti connetterai.
Quindi, copia la chiave privata generata negli appunti:
cat ~/.ssh/id_rsa | xclip -selection c
Vai al tuo progetto GitLab e fai clic su "Impostazioni" nella parte inferiore del menu di navigazione a sinistra. Fare clic sulla voce "CI/CD" nel sottomenu. Scorri verso il basso fino alla sezione "Variabili" nella pagina risultante.
Fare clic sul pulsante blu "Aggiungi variabile". Assegna un nome alla tua nuova variabile nel campo "Chiave". Stiamo utilizzando SSH_PRIVATE_KEY . Incolla la tua chiave privata nel campo "Valore", incluso il ----BEGIN iniziale e -----END finale linee.
L'aggiunta della chiave come variabile CI consente di farvi riferimento nella pipeline in un secondo momento. Verrà aggiunto all'agente SSH nei contenitori creati dalla pipeline.
Aggiunta del file della pipeline
GitLab CI esegue lavori in base al contenuto di un .gitlab-ci.yml file nel tuo repository. GitLab troverà automaticamente questo file ed eseguirà la pipeline che definisce quando esegui il push delle modifiche ai tuoi rami.
deploy:
stage: deploy
image: alpine:latest
script:
- rsync -atv --delete --progress ./ [email protected]:/var/www/html
Questo .gitlab-ci.yml contiene un lavoro che utilizza rsync per sincronizzare il contenuto della directory di lavoro su /var/www/html su example.com server. Utilizza alpine:latest Immagine Docker come ambiente di compilazione. La pipeline al momento fallirà perché rsync non è incluso nell'immagine Alpine.
Installazione di SSH e rsync
Alpine è una buona base per il lavoro perché è un'immagine leggera con poche dipendenze. Ciò riduce l'utilizzo della rete mentre GitLab estrae l'immagine all'inizio del lavoro, accelerando la pipeline. Per far funzionare rsync, aggiungi SSH e rsync all'immagine, quindi avvia l'agente SSH e registra la chiave privata che hai generato in precedenza.
deploy:
stage: deploy
image: alpine:latest
before_script:
- apk update && apk add openssh-client rsync
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | ssh-add -
script:
- rsync -atv --delete --progress ./ [email protected]:/var/www/html
OpenSSH e rsync vengono installati utilizzando apk di Alpine gestore di pacchetti. L'agente di autenticazione SSH viene avviato e la tua chiave privata viene aggiunta tramite ssh-add . GitLab inietta automaticamente il SSH_PRIVATE_KEY variabile di ambiente con il valore che hai definito nelle impostazioni del tuo progetto. Se hai utilizzato una chiave diversa nella schermata delle variabili GitLab, assicurati di regolare la pipeline di conseguenza.
Gestione della verifica dell'host
SSH richiede in modo interattivo la conferma la prima volta che ci si connette a un nuovo host remoto. Questo è incompatibile con l'ambiente CI, dove non sarai in grado di vedere o rispondere a queste richieste.
Sono disponibili due opzioni per risolvere questo problema:disabilitare i controlli severi della chiave dell'host o registrare il server come host "noto" in anticipo.
Per la prima opzione, aggiungi la seguente riga al before_script della tua pipeline :
- echo "Host *ntStrictHostKeyChecking no" >> ~/.ssh/config
Sebbene funzioni, è un potenziale rischio per la sicurezza. Non avresti alcun avviso se un utente malintenzionato avesse ottenuto il controllo del dominio o dell'IP del tuo server. L'utilizzo del controllo della chiave host ti consente di verificare che l'identità del telecomando sia quella che ti aspetti che sia.
Puoi aggiungere il telecomando come host noto in modo non interattivo connettendoti ad esso sulla tua macchina al di fuori della pipeline. Controlla il tuo ~/.ssh/known_hosts file e trova la riga contenente l'IP o il nome host del telecomando. Copia questa riga e usa la procedura precedente per aggiungere una nuova variabile CI GitLab. Assegna un nome a questa variabile SSH_HOST_KEY .
Ora aggiorna il tuo before_script sezione con la seguente riga:
- echo "$SSH_HOST_KEY" > ~/.ssh/known_hosts
Ora sarai in grado di connetterti al server senza ricevere alcuna richiesta di conferma. Invia il tuo codice al tuo repository GitLab e osserva il completamento della pipeline.
Ulteriori miglioramenti
Questa pipeline è un semplice esempio di come iniziare con SSH e rsync in un ambiente Dockerized. Esistono opportunità per migliorare ulteriormente il sistema racchiudendo i passaggi di preparazione in una fase di creazione dedicata che crea un'immagine Docker che puoi riutilizzare tra le pipeline.
Il .gitlab-ci.yml trarrebbe vantaggio anche da un maggiore utilizzo delle variabili. Astrarre il nome host del server remoto (example.com ), directory (/var/www/html ) e utente (user ) nelle variabili CI di GitLab aiuterebbero a mantenere pulito il file, impedirebbero ai browser dei repository casuali di vedere i dettagli ambientali e ti permetterebbero di modificare i valori di configurazione senza modificare il file della pipeline.
Riepilogo
L'uso di rsync nelle pipeline CI di GitLab richiede una piccola configurazione manuale per formare un ambiente di compilazione con le dipendenze necessarie. Devi inserire manualmente una chiave privata SSH e registrare il server remoto come host noto.
Sebbene siano disponibili immagini Docker della community che eseguono SSH e rsync su immagini di base popolari, alla fine queste ti danno meno controllo sulla tua build. Stai estendendo la catena di approvvigionamento della tua pipeline con un'immagine di cui non puoi necessariamente fidarti. Iniziare con un'immagine di base del sistema operativo e aggiungere ciò di cui hai bisogno ti aiuta ad avere fiducia nelle tue build.