The Operations Loop — De serverinstallatie als begin van het beheer

AI_Manager

Het installeren van een enkele server is slechts een deel van de voorbereiding op beheer. Een server is pas klaar voor gebruik als het duidelijk is wie hem in welke omgeving heeft geplaatst, welke software er actief is, waar verbinding moet worden gemaakt, en hoe storingen kunnen worden gedetecteerd en opgelost.

Dit project is een infrastructuurlab die loopt van de installatie van Rocky Linux-servers tot basisconfiguratie, gedetailleerde activaregistratie, automatische inventaris-updates en het ontvangen van daadwerkelijke monitoringwaarden. We hebben een centraal beheernetwerk en PROD, DEV en STG opgesplitst op Oracle VirtualBox, en Zabbix, NetBox, AWX, Git en PXE geconfigureerd in één operationele workflow.

De praktijkomgeving is een virtuele machine (VM) op een enkele pc. Dit is een omgeving om services en VM-storingen te testen, en het is geen beheersysteem met redundantie voor fysieke hosts of opslag. De verificatieresultaten worden ingedeeld op basis van de taak-ID, tijdstip en observatieresultaten van een afzonderlijk verificatieproject.

• 1. Projectoverzicht
• 2. Operationele problemen die we willen oplossen
• 3. Serverconfiguratie en netwerk
• 4. Het proces waarbij een server toetreedt tot het beheer
• 5. Hoe we de bijgevoegde YAML voor activaverzameling hebben toegepast
• 6. Waarom we het zo hebben ontworpen
• 7. Storingsscenario’s en de grens van beschikbaarheid
• 8. Beheer met oog voor zowel online netwerken als afgesloten netwerken
• 9. Competenties die dit project wil aantonen
• 10. Vervolgstijlen en technische fundamenten
• Verder lezen en configuratiematerialen

1. Projectoverzicht

Als criterium voor voltooiing is gekozen of de identificatiecode en het beheer-IP van één server overeenkomen gedurende installatie, assetbeheer, automatisering en bewaking, in plaats van simpelweg de installatie per tool te voltooien. Zelfs als de API de status 200 retourneert, wordt de onboarding niet als succesvol beschouwd als het doelsysteem ontbreekt in de inventory of als de meest recente Zabbix-waarden niet binnenkomen.

De daadwerkelijke onboarding van de drie doelsystemen PROD, DEV en STG is voltooid. Van assetregistratie, inventory-updates tot het controleren van de nieuwste bewakingswaarden in AWX Workflow 22, 30 en 38 is alles succesvol verlopen. Ook power-loss tests on each of the two central nodes afzonderlijk, onderbreking van de Proxy-overdracht en herstel van vertraagde data, weigering van assetconflicten en herstel van een afzonderlijke database zijn getest. De voorwaarden voor elk succes en het niet-gevalideerde bereik zijn vastgelegd in het verificatieartikel.

2. Operationele problemen die moeten worden opgelost

Het los van elkaar uitvoeren van OS-installatie, bijwerken van Excel-assetregisters, toevoegen van Ansible-hosts en registreren van monitoring leidt tot omissies en inconsistenties. Het komt voor dat een opnieuw geïnstalleerde server de eerdere assets overschrijft, dat een NAT-adres wordt geregistreerd als beheer-IP, of dat monitoring alleen een host toont zonder data.

Om dit te verminderen worden goedgekeurde hostnamen, omgevingen en beheer-IP’s vastgesteld als invoerbasis en vergeleken met de hostname, machine-ID en interfaces daadwerkelijk uitgelezen op de gast. In NetBox worden niet alleen tekenreeks-IP’s gebruikt, maar worden de relaties VM/Device → Interface → IPAddress → primary_ip4 aangemaakt, en AWX haalt de inventory op uit die relaties. Bij het opnieuw uitvoeren van de registratie worden de bestaande identificatiecode en het beheerobject gecontroleerd.

De tweede uitdaging is het uitleggen van de storingsomvang. Het feit dat er twee Zabbix-servers zijn, betekent niet automatisch dat de database ook in HA is uitgevoerd. Twee NetBox Web-instanties zijn eveneens pas zinvol als PostgreSQL, Redis, gedeelde media en verbindingsadressen samenwerken. De omschakelvoorwaarden van elke laag en de resterende enkelvoudige storingspunten zijn afzonderlijk weergegeven.

Interactieve architectuur — Totale structuur en operationele stroom

3. Serverconfiguratie en netwerk

De fysieke pc is een Windows 11 Pro met een Intel Core Ultra 9 185H (16 cores / 22 logische processors), ca. 31,4 GiB beschikbaar geheugen en een 2TB SSD. VM’s krijgen alleen het hoognodige geheugen toegewezen en PXE-installatiedoelen worden opeenvolgend uitgevoerd. Doelen die tijdens de installatie 4 GiB nodig hebben, worden na installatie teruggebracht tot 1 GiB.

In de hostnaam staat ops voor de productieservice, quorum voor storingsdetectie, edge voor het omgevingsstartpunt en provision voor de installatiebasis. De FQDN zoals herkend door het besturingssysteem is 호스트명.fullmoon.test. Het domein voor de openbare site en de oefen-DNS zijn van elkaar gescheiden.

Er worden geen NAT- of Bridge-NIC’s gekoppeld aan de PXE-doelen per omgeving. SSH van het centrale systeem naar de doelserver loopt via de Bastion van de betreffende omgeving. Communicatie tussen omgevingen wordt standaard geblokkeerd en vereist dat de benodigde bron, bestemming en poort worden opgegeven. De NAT van de beheer-VM die werd gebruikt voor het importeren van de initiële pakketten en de interne servicepaden worden in de build log van elkaar onderscheiden.

4. Het proces waarin een server toetreedt tot de productieomgeving

Plaats geen NetBox-beheerderswachtwoorden op externe servers. Externe verzameling wordt uitgevoerd met beheerdersrechten binnen het vereiste bereik, en API-verzoeken worden uitgevoerd met inloggegevens die worden geïnjecteerd vanuit de AWX Execution Environment. SSH-privésleutels worden niet gekopieerd naar de Bastion.

Automatische toevoeging van inventaris in AWX is een implementeerbare functie. We hebben de officiële NetBox Ansible inventory-plugin gekoppeld als SCM inventory source en geconfigureerd zodat de workflow na een succesvolle registratietaak doorgaat met inventarissynchronisatie en verificatie. Voor NetBox-tokens zijn asset-schrijfrechten en leesrechten voor de inventory gescheiden.

Verbindingen na PXE worden afgehandeld door de centrale installatiecontroller. Nadat de geautoriseerde SSH-hostkey, het installatievoltooiingsmerkteken, de hostname en de machine-ID zijn geverifieerd, wordt de workflow voor de betreffende server gestart. Initiële goedkeuring van de serveridentiteit blijft een verificatiestap voor de beheerder; na goedkeuring worden assets, inventaris en monitoringregistratie achter elkaar uitgevoerd. Als de machine-ID verandert door een herinstallatie, wordt dit ter beoordeling gelaten in plaats van automatisch te worden overschreven.

5. Hoe is YAML voor het verzamelen van bijgevoegde assets toegepast?

De bijgevoegde YAML is geen simpele hostname-registratie. Het is een assetregister dat OS, CPU, schijf, netwerk, product, virtualisatie en sporen van back-upagent verzamelt met actieve Linux-processen en /proc-informatie als startpunt. Om deze intentie te behouden, zijn de vier items verzamelstatus, tijdstip, fout en machine-ID toegevoegd aan de 34 originele aangepaste velden.

De locatieadressen, sites en regels voor omgevingsbepaling uit het origineel zijn vervangen door de PROD/DEV/STG en expliciete inventarisvariabelen van deze oefening. NetBox-native IPAM-relaties zijn toegevoegd aan het gedeelte waar alleen primary_ipv4-tekenreeksen werden opgeslagen. Bestaande goedgekeurde site-, rol-, platform- en gebruikerstags worden niet blindelings vervangen door het verzamelresultaat.

De versiedetectie is niet met echte installaties van alle commerciële databases en applicatieservers getest. Controleer het eigendom van uitvoerbare bestanden, toestemmingslijsten en naamruimten, en voer onzekere opstartscripts niet uit als root. Niet-gevalideerde versies blijven onbevestigd. Productverzameling binnen containers wordt eveneens gescheiden gehouden van de verzameling van hostassets.

6. Waarom dit zo is ontworpen

Waarom meerdere services op de twee centrale VM’s zijn geplaatst

In een productieomgeving is het voordelig om servers te verdelen op basis van resources, beveiliging en isolatie van storingen per rol. Omdat in deze oefening de integratie tussen services en failover binnen een pc van 32 GB moesten worden gevalideerd, zijn de rollen samengebracht op de twee centrale VM’s. NetBox, Zabbix en dataservices zijn gescheiden via Compose-projecten, volumes en accounts, terwijl AWX in K3s is geplaatst om de installatie- en beheerstructuur van de officiële Operator te volgen.

Het scheiden van containers betekent echter niet dat storingen op VM-niveau automatisch worden geïsoleerd. Veel services gebruiken het hostnetwerk en delen de impact op CPU, geheugen, schijf-I/O, kernel en VM-herstart. Geheugenlimieten en beperkingen op taakgelijktijdigheid zijn de middelen voor resourcebeheer onder deze omstandigheid.

Waarom Zabbix Server HA en Proxy zijn gescheiden

De twee centrale servers verdelen de actieve/standby-rollen via Native HA en gebruiken een gemeenschappelijke database. De actieve proxy’s per omgeving verzamelen gegevens van lokale agents en sturen deze door naar het centrum. Als de centrale verbinding wegvalt, kan de proxy gegevens blijven verzamelen en op schijf bufferen, maar als de proxy-VM zelf stopt, verdwijnt die functionaliteit ook. Agent-naar-proxy en proxy-naar-server worden elk geverifieerd via PSK.

Waarom NetBox HA tot op de datalaag is gescheiden

NetBox App en Worker zijn op de twee centrale knooppunten geplaatst, waarbij PostgreSQL is geconfigureerd met Patroni, Redis met Sentinel, en het verbindingsadres met Keepalived/HAProxy. De twee NetBox-knooppunten gebruiken dezelfde SECRET_KEY en token-pepper, en media verwijzen naar een gemeenschappelijke NFS. De derde etcd/Sentinel zorgt voor de benodigde meerderheid wanneer een van de twee centrale knooppunten wegvalt.

NFS zelf is een enkel knooppunt. Daarom is het bereik van NetBox HA in deze configuratie primair gedefinieerd rond een storing van één centraal knooppunt. Dit wordt niet omschreven als volledige opslag-HA die bestand is tegen storingen in de mediaopslag. Omdat PostgreSQL de synchrone modus gebruikt maar geen strikte modus, wordt RPO 0 niet gegarandeerd bij alle storingen.

Waarom Proxy en Bastion samen zijn geplaatst

Het verzamelpunt voor monitoring en het toegangspunt voor automatisering in elke omgeving zijn samengebracht op één VM om het resourcegebruik voor de kleine oefening te verminderen. Bastion forwardt alleen naar SSH-poorten van geautoriseerde doelen en beperkt interactieve shells en agent forwarding. Deze opstelling brengt met zich mee dat een storing van één enkele Proxy/Bastion gelijktijdige invloed heeft op monitoring en nieuwe automatisering. In daadwerkelijke producties kan dit worden gescheiden op basis van schaal en beveiligingsgrenzen.

Waarom Git en AWX zijn geplaatst

Het hebben van playbook-bestanden is iets anders dan het kunnen reproduceren van dezelfde configuratie. Door Git-commits, AWX Project-sync, Job ID’s, doel-inventarissen en versies van Execution Environments te koppelen, kunt u traceren welke code welke wijzigingen heeft veroorzaakt. Terwijl NetBox wordt gebruikt als de bron der waarheid voor werkelijke assets, wordt de goedkeuringslijst voor de initiële installatie onderhouden als een aparte bootstrap-inventaris.

7. Storingsscenario’s en grenzen van beschikbaarheid

Deze tabel toont het verwachte bereik op basis van het ontwerp. Daadwerkelijke storingen, hiaten in de verzameling, hersteltijden en gegevensbehoud worden afzonderlijk beoordeeld in het validatieartikel. De storingsanimatie op het scherm vraagt de werkelijke serverstatus niet op en voert geen opdrachten uit.

8. Operaties met zowel online als geïsoleerde netwerken

In het onlinenetwerk worden versies gedownload die zijn geverifieerd in de officiële repository, en worden imagedigest, RPM-handtekeningen en Git-commits vastgelegd. In het geïsoleerde netwerk worden dezelfde versies van RPM’s en afhankelijkheden, containerimages, K3s-images, AWX EE, Ansible-collecties, Git-bundles en OS-installatiebomen geïmporteerd. CA, DNS en NTP moeten eveneens intern worden aangeboden.

Voor doelservers zonder internettoegang worden ondertekende RPM’s geleverd via een interne HTTP-repository, en gebruikt de API HTTPS dat is geverifieerd met de lab-CA. Er wordt onderscheid gemaakt tussen HTTP-transmissie voor de interne RPM-repository en HTTPS-verificatie voor de API. Interne onversleutelde verbindingen in de datalaag vormen een beperking van de huidige oefening; bij operationele toepassing moeten TLS, geheimbeheer en toegangscontrole worden versterkt.

9. Competenties die dit project wil aantonen

De kern van deze oefening is niet het aantal tools, maar het vermogen om operationele resultaten met elkaar te verbinden. Identificatoren uit de installatiefase worden doorgetrokken naar NetBox en Zabbix, er wordt rekening gehouden met herhalingen en gedeeltelijke mislukkingen, en er wordt niet alleen geverifieerd wat er in de normale status gebeurt, maar ook wat er na een storing behouden blijft en wat er stopt.

Problemen met repositorypaden, API-schema’s, tokendefinities, AWX-uitvoeringsomgevingen en HAProxy-gezondheidschecks die tijdens de opbouw zijn ontdekt, worden vastgelegd samen met de herhalingsvoorwaarden en de onderbouwing van de correcties. Kwesties betreffende VirtualBox-firmware, virtuele CPU’s en installatiegeheugen worden los van het serviceontwerp in een afzonderlijke blogpost behandeld.

Bij uitbreiding naar een toekomstige productieomgeving moeten fysieke host- en opslagredundantie, AWX/Git-beschikbaarheid, end-to-end-encryptie, externe geheimenopslag, back-upbeleid en periodieke hersteltests prioriteit krijgen. De integratie van UEFI PXE, NIC-drivers, RAID en BMC op echte fysieke servers moet afzonderlijk van deze VM-test worden geverifieerd.

10. Verder lezen en technische onderbouwing

De installatieprocedures en validatieresultaten zijn gekoppeld als projectreeksen binnen dezelfde portfolio. De status en het bereik van elk artikel worden bijgewerkt op basis van feitelijke testrecords.

Zabbix Native HA, Zabbix-releaselevenscyclus, NetBox-vereiste instellingen en Redis Sentinel, AWX Operator-installatie, NetBox Ansible-inventarisplugin, Rocky Linux-ondersteuningslevenscyclus.

Verder lezen en configuratiemateriaal

Origineel portfolioartikel · Gids voor het opzetten van online en geïsoleerde netwerken · Storingsscenario’s en validatierecords · Record van het oplossen van VirtualBox-configuratieproblemen

ZIP-bestand met oefeningsconfiguraties en automatiseringsbronnen · ZIP SHA-256

De openbare ZIP bevat configuratiesjablonen en automatiseringsbronnen. OS-, RPM-, containerimages en inloggegevens zijn niet inbegrepen. Deze moeten worden geconfigureerd met uw eigen adressen, openbare CA, geautoriseerde SSH-sleutels en geheimenopslag voordat ze worden toegepast.