„Das Wiki ist wieder da!“ Und alle so …

[Julius]

Hallo Raketenwilli,

Außerdem kann man dann den Server einfach und schnell neu aufsetzen, bereits bestehende Automatisierungen wieder verwenden

Das wird „schwierig bin unmöglich“ sobald sich die Versionen der Software und Betriebssysteme ändern. Ich nenne mal die zahlreichen Unterschiede zwischen Apache 2.2/2.4, Python 2/3 und nicht zuletzt den Übergang von SystemV-init zu Systemd.

Natürlich muss man da Anpassungen vornehmen. Aber immerhin kann man einfach nachvollziehen, was die alte Konfiguration ist und diese in die neue Welt übertragen, ohne vorher Archäologie betreiben zu müssen.

Außerdem kann eine Wiederverwendung der Automatisierung bereits vor Ablauf des technischen Haltbarkeitsdatums erfolgen.

Vorliegend sind es 2 Server - ich denke wirklich, da mit ansible & co. drauf zu hauen macht die Sache viel zu aufwändig und mit Verlaub fehlerträchtig. In der Zeit, die ich brauchen würde um zahlreiche ansible-Konfigurations-Dateien anzupassen und neue Skripte zu schreiben konfiguriere ich ein paar Server mehr manuell bzw. mit copy & paste der Konfigfuration und benötigter Daten.

Da übertreibst du ein bisschen arg. Ich sehe in meinen minimalen Ansible-Anwendungen nur ein Inventory mit 5 Zeilen und (je nach Anwendung) n Playbooks.

Gerade dieses manuelle Kopieren ist extrem fehleranfällig. Wenn ich ein Ansible Playbook auf ein paar Server anwende, weiß ich, dass die Konfiguration auf den Servern exakt die selbe ist und keine Kopierfehler enthält. Und wenn nicht, führe ich das Playbook halt erneut aus.

Ein paar Pakete zu installieren, ein paar Konfigurationsdateien zu kopieren bzw. aus Templates zu bauen, ist mit Ansible wirklich kein Hexenwerk.

Außerdem erhalte ich völlig nebenbei die Vorteile von Infrastructure as code:

1. Sauber geschriebene Playbooks sind auch gleichzeitig die Dokumentation.
2. Dank 1.) weiß ich, dass meine Dokumentation auch tatsächlich dem Stand auf dem Server entspricht.
3. Ich kann das ganze in ein git-Repo werfen und so Änderungen nachvollziehen (vernünftige Commit-Messages mal vorausgesetzt).

oder Setups zu Testzwecken replizieren.

Dann versuche mal - zu Testzwecken - mit ansible einen identisch funktionierenden Was-auch-immer-Server mit RedHat(oder Rocky), einen mit Debian(oder Ubuntu) und einen mit OpenSuSE einzurichten und so an einen LDAP-Server zu hängen, dass deren PAM diesem vertraut. Wie „schnell“ wirst Du fertig?

Ich verstehe nicht ganz, worauf du hinauswillst. Wenn ich einen Produktiv-Server mit Distribution x in Version z habe, setzte ich zu Testzwecken natürlich auch genau auf diese, außer wenn ich die Migration zu Distribution y testen will.

Nur frage ich mich, ob es dafür z.B. wirklich ansible braucht, denn letztendlich kann man das mit einem simplen Skript auch anders, sehr viel einfacher, durchsichtiger und also weniger fehlerträchtig haben.

Wenn du dann anfängst, deine Skripte fehlertoleranter zu bauen oder idempotent zu bauen, fängst du an, Ansible nachzubauen.

Viele Grüße
Julius