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.
1 2 3 | 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.
1 2 3 | 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.
1 |
Übermittlung an das Repository
Nachdem die Änderungen lokal committet wurden, können diese an das zentrale Repository übermittelt werden.
1 2 3 | 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.
1 2 3 | 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.
1 2 3 | git checkout production |
und führen die Änderungen zusammen
1 2 3 | git merge master |
Abschließend werden die Änderungen wieder committet.
1 |
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.
1 2 3 | git push origin production |
Historie
Um die Git Historie anzuzeigen wird die Option log verwendet.
1 2 3 | 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.
1 2 3 4 5 | git pull git checkout production |
Im Anschluss machen wir den letzten Commit rückgängig und übermitteln die Änderungen an den Server.
1 2 3 4 5 6 7 | 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.
1 2 3 4 5 6 7 | git checkout 07bc9054abfd8c599560026df2be8e100add75b0 git commit -am "Rollback - Deaktivierung SSLv3" git push origin master |