Deploying and managing SAP environments on SUSE Linux Enterprise Server for SAP applications 16 is a complex process that often relies on manual, error-prone tasks. To solve this, we’ve created a powerful set of Ansible collections and playbooks designed specifically for SAP on SLES. This automation codifies best practices, allowing you to build and maintain your SAP landscapes with speed, reliability, and consistency.

This post will guide you through the components of our solution, how to install them, and how to run your first playbook. It’s intended for administrators who are already familiar with basic Ansible concepts.

An introductory blog post for getting started with Ansible can be found at Getting Started with Ansible on SUSE Linux Enterprise Server 16.

SAP LinuxLab Open Source Initiative

At the heart of our automation lies SAP LinuxLab, an open-source initiative that SAP founded alongside key technology partners like SUSE. The initiative drives the development of best-practice automation for running SAP solutions on Linux, fostering a powerful collaboration between community experts and enterprise engineers.

SAP LinuxLab is the direct upstream source for the Ansible Automation introduced in this blog post.

For those interested in the project or ways to contribute, you can explore the project at the SAP LinuxLab GitHub.

Pattern Installation

The easiest and most reliable way to install all the necessary components for SAP automation is by using the official SUSE package pattern.

Using the pattern ensures that all required Ansible collections and the playbook package are installed together, preventing any potential dependency issues.

The following pattern is present only on SLES for SAP applications 16.

sudo zypper install --type pattern sles_sap_automation

This single command takes care of everything. For your reference, the pattern currently includes the following packages:

• ansible-sap-infrastructure
• ansible-sap-install
• ansible-sap-operations
• ansible-sap-playbooks

All packages above are also available on SLES for SAP applications 15 SP6 and SP7, but without the pattern.

Package design and usage

Before we explore the available automation, let’s quickly cover how it’s packaged and used. Understanding this structure is key to working with automation effectively.

Collections of Roles

First, it’s important to know that we do not deliver separate Ansible Roles. Instead, we deliver our packages that each contain an Ansible Collection with a curated list of supported Ansible Roles.

Using Roles with Fully Qualified Collection Names (FQCN)

Because every role is present inside a collection, you must use its Fully Qualified Collection Name (FQCN) to call it. This acts like a precise address, telling Ansible exactly where to find the role and preventing any naming conflicts with other collections.

Here is a practical example of how to call the sap_swpm role from the sap_install collection under the suse namespace.

---
- name: Ansible Play to install SAP Product
  hosts: all
  tasks:
    - name: Install SAP Product
      ansible.builtin.include_role:
        name: suse.sap_install.sap_swpm

The sap_install Collection: Deploying your SAP System

This collection is your primary toolkit for deploying SAP software. It’s provided by the ansible-sap-install package, which is the SUSE-supported version of the upstream community.sap_install project from SAP LinuxLab.

Once your system is provisioned, you’ll use the roles from this collection to handle the entire lifecycle: preparing the operating system according to SAP Notes, setting up storage, installing the SAP software itself, and configuring the final high-availability cluster.

Here are the key roles included in this collection:

The sap_infrastructure Collection: Building Your Cloud Foundation

While the sap_install collection focuses on the software, the sap_infrastructure collection is all about building the foundation.

Provided by the ansible-sap-infrastructure package, its purpose is to automate the deployment of the underlying cloud infrastructure needed to host your SAP landscape.

Using the principles of Infrastructure as Code (IaC), these roles allow you to programmatically create virtual machines, networks, and storage in a repeatable and consistent manner. This is the first step in a fully automated deployment.

The key role of this collection is sap_vm_provision, which provisions to the following platforms:

• Amazon Web Services EC2 Virtual Servers
• Google Cloud Compute Engine Virtual Machines
• IBM Cloud, Intel and Power Virtual Servers
• Microsoft Azure Virtual Machines
• IBM PowerVM Virtual Machines

A Note on Prerequisites

This collection leverages the native automation tools of each cloud provider. Before using it, you must fulfill the specific prerequisites for your target platform as explained in the official documentation.

To give you an idea, here are the typical requirements for provisioning on AWS:

• Existing AWS Infrastructure: You’ll need a pre-existing VPC with subnets, DNS (Route 53), an NFS share (EFS), an Internet or NAT Gateway, and available SSH keys.
• Access Method: By default, the automation uses a Bastion host to connect to private subnets. This is the recommended method for secure access but can be disabled if you have a direct connection to your cloud network (e.g., a Site-to-Site VPN or a dedicated network extension).
• Ansible Control Node Setup: The amazon.aws Ansible Collection and the boto3 Python library (included in package python313-boto3) must be installed.

The sap_operations Collection: Managing Your Live SAP System

Once your SAP landscape is built and running, the focus shifts to daily management and maintenance. The sap_operations collection is designed for these “Day 2” tasks.

Provided by the ansible-sap-operations package, its roles help you automate routine procedures, ensuring they are performed consistently and safely every time.

Here are some of the roles included in this collection:

The Final Piece: Ansible Playbooks

We’ve covered the collections that provide the individual tools for infrastructure, installation, and operations. The ansible-sap-playbooks package is the final piece of the puzzle: it contains the complete, end-to-end playbooks that use all those tools together.

All of our playbooks are designed with a few key principles in mind to make them both powerful and easy to use:

• Modular Configuration: The playbooks use a modular variable system. This means you only need to configure the specific values for your environment, without being overwhelmed by hundreds of optional settings.
• Brownfield & Greenfield Support: The playbooks are flexible. They can deploy a complete landscape from scratch (“greenfield”) or run against existing servers that you already have in place (“brownfield”).
• Interactive Mode: For quick deployments or for users who prefer not to create variable files, an interactive mode is available. The playbook will prompt you for the necessary information step-by-step.
• (Optional) Automated Media Downloads: If the community.sap_launchpad Ansible Collection is present on your control node, the playbooks can automatically download the required SAP installation media for you, saving a significant amount of manual effort. This requires a valid SAP S-User with privileges to download SAP software.

This package provides ready-to-run playbooks for your most common and complex scenarios, such as:

Hands-On: Installing and Running Your First Playbook

Now that you understand the components, let’s walk through practical examples. We’ll deploy an SAP S/4HANA Sandbox system using two methods: deployment in AWS and on an existing host.

This deployment scenario is located in /usr/share/ansible/playbooks/ansible.playbooks_for_sap/deploy_scenarios/sap_s4hana_sandbox

Deployment on AWS

1. Prepare your cloud environment

Detailed information about requirements for each environment can be found in the documentation.

• VPC with subnets: public for Bastion host and private for provisioned hosts
• DNS (Route 53)
• Internet or NAT Gateway
• Bastion host in public subnet with SSH keys and access to private subnet
• SSH keys: one for Bastion and one for provisioned hosts

2. Prepare Ansible control node

Install the package pattern and required dependencies for provisioning in AWS.

sudo zypper install --type pattern sles_sap_automation
sudo zypper install python313-boto3
sudo ansible-galaxy collection install amazon.aws

3. Update all required variables

The scenario directory contains several YAML files for variables. You will need to update them with details specific to your environment.

• ansible_extravars.yml: Contains scenario specific variables that are not specific to platform, like:
  • SAP system details (e.g. SID, Instance Numbers, software version, etc.)
  • Preset and customizable variables for preconfigure and installation roles.
  • Customizable directory with definition of SAP software to be installed.

4. Execute playbook

sudo ansible-playbook ansible_playbook.yml \
  --extra-vars "@./ansible_extravars.yml" \
  --extra-vars "@./ansible_extravars_aws_ec2_vs.yml"

Deployment on Existing Hosts

1. Prepare your existing hosts

On your existing hosts, prepare an automation user (this can be a new user with sudo permissions or the root user) and generate an SSH key to be used for communication from the control node.

2. Prepare Ansible control node

Install the package pattern.

sudo zypper install --type pattern sles_sap_automation

3. Update all required variables

The scenario directory contains several YAML files for variables. You will need to update them with details specific to your environment.

• ansible_extravars.yml: Contains scenario specific variables that are not specific to platform, like:
  • SAP system details (e.g. SID, Instance Numbers, software version, etc.)
  • Preset and customizable variables for preconfigure and installation roles.
  • Customizable directory with definition of SAP software to be installed.
• optional/ansible_extravars_existing_hosts.yml: Contains details of existing hosts like:
  • Domain details
  • Customizable dictionary with definition of existing host (hostname, instance type, storage setup, etc.)
• optional/ansible_inventory_noninteractive.yml: Inventory file with existing hosts.
  • This is predefined file with expected structure, which needs to be updated with connection details to existing hosts and path to SSH keys on control node.

4. Execute playbook

sudo ansible-playbook ansible_playbook.yml \
 --extra-vars "@./ansible_extravars.yml" \
 --extra-vars "@./optional/ansible_extravars_existing_hosts.yml" \
 --inventory "./optional/ansible_inventory_noninteractive.yml"

Your Journey From Here

You’ve now seen how the different components of our SAP automation work together, from the infrastructure and installation collections to the ready-to-run deployment playbooks.

The real power of this framework lies in its flexibility. While our provided playbooks cover the most common scenarios, you are encouraged to adapt them to your specific needs.

Our playbooks are designed to fit any environment and can be used at different levels of customization:

• Out of the Box: For standard deployments, you only need to provide a handful of core variables to get a predefined scenario up and running.
• Fine-Tuned: Easily customize any deployment by changing default variables. This gives you full control over parameters like cloud instance types, disk sizes, and specific SAP product versions.
• Fully Customized: Treat our playbooks as a starting point for your own automation. You can add company-specific tasks, such as security hardening or custom monitoring, to create workflows that are perfectly tailored to your operational needs.

For a deep dive into every role, playbook, and variable, the official documentation is your new best friend.

For those who want to contribute, report issues, or see the code in development, the SAP LinuxLab upstream project on GitHub welcomes your involvement.