01 Ansible Control Node

Einleitung

Im Gegensatz zu klassischen Konfigurationsmanagement-Lösungen wie Puppet benötigt Ansible auf den verwalteten Zielsystemen in der Regel keinen dauerhaft installierten Agenten. Ansible arbeitet weitgehend agentenlos und verbindet sich bei Linux-Systemen standardmäßig über SSH mit den Zielhosts.

Damit ein Linux-System durch Ansible verwaltet werden kann, müssen im Wesentlichen folgende Voraussetzungen erfüllt sein:

• Das Zielsystem ist vom Ansible-Steuerungssystem aus über das Netzwerk erreichbar.
• Eine Anmeldung per SSH ist möglich.
• Der verwendete Benutzer verfügt über die erforderlichen Berechtigungen.
• Für administrative Aufgaben kann der Benutzer bei Bedarf über sudo oder eine vergleichbare Rechteeskalation verfügen.
• Auf dem Zielsystem ist eine von Ansible unterstützte Python-Version installiert.

Technisch wäre es möglich, Ansible direkt auf einem Arbeitsplatzrechner zu installieren und von dort aus die gesamte Infrastruktur zu verwalten. Auf einem Fedora-System könnte Ansible beispielsweise über die Paketverwaltung installiert werden:

sudo dnf install ansible-core

Für einzelne Tests, kleine Umgebungen oder die Entwicklung von Playbooks ist dieses Vorgehen grundsätzlich ausreichend. Für eine dauerhaft betriebene Automatisierungsumgebung ist ein Arbeitsplatzrechner als zentrale Ansible-Instanz jedoch nur eingeschränkt geeignet. Mein Desktop Rechner ist verständlicherweise nicht den ganzen Tag in Betrieb. Automatische Vorgänge würden also nur funktionieren, wenn ich denn gerade mal vor meinem Rechner sitze.

Aus diesem Grund wird Ansible in meiner Umgebung auf einem dedizierten Steuerungssystem betrieben. Dieses System wird häufig als Ansible Control Node bezeichnet. Es führt die Playbooks aus, hält die Inventories und Rollen vor und stellt die Verbindungen zu den verwalteten Systemen her.

Der Control Node soll folgende Aufgaben übernehmen:

• Zentrale Ablage von Inventories, Playbooks, Rollen und Templates
• Verwaltung der SSH-Schlüssel und Zugangsdaten
• Reproduzierbare Ausführung von Automatisierungsaufgaben
• Trennung der Infrastrukturverwaltung vom persönlichen Arbeitsplatz
• Zeit- oder ereignisgesteuerte Ausführung von Jobs
• Integration in Versionsverwaltung (git)
• (Vielleicht einmal) spätere Erweiterung um eine grafische oder API-basierte Automatisierungsplattform

Als Control Node richte ich eine kleine dedizierte Linux-VM ein. Diese kann unabhängig vom Desktop betrieben, regelmäßig gesichert und gezielt gehärtet werden. Ich fange mal mit einer vergleichsweise kleine virtuelle Maschine an. Erweitern geht später ja immer. 

Ressource	Empfehlung
CPU	2 vCPU
Arbeitsspeicher	4 GB
Festplatte	32 GB
Betriebssystem	Rocky Linux 1
Netzwerkzugriff	SSH zu allen verwalteten Zielsystemen
Benutzerkonto	Dediziertes Ansible-Servicekonto

Da ich privat viel im Fallout Universum unterwegs bin, nennen wir die Kiste mal AUTOMATRON. Einfach nur ansible oder control-node wäre mir zu langweilig.

Installation VM auf Proxmox

Als erstes rollen wir ne neue VM auf Proxmox aus und konfigurieren die VM für UEFI und Secure Boot. Als Basis dient das Rocky Linux 10 minmal ISO. Alle notwendigen Pakete können später nachinstalliert werden.

Die VM wird gleich mit den passenden Tags versehen, und startet automatisch mit dem Proxmox Host.

Also OS wird Rocky Linux 10 verwendet. Installiert aus dem "minimal" ISO.

Wir stellen die VM auf q35 für die deutlich neuere HW Emulation und erstellen EFI und TPM Disk auf dem gleichen Volume wie gleich auch die OS Disk.

Disk nach Best Practice eine SCSI Disk, die an einem VirtIO SCSI Single Adapter hängt. Discard und SSD Emulation (damit fstrim aucxh aus dem guest funktioniert) nicht vergessen.

2 vCPU in einem virtuellen Sockel (der Server hat auch nur einen Sockel, alles andere wäre also Quatsch) und auf x86-64-v3 gestellt, da beide Server im Cluster passende CPUs haben.

Folgende CPU Flags sind gesetzt:

• aes
• amd-ssbd
• ibpb
• virt-ssbd

Abgesehen von aes alles zur Verhinderung von Spectre & Co.

RAM Zuweisung erst mal eher konservativ. Mehr geht später immer. Da Ansible aber eigentlich in so kleinen Umgebungen eher Ressourcenfreundlich ist, werden wir wahrscheinlich nie mehr benötigen.

Die VM kommt in mein abgeschottetes Server VLAN 121, da der Zugriff auf diese VM möglichst stark eingeschränkt sein sollte.

Nach der Erstellung der VM kann die OS Installation starten.

OS Installation

Da wir es mit einem geprüften ISO File zu tun haben, können wir uns das Testen des Datenträgers schenken und starten direkt mit der Installation.

Sprachauswahl des Systems auf Deutsch eingestellt und damit auch schon die richtige Tastatuauswahl vorgegeben.

Im Konfigurationsdialog müssen wir jetzt also noch

• Festplattenkonfiguration
• Netzwerkkonfiguration
• Software Auswahl
• NTP / Zeitkonfiguration
• User Name und Kennwort

festlegen.

Festplattenkonfiguration

Eine Disk, per LVM partitioniert. Wie bei RedHat derivaten üblich XFS als Standard Dateisystem.

Ich mag die Standard Bezeichnungen der vg und lv nicht, daher passe ich die jedes Mal an. Außerdem ist auch 2GB swap für dieses System sicherlich mehr als ausreichend (die Automatik wollte mehr als 4). Für dieses System ist eine Unterteilung und z.B. eine Abtrennung von /var/log meiner Meinung nach nicht notwendig.

Netzwerkkonfiguration

Da ich intern auch mit gemischter Konfiguration arbeite (IPv4 und IPv6 mit öffentlichen und ULA Adressen), bekommt der Server auch beides zugewiesen.

Softwareauswahl

Bei der initialen Installation wird keine zusätzliche Software installiert. Alle notwendigen Tools werden später per DNF atomar hinzugefügt.

NTP

Ich steh auf die NTP Server des PTB, da hier die deutsche Atomuhr steht, die auch die Zeit für diese NTP Server liefert. Vor allen Dingen können die auch NTS (Network Time Security), was eine Man-in-the-middle Attacke auf Zeitservices wirksam unterbindet, weil ich nur Zeit von einem Server akzeptiere, der sich vorher auch ausgewiesen hat.

USER

Im ersten Schritt wird der admin Account angelegt, der für die Verwaltung des Systems benötigt wird und sudo Berechtigung bekommen wird. Nach der Installation legen wir noch einen User ansible an, der die eigentlichen ansible Aufgaben übernehmen wird und lokale KEINE sudo Berechtigung hat.

Installation

Danach kann die Installation starten:

Nach dem ersten Neustart ein vollständiges Systemupdate durchführen (sudo dnf upgrade -y):

Jetzt noch Standard Anpassungen vornehmen wie z.B. meinen SSH Key importieren, damit ich mich ohne Kennwort per SSH am System anmelden kann.