Automatisierung im Netzwerkumfeld: Moderne Tools für den effizienten IT-Betrieb

Configuration Management und Infrastructure-as-Code (IaC) haben sich als Antwort auf diese Herausforderungen etabliert. Statt Server und Netzwerkkomponenten manuell zu konfigurieren, wird der gewünschte Zustand einer Infrastruktur in maschinenlesbarer Form beschrieben und automatisiert angewendet. Dies ermöglicht Versionierung, Nachvollziehbarkeit und Wiederholbarkeit – Eigenschaften, die aus der Softwareentwicklung bekannt sind und nun auf den Infrastrukturbetrieb übertragen werden.

In diesem Beitrag werden fünf etablierte Werkzeuge vorgestellt, die in diesem Umfeld weit verbreitet sind: Ansible, Puppet, Chef, SaltStack und Terraform. Jedes dieser Tools verfolgt einen eigenen Ansatz und eignet sich für unterschiedliche Anwendungsfälle und Betriebsmodelle.

Ansible

Ansible setzt auf einen agentenlosen Ansatz: Die Kommunikation mit verwalteten Systemen erfolgt über SSH bzw. WinRM, ohne dass auf den Zielsystemen zusätzliche Software installiert werden muss. Konfigurationen werden in YAML-basierten Playbooks beschrieben, die auch ohne tiefe Programmierkenntnisse verfasst und gelesen werden können. Playbooks bestehen aus einer geordneten Abfolge von Tasks, die auf einer Inventarliste von Hosts ausgeführt werden. Über Rollen (Roles) lassen sich Playbooks modular aufbauen und wiederverwenden. Für das Netzwerkumfeld bietet Ansible eine besonders breite Abdeckung: Module für Cisco IOS, NX-OS, Juniper Junos, Arista EOS und viele weitere Plattformen ermöglichen die automatisierte Konfiguration von Interfaces, VLANs, Routing-Protokollen, ACLs und BGP-Peerings. Sofern von den Netzwerkgeräten kein SSH-Agent unterstützt wird, können zusätzlich NETCONF- und RESTCONF-basierte Verbindungsmodule eingesetzt werden.

Puppet

Puppet verfolgt ein deklaratives Modell: Der gewünschte Zustand eines Systems wird in der Puppet DSL beschrieben, und ein auf dem Zielsystem laufender Agent sorgt dafür, dass dieser Zustand kontinuierlich eingehalten wird. Abweichungen werden automatisch korrigiert. Die Konfiguration wird in sogenannten Manifesten (.pp-Dateien) abgelegt, die in Modulen organisiert sind. Ein zentraler Puppet Master (bzw. Puppet Server) stellt den Agenten kompilierte Kataloge bereit – eine maschinenlesbare Beschreibung des gewünschten Zustands. Der Pull-Zyklus läuft typischerweise alle 30 Minuten ab, kann allerdings auch manuell ausgelöst werden. Puppet eignet sich besonders für Umgebungen, in denen eine zuverlässige Durchsetzung von Baseline-Konfigurationen über eine große, heterogene Systemlandschaft hinweg gefragt ist. Dies ermöglicht eine saubere Trennung von Code und Daten, wodurch die Wiederverwendbarkeit von Modulen in unterschiedlichen Umgebungen verbessert wird.

Chef

Chef beschreibt Infrastruktur in Ruby-Code, der in Rezepten (Recipes) und Kochbüchern (Cookbooks) organisiert ist. Dieser programmatische Ansatz gibt erfahrenen Entwicklern viel Ausdrucksstärke, erfordert jedoch Ruby-Kenntnisse und einen entsprechend eingerichteten Workflow. Der zentrale Chef-Server speichert Cookbooks, Knotendaten und Richtlinien. Der Chef-client auf jedem Knoten ruft regelmäßig seinen Zustand ab und führt die zugewiesenen Rezepte aus. Mit Policyfiles lassen sich Konfigurationen für bestimmte Umgebungen fest versionieren – ein Ansatz, der Deployments besser reproduzierbar macht. Chef InSpec, ein Schwester-Projekt, erlaubt das automatisierte Testen von Infrastruktur gegen Compliance-Anforderungen (z. B. CIS-Benchmarks). Besonders in Umgebungen, in denen Infrastruktur sehr eng mit CI/CD-Pipelines verzahnt ist und Konfigurationen denselben Entwicklungsprozessen wie Anwendungscode folgen sollen, ist Chef verbreitet.

SaltStack

SaltStack kombiniert Configuration Management mit einem leistungsfähigen Echtzeit-Kommunikationsbus auf Basis von ZeroMQ über TCP. Über einen zentralen Salt Master werden Minions gesteuert, wobei Befehle und Konfigurationen nahezu in Echtzeit übertragen werden können. Konfigurationen werden in YAML-basierten State-Dateien (.sls) beschrieben, die über ein Pillar-System mit umgebungsspezifischen Daten versorgt werden. Besonders hervorzuheben ist das Reactor-System: Es erlaubt, auf Events im Salt-Bus zu reagieren und automatisch States oder Remote Execution Modules auszuführen – etwa, wenn ein Dienst ausfällt oder ein Netzwerkknoten einen bestimmten Zustand meldet. Im Netzwerkbereich bietet Salt NAPALM-Integration (Network Automation and Programmability Abstraction Layer with Multivendor support), die eine herstellerunabhängige Schicht für Netzwerkkonfiguration und -abfragen bereitstellt. Salt Proxy Minions ermöglichen es, auch agentenlose Netzwerkgeräte in das Salt-Ökosystem einzubinden.

Terraform

Terraform ist kein Configuration Management Tool im klassischen Sinne, sondern ein Werkzeug zur Provisionierung von Infrastruktur. Über HCL (HashiCorp Configuration Language) werden Ressourcen deklarativ beschrieben und über Provider-Plugins erstellt, geändert oder entfernt. Das Kernprinzip ist der Lebenszyklus einer Ressource: terraform plan zeigt geplante Änderungen an, bevor terraform apply sie umsetzt. Der State wird in einer Zustandsdatei gespeichert, die den tatsächlich provisionierten Zustand abbildet und Grundlage für alle nachfolgenden Änderungsberechnungen (Diffs) ist. Im Netzwerkumfeld werden Provider für AWS VPC, Azure Networking, GCP, doch auch für physische Geräte wie Cisco ACI, Juniper Apstra oder Palo Alto Panorama eingesetzt. Terraform-Module erlauben die Kapselung von Netzwerktopologien als wiederverwendbare Bausteine. Seit Version 1.6 steht Terraform unter der BSL-Lizenz; mit der Community-Alternative OpenTofu (Linux Foundation) steht ein vollständig quelloffener Fork bereit.

Einordnung und Gemeinsamkeiten

Trotz ihrer unterschiedlichen Ansätze teilen die genannten Tools grundlegende Prinzipien. Alle ermöglichen es, Infrastruktur in Textform zu beschreiben, in Versionskontrollsystemen zu verwalten und reproduzierbar auszurollen. Peer Review, automatisiertes Testen von Konfigurationen und eine lückenlose Änderungshistorie werden damit möglich – Praktiken, die unter dem Begriff GitOps zusammengefasst werden. Ein wesentlicher Unterschied liegt im Ausführungsmodell: Push-basierte Systeme wie Ansible übertragen Konfigurationen aktiv an die Zielsysteme, während Pull-basierte Systeme wie Puppet und Chef einen Agenten voraussetzen, der Konfigurationen eigenständig vom zentralen Server abruft. Beide Ansätze haben Vor- und Nachteile bezüglich Skalierbarkeit, Sicherheit und Betriebsaufwand. Im Netzwerkumfeld sind zudem spezifische Anforderungen zu beachten: Viele Netzwerkbetriebssysteme erlauben keine Agenteninstallation, weshalb agentenlose Ansätze oder spezialisierte Netzwerk-APIs (NETCONF, RESTCONF) eine zentrale Rolle spielen. Ansible hat hier durch seine breite Herstellerabdeckung eine starke Position, während Terraform insbesondere im Cloud-Netzwerkbereich und bei der Verwaltung von SDN-Umgebungen eingesetzt wird.

Fazit

Automatisierung ist im modernen Netzwerkbetrieb kein optionales Add-on, sondern eine operationelle Notwendigkeit. Ansible, Puppet, Chef, SaltStack und Terraform decken dabei unterschiedliche Aspekte des Infrastrukturlebenszyklus ab – von der initialen Provisionierung über kontinuierliches Configuration Enforcement bis hin zu event-gesteuerter Reaktion auf Infrastrukturzustände. Die Auswahl des passenden Werkzeugs hängt von der bestehenden Umgebung, den Kenntnissen im Team, den Anforderungen an Skalierbarkeit und den eingesetzten Plattformen ab. In der Praxis werden diese Tools häufig kombiniert: Terraform für die Bereitstellung, Ansible oder Puppet für die Konfiguration – ein Ansatz, der die jeweiligen Stärken der Werkzeuge gezielt nutzt. Entscheidend ist nicht das einzelne Tool, sondern die Disziplin, Infrastruktur konsequent als Code zu behandeln.

Wer tiefer in die Welt der Netzwerkautomatisierung einsteigen möchte: Auf unserer diesjährigen Sommerschule werden praxisnahe Einblicke in Ansible geboten: von den Grundlagen über Playbook-Struktur bis hin zu konkreten Anwendungsfällen im Netzwerkumfeld. Eine gute Gelegenheit, das Thema tiefer zu erkunden und Fragen direkt zu stellen. Wir freuen uns auf Sie!

Quellen

• https://www.redhat.com/
• https://www.it-schulungen.com
• https://www.netsync.com/wp-content/uploads/2022/12/Ansible-Price-List.pdf
• https://cyberpanel.net/blog/ansible-pricing
• https://www.aalpha.net/articles/ansible-vs-puppet-difference/
• https://www.upguard.com/blog/open-source-puppet-vs-puppet-enterprise-which-is-right-for-you