Du kan ikke gjøre GitOps før du` git add `

(3. feb 2020)

Denne artikkelen forklarer hvordan jeg løste et par utfordringer med å få mitt opprinnelige miljø og konfigurere meg til Git – de første trinnene til GitOps.

Jeg har ønsket å omfavne GitOps i ganske lang tid, men det er alltid vanskelig å vite hvor du skal begynne. Bruker jeg Jenkins Jobs – jeg kjenner Jenkins godt? Det er litt gammel skole skjønt, kanskje jeg burde bruke Ansible Tower. Jeg har hørt ting om ArgoCD, og ​​mange andre. Sannheten er at jeg ikke kan gjøre noe før jeg faktisk har lagret miljøet og konfigurasjonen min i Git.

På slutten av denne artikkelen, Jeg håper du henter noen av tipsene mine for å komme i gang.

Hva får jeg ved å bruke Git for serverkonfigurasjoner?

  1. Alle endringer logges & spores. Hvem gjorde det endring? Når? osv.
  2. Alle endringer er versjonert. Ups, den siste endringen brøt noe. Enkel å rulle tilbake.
  3. Gratis backup. Bare klon depotet til flere steder.
  4. Enkel å bruke konfigurasjoner. Nettopp installert en ny server, og vil bruke 90\% av en vanlig apache-konfigurasjon. Bare klon repoen og kopier filen.

Opprett et Git-arkiv – privat, men tilgjengelig

Min intensjon er å lagre alle konfigurasjonsfilene mine for dnsmasq, httpd, og så videre, alt i Git. Konfigurasjon er sensitiv, inkludert brukernavn og passord, og så åpenbart er ikke et GitHub-arkiv den beste ideen. Hvis du er villig til å betale for et privat depot, kan du prøve det. Jeg valgte å opprette et lager på en dedikert server jeg har på det offentlige internett, slik at alle andre servere kan få det.

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

DNS-baserte katalognavn – lett å bla gjennom

Jeg vil gjøre det enkelt å sortere og strukturere konfigurasjonen min. Jeg bestemte meg for å bruke server-DNS-navn for katalogene . Jeg gjorde på hjemmetjenerne mine, det gjorde jeg;

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

Hvorfor lagre det i /opt? Jeg bruker vanligvis denne katalogen for filer som er lagret på en server som er spesifikke for den. Det har fordelen av at det ofte er det samme filsystemet som / – noe som gjør det enkelt å koble filer. Til neste punkt;

Hardlinking-tjenesten konfigureres i Git-repoen din

Du kan ha et eget Git-arkiv per server, eller til og med per tjeneste, men dette blir veldig raskt uhåndterlig. Snarere kan dette «ServerConfiguration» -lageret for hele miljøet ditt enkelt lagre konfigurasjon for mange forskjellige tjenester.

Hvordan får vi Apache, dnsmasq og alle de andre tjenestene til å bruke det? Hardlenker er veien å gå. Syntaksen er ln

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

Hvorfor ikke symlinker, sier du? Vel, jeg begynte å bruke symlinker, men jeg fant ut at SELinux-policyer for ting som dnsmasq virkelig klaget over å bruke en konfigurasjonsfil utenfor en forventet katalog. Det ser ut til at SELinux tillater at to separate hardlenker har to separate SELinux-kontekster.

Symlinking til vanlig tjenestekonfigurasjon

Jeg har en rekke servere som alle deler de samme konfigurasjonsfilene. En common -katalog med relative symlenker fungerer bra her.

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
...

Bli engasjert

En gang du har koblet konfigurasjonsfilene dine til, ikke glem å git add og git commit fremdriften din.

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

Gå inn i en redaksjon av redigering av konfigurasjoner, og legg til deretter, begå endringer. Skyv endringene tilbake til opprinnelsesserveren din med jevne mellomrom og trekk / oppdater når det er nødvendig. Jeg synes det er smittsomt, og når jeg finner en server som ikke er under Git config-versjonskontroll, går jeg raskt rundt og legger til de nødvendige konfigurasjonene i depotet.

Dette vil være grunnlaget for noen mer sofistikerte GitOps senere i linje. Men foreløpig har denne prosessen allerede mange fordeler.

Hvis du leter etter en veiledning for å komme i gang med Git, anbefaler jeg på det sterkeste Git Book .

Hvor kan jeg gå herfra ?!

  1. Lagre production, test og configuration i forskjellige grener, og slå sammen mellom dem.
  2. Gjør code reviews folk sender inn – hvem trenger et Change Advisory Board ?!
  3. Utforsk de forskjellige alternativene for automatisk å bruke den konfigurasjonen ved innsjekking – Jenkins Jobs, Ansible Tower, ArgoCD, etc.

Foto av Yancy Min Uplash