SUSE Multi-Linux Manager 5.2: use Ansible next to Salt in production

SUSE Multi-Linux Manager uses Salt as its primary automation and remote-execution layer. Salt is deeply integrated for client onboarding, state queries, package actions, events and many Manager functions.

Ansible does not replace Salt in Multi-Linux Manager 5.2. It complements operations where playbooks, roles and inventories are already part of the enterprise automation model. The Manager can expose Ansible control nodes, read playbook directories, display inventories and schedule playbook execution.

Complete series path

This series guides you step by step through production deployment: 1. Install SLES 16 for production · 2. Install SUSE Multi-Linux Manager 5.2 · 3. Onboard first Linux clients · 4. Patch and lifecycle management · 5. Manage mixed Linux · 6. OpenSCAP, compliance and audit · 7. Build proxies for sites · 8. Integrate SSO with Keycloak · 9. Use Ansible next to Salt · 10. Reporting, inventory and audit · 11. Operate and harden in production

https://mlm01.lab.example

What SUSE Multi-Linux Manager 5.2 can do with Ansible

The 5.2 documentation describes Ansible features on the system details page of a control node. It includes areas for Control Node, Playbooks and Inventories. Administrators can define paths to inventory files and playbook directories, discover playbooks, inspect details and schedule execution.

This is not a replacement for AWX or Ansible Automation Platform. It is a practical integration so existing Ansible control nodes are not invisible next to the Manager. Salt remains the native management path.

Prepare the control node

An Ansible control node is a managed system with Ansible installed and inventories, playbooks, roles and collections available. In SUSE environments, Ansible usually comes from official operating system repositories, for example through the Systems Management Module on matching SLES versions.

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

Mark the control node in the Manager

The host is first managed as a normal client. Then enable the Add-on System Type for Ansible Control Node on the system details page. This exposes the Ansible area and lets the Manager manage playbook and inventory paths.

https://mlm01.lab.example

Expose inventories

Inventories describe which systems Ansible targets. In mixed Linux environments they should separate operating-system families, environments and responsibilities so playbooks do not accidentally run on the wrong distributions.

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:

Execute playbooks

Playbooks should be syntax-checked, versioned and limited to a controlled target group before execution. The Manager can discover playbooks from configured directories and schedule runs. Production workflows still need review, maintenance windows and rollback.

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

Separate Salt and Ansible cleanly

Salt is suitable for native Manager client control, package and patch actions, fast grains queries, event-driven management and integrated system actions. Ansible is useful for existing roles, application-oriented configuration, cross-team playbooks and automation logic already maintained outside the Manager.

Best practice is not Salt versus Ansible. Best practice is clear responsibility: the Manager remains the source for inventory, patch state, compliance and system control. Ansible remains a controlled automation path for versioned, tested and traceable playbooks.

Compliance as Code with Ansible

SUSE also documents remediation through Ansible playbooks in a Compliance-as-Code context. The control node needs the matching SCAP Security Guide content. This is relevant when OpenSCAP results should feed controlled remediation workflows.

https://mlm01.lab.example

Acceptance test

The integration is complete when the control node is reachable as a managed system, Ansible is installed, inventory paths are visible in the Manager, playbooks are discovered, syntax check passes, a limited check run works and a scheduled execution remains auditable.

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

Limits

The Ansible integration does not turn Multi-Linux Manager into AWX or Red Hat Ansible Automation Platform. Complex workflows, credentials, surveys, approval chains and large automation organizations still benefit from a dedicated Ansible platform. Multi-Linux Manager 5.2 mainly helps make control nodes, inventories and playbooks usable from the Linux operations view.

Practical example: Ansible for complementary Day-2 work

A typical entry point is not a full server rollout, but a limited Day-2 task: verify a configuration file, align a service state, deploy an application role or apply an OpenSCAP remediation to a small system group.

Targeting stays deliberately narrow. Start with one host, then with a lab group, then with a production maintenance group. Expand only when check run, rollback and monitoring are clear.

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

What remains a Salt task

Salt remains strong where the platform works directly with system state, package actions, events and Manager workflows. That includes Salt minions, grains, fast remote commands, package state, patch actions, system groups and many integrated UI actions.

If a team already uses Ansible roles for applications or configuration, that work does not need to be discarded. Multi-Linux Manager can expose the control node and bring execution into the operations process. The central truth about inventory, patch state and compliance still remains in the Manager.

Documentation and repository structure

Playbooks belong in Git. Inventory files, roles, collections and variables must be versioned. Secrets belong in a proper secret workflow, not in playbooks, screenshots or CMS content. For customer environments it must remain clear which playbook version was applied to which target group.

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