Bei Git handelt es sich um ein aus der Softwarentwicklung bekanntes verteiltes Versionsverwaltungstool. Hiermit lassen sich verschiedene Versionsstände von Textdateien verwalten und die Historie erfassen.
Um Änderungen an den Puppet Manifesten jederzeit nachvollziehen zu können und bei Bedarf wieder auf die letzte Version zurückkehren zu können, ist eine Versionsverwaltung vor allem in größeren Umgebungen zu empfehlen.
Im ersten Schritt installieren wir die notwendigen Pakete.
1 2 3 4 5 | apt-get install git # Ubuntu / Debian yum install git # RedHat / CentOS |
Anschließend erstellen wir einen neuen Benutzer git
auf dem System über den die Administratoren später Änderungen einreichen können.
1 2 3 | adduser git |
Um später an das Git Verzeichnis Pushen zu können, muss der eigene Public Key zu der Datei authorized_keys
hinzugefügt werden. Hierzu wechseln wir zunächst zum git Benutzer.
1 2 3 4 5 | su git mkdir ~/.ssh && touch ~/.ssh/authorized_keys |
Auf unserem lokalen System übertragen wir jetzt den Key an den Server:
1 2 3 | cat ~/.ssh/id_rsa.pub | ssh git@puppet.enteksystems.local "cat >> ~/.ssh/authorized_keys" |
Im Anschluss legen wir ein neues Verzeichnis für die Repositories an
1 2 3 | mkdir /home/git/repos |
und erstellen eine neues Repository für unsere Puppet Module.
1 2 3 | git init --bare /home/git/repos/puppet.git |
Als Nächstes setzen wir die Git Hooks auf. Hierbei handelt es sich um Skripte, welche z.B. beim Übermitteln von Änderungen an das Git Repository (= Push) ausgeführt werden. In unserem Fall erfüllen die Hooks zwei grundlegende Funktionen.
Alle notwendigen Git Hooks stehen im GitHub Repository von David Wahlstrom zur Verfügung. Da einige Hooks noch weitere Skripte benötigen, laden wir das gesamte Repository herunter.
1 2 3 4 5 | cd /tmp git clone https://github.com/drwahl/puppet-git-hooks.git |
Im ersten Schritt kopieren wir die benötigten Skripte in unser Git Repository.
1 2 3 | cp -r /tmp/puppet-git-hooks.git/commit-hooks /home/git/repos/puppet.git/hooks/ |
Zunächst konfigurieren wir den pre-commit
Hook. Hierzu wechseln wir in das Verzeichnis /home/git/repos/puppet.git/hooks
und kopieren die Hook Datei bzw. machen sie anschließend ausführbar. Hiermit wird der Code bereits clientseitig beim Commit auf evtl. Fehler geprüft.
1 2 3 4 5 | cp -r /tmp/puppet-git-hooks.git/pre-commit ./ chmod +x pre-commit |
Im nächsten Schritt erfolgt die Installation des pre-receive
Hooks. Dieser prüft den Code vor dem Pushen (Übermitteln) an das Puppet Repository und stellt damit die zweite Prüfungsinstanz dar.
1 2 3 4 5 | cp -r /tmp/puppet-git-hooks.git/pre-receive ./ chmod +x pre-commit |
Den post-receive
Hook verwenden wir zum Deployment des geprüften Codes in die Produktivumgebung. Hier kommt eine angepasste Implementierung aus unserem FoxPlex Blog zum Einsatz.
1 2 3 | nano post-receive |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | #!/bin/bash while read oldrev newrev refname do branch=$(git rev-parse --symbolic --abbrev-ref $refname) if [ "$branch" == "production" ]; then # Production echo "Pushing to production" mkdir /tmp/production GIT_WORK_TREE=/tmp/production git checkout production -f rsync -ruvz /tmp/production/ /etc/puppet/environments/production/ rm -rf /tmp/production rm -rf /tmp/rsync; fi done |
1 2 3 | chmod +x post-receive |
production
nach der Übermittlung an unser Puppet Repository in das Puppet Verzeichnis eingespielt und somit produktiv gesetzt. Änderungen, welche im Standardbranch master
oder anderen Branches erfolgen werden nicht automatisch in die Produktivumgebung eingespielt.Der Rsync Befehl kann z.B. auch durch SCP ersetzt werden, wenn das Git Repository nicht auf dem Puppet Master liegt.