Git Workflow

Mittels der Versionskontrolle durch Git bieten sich mit Puppet folgende Vorteile:

  • Historie – Änderungen an der Infrastruktur sind nachvollziehbar und einem Administrator zuzuordnen.
  • Rollback – Bei Problemen mit neuen Changes kann jederzeit der alte Zustand wiederhergestellt werden.
  • Qualitätskontrolle – Über die Git Hooks wird eine automatische Prüfung auf Fehler durchgeführt.
  • Change Management – Mittels der verschiedenen Branches lässt sich sehr leicht ein Change Management implementieren.

Vorbereitungen

Bevor wir mit Git loslegen können sind noch einige Vorbereitungen zu treffen um den Administratoren Zugriff auf das Repository zu ermöglichen.

Berechtigungen

Jeder Administrator benötigt einen SSH Key, welcher auf dem zentralen Puppet Repository freigeschaltet werden muss. Unter Linux ist dies wie folgt möglich.

cat ~/.ssh/id_rsa.pub | ssh git@puppet.enteksystems.local "cat >> ~/.ssh/authorized_keys"

Windows Benutzer müssen Ihren Public Key zunächst auf den Server kopieren und dort mittels cat in die Datei /home/git/.ssh/authorized_keys eintragen. Alternativ ist dieser Schritt auch mit einem Editor möglich, hier ist allerdings darauf zu achten, dass keine Zeilenumbrüche eingefügt werden.

Git Client

Jeder Administrator benötigt auf seinem lokalen Endgerät einen passenden Git Client. Für alle gängigen Plattformen stehen entsprechende Lösungen zur Verfügung. Windows Benutzer empfehlen wir hier die Verwendung von TortoiseGit als Frontend. Im ersten Schritt wird das zentrale Git Repository geklont.

git clone git://puppet.enteksystems.local/home/git/repos/puppet.git

Alle Anpassungen werden nun im lokalen Verzeichnis puppet.git vorgenommen (auch Working Copy genannt).

Testen von Änderungen

Die Tests von Änderungen werden immer zunächst lokal durch den Administrator durchgeführt. Für weitergehende Tests kann auch ein lokaler Puppetmaster aufgesetzt werden. Hierfür kann die offizielle Learning VM verwendet werden.

Sind die durchgeführten Änderungen funktionsfähig, können wir diese Committen. Dabei sollte immer eine sinnvolle Notiz hinzugefügt werden.

git commit -am "Deaktivierung von SSLv3 für Webserver"

Übermittlung an das Repository

Nachdem die Änderungen lokal committet wurden, können diese an das zentrale Repository übermittelt werden.

git push origin master

Change Management / Review

Vor der Produktivsetzung eines neues Changes sollte mindestens ein zweiter Administrator die durchgeführten Änderungen prüfen. Hierzu holt dieser sich die neuen Daten vom Repository.

git pull

Sind alle Änderungen in Ordnung, werden die Änderungen zunächst lokal mit unserem Produktivzweig zusammengeführt. Dazu wechseln wir zunächst in den production Branch.

git checkout production

und führen die Änderungen zusammen

git merge master

Abschließend werden die Änderungen wieder committet.

Produktivsetzung

Nachdem die Änderungen per merge zusammengeführt wurden, erfolgt die Übermittlung an das Repository. An dieser Stelle springt der von uns erstellte post-receive Hook ein und überspielt die Änderungen in das Produktivsystem.

git push origin production

Historie

Um die Git Historie anzuzeigen wird die Option log verwendet.

git log

Hier werden auch die eindeutigen IDs der Commits in Form eines SHA Hashes angezeigt.

Rollback

Funktioniert die neue Konfiguration nicht wie gewünscht, lassen sich die Änderungen zurückrollen. Hierzu aktualisieren wir wieder unsere lokale Working Copy und wechseln in den production Branch.

git pull
git checkout production

Im Anschluss machen wir den letzten Commit rückgängig und übermitteln die Änderungen an den Server.

git checkout HEAD~1
git commit -am "Rollback - Deaktivierung SSLv3"
git push origin master

Um zu einem bestimmten Stand zu springen (siehe Historie), verwenden wir den SHA Hash.

git checkout 07bc9054abfd8c599560026df2be8e100add75b0
git commit -am "Rollback - Deaktivierung SSLv3"
git push origin master