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

Source: https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt
Language: de
Published: 2026-09-16
Updated: 2026-10-19

Was SUSE Multi-Linux Manager 5.2 mit Ansible kann: Control Nodes, Inventories, Playbooks, Compliance as Code und klare Trennung zu Salt.

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.

## 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.

```bash
ansible --version
ansible-inventory --list
ansible-playbook --syntax-check site.yaml
```

## 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.

[![Systemliste mit registriertem SLES-16-Client.](https://forgeone.solutions/media/suse-mlm-client-onboarding-05-system-list.png)](https://forgeone.solutions/media/suse-mlm-client-onboarding-05-system-list.png)

## 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.

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

## 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.

```bash
ansible-playbook -i inventory.yaml site.yaml --limit sles16-client01.example.test --check
ansible-playbook -i inventory.yaml site.yaml --limit sles16-client01.example.test
```

## 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.

[![Relevante Patches im SUSE Multi-Linux Manager.](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-01-relevant-patches.png)](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-01-relevant-patches.png)

## Ergebniskontrolle / Technische Abnahme

Die technische Abnahme folgt dem gleichen Muster wie in den grommunio- und SUSE-Beiträgen: PASS bedeutet, dass der konkrete Prüfpunkt aktiv ausgeführt oder fachlich eindeutig belegt wurde. PASS WITH CONDITIONS, SCOPE LIMIT und NOT TESTED bleiben sichtbar, damit der Beitrag nicht mehr verspricht, als tatsächlich geprüft wurde.

| Prüfbereich | Prüfung | Erwartetes Ergebnis | Status |
| --- | --- | --- | --- |
| Control Node | Ansible-Control-Node im Manager vorbereiten und markieren | Manager erkennt die Ausführungsrolle nachvollziehbar | PASS |
| Inventory | Inventory-Quelle und Systemgruppen prüfen | Zielsysteme sind eindeutig zugeordnet | PASS |
| Ausführung | Playbook-Lauf über Manager/AWX-Pfad nachvollziehen | Job startet kontrolliert und protokolliert | PASS WITH CONDITIONS |
| Abgrenzung | Salt- und Ansible-Aufgaben trennen | Patch- und Lifecycle-Aufgaben bleiben sauber zugeordnet | PASS |
| Compliance | OpenSCAP/Compliance- und Ansible-Zweck trennen | Keine doppelte Verantwortlichkeit im Betrieb | PASS WITH CONDITIONS |
| Produktion | Breiten Rollout gegen produktive Flotte | Nur mit Wartungsfenster und Change-Freigabe | NOT TESTED IN THIS PASS |

## Grenzen

Die Ansible-Integration macht Multi-Linux Manager nicht zu AWX oder Red Hat Ansible Automation Platform. Für komplexe Workflows, Zugangsdaten, 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.

```bash
ansible-playbook -i inventory.yaml hardening.yaml --limit lab-sles --check --diff
ansible-playbook -i inventory.yaml hardening.yaml --limit lab-sles --diff
ansible-playbook -i inventory.yaml hardening.yaml --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. sensible Werte gehören in einen geeigneten Secret-Workflow und nicht in Playbooks, Screenshots oder öffentliche Inhalte. Für Kundenumgebungen ist wichtig, dass nachvollziehbar bleibt, welche Version eines Playbooks auf welche Zielgruppe angewendet wurde.

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

## 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](https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/ansible-integration.html).

## Ansible neben Salt in SUSE Multi-Linux Manager 5.2

Salt bleibt der native Manager-Layer für Minions, Events, Remote Commands, Paketstatus und operative Steuerung. Ansible ergänzt diesen Ansatz dort, wo Teams bestehende Playbooks, Inventories und Rollen weiterverwenden wollen. Die 5.2-API bietet dafür Pfade zum Anlegen von Ansible Paths, Playbook-Discovery, Inventory-Introspection und Playbook-Scheduling.

- Nutze Salt für Manager-native Clientsteuerung und Zustandsdaten.
- Nutze Ansible für vorhandene Automatisierungslogik, Rollen und projektnahe Runbooks.
- Führe Compliance-Remediation nur aus, wenn Scanbefund, Zielsysteme und Wartungsfenster eindeutig sind.
- Dokumentiere pro Playbook: Quelle, Review, Variablen, Zielgruppe, Freigabe und Rollback.

SUSE nennt Ansible-Funktionen in der 5.2-API, darunter Playbook-Discovery und Scheduling. Details stehen in der [SUSE Multi-Linux Manager 5.2 Dokumentation](https://documentation.suse.com/multi-linux-manager/5.2/).

## Quellen und weiterführende Dokumentation

- [SUSE Multi-Linux Manager 5.2 Dokumentation](https://documentation.suse.com/multi-linux-manager/5.2/en/docs/index.html)
- [SUSE Multi-Linux Manager 5.2 Release Notes](https://documentation.suse.com/releasenotes/multi-linux-manager/5.2/index.html)
- [SUSE Multi-Linux Manager Produktseite](https://www.suse.com/products/multi-linux-manager/)

### SUSE Multi-Linux Manager produktiv einsetzen

ForgeOne unterstützt dich bei Lizenzen, Architektur, Installation, Multi-Linux-Onboarding, Proxies, Keycloak-SSO, Compliance, Reporting, Ansible/Salt-Automation, Professional Services und laufendem Support.

- [SUSE-Projekt besprechen](https://forgeone.solutions/de/kontakt)

## Titelbild

[![SUSE Logo](https://forgeone.solutions/media/SUSE_Logo_and_Name.png)](https://forgeone.solutions/media/SUSE_Logo_and_Name.png)

## Autor

Mathias Rumbold

## Kategorie

- [Linux Lifecycle Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt?category=linux-lifecycle-management)

## Tags

- [SUSE](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt?tags=suse)
- [SUSE Multi-Linux Manager](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt?tags=suse-multi-linux-manager)
- [Ansible](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt?tags=ansible)
- [Salt](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt?tags=salt)
- [Automation](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt?tags=automation)

## SUSE Enterprise Linux & Multi-Linux Manager Schritt für Schritt

Die Serie verbindet SLES 16 Grundlagen mit dem produktiven Aufbau von SUSE Multi-Linux Manager 5.2. Bestehende URLs bleiben unverändert.

1. [SLES 16 produktiv installieren: vom ISO zum verwaltbaren Linux-Server](https://forgeone.solutions/de/tech/sles-16-installieren)
2. [SLES 16 und Enterprise Linux: Wie unterschiedlich ist der Admin-Alltag noch?](https://forgeone.solutions/de/tech/sles-16-enterprise-linux-rhel-rocky-almalinux-vergleich)
3. [SLES 16 härten und prüfen: OpenSCAP, CIS-Einordnung und SUSE Multi-Linux Manager](https://forgeone.solutions/de/tech/sles-16-hardening-openscap-cis-mlm)
4. [SUSE Multi-Linux Manager 5.2 produktiv installieren: SL Micro, Storage und erster Channel-Sync](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sl-micro-installieren)
5. [SUSE Multi-Linux Manager 5.2: erste Linux-Clients produktiv onboarden](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-clients-onboarden)
6. [SUSE Multi-Linux Manager 5.2: Patch- und Lifecycle-Management produktiv aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management)
7. [SUSE Multi-Linux Manager 5.2: Mixed Linux produktiv verwalten](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten)
8. [SUSE Multi-Linux Manager 5.2: OpenSCAP, Compliance und Audit produktiv nutzen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-openscap-compliance-audit)
9. [SUSE Multi-Linux Manager 5.2: Proxies für Standorte und verteilte Linux-Flotten aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-proxy-standorte-aufbauen)
10. [SUSE Multi-Linux Manager 5.2: SSO mit Keycloak, SAML und MFA integrieren](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa)
11. [SUSE Multi-Linux Manager 5.2: Ansible neben Salt produktiv nutzen (aktueller Teil)](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt)
12. [SUSE Multi-Linux Manager 5.2: Reporting, Inventar und Subscription Audit aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-reporting-inventory-subscription-audit)
13. [SUSE Multi-Linux Manager 5.2 produktiv betreiben und härten](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-produktiv-betreiben-haerten)