Non puoi eseguire GitOps finché non" git add "

(3 febbraio 2020)

Questo articolo spiega come ho risolto un paio di sfide per portare il mio ambiente iniziale e le mie configurazioni in Git: i primi passi per GitOps.

Volevo abbracciare GitOps da un po di tempo, ma è sempre complicato per sapere da dove cominciare. Uso Jenkins Jobs – Conosco bene Jenkins? Tuttavia è un po vecchia scuola, forse dovrei usare Ansible Tower. Ho sentito parlare di ArgoCD e di molti altri. La verità è che non posso fare nulla finché non ho effettivamente il mio ambiente e la mia configurazione memorizzati in Git.

Entro la fine di questo articolo, Spero che tu possa raccogliere alcuni dei miei suggerimenti per iniziare.

Cosa otterrò utilizzando Git per le configurazioni del server?

  1. Tutte le modifiche vengono registrate & tracciate. Chi lha fatto modificare? Quando? ecc.
  2. Tutte le modifiche hanno una versione. Spiacenti, lultima modifica ha rotto qualcosa. Facile da ripristinare.
  3. Backup gratuito. Basta clonare il repository in più posizioni.
  4. Configurazioni facili da riutilizzare. Ho appena installato un nuovo server e desidero utilizzare il 90\% di una configurazione comune di Apache. Basta clonare il repository e copiare il file.

Crea un repository Git – privato, ma accessibile

La mia intenzione è quella di memorizzare tutti i miei file di configurazione per dnsmasq, httpd, e così via, tutto in Git. La configurazione è sensibile, inclusi nomi utente e password, quindi ovviamente un repository pubblico GitHub non è lidea migliore. Se sei disposto a pagare per un repository privato, fallo. Ho scelto di creare un repository su un server dedicato che ho su Internet pubblico, in modo che tutti gli altri server possano ottenerlo.

cd /opt/ 
git init --bare ServerConfiguration.git

Nomi di directory basati su DNS – facili da sfogliare

Voglio semplificare lordinamento e la struttura della mia configurazione. Ho deciso di utilizzare i nomi DNS del server per le directory . Io sul mio server di casa lho fatto;

git clone ssh://[email protected]/opt/ServerConfiguration.git
cd ServerConfiguration.git
mkdir -p example.com/server1/{httpd,dnsqmasq}

Perché memorizzarlo in /opt? In genere uso questa directory per i file memorizzati su un server che sono specifici per esso. Ha il vantaggio di essere il più delle volte lo stesso filesystem di /, semplificando il collegamento dei file. Passiamo al punto successivo;

Configurazione del servizio di hardlink nel tuo repository Git

Potresti avere un repository Git separato per server, o anche per servizio, ma questo diventerà molto rapidamente ingestibile. Piuttosto, questo repository “ServerConfiguration” per lintero ambiente può facilmente memorizzare la configurazione per molti servizi diversi.

Come possiamo quindi ottenere Apache, dnsmasq e tutti gli altri servizi per usarlo? Hardlinks è la strada da percorrere. La sintassi è ln

ln /opt/ServerConfiguration/example.com/server1/httpd.conf /etc/httpd/conf/httpd.conf

Perché non link simbolici, dici? Bene, ho iniziato a usare i collegamenti simbolici, ma ho scoperto che le politiche di SELinux per cose come dnsmasq si lamentavano davvero dellutilizzo di un file di configurazione al di fuori di una directory prevista. Sembra che SELinux consenta a due hardlink separati di avere due contesti SELinux separati.

Collegamento simbolico alla configurazione del servizio comune

Ho un mucchio di server che condividono tutti gli stessi file di configurazione. Una directory common con i relativi collegamenti simbolici funziona bene qui.

cd /opt/ServerConfiguration 
mkdir -p example.com/common
cp /etc/httpd/conf/httpd.conf common/httpd.conf
ln -s "../common/httpd.conf" server1/httpd.conf
ln -s "../common/httpd.conf" server2/httpd.conf
...

Impegnati

una volta hai collegato i tuoi file di configurazione, non dimenticare di git add e git commit i tuoi progressi.

cd /opt/ServerConfiguration
git add -A
git commit "Made some changes..."
git push

Entra nellabitudine di modificare le configurazioni e aggiungerle, quindi confermare le modifiche. Invia periodicamente tali modifiche al tuo server di origine e tira / aggiorna quando necessario. Trovo che sia contagioso e quando trovo un server non sotto il controllo della versione di Git config, vado rapidamente in giro ad aggiungere le configurazioni necessarie nel repository.

Questa sarà la base per alcuni GitOps più sofisticati più avanti nel linea. Ma per ora, questo processo ha già molti vantaggi.

Se stai cercando un tutorial per iniziare con Git, consiglio vivamente il Git Book .

Dove posso andare da qui ?!

  1. Store production, test e configuration in rami diversi e unisci tra loro.
  2. Fai code reviews quando le persone inviano: chi ha bisogno di un comitato consultivo per il cambiamento ?!
  3. Esplora le varie opzioni per applicare automaticamente quella configurazione al check-in: Jenkins Jobs, Ansible Tower, ArgoCD, ecc.

Foto di Yancy Min su Unsplash