09 — Infrastructure as Code

Teil D — Wie man betreibt. Zurück zur Übersicht.

In Kapitel 6 kam der Begriff schon vor: Eine Schneeflocke ist ein über Jahre von Hand gepflegtes System, das niemand mehr identisch nachbauen kann. Jede ist einzigartig, keine ist reproduzierbar.

Wie sie entsteht, kennt jeder:

2021-03  Server aufgesetzt, nach Anleitung im Wiki
2021-07  Paket nachinstalliert, weil etwas fehlte   (nicht dokumentiert)
2022-01  Kernel-Parameter angepasst, wegen Performance
2022-09  Zertifikat von Hand ersetzt                (Kollege war im Urlaub)
2023-04  Firewall-Regel ergänzt, "nur mal kurz zum Testen"
2024-11  Niemand traut sich mehr, das System neu zu starten

Die schleichende Abweichung zwischen dokumentiertem Sollzustand und tatsächlichem Ist-Zustand heißt Konfigurationsdrift. Sie ist die Ursache hinter dem Satz „auf der Abnahme läuft es aber„ — und sie wächst monoton, solange niemand eingreift.

Infrastructure as Code dreht das Verhältnis um: Nicht das System ist die Wahrheit, sondern das Repository. Weicht das System ab, wird es korrigiert — nicht die Dokumentation.

# Imperativ - der zweite Durchlauf hängt die Zeile erneut an
useradd conops
echo "conops ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers.d/conops

# Deklarativ - beliebig oft ausführbar
- name: Dienstbenutzer sicherstellen
  ansible.builtin.user:
    name: conops
    shell: /bin/bash
    state: present

- name: sudo-Regel sicherstellen
  ansible.builtin.copy:
    dest: /etc/sudoers.d/conops
    content: "conops ALL=(ALL) NOPASSWD:ALL\n"
    mode: "0440"
    validate: /usr/sbin/visudo -cf %s

Die Eigenschaft, dass ein wiederholter Durchlauf nichts verändert, heißt Idempotenz. Sie ist der Kern der Sache: Nur so kann man den Automatismus regelmäßig laufen lassen und Drift damit aktiv beseitigen, statt ihn nur zu dokumentieren.

In der Praxis kombiniert man: Terraform erzeugt die virtuellen Maschinen, Netze und Speicher; Ansible richtet die Betriebssysteme ein; Container bringen die Anwendungen. In einer reinen Rechenzentrumsumgebung ohne Cloud-Anteil fällt die erste Ebene oft weg oder wird von der Virtualisierungsplattform übernommen.

Für den Rest dieses Kapitels bleiben wir bei Ansible, weil es ohne Agenten, ohne Server und ohne Zustandsdatei auskommt — und weil es in RHEL-Umgebungen ohnehin der Standard ist. Die ausführliche Behandlung findest du in der Ansible-Unterlage dieses Wikis; hier geht es nur um die Einordnung in den DevOps-Zusammenhang.

Werkzeuge wie Terraform führen eine Zustandsdatei, die den zuletzt hergestellten Stand festhält. Daraus ergibt sich ein mächtiges Werkzeug: der Abgleich von Soll und Ist.

terraform plan            # Was würde sich ändern? Ändert nichts.
ansible-playbook site.yml --check --diff

Die Zustandsdatei bei Terraform ist gleichzeitig ein empfindlicher Punkt: Sie enthält oft Geheimnisse im Klartext und darf niemals ins Git-Repository. Sie gehört in einen Objektspeicher mit Verschlüsselung und Sperrmechanismus.

Der unveränderliche Ansatz ist der konsequentere: Statt einen Server zu patchen, baut man ein neues Abbild und tauscht ihn aus. Genau das machen Container ohnehin, weshalb sie und IaC so gut zusammenpassen.

In gewachsenen Umgebungen mit Datenbankservern und Altanwendungen bleibt der veränderliche Ansatz aber die Realität — und dort ist regelmäßige, idempotente Konfigurationsverwaltung das nächstbeste Mittel.

Zugangsdaten gehören nicht ins Repository — auch nicht in eine Ansible-Variablendatei.

ansible-vault encrypt_string 'GeheimesPasswort' --name 'db_passwort'

Bewährt hat sich die Trennung in eine unverschlüsselte Datei mit sprechenden Variablennamen und eine verschlüsselte mit den Werten. So bleibt im Klartext sichtbar, welche Geheimnisse existieren, ohne ihren Inhalt preiszugeben.

Beschreibungen von Infrastruktur sind Code — also gelten die Regeln aus Kapitel 4.

# Molecule: Rolle in einem Container prüfen, inklusive Idempotenz
molecule test

Der Idempotenztest von Molecule ist dabei der wertvollste Teil: Er führt die Rolle zweimal aus und schlägt fehl, wenn der zweite Lauf Änderungen meldet.

roles/kfz_host/tasks/main.yml

---
- name: Distributionsspezifische Variablen laden
  ansible.builtin.include_vars: "{{ ansible_facts['os_family'] }}.yml"

- name: Erforderliche Pakete installieren
  ansible.builtin.package:
    name: "{{ kfz_pakete }}"
    state: present

- name: Dienstbenutzer anlegen
  ansible.builtin.user:
    name: "{{ kfz_benutzer }}"
    shell: /bin/bash
    create_home: true
    state: present

- name: Lingering aktivieren, damit Container ohne Anmeldung laufen
  ansible.builtin.command: "loginctl enable-linger {{ kfz_benutzer }}"
  args:
    creates: "/var/lib/systemd/linger/{{ kfz_benutzer }}"

- name: Verzeichnis für Quadlet-Units anlegen
  ansible.builtin.file:
    path: "/home/{{ kfz_benutzer }}/.config/containers/systemd"
    state: directory
    owner: "{{ kfz_benutzer }}"
    group: "{{ kfz_benutzer }}"
    mode: "0755"

- name: Unprivilegierte Ports ab 80 freigeben
  ansible.posix.sysctl:
    name: net.ipv4.ip_unprivileged_port_start
    value: "80"
    sysctl_file: /etc/sysctl.d/99-rootless.conf
    state: present
    reload: true

- name: Datenverzeichnis anlegen
  ansible.builtin.file:
    path: "{{ kfz_datenverzeichnis }}"
    state: directory
    owner: "{{ kfz_benutzer }}"
    group: "{{ kfz_benutzer }}"
    mode: "0750"

- name: SELinux-Kontext für Containerdaten setzen
  community.general.sefcontext:
    target: "{{ kfz_datenverzeichnis }}(/.*)?"
    setype: container_file_t
    state: present
  when: ansible_facts['os_family'] == 'RedHat'
  notify: SELinux-Kontext anwenden

- name: Firewall für HTTPS öffnen
  ansible.posix.firewalld:
    service: https
    permanent: true
    immediate: true
    state: enabled
  when: ansible_facts['os_family'] == 'RedHat'

- name: Quadlet-Unit ausbringen
  ansible.builtin.template:
    src: kfz-rechner.container.j2
    dest: "/home/{{ kfz_benutzer }}/.config/containers/systemd/kfz-rechner.container"
    owner: "{{ kfz_benutzer }}"
    mode: "0644"
  notify: Container neu starten

roles/kfz_host/handlers/main.yml

---
- name: SELinux-Kontext anwenden
  ansible.builtin.command: "restorecon -Rv {{ kfz_datenverzeichnis }}"

- name: Container neu starten
  ansible.builtin.systemd_service:
    name: kfz-rechner.service
    state: restarted
    daemon_reload: true
    scope: user
  become: true
  become_user: "{{ kfz_benutzer }}"

Aufgaben:

1. Führe das Playbook zweimal aus. Der zweite Lauf muss changed=0 melden.
2. Verändere von Hand etwas auf dem Server — etwa die Firewall-Regel. Lass das Playbook mit –check –diff laufen. Es muss die Abweichung finden.
3. Lösche die virtuelle Maschine und baue sie aus dem Playbook neu auf. Stoppe die Zeit.
4. Ergänze eine Prüfung, die sicherstellt, dass der Dienst nach dem Durchlauf tatsächlich antwortet.
5. Baue das Playbook in die Pipeline aus Kapitel 7 ein — zunächst nur mit –check.

Welcher Server in deiner Umgebung würde dir die meisten Sorgen bereiten, wenn er heute Nacht ausfiele — und warum ausgerechnet dieser?

Die Antwort benennt fast immer eine Schneeflocke. Und damit auch das erste sinnvolle Ziel für Infrastructure as Code.

Weiter mit Kapitel 10 — Container und Orchestrierung