The Operations Loop — Mit der Serverinstallation beginnt der Betrieb

AI_Manager

Die Installation eines einzelnen Servers ist nur ein Teil der Betriebsvorbereitung. Erst wenn geklärt ist, wer ihn in welcher Umgebung bereitgestellt hat, welche Software ausgeführt wird, wie zugegriffen werden muss und wie Fehler erkannt und behoben werden, wird ein Server betriebsbereit.

Dieses Projekt ist eine Infrastrukturübung, die von der Installation des Rocky Linux-Servers über die Basiskonfiguration, detaillierte Asset-Registrierung und automatisierte Inventaraktualisierung bis hin zum Empfang tatsächlicher Monitoring-Messwerte alles miteinander verbindet. Auf Basis von Oracle VirtualBox wurden ein zentrales Betriebsnetzwerk sowie PROD, DEV und STG unterteilt und Zabbix, NetBox, AWX, Git sowie PXE zu einem einzigen Betriebsablauf konfiguriert.

Die Übungsumgebung besteht aus VMs auf einem einzigen PC. Es handelt sich hierbei um eine Umgebung zum Testen von Dienst- und VM-Ausfällen; es ist kein Betriebssystem mit redundanten physischen Hosts oder Speichern. Die Validierungsergebnisse werden basierend auf den Job-IDs, Zeitstempeln und Beobachtungswerten eines separaten Validierungsprojekts unterschieden.

• 1. Projektübersicht
• 2. Zu lösende Betriebsprobleme
• 3. Serverkonfiguration und Netzwerk
• 4. Der Prozess der Integration eines Servers in den Betrieb
• 5. Wie die beigefügten Asset-Erfassungs-YAMLs übernommen wurden
• 6. Warum so konzipiert wurde
• 7. Fehlerszenarien und die Grenzen der Verfügbarkeit
• 8. Betrieb unter Berücksichtigung von Online- und isolierten Netzwerken
• 9. In diesem Projekt demonstrierte Kompetenzen
• 10. Weiterführende Lektüre und technische Grundlagen
• Empfohlene Lektüre und Konfigurationsmaterialien

1. Projektübersicht

Als Abschlusskriterium galt nicht die erfolgreiche Installation einzelner Werkzeuge, sondern die Frage, ob der Bezeichner und die Verwaltungs-IP eines Servers über Installation, Asset-Verwaltung, Automatisierung und Monitoring hinweg übereinstimmen. Selbst wenn eine API den Status 200 zurückgibt, wird das Onboarding nicht als erfolgreich gewertet, wenn das Ziel im Inventar fehlt oder keine aktuellen Zabbix-Werte einlaufen.

Das tatsächliche Onboarding für die drei Ziele PROD, DEV und STG wurde abgeschlossen. In AWX Workflow 22, 30 und 38 waren die Registrierung von Assets, die Aktualisierung des Inventars sowie die Überprüfung aktueller Monitoring-Werte erfolgreich. Auch der beidseitige Stromausfall des zentralen Knotens, die Unterbrechung der Proxy-Übertragung mit Wiederherstellung verzögerter Daten, die Abweisung von Asset-Konflikten und die separate Datenbank-Wiederherstellung wurden getestet. Die Bedingungen für die jeweiligen Erfolge und der nicht verifizierte Bereich sind im Verifizierungsartikel festgehalten.

2. Zu lösende Betriebsprobleme

Wenn OS-Installation, Aktualisierung des Excel-Asset-Verzeichnisses, Hinzufügen von Ansible-Hosts und Monitoring-Registrierung getrennt voneinander durchgeführt werden, kommt es zu Auslassungen und Abweichungen. Es kann vorkommen, dass eine neu installierte Serverinstanz bestehende Assets überschreibt, eine NAT-Adresse als Verwaltungs-IP registriert wird oder im Monitoring zwar ein Host vorhanden ist, aber keine Daten vorliegen.

Um dies zu reduzieren, werden freigegebener Hostname, Umgebung und Verwaltungs-IP als Eingabegrundlage festgelegt und mit den tatsächlich vom Gast ausgelesenen Werten für Hostname, Machine ID und Schnittstellen abgeglichen. In NetBox wird nicht nur eine IP als Zeichenkette hinterlegt, sondern es werden die Beziehungen VM/Device → Interface → IPAddress → primary_ip4 erstellt, und AWX ruft das Inventar über diese Beziehungen ab. Bei einer erneuten Registrierung werden die bisherigen Kennungen und die zuständige Verwaltungseinheit überprüft.

Die zweite Herausforderung besteht darin, den Ausfallumfang klar zu definieren. Die bloße Existenz von zwei Zabbix-Servern bedeutet noch keine HA bis hinunter zur Datenbank. Auch bei zwei NetBox-Web-Instanzen müssen PostgreSQL, Redis, gemeinsam genutzte Medien und die Zugriffsadresse koordiniert funktionieren, um einen Nutzen zu haben. Die Umschaltbedingungen und verbleibenden Single Points of Failure für jede Schicht wurden separat gekennzeichnet.

Interaktive Architektur — Gesamtstruktur und Betriebsablauf

3. Serverkonfiguration und Netzwerk

Der physische PC ist mit Windows 11 Pro, Intel Core Ultra 9 185H (16 Kerne / 22 logische Prozessoren), ca. 31,4 GiB verfügbarem Arbeitsspeicher und einer 2TB-SSD ausgestattet. Den VMs wird nur der jeweils benötigte Arbeitsspeicher zugewiesen, und PXE-Installationsziele werden nacheinander ausgeführt. Ziele, die während der Installation 4 GiB benötigen, werden danach auf 1 GiB reduziert.

Im Hostnamen steht ops für den operativen Dienst, quorum für die Fehlererkennung, edge für den Umgebungseinstiegspunkt und provision für die Installationsbasis. Der vom Betriebssystem erkannte FQDN lautet 호스트명.fullmoon.test. Die Domain für öffentliche Websites und das Übungs-DNS wurden voneinander getrennt.

An PXE-Ziele in den jeweiligen Umgebungen werden keine NAT- oder Bridge-NICs angeschlossen. SSH-Verbindungen von der Zentrale zum Zielserver laufen über das Bastion-Host der jeweiligen Umgebung. Die Kommunikation zwischen den Umgebungen ist standardmäßig blockiert, und notwendige Quellen, Ziele sowie Ports werden explizit angegeben. Das NAT der für den initialen Paketimport verwendeten Verwaltungs-VM und die internen Pfade für Dienste werden im Build-Log separat behandelt.

4. Der Prozess der Aufnahme eines Servers in den Betrieb

Keine Administrator-Passwörter von NetBox auf Remote-Servern hinterlegen. Die Remote-Erfassung wird im erforderlichen Umfang mit Administratorrechten ausgeführt, und API-Anfragen erhalten ihre Zugangsdaten durch Injektion aus der AWX Execution Environment. SSH-private Schlüssel werden nicht auf das Bastion-Host kopiert.

Das automatische Hinzufügen von Inventaren in AWX ist eine implementierbare Funktion. Das offizielle Ansible Inventory Plugin von NetBox wurde als SCM-Inventarquelle eingebunden, und der Workflow wurde so konfiguriert, dass er nach erfolgreicher Registrierung die Inventarsynchronisierung und Validierungsaufgaben nacheinander ausführt. Für das NetBox-Token wurden die Zwecke des Asset-Schreibens und des Inventarlesens getrennt.

Die Verbindung nach PXE übernimmt der zentrale Installationsabschluss-Controller. Nach der Verifizierung des genehmigten SSH-Host-Keys, der Installationsabschlussmarkierung, des Hostnamens und der Maschinen-ID wird der entsprechende Server-Workflow gestartet. Die erste Verifizierung der Serveridentität bleibt als Bestätigungsschritt für den Administrator erhalten, und nach der Genehmigung werden Asset-, Inventar- und Monitoring-Registrierung nacheinander ausgeführt. Wenn sich die Maschinen-ID durch eine Neuinstallation ändert, wird sie anstelle eines automatischen Überschreibens zur Überprüfung belassen.

5. Wie die YAML-Datei zur Erfassung der angehängten Assets übernommen wurde

Das angehängte YAML ist kein einfacher Hostname-Registrar. Es handelt sich um ein Asset-Verzeichnis, das als Ausgangspunkt laufende Linux-Prozesse und /proc-Informationen nutzt, um Betriebssystem, CPU, Festplatten, Netzwerk, Produkte, Virtualisierung und Spuren von Backup-Agenten zu erfassen. Diese Absicht wurde beibehalten und es wurden vier Einträge zu den 34 ursprünglichen benutzerdefinierten Feldern hinzugefügt: Erfassungsstatus, Zeitpunkt, Fehler und Maschinen-ID.

Die ursprünglichen Regeln zur Bestimmung von Standortadresse, Site und Umgebung wurden durch die expliziten Inventarvariablen PROD/DEV/STG dieses Übungsbeispiels ersetzt. Wo zuvor nur primary_ipv4-Zeichenfolgen gespeichert wurden, wurden native NetBox-IPAM-Beziehungen hinzugefügt. Bisher genehmigte Site-, Rollen-, Plattform- und Benutzer-Tags werden nicht bedingungslos durch die Erfassungsergebnisse ersetzt.

Die Versionserkennung wurde nicht für jede kommerzielle DB/WAS durch eine Installationsüberprüfung verifiziert. Die Eigentümerschaft von ausführbaren Dateien, Zulassungslisten (Whitelists) und Namespaces werden überprüft, und unklare Startskripte werden nicht als root ausgeführt. Nicht verifizierte Versionen verbleiben als unbestätigt. Die Erfassung von Produkten innerhalb von Container wird ebenfalls als eine separate Aufgabe von der Host-Asset-Erfassung abgegrenzt.

6. Warum dieses Design gewählt wurde

Gründe für die Platzierung mehrerer Services auf den beiden zentralen VMs

In einer Produktionsumgebung ist es von Vorteil, Server im Hinblick auf Ressourcenzuweisung, Sicherheit und Fehlertrennung nach Rollen aufzuteilen. Da in diesem Praxistraining die Integration zwischen Services und das Failover auf einem 32-GB-PC überprüft werden müssen, wurden die Rollen auf zwei zentrale VMs konzentriert. NetBox, Zabbix und die Datendienste wurden durch Compose-Projekte, Volumes und Konten getrennt, während AWX in K3s bereitgestellt wurde, um der Installations- und Verwaltungsstruktur des offiziellen Operators zu folgen.

Die Trennung von Containern isoliert jedoch keine VM-Ausfälle. Die meisten Services nutzen das Host-Netzwerk und teilen sich die Auswirkungen von CPU, Arbeitsspeicher, Festplatten-E/A, Kernel und VM-Neustarts. Speicherlimits und die Begrenzung der Auftrags-Konkurrenz sind in diesem Szenario die Mittel zur Ressourcenverwaltung.

Gründe für die Trennung von Zabbix Server HA und Proxy

Die beiden zentralen Server teilen sich über Native HA in die Rollen Active/Standby und nutzen eine gemeinsame Datenbank. Die umgebungsspezifischen Active Proxies sammeln die Daten der lokalen Agenten und leiten sie an die Zentrale weiter. Wenn die Verbindung zur Zentrale unterbrochen wird, kann der Festplattenpuffer des Proxys die Datenerfassung fortsetzen, aber wenn die Proxy-VM selbst ausfällt, geht diese Funktion ebenfalls verloren. Agent-zu-Proxy und Proxy-zu-Server werden jeweils per PSK authentifiziert.

Gründe für die Trennung von NetBox HA bis zur Datenebene

NetBox App und Worker wurden auf den beiden zentralen Knoten platziert, während PostgreSQL mit Patroni, Redis mit Sentinel und die Zugriffsadresse mit Keepalived/HAProxy konfiguriert wurden. Die beiden NetBox-Knoten verwenden denselben SECRET_KEY sowie Token-Pepper, und Medien verweisen auf ein gemeinsames NFS. Der dritte etcd/Sentinel stellt das Quorum sicher, wenn einer der beiden zentralen Knoten ausfällt.

NFS selbst ist ein einzelner Knoten. Daher ist der NetBox-HA-Umfang dieser Konfiguration primär auf den Ausfall eines zentralen Knotens ausgerichtet. Es wird nicht als vollständige Storage-HA bezeichnet, die auch den Ausfall des Medienspeichers übersteht. PostgreSQL verwendet den synchronen Modus, jedoch keinen strikten Modus, weshalb RPO 0 nicht bei allen Ausfällen garantiert werden kann.

Gründe für die gemeinsame Platzierung von Proxy und Bastion

Durch die Zusammenlegung des Monitoring-Sammelpunkts und des Automatisierungs-Eingangspunkts jeder Umgebung auf einer VM wurde der Ressourcenverbrauch für dieses kleine Praxistraining reduziert. Die Bastion leitet Daten nur an die SSH-Ports autorisierter Ziele weiter und schränkt interaktive Shells sowie Agent Forwarding ein. Diese Bereitstellung hat den Preis, dass ein Ausfall von Proxy/Bastion sowohl das Monitoring als auch neue Automatisierungen gleichzeitig beeinträchtigt. Im realen Betrieb kann dies je nach Größe und Sicherheitsgrenzen getrennt werden.

Gründe für den Einsatz von Git und AWX

Das Vorhandensein von Playbook-Dateien ist nicht dasselbe wie die Reproduzierbarkeit derselben Konfiguration. Durch die Verknüpfung von Git-Commits, AWX-Projekt-Sync, Job-IDs, Ziel-Inventaren und Execution-Environment-Versionen lässt sich nachvollziehen, welcher Code welche Änderungen vorgenommen hat. Während NetBox als Quelle der Wahrheit für tatsächliche Assets verwendet wird, bleibt die Genehmigungsliste für die Ersteinrichtung als separates Bootstrap-Inventar erhalten.

7. Fehlerszenarien und Verfügbarkeitsgrenzen

Diese Tabelle zeigt den erwarteten Umfang gemäß Entwurf. Tatsächlich durchgeführte Ausfälle, Erfassungslücken, Wiederherstellungszeitpunkte und Datenaufbewahrung werden im Verifizierungsbericht separat bewertet. Die Störungsanimationen auf dem Bildschirm fragen nicht den tatsächlichen Serverstatus ab und führen keine Befehle aus.

8. Betrieb unter Berücksichtigung von Online- und isolierten Netzen

Im Onlinenetz werden die im offiziellen Repository verifizierten Versionen heruntergeladen und Image-Digests, RPM-Signaturen sowie Git-Commits aufgezeichnet. Im isolierten Netz werden dieselbe Version von RPMs und Abhängigkeiten, Container-Images, K3s-Images, AWX EE, Ansible-Collections, Git-Bundles und der OS-Installationsbaum bereitgestellt. CA, DNS und NTP müssen ebenfalls intern bereitgestellt werden.

Zielservern ohne Internetzugang werden signierte RPMs über ein internes HTTP-Repository bereitgestellt, und für APIs wird HTTPS verwendet, das durch die Übungs-CA verifiziert wurde. Die HTTP-Übertragung des internen RPM-Repositorys und die HTTPS-Authentifizierung der API werden voneinander getrennt. Die interne Klartextverbindung der Datenebene stellt eine Einschränkung der aktuellen Übung dar; bei der produktiven Anwendung müssen TLS, Geheimhaltung (Secret Management) und Zugriffsprüfungen verstärkt werden.

9. In diesem Projekt vermittelte Kompetenzen

Der Kern dieser Übung liegt nicht in der Anzahl der Tools, sondern in der Fähigkeit, Betriebsergebnisse miteinander zu verknüpfen. Die Bezeichner der Installationsphase werden bis zu NetBox und Zabbix weitergeführt, Wiederholungen und Teilausfälle werden berücksichtigt, und es wird nicht nur der Normalzustand verifiziert, sondern auch, was nach einem Ausfall erhalten bleibt und was gestoppt wird.

Repository-Pfade, API-Schemata, Token-Verfahren, AWX-Ausführungsumgebungen und Probleme mit den HAProxy-Gesundheitsprüfungen (Health Checks), die während des Build-Protokolls entdeckt wurden, werden zusammen mit den Reproduktionsbedingungen und den Korrekturgrundlagen dokumentiert. Probleme im Zusammenhang mit VirtualBox-Firmware, virtuellen CPUs und Installationsspeicher werden unabhängig vom Servicedesign in separaten Blogbeiträgen zusammengefasst.

Bei der zukünftigen Erweiterung auf eine Betriebsumgebung sollten physische Host- und Speicherredundanz, AWX/Git-Verfügbarkeit, durchgehende Verschlüsselung, externe Geheimhaltungsspeicher sowie Backup-Richtlinien und regelmäßige Wiederherstellungstests priorisiert werden. Die Integration von UEFI-PXE, NIC-Treibern, RAID und BMC auf echten physischen Servern muss unabhängig von diesem VM-Test verifiziert werden.

10. Weiterführende Literatur und technische Grundlagen

Die Installationsprozeduren und Validierungsergebnisse sind als Projektserie desselben Portfolios miteinander verknüpft. Status und Umfang der jeweiligen Beiträge werden basierend auf den tatsächlichen Testaufzeichnungen aktualisiert.

Zabbix Native HA, Zabbix-Release-Lebenszyklus, NetBox-Pflichtkonfigurationen und Redis Sentinel, AWX-Operator-Installation, NetBox Ansible Inventory Plugin, Rocky-Linux-Unterstützungszyklus.

Weiterführende Lektüre und Konfigurationsmaterialien

Portfolio-Originaltext · Leitfaden zum Aufbau von Online- und isolierten Netzen · Ausfallszenarien und Validierungsaufzeichnungen · Protokoll zur Behebung von VirtualBox-Konfigurationsproblemen

Übungskonfiguration & Automatisierungsquellen als ZIP · ZIP SHA-256

Das öffentliche ZIP enthält Konfigurationsvorlagen und Automatisierungsquellen. Betriebssysteme, RPMs, Container-Images und Anmeldeinformationen sind nicht enthalten. Diese werden nach der Konfiguration mit eigenen Adressen, öffentlichen CAs, autorisierten SSH-Schlüsseln und Geheimhaltungsspeichern angewendet.