Teil 1 der Artikelserie über die Automatisierung mit Ansible.
Vorwort
Versionskontrolle ist bei der Automatisierung von Vorgängen von grundlegender Bedeutung. Wie bei der Softwareentwicklung ist es wichtig, Änderungen nachvollziehen zu können. Daher auch der Begriff “DevOps”, von Development ((Software-)Entwicklung) und Operations ((ICT-)Betrieb).
Stell dir vor, ein “Automatisierung-Rezept”, im Umgang mit Ansible “Playbook” genannt, verändert sich. Vielleicht hast Du es geändert und weisst es nicht mehr, vielleicht ein Kollege, vielleicht ein Angreifer…
Du weisst nun nicht mehr, wie es vorher aussah. Was tun? Neu Entwickeln? Nein. Du wirst es niemals ein zweites mal exakt so hinbekommen wie beim ersten mal.
Wenn Dir ein Automat eine Aufgabe abnimmt ist es wichtig, dass Du zu jeder Zeit weisst, was der Automat gemacht hat. Schliesslich bist Du in der Verantwortung und nicht die “nicht-menschliche Entität”.
Der Ubuntu-Server
Wie benötigen einen Ubuntu-Server. Die Installation möchte ich hier nicht beschreiben, die ist im offiziellen Handbuch bestens erklärt.
Pro Server empfehle ich mindestens 3 dedizierte Disks:
Disk 1: /boot (64MB)Seit Ubuntu 18.04 nicht mehr machbar.- Disk 2: / (16GB)
- Disk 3: swap (1GB)
Es ist wesentlich einfacher, ein Partitionen zu vergrössern, wenn sie alle auf dedizierten Disks liegen. In virtualisierten Umgebungen ist es sowieso nicht best-practice, mehr als eine Partition auf eine virtuelle Disk zu legen.
Der Ubuntu-Server soll lediglich die Rolle “OpenSSH Server” erhalten. Seit Ubuntu 18.04 gibt’s diesen Dialog nicht mehr.
Gitolite3 installieren
Für die Verwaltung der Git-Reporitories werden wir gitolite3 verwenden. Dies lässt sich auf dem Ubuntu-Server folgendermassen installieren:
root@s-001-0021:~# apt install gitolite3
Die Installation ist unbedingt remote per SSH durchzuführen und nicht an einer interaktiver Session am Server, denn während der Installation muss der SSH public key des Administrators angegeben werden. Diesen korrekt abzutippen ist reine Strafarbeit.
Ein bereits bestehender public key kann selbstverständlich verwendet werden, wie ein Neuer erstellt wird, erfährst Du im folgenden Kapitel.
Git installieren und SSH-Schlüsselpärchen erstellen [Linux]
root@s-001-0021:~# ssh-keygen
Falls gewünscht kann dem neuen Schlüssel bei der Frage “Enter passphrase (empty for no passphrase):” ein Kennwort zugewiesen werden. Sehr empfehlenswert – und bitte nicht vergessen.
root@s-001-0021:~# apt install git
Git installieren und SSH-Schlüsselpärchen erstellen [Windows]
Git für Windows kann man auf der Website git-scm.com beziehen.
Die Installation ist simpel, ich empfehle an den folgenden Dialogen vom Voreingestellten Wert abzuweichen:
Nun kann über das Kontextmenü eines beliebigen Ordner mit “Git Bash” eine Kommandozeile geöffnet werden, in welcher Das SSH-Schlüsselpärchen generiert werden, genau wie unter Linux:
Administrator@hostname MINGW64 ~/Desktop/git $ ssh-keygen
Das ist kein Zufall, Git für Windows baut auf Mingw auf, einem Projekt, welches viele Linux-Werkzeuge für Windows bereitstellt.
Mit dem folgenden Befehl lässt sich der Schlüssel anzeigen:
root@s-001-0021:~# cat ~/.ssh/id_rsa.pub
Gitolite konfigurieren
Alle meine Git-Repos bearbeite ich gerne in einem Ordner namens “git”:
s-001-0003 ~ # mkdir git s-001-0003 ~ # cd git
Gitolite3 wird über ein eigenes Git-Repository konfiguriert. Dieses wird geklont:
s-001-0003 ~/git # git clone \ gitolite3@s-001-0021:gitolite-admin.git
Folgende Ordnerstruktur wurde ab dem Server geklont:
./gitolite-admin ./gitolite-admin/keydir ./gitolite-admin/keydir/admin.pub ./gitolite-admin/conf ./gitolite-admin/conf/gitolite.conf
Nun wird ein neues Git-Repository erstellt, dazu wird die Datei ./gitolite-admin/conf/gitolite.conf wie folgt editiert:
repo gitolite-admin
RW+ = admin
repo ansible-WindowsServerManagement
RW+ = admin
Die erste Zeile definiert den Namen des Repository, die folgende Zeile(n) die Berechtigungen. In diesem Fall erhält der Benutzer “admin” die Rechte “RW+”.
Ein Benutzer wird über einen SSH Public Key im Verzeichnis ./gitolite-admin/keydir/<<benutzername>>.pub identifiziert.
Weitere Informationen über die Konfiguration von Gitolite findet sich auf dessen Website.
Die Änderungen müssen nun der Versionskontrolle hinzugefügt und wieder an den Server gepusht werden:
s-001-0003 ~/git # cd gitolite-admin/ s-001-0003 ~/git/gitolite-admin # git commit -a \ -m "Created repository 'ansible-WindowsServerManagement'"
Mit “git commit” wird signalisiert, die Änderungen in die Versionskontrolle aufzunehmen, der Parameter “-a” nimmt alle geänderten oder entfernten Dateien mit und “-m” gefolgt von einem Kommentar in Anführungs- und Schlusszeichen definiert den Kommentar zu diesem Commit.
Jeder Commit muss kommentiert werden. Es empfiehlt sich, vernünftig zu kommentieren.
Aufgrund seiner dezentralen Architektur sind die Änderungen nur in der lokalen Kopie des Repository verfügbar. Dieses wird nun noch auf den Server gepusht:
s-001-0003 ~/git/gitolite-admin # git push
Der Server meldet sich nun damit, dass er die Änderungen empfangen und das neue Repository angelegt hat:
Zähle Objekte: 4, Fertig. Komprimiere Objekte: 100% (3/3), Fertig. Schreibe Objekte: 100% (4/4), 426 bytes | 213.00 KiB/s, Fertig. Total 4 (delta 0), reused 0 (delta 0) remote: Initialized empty Git repository in /var/lib/gitolite3/repositories/ansible-WindowsServerManagement.git/ To 10.10.7.56:gitolite-admin.git 15a57b9..348cd48 master -> master
Damit sind wir am Ende des 1. Teil. Weiter geht’s demnächst mit dem Bau der Zertifizierungsstelle.