Je kunt GitOps niet doen totdat je` git add `

(3 februari 2020)

Dit artikel legt uit hoe ik een aantal uitdagingen heb opgelost om mijn initiële omgeving en configuraties in Git te krijgen – de eerste stappen naar GitOps.

Ik wil GitOps al geruime tijd omarmen, maar het is altijd lastig om te weten waar je moet beginnen. Gebruik ik Jenkins Jobs – ik ken Jenkins goed? Het is echter een beetje ouderwets, misschien zou ik Ansible Tower moeten gebruiken. Ik heb dingen gehoord over ArgoCD, en nog veel meer. De waarheid is dat ik niets kan doen totdat ik mijn omgeving en configuratie daadwerkelijk heb opgeslagen in Git.

Aan het einde van dit artikel, Ik hoop dat je een paar van mijn tips oppikt om aan de slag te gaan.

Wat krijg ik door Git te gebruiken voor serverconfiguraties?

  1. Alle wijzigingen worden gelogd & bijgehouden. Wie heeft dat gemaakt verandering? Wanneer? etc.
  2. Alle wijzigingen zijn voorzien van een versie. Oeps, de meest recente wijziging heeft iets gebroken. Gemakkelijk terug te draaien.
  3. Gratis back-up. Kloon de repository gewoon naar meerdere locaties.
  4. Gemakkelijk te hergebruiken configuraties. Ik heb zojuist een nieuwe server geïnstalleerd en wil 90\% van een algemene apache-configuratie gebruiken. Klonen gewoon de repo en kopieer het bestand.

Maak een Git-repository – privé, maar toegankelijk

Mijn bedoeling is om al mijn configuratiebestanden op te slaan voor dnsmasq, httpd, enzovoort, allemaal in Git. De configuratie is gevoelig, inclusief gebruikersnamen en wachtwoorden, en dus is een openbare GitHub-repository natuurlijk niet het beste idee. Als je bereid bent te betalen voor een privérepository, ga ervoor. Ik heb ervoor gekozen om een ​​repository te maken op een speciale server die ik op het openbare internet heb, zodat alle andere servers het kunnen krijgen.

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

DNS-gebaseerde directory-namen – gemakkelijk te bladeren

Ik wil het gemakkelijk maken om mijn configuratie te sorteren en te structureren. Ik besloot om server-DNS-namen te gebruiken voor de mappen . Ik deed het op mijn thuisservers;

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

Waarom opslaan in /opt? Ik gebruik deze map meestal voor bestanden die zijn opgeslagen op een server die er specifiek voor is. Het heeft het voordeel dat het meestal hetzelfde bestandssysteem is als / – waardoor het gemakkelijk is om bestanden hard te koppelen. Op het volgende punt;

Hardlinking service configureert in je Git repo

Je zou een aparte Git repository per server kunnen hebben, of zelfs per service, maar dit zal zeer snel onhandelbaar worden. In plaats daarvan kan deze “ServerConfiguration” -repository voor uw hele omgeving gemakkelijk configuratie opslaan voor veel verschillende services.

Hoe krijgen we Apache, dnsmasq en al die andere services er dan voor om het te gebruiken? Hardlinks is de juiste keuze. De syntaxis is ln

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

Waarom geen symlinks, zegt u? Nou, ik begon met het gebruik van symlinks, maar ik ontdekte dat SELinux-beleid voor zaken als dnsmasq echt klaagde over het gebruik van een configuratiebestand buiten een verwachte map. Het lijkt erop dat SELinux twee afzonderlijke hardlinks toestaat om twee aparte SELinux-contexten te hebben.

Symlinking to common service configuration

Ik heb een aantal servers die allemaal dezelfde configuratiebestanden delen. Een common directory met relatieve symlinks werkt hier goed.

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

Get Committed

Eenmaal je hebt je configuratiebestanden gekoppeld, vergeet dan niet git add en git commit je voortgang.

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

Begin aan de gewoonte om configuraties te bewerken, en vervolgens toe te voegen, wijzigingen door te voeren. Duw die wijzigingen regelmatig terug naar uw oorspronkelijke server en trek / update ze indien nodig. Ik vind het besmettelijk, en als ik een server vind die niet onder Git config-versiebeheer staat, ga ik snel rond met het toevoegen van de benodigde configuraties aan de repository.

Dit zal de basis zijn voor wat meer geavanceerde GitOps later in de lijn. Maar voorlopig heeft dit proces al veel voordelen.

Als je op zoek bent naar een tutorial om met Git aan de slag te gaan, raad ik het Git Book ten zeerste aan. .

Waar kan ik heen vanaf hier ?!

  1. Opslaan production, test, en configuration in verschillende branches, en daartussen samenvoegen.
  2. Doe code reviews wanneer mensen dienen in – wie heeft er een Change Advisory Board nodig ?!
  3. Onderzoek de verschillende opties om die configuratie automatisch toe te passen bij het inchecken – Jenkins Jobs, Ansible Tower, ArgoCD, enz.

Foto door Yancy Min op Unsplash