SUSE Multi-Linux Manager 5.2: Ansible neben Salt produktiv nutzen

SUSE Multi-Linux Manager verwendet Salt als primäre Automations- und Remote-Execution-Basis. Das ist wichtig, weil Salt für Client-Onboarding, Zustandsabfragen, Paketaktionen, Events und viele Manager-Funktionen tief integriert ist.

Ansible ersetzt Salt in Multi-Linux Manager 5.2 nicht. Es ergänzt den Betrieb dort, wo bestehende Playbooks, Rollen und Inventories bereits Teil der Unternehmensautomation sind. Der Manager kann Ansible Control Nodes sichtbar machen, Playbook-Verzeichnisse auslesen, Inventories anzeigen und Playbook-Ausführungen planen.

Kompletter Ablauf der Serie

Diese Reihe führt dich Schritt für Schritt durch den produktiven Aufbau: 1. SLES 16 produktiv installieren · 2. SUSE Multi-Linux Manager 5.2 installieren · 3. Erste Linux-Clients onboarden · 4. Patch- und Lifecycle-Management · 5. Mixed Linux verwalten · 6. OpenSCAP, Compliance und Audit · 7. Proxies für Standorte aufbauen · 8. SSO mit Keycloak integrieren · 9. Ansible neben Salt nutzen · 10. Reporting, Inventar und Audit · 11. Produktiv betreiben und härten

https://mlm01.lab.example

Was SUSE Multi-Linux Manager 5.2 mit Ansible kann

Die 5.2-Dokumentation beschreibt Ansible-Funktionen auf der System-Detailseite eines Control Nodes. Dort gibt es Bereiche für Control Node, Playbooks und Inventories. Administratoren können Pfade zu Inventory-Dateien und Playbook-Verzeichnissen definieren, Playbooks entdecken, Details prüfen und Ausführungen planen.

Das ist keine vollwertige AWX- oder AAP-Ersetzung. Es ist eine praktische Integration, damit vorhandene Ansible-Control-Nodes nicht neben dem Manager unsichtbar laufen. Der Manager wird damit zur zentraleren Betriebsansicht, während Salt weiterhin der native Managementpfad bleibt.

Control Node vorbereiten

Ein Ansible Control Node ist ein verwaltetes System, auf dem Ansible installiert ist und auf dem Inventories, Playbooks, Rollen und Collections liegen. In SUSE-Umgebungen kommt Ansible üblicherweise aus den offiziellen Betriebssystem-Repositories, zum Beispiel über das Systems Management Module auf passenden SLES-Versionen.

ansible --version
ansible-inventory --list
ansible-playbook --syntax-check site.yml

Control Node im Manager markieren

Der Host wird zuerst als normaler Client verwaltet. Danach aktivierst du auf der System-Detailseite den Add-on System Type für Ansible Control Node. Dadurch erscheint der Ansible-Bereich am System und der Manager kann dort Playbook- und Inventory-Pfade verwalten.

https://mlm01.lab.example

Inventories sichtbar machen

Inventories beschreiben, welche Systeme Ansible anspricht. In einer Multi-Linux-Umgebung sollten sie Betriebssystemfamilien, Umgebungen und Verantwortlichkeiten sauber trennen. Das verhindert, dass ein Playbook versehentlich auf falsche Distributionen läuft.

all:
  children:
    sles:
      hosts:
        sles16-client01.lab.example:
    debian:
      hosts:
        debian13-client01.lab.example:
    ubuntu:
      hosts:
        ubuntu2404-client01.lab.example:
    rhel_compatible:
      hosts:
        rocky10-client01.lab.example:
        alma10-client01.lab.example:

Playbooks ausführen

Playbooks sollten vor der Ausführung syntaktisch geprüft, versioniert und auf eine begrenzte Zielgruppe eingeschränkt werden. Der Manager kann Playbooks aus den definierten Verzeichnissen entdecken und Ausführungen planen. Für produktive Abläufe gehören Review, Wartungsfenster und Rollback trotzdem in den Prozess.

ansible-playbook -i inventory.yml site.yml --limit sles16-client01.lab.example --check
ansible-playbook -i inventory.yml site.yml --limit sles16-client01.lab.example

Salt und Ansible sauber trennen

Salt eignet sich im Manager für native Client-Steuerung, Paket- und Patchaktionen, schnelle Grains-Abfragen, Event-getriebene Verwaltung und integrierte Systemaktionen. Ansible eignet sich für vorhandene Rollen, applikationsnahe Konfiguration, teamübergreifende Playbooks und Automationslogik, die bereits außerhalb des Managers gepflegt wird.

Best Practice ist nicht entweder Salt oder Ansible. Best Practice ist eine klare Zuständigkeit: Der Manager bleibt Quelle für Inventar, Patchstatus, Compliance und Systemsteuerung. Ansible bleibt ein kontrollierter Automationspfad für Playbooks, die versioniert, getestet und nachvollziehbar ausgeführt werden.

Compliance as Code mit Ansible

SUSE dokumentiert auch Remediation über Ansible-Playbooks im Compliance-as-Code-Kontext. Dafür braucht der Control Node die passenden SCAP Security Guide Inhalte. Das ist besonders interessant, wenn OpenSCAP-Ergebnisse nicht nur gemeldet, sondern in kontrollierte Remediation-Workflows übersetzt werden sollen.

https://mlm01.lab.example

Abnahmetest

Die Integration ist erst belastbar, wenn der Control Node als verwaltetes System erreichbar ist, Ansible installiert ist, Inventory-Pfade im Manager angezeigt werden, Playbooks entdeckt werden, ein Syntaxcheck erfolgreich ist, ein begrenzter Check-Run funktioniert und eine geplante Ausführung auditierbar bleibt.

acceptance:
  control_node_managed: PASS
  ansible_installed: PASS
  inventories_visible: PASS
  playbooks_discovered: PASS
  syntax_check: PASS
  limited_check_run: PASS
  scheduled_execution_traceable: PASS

Grenzen

Die Ansible-Integration macht Multi-Linux Manager nicht zu AWX oder Red Hat Ansible Automation Platform. Für komplexe Workflows, Credentials, Surveys, Approval Chains und große Automationsorganisationen bleibt eine dedizierte Ansible-Plattform sinnvoll. Multi-Linux Manager 5.2 hilft vor allem dabei, Control Nodes, Inventories und Playbooks aus der Linux-Betriebssicht heraus nutzbar zu machen.

Praxisbeispiel: Ansible für ergänzende Day-2-Aufgaben

Ein typischer Einstieg ist kein vollständiger Server-Rollout, sondern eine begrenzte Day-2-Aufgabe: eine Konfigurationsdatei prüfen, einen Dienstzustand vereinheitlichen, eine Applikationsrolle ausrollen oder eine OpenSCAP-Remediation kontrolliert auf eine kleine Systemgruppe anwenden.

Dabei bleibt die Zielauswahl bewusst eng. Du startest mit einem einzelnen Host, danach mit einer Lab-Gruppe, danach mit einer produktiven Wartungsgruppe. Erst wenn Check-Run, Rollback und Monitoring passen, wird die Zielgruppe erweitert.

ansible-playbook -i inventory.yml hardening.yml --limit lab-sles --check --diff
ansible-playbook -i inventory.yml hardening.yml --limit lab-sles --diff
ansible-playbook -i inventory.yml hardening.yml --limit patch-window-weekly --check --diff

Was weiterhin Salt-Aufgabe bleibt

Salt bleibt im Manager dort stark, wo die Plattform direkt mit Systemzustand, Paketaktionen, Events und Manager-Workflows arbeitet. Dazu gehören Salt-Minions, Grains, schnelle Remote-Kommandos, Paketstatus, Patchaktionen, Systemgruppen und viele integrierte Aktionen aus der Weboberfläche.

Wenn ein Team bereits Ansible-Rollen für Applikationen oder Konfigurationen nutzt, muss man diese Arbeit nicht wegwerfen. Multi-Linux Manager kann den Control Node sichtbar machen und Ausführung in den Betriebsprozess einordnen. Die zentrale Wahrheit über Systembestand, Patchstand und Compliance bleibt trotzdem im Manager.

Dokumentation und Repository-Struktur

Playbooks gehören in Git. Inventory-Dateien, Rollen, Collections und Variablen müssen nachvollziehbar versioniert sein. Secrets gehören in einen geeigneten Secret-Workflow und nicht in Playbooks, Screenshots oder CMS-Inhalte. Für Kundenumgebungen ist wichtig, dass nachvollziehbar bleibt, welche Version eines Playbooks auf welche Zielgruppe angewendet wurde.

repository:
  inventories:
    - inventory-production.yml
    - inventory-lab.yml
  playbooks:
    - site.yml
    - hardening.yml
    - remediation.yml
  roles:
    - baseline_linux
    - application_config
  collections:
    - requirements.yml

Was SUSE Multi-Linux Manager 5.2 mit Ansible leisten kann

SUSE Multi-Linux Manager 5.2 ersetzt AWX oder Red Hat Ansible Automation Platform nicht. Der Manager kann aber Ansible Control Nodes sichtbar machen und deren Playbooks aus dem Betriebskontext heraus nutzbar machen.

• Ein System wird als Ansible Control Node markiert.
• Auf dem Control Node liegen Inventory-Dateien und Playbook-Verzeichnisse.
• Der Manager kann Inventories inspizieren, Playbooks erkennen und Playbook-Ausführungen planen.
• Compliance-as-Code kann Ansible-Remediation nutzen, wenn die passenden SCAP-Inhalte und Playbooks vorhanden sind.
• Salt bleibt für native Manager-Aktionen, Minion-Kommunikation, Remote Commands und den laufenden Systembetrieb die zentrale Ebene.

Offizielle Einordnung: SUSE Multi-Linux Manager 5.2 Ansible Integration.