Infrastruktur-Zuständigkeit und IaC

Opfield ist für die Dienstebene zuständig: Nodes, Routen, Zertifikate, Workloads, Datenbanken, Backups, Monitoring und Berechtigungen. Die Ebenen darunter – Anbieterkonten, Netzwerke und das Host-Betriebssystem – werden von Hand, mit Terraform, OpenTofu oder Ansible oder von Opfield selbst über eine Integration mit einem Hosting-Anbieter erstellt.

Die einfache Regel lautet: eine Ressource, ein Eigentümer. Zwei Systeme können dieselbe Ressource beobachten, sie sollten sie aber nicht beide fortlaufend überschreiben.

Wer für welche Ebene zuständig ist

Ebene	Typischer Eigentümer	Beispiele
Anbieter-Fundament	Terraform, OpenTofu, Cloud-Konsole oder Opfield-Hosting-Integrationen	Netzwerke, virtuelle Maschinen, Firewalls, DNS-Zonen, Backup-Ziele
Host-Basis	Ansible, Image-Pipeline oder Host-Team	Betriebssystem, Benutzer, Kernel-Richtlinien, Docker-Installation, Festplatten, Endpoint Security
Dienstebene	Opfield	Nodes, Routen, Zertifikate, Workloads, Compose-Projekte, verwaltete Datenbanken und Speicher, Bindings, Backups, Metriken, Logs, Alarme, Berechtigungen, Betriebsverlauf
Release-Absicht der Anwendung	Quellcodeverwaltung und Opfield	Repository-Revision, Build, Artefakt, Deployment, Rollback
Externe Kopien	Speicher außerhalb der Installation	externe Backup-Kopien; ein SIEM, wenn Ihre Compliance-Regeln eine Aufbewahrung des Audits außerhalb von Opfield verlangen

Ein kleines Team erstellt Hosts von Hand oder über eine Hosting-Integration und überlässt Opfield alles oberhalb des Betriebssystems. Eine größere Organisation erstellt Hosts mit Terraform und registriert jeden einzelnen, nachdem seine Sicherheitsprüfungen bestanden sind.

Zuständigkeit vor dem Import festlegen

Bevor Sie eine bestehende Ressource in Opfield übernehmen, halten Sie fest:

1. welches System sie ändern darf;
2. welches System sie nur beobachten darf;
3. wo ihre maßgebliche Quelle liegt;
4. wer Notfalländerungen genehmigt;
5. wie eine Notfalländerung anschließend abgeglichen wird.

Wenn zum Beispiel Terraform für einen DNS-Eintrag zuständig ist, konfigurieren Sie Opfield nicht zusätzlich so, dass es denselben Eintrag fortlaufend überschreibt. Behalten Sie DNS entweder in Terraform und lassen Sie es auf eine von Opfield verwaltete Route zeigen, oder übertragen Sie den Lebenszyklus dieses Eintrags bewusst an Opfield und entfernen Sie ihn aus dem Terraform-State.

Geteilte Zuständigkeit vermeiden

Geteilte Zuständigkeit erzeugt Abweichungen: Ein Werkzeug wendet eine gültige Änderung an, ein anderes sieht einen unerwarteten Wert und setzt ihn zurück. Das Ergebnis kann zufällig wirken, obwohl sich beide Systeme so verhalten, wie sie konfiguriert sind.

Häufige Konflikte sind:

• Terraform und Opfield verwalten beide denselben DNS-Eintrag;
• Ansible und Opfield ersetzen beide dieselbe nginx-Konfiguration;
• ein Host-Skript startet Container neu oder löscht Container, die einem Opfield-Deployment oder Compose-Projekt gehören;
• ein externes Datenbankwerkzeug ändert Benutzer, die für ein von Opfield verwaltetes Binding erstellt wurden;
• eine CI-Pipeline stellt denselben Workload bereit, den auch Opfield baut und bereitstellt.

Wenn zwei Systeme denselben Bereich berühren müssen, teilen Sie ihn durch eine ausdrückliche Grenze. Terraform kann für die VM und die Firewall zuständig sein, während Opfield für die Anwendungen in dieser VM zuständig ist. Ansible kann für die Docker-Installation zuständig sein, während Opfield für die Docker-Ressourcen zuständig ist. Ein externes Backup-System kann eine Datenbank lesen, während Opfield für ihren Dienst-Lebenszyklus zuständig ist.

Manuelle Notfalländerungen

Während eines Vorfalls kann eine direkte Änderung am Host die sicherste Maßnahme sein. Behandeln Sie sie als vorübergehende Ausnahme:

1. Halten Sie Ressource, Befehl oder Einstellung, Operator, Zeitpunkt und Grund fest.
2. Pausieren Sie die Automatisierung, die die Änderung überschreiben könnte.
3. Stellen Sie den Dienst für Kunden wieder her und sichern Sie Belege.
4. Entscheiden Sie, ob Opfield oder die externe maßgebliche Quelle den neuen Zustand übernehmen soll.
5. Gleichen Sie bewusst ab und entfernen Sie die vorübergehende Ausnahme.

Lassen Sie eine erfolgreiche Notfallkorrektur nicht als undokumentierte dauerhafte Abweichung bestehen. Das nächste routinemäßige Deployment könnte sie sonst rückgängig machen.

Umzug zu Opfield

Ziehen Sie eine Ressourcenfamilie nach der anderen um: Ingress, Workloads, Datenbanken, Backups, Monitoring. Übertragen Sie für jede die Zuständigkeit ausdrücklich, entfernen Sie sie aus dem alten Werkzeug und weisen Sie ihren Wiederherstellungsweg nach, bevor Sie zur nächsten übergehen. Ihren Stack zu Opfield umziehen gibt die Reihenfolge und die Prüfung für jeden Schritt vor.