Deep Dive: SAP Automation with Ansible on SLES for SAP 16 – Architecture, Collections & Playbooks

Welcome back to the tech blog. As a Senior IT Architect, I have been following the evolution of SAP infrastructures for years. With the upcoming release of SUSE Linux Enterprise Server (SLES) 16, a fundamental paradigm shift in the automation of SAP landscapes is imminent. The classic deployment via manual sapinst calls or highly fragmented Bash scripts is giving way to a highly standardized, declarative methodology. In this article, we will deeply analyze the new Ansible concepts, link them with established architectural knowledge, and dissect the technical details recently presented by SUSE Solution Architect Mat Matsum Mamula.

The Strategic Shift: From Salt to Ansible

Historically, SUSE was strongly tied to Salt (or SaltStack) in the automation environment, particularly driven by SUSE Manager (Uyuni). The important news for existing architectures is: Salt is not disappearing and remains an essential component for managing existing infrastructures. However, SUSE is shifting its clear focus for dedicated SAP automation to Ansible. This decision reflects the broader industry standard. To maximize interoperability, the SAP Linux Lab Open Source Initiative was launched – a collaborative upstream project on GitHub (github.com/sap-linuxlab) uniting technology partners like SUSE, Red Hat, IBM, SAP, NetApp, and the open-source community. The architectural goal of this alliance ("fostering collaboration") is to write automation code that works agnostically and flawlessly on all partner platforms, instead of maintaining proprietary silos. If, for example, new features are developed based on SUSE documentation, they flow into the Red Hat branch simultaneously to ensure complete compatibility.

SLES 16 vs. SLES for SAP 16: Tooling vs. Automations

A critical aspect for designing future landscapes is the strict separation of delivery. While the regular SLES 16 only receives the basic tools (tooling), the actual SAP automations are delivered exclusively with SLES for SAP 16. The architectural reason for this is simple but crucial: Regular SLES 16 is neither validated nor certified or officially released for operating SAP workloads or SAP High Availability (HA) clusters. This is exclusively reserved for the "for SAP" variant, which is why the automation scripts are also strictly tied to this product. For installation, there is a special pattern in SLES for SAP 16 called patterns-sap-automation, which installs all necessary dependencies on the system.

Technical Baseline Data: Python, Ansible Core, and CVE Hurdles

The underlying technology is undergoing a significant upgrade that must imperatively be considered during migrations. The current planning status (which may still change minimally in the agile release cycle) envisions the delivery of Python 3.11 for both SLES 16 and SLES for SAP. This is a drastic modernization compared to the old SLES 15 states. On this basis, Ansible and Ansible Core in version 2.18 are currently being validated and tested. Interesting from a security perspective: Originally, older Ansible versions were planned, but critical security vulnerabilities (CVEs) in two previous versions forced the development team to jump directly to the latest version state, which passed the tests successfully.

Architectural Pitfalls: Backward Compatibility and Python

An extremely important detail for hybrid landscapes or migrations from SLES 15 to 16: In Python 3.7 and 3.9, there were fundamental changes regarding so-called iterated to future feature annotations, which led to complications in Ansible and enforced stricter Python requirements. Since SLES 16 is based on Python 3.11, "16 to 16" communication works out-of-the-box. However, if you use SLES 16 as an orchestration node to roll out SAP on SLES 15 (from SP5), you must mandatorily install Python 3.11 on the target system. This is solved automatically in the provided playbooks via the Ansible raw module but is indispensable as foundational knowledge for IT architects when troubleshooting.

Deep Dive: The Three Pillars of SAP Collections

The automation code is divided into highly specialized Ansible Collections, which have clear responsibilities in the provisioning pipeline (Day-1 and Day-2 Operations).

1. SAP Infrastructure (ansible-collection-sap_infrastructure)

This collection is responsible for provisioning bare servers in cloud environments. Architecturally exciting is the duality: Provisioning can be done natively by Ansible or optionally by Terraform (controlled via Ansible). The official philosophy here is: "Terraform is more powerful, but Ansible is smarter". Accordingly, Ansible is favored as the primary provisioning method, as it can check conditions (requirements) more intelligently upfront, while Terraform bluntly provisions network elements. The infrastructure collection currently supports major cloud providers but also has experimental modules for VMware and KubeVirt in the pipeline. Important: The pure package is not enough. Due to licensing restrictions, third-party libraries cannot be included. If you are targeting AWS, for example, you must manually provide Python boto3, the AWS CLI, and the amazon.aws collection, which is documented accordingly in the packages.

2. SAP Install (ansible-collection-sap_install)

The heart of automation for on-premise and cloud (Day-1 application layer). The architecture follows a strict, non-overlapping pipeline (top-to-bottom execution):

• sap_storage_setup: Initialization of disks, LVMs, volumes, and partitions (for cloud as well as on-prem and bare-metal).

• sap_general_preconfigure: Setting extremely critical saptune parameters (kernel, sysctl) and installing OS packages required by SAP Notes.

• sap_install_media: An intelligent unpacker. Reads manifest files from provided SAP media and purposefully unpacks/sorts files, an area where classic Bash scripts often fail.

• sap_swpm & sap_hana_install: These are very profound, complex wrappers around the official SAP binaries sapinst (Software Provisioning Manager) and hdblcm (HANA Database Lifecycle Manager).

• HA Pacemaker: The final configuration of cluster resources for HANA, ASCS, and (newly added) SCS/ERS.

3. SAP Operations (ansible-collection-sap_operations)

A focused, smaller collection for Day-2 automations after successful initial installation.

Playbooks and Deployment Scenarios (ansible-sap-playbooks)

The real magic happens when these collections are orchestrated. SUSE has subjected the playbooks (found under /usr/share/ansible/playbooks/) to a gigantic overhaul for the upcoming release – 90% of the code was rewritten from scratch (with over 15,000 code changes in current Pull Requests). Over 20 different deployment scenarios are available, covering almost every architecture pattern. These include BW/4HANA, SAP ECC, HANA, NetWeaver, S/4HANA, and Solution Manager. These in turn come in various flavors: from simple sandbox systems to high-availability (HA) clusters to extremely distributed systems. A massive architectural advancement is the decoupling of infrastructure provisioning and software deployment. The playbooks have been heavily modularized. If a company already operates its own servers on-premise (Prague Data Center in the example) or has its own Terraform pipeline, the provisioning phase in the playbooks can be skipped completely. The only prerequisites in this case are: The presence of the pattern package, a clean Ansible inventory, and distributed SSH keys.

Execution Modes: From Pro to Beginner

To drastically lower the entry barrier ("How to start"), three specific execution modes were implemented:

• Fully Non-Interactive Mode (The standard for automation architects): Expects an experienced DevOps engineer. All variables (host definitions, OS parameters, SAP product IDs) are defined in a compact YAML file stripped of unnecessary ballast.

• Fully Interactive Mode (The new highlight): A massive feature with over 1,300 lines of code solely for interactive querying. The mode queries all parameters step by step ("Are you using Ansible or Terraform?", "Where to provision?"). About 70% of the variables are pre-filled with valid default values and can be confirmed by pressing Enter. The kicker: At the end of the guided installation, the inputs can be saved as YAML and used as a blueprint for future, non-interactive rollouts.

• Light Mode for existing servers: A minimal input file where all cloud/platform-specific variables are simply deleted. The playbooks are so robust that they are not bothered by missing infrastructure variables if no provisioning is taking place.

High Availability (HA) and Idempotency Challenges

As a Senior IT Architect, I place special emphasis on reliability. HA automation now covers an extremely broad spectrum. For the HANA database, support for SAP HANA SR-NG (System Replication Next Generation), the designated HA future for HANA, was successfully implemented last year. For application clusters (ASCS / ERS), both ENSA1 and the modern ENSA2 are supported. In the ENSA2 environment, installation is even possible in "Classic Mode" using File System Resource Agents or Simple Mount. Interesting side note: Even non-officially supported architectures, like Java clusters, were integrated into the code from a Proof-of-Concept perspective. An often underestimated problem of automation is idempotency (the property of a script to guarantee the same end state without side effects upon multiple executions). The good news: Almost all SAP roles, including the hdblcm wrapper for HANA, work completely idempotently. They check configurations and fix deviations, otherwise they skip the task. The architectural exception is the SAP SWPM (sapinst). SAP historically did not design sapinst for idempotency; if you run it again on a running system, it irrevocably destroys the installation. The developers of the upstream initiative are currently working massively on building robust wrappers around SWPM to bypass this design flaw from SAP and simulate item potency.

Software Supply Chain: Automated SAP Download

Another practical problem is solved by the upstream role sap_launchpad (which will soon also be available via the SUSE Package Hub). If you provide valid S-User credentials, the role automatically handles the download of required software packages and patches directly from SAP. This eliminates a manual and extremely error-prone process. If the role is absent or no credentials are provided, the code dynamically falls back on alternative sources like central NFS shares. Since SAP is notoriously known for changing filenames overnight during patch rollouts, this role is continuously developed to identify files more intelligently.

Conclusion

With the announcements regarding SLES for SAP 16, SUSE proves they have understood the necessity of an "Infrastructure as Code" culture in the SAP environment. The shift from isolated script collections to a standardized, extremely flexible Ansible rule set, driven by the SAP Linux Lab Open Source Initiative, is a massive leap. For us as IT architects, this means: Playbooks that work equally well on AWS, in our own data center, for HANA scale-outs, or NetWeaver sandboxes, radically streamlined variable files, and, thanks to the interactive mode, a significantly flatter learning curve for operations teams. However, it is important to keep the architectural restrictions in mind: Remember the lack of out-of-the-box idempotency of sapinst, the correct Python 3.11 injection on SLES 15 target systems via the raw module, and the strict separation of Tooling (SLES 16) and Automations (SLES for SAP 16). Those who consider these aspects in their solution architecture gain a powerful, future-proof tool. The code is on GitHub – so nothing stands in the way of evaluation for your next SAP landscape.