Sie können GitOps erst ausführen, wenn Sie "git add" ausführen `

(3. Februar 2020)

In diesem Artikel wird erklärt, wie ich einige Herausforderungen gelöst habe, um meine ursprüngliche Umgebung und Konfiguration in Git zu integrieren – die ersten Schritte zu GitOps.

Ich wollte GitOps schon seit einiger Zeit nutzen, aber es ist immer schwierig um zu wissen, wo ich anfangen soll. Benutze ich Jenkins Jobs – ich kenne Jenkins gut? Es ist allerdings etwas altmodisch, vielleicht sollte ich Ansible Tower verwenden. Ich habe Dinge über ArgoCD und viele andere gehört. Die Wahrheit ist, ich kann nichts tun, bis ich meine Umgebung und Konfiguration tatsächlich in Git gespeichert habe.

Am Ende dieses Artikels Ich hoffe, dass Sie einige meiner Tipps für den Einstieg aufgreifen.

Was bekomme ich, wenn ich Git für Serverkonfigurationen verwende?

  1. Alle Änderungen werden protokolliert & verfolgt. Wer hat das gemacht? Veränderung? Wann? usw.
  2. Alle Änderungen werden versioniert. Hoppla, die letzte Änderung hat etwas kaputt gemacht. Einfaches Rollback.
  3. Kostenloses Backup. Klonen Sie das Repository einfach an mehrere Speicherorte.
  4. Einfach zu verwendende Konfigurationen. Ich habe gerade einen neuen Server installiert und möchte 90\% einer allgemeinen Apache-Konfiguration verwenden. Klonen Sie einfach das Repo und kopieren Sie die Datei.

Erstellen Sie ein Git-Repository – privat, aber zugänglich

Ich beabsichtige, alle meine Konfigurationsdateien für dnsmasq, httpd, zu speichern. und so weiter, alles in Git. Die Konfiguration ist vertraulich, einschließlich Benutzernamen und Kennwörtern. Daher ist ein öffentliches GitHub-Repository offensichtlich nicht die beste Idee. Wenn Sie bereit sind, für ein privates Repository zu bezahlen, entscheiden Sie sich dafür. Ich habe mich dafür entschieden, ein Repository auf einem dedizierten Server im öffentlichen Internet zu erstellen, damit alle anderen Server es erhalten können.

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

DNS-basierte Verzeichnisnamen – einfach zu durchsuchen

Ich möchte das Sortieren und Strukturieren meiner Konfiguration vereinfachen. Ich habe beschlossen, Server-DNS-Namen für die Verzeichnisse zu verwenden. Ich habe es auf meinen Heimservern getan:

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

Warum in /opt speichern? Ich verwende dieses Verzeichnis im Allgemeinen für Dateien, die auf einem bestimmten Server gespeichert sind. Es hat den Vorteil, dass es meistens dasselbe Dateisystem wie / ist, wodurch das Verknüpfen von Dateien vereinfacht wird. Zum nächsten Punkt:

Hardlinking-Dienst wird in Ihrem Git-Repo konfiguriert.

Sie könnten ein separates Git-Repository pro Server oder sogar pro Dienst haben, dies wird jedoch sehr schnell nicht mehr verwaltet. Vielmehr kann dieses „ServerConfiguration“ -Repository für Ihre gesamte Umgebung problemlos die Konfiguration für viele verschiedene Dienste speichern.

Wie erhalten wir dann Apache, dnsmasq und all diese anderen Dienste, um es zu verwenden? Hardlinks ist der richtige Weg. Die Syntax lautet ln

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

Warum nicht Symlinks, sagen Sie? Nun, ich habe angefangen, Symlinks zu verwenden, aber ich habe festgestellt, dass sich SELinux-Richtlinien für Dinge wie dnsmasq wirklich über die Verwendung einer Konfigurationsdatei außerhalb eines erwarteten Verzeichnisses beschwert haben. Es scheint, dass SELinux zwei getrennten Hardlinks erlaubt, zwei getrennte SELinux-Kontexte zu haben.

Verknüpfung mit der allgemeinen Dienstkonfiguration

Ich habe eine Reihe von Servern, die alle dieselben Konfigurationsdateien verwenden. Ein common -Verzeichnis mit relativen Symlinks funktioniert hier gut.

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

Einmal festgeschrieben

Wenn Sie Ihre Konfigurationsdateien verlinkt haben, vergessen Sie nicht, git add und git commit Ihren Fortschritt.

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

Machen Sie es sich zur Gewohnheit, Konfigurationen zu bearbeiten und dann Änderungen hinzuzufügen. Übertragen Sie diese Änderungen regelmäßig auf Ihren Ursprungsserver und ziehen / aktualisieren Sie sie bei Bedarf. Ich finde es ansteckend, und wenn ich einen Server finde, der nicht unter der Versionskontrolle der Git-Konfiguration steht, füge ich schnell die erforderlichen Konfigurationen in das Repository ein.

Dies wird die Grundlage für einige anspruchsvollere GitOps später sein Linie. Im Moment hat dieser Prozess jedoch bereits viele Vorteile.

Wenn Sie nach einem Tutorial suchen, um mit Git zu beginnen, empfehle ich das Git-Buch .

Wohin kann ich von hier aus gehen?!

  1. Speichern Sie production, test und configuration in verschiedenen Zweigen und verschmelzen zwischen ihnen.
  2. Führen Sie code reviews aus, wenn Personen einreichen – wer benötigt einen Change Advisory Board?!
  3. Entdecken Sie die verschiedenen Optionen, um diese Konfiguration beim Einchecken automatisch anzuwenden – Jenkins Jobs, Ansible Tower, ArgoCD usw.

Foto von Yancy Min auf Unsplash