Ansible playbook to manage WTF Kooperative eG Server

This is a ansible playbook to setup the servers from the WTF Kooperative eG.

Have a look into hosts.ini to see all hosts who will be managed by this role.

Tipps und Tricks:

Submodule

Dieses Ansible verwendet git submodule. Vergesst nicht diese regelmäßig mit auszuchecken!

git config submodule.recurse true
git submodule update --init --recursive

Weitere Informationen zu git Submodulen.

Abhängigkeiten

Die verwendeten Collections sind in der Datei requirements.yml definiert. Installiere sie mit dem Befehl ansible-galaxy install -r requirements.yml.

Die Rollen liegen meist als Git-Submodul vor. Als Versuch werden neue Rollen ebenso über die requirements.yml gepflegt und mit obigem Befehl installiert. Einzelne WTF-eigene Rollen, die keinen Wert für Außenstehende haben, werden direkt in diesem Repository gepflegt.

Neue commits auf den main Branch

🔒 Der main-Branch ist geschützt, das heißt, dass Commits nicht direkt gepusht werden können. Das hat den Grund, dass der main-Branch immer funktionsfähig bleiben muss.

Deshalb müssen Änderungen über einen Pull Request vorgenommen werden. Erstelle dazu einen Branch, auf dem du die Änderungen vornimmst:

# create new branch test
git checkout -b test

# now commit your changes

# push your changes and create a test branch at the server
git push origin test

# create a Pull-Request via gitea UI

Triviale Änderungen können selbst gemergt werden. Bei komplexeren Änderungen oder komplett neuen Dingen ist ein Review vor dem Merge dringend empfohlen.

✅ You merge, you deploy: Damit der main-Branch immer den status quo widerspiegelt, bitte nach jedem Merge die Änderungen auf die betroffenen Systeme ausrollen.

Pull the latest changes from main before running ansible

Do not run a old ansible config.

Der derzeitige main branch sollte stets in der Lage sein ausgeführt zu werden ohne etwas kaputt zu machen.

Es kann daher hilfreich sein, wenn man vor hat an bestehenden Servern viel zu ändern, diese vorher im main ansible zu überspringen damit nichts kaputt geht!

variabeln und vault

In diesem Repo werden geheime variabeln in einem ansible vault gespeichert. Das vault befindet sich im gopass und sollte lokal als .vault entschlüsselt vorliegen! (gopass show wtf-eg/ag-admin/secrets/ansible_playbook_server.vault > .vault) Best practise und weitere Infos zum ansible vault gibt es u.a. auf docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html. Infos zu GoPass auf gopass.pw.

Um Veränderungen an vault-Dateien in Diffs leichter nachvollziehen zu können, muss folgende Config gesetzt werden:

git config diff.ansible-vault.textconv "ansible-vault view"
git config diff.ansible-vault.cachetextconv false

Ort der variablen

Zur Erinnerung: Variabeln werden in group_vars für Gruppen von Servern und host_vars für die einzelnen Server aus dem Inventory (hosts.ini) gespeichert. Eine Gruppen-variabel überschreibt die default Werte aus den ansible rollen. Eine host-variabel kann das auch. Sie überschreibt aber auch die Rruppen variabel.

Für die bedeutung der einzelnen variabeln bitte in den jeweiligen READMEs der git Submodule nachlesen!

Neuen Server hinzufügen

Der Standard User für dieses ansible hier lautet ansible. Da das aber nicht immer so auf neuen Servern gegeben ist kann man sich da auch aushelfen. Im Nachfolgenden ist ein Beispiel für den Fall das du die variablen alle für den neuen Server gesetzt hast. Und dein ssh public Key bei user root eingetragen ist:

ansible-playbook site.yml -u root --limit neuer-server.example.com --tags init

Achtung. Die sshd rolle würfelt beim initialen Setup bei bedarf neue ssh host keys. Womöglich musst du deine lokale ~/.ssh/known_hosts dann nochmal anpassen!

Übrigens bei neuen Servern sollte man auch darauf auchten, das die Hostnamen der Schemata.md entsprechen ;-)

Unklarheiten

Bei Fragen zu diesen Ansible öffne gerne ein Issue oder Lade L3D auf einen Tschunk ein um über das ansible zu reden und es genauer zu verstehen.