The sap_install
Ansible Collection provides a variety of automated tasks for the configuration and installation of SAP Software.
Each Ansible Role contained within this Ansible Collection, performs a distinct set of tasks and are designed to be run independently or cohesively - depending on the outcome desired by an end-user.
This Ansible Collection executes various SAP Software installations for different SAP solution scenarios. The code structure and logic has been separated to support a flexible execution of different steps for various scenarios.
Any Ansible Roles labelled "preconfigure" and "prepare" are prerequisites, executed before the corresponding installation Ansible Roles (such as sap_hana_install
or sap_swpm
).
At a high-level, the key installation functionality of this Ansible Collection includes:
-
OS Preparation activities for SAP HANA Database Server, SAP AnyDB Database Server or SAP NetWeaver Application Server
-
SAP HANA installations via SAP HANA database lifecycle manager (HDBLCM)
- Configure Firewall rules and Hosts file for SAP HANA database server instance/s
- Install SAP Host Agent
- Install SAP HANA database server, with any SAP HANA Component (e.g. Live Cache Apps, Application Function Library etc.)
- Apply license to SAP HANA
-
SAP HANA High Availability tasks
- Install SAP HANA System Replication
- Install Linux Pacemaker, configure Pacemaker Fencing Agents for a given Infrastructure Platform
- Configure Linux Pacemaker Resource Agents for SAP HANA
-
Every SAP Software installation via SAP Software Provisioning Manager (SWPM)
- Execute SAP SWPM Unattended installation
- Using on-the-fly generated inifile.params from Ansible Variables
- Using a list of inifile parameters in an Ansible Dictionary
- Re-using an existing inifile.params
- Execute SAP SWPM Unattended installation
-
SAP NetWeaver High Availability tasks
- Install Linux Pacemaker, configure Pacemaker Fencing Agents for a given Infrastructure Platform
- Configure Linux Pacemaker Resource Agents for SAP NetWeaver ASCS/ERS
An Ansible Playbook is the file created and executed by an end-user, which imports from Ansible Collections to perform various activities on the target hosts.
The Ansible Playbook can call either an Ansible Role, or directly call the individual Ansible Modules:
- Ansible Roles (runs multiple Ansible Modules)
- Ansible Modules (and adjoining Python/Bash Functions)
It is strongly recommended to execute these Ansible Roles in accordance to best practice Ansible usage, where an Ansible Playbook is executed from a host and Ansible will login to a target host to perform the activities.
If an Ansible Playbook is executed from the target host itself (similar to logging in and running a shell script), this is known as an Ansible Playbook 'localhost execution' and is not recommended as it has limitations on SAP Software installations (particularly installations across multiple hosts).
At a high-level, complex executions with various interlinked activities are run in parallel or sequentially using the following execution structure:
Ansible Playbook
-> source Ansible Collection
-> execute Ansible Task
---> run Ansible Role
-----> run Ansible Module (e.g. built-in Ansible Module for Shell)
There are various methods to execute the Ansible Collection, dependent on the use case.
For more information, see Getting started and edit the sample Ansible Playbooks in /playbooks
.
Designed for Linux operating systems, e.g. RHEL (7.x, 8.x, 9.x) and SLES (15 SPx).
This Ansible Collection has not been tested and amended for SAP NetWeaver Application Server instantiations on IBM AIX or Windows Server.
Assumptions for executing the Ansible Roles from this Ansible Collection include:
- Registered OS
- OS Package repositories are available (from the relevant content delivery network of the OS vendor)
N.B. The Ansible Collection works with SLES from version 15 SP3 and upwards, for the following reasons:
- firewalld is used within the Ansible Collection. In SLES 15 SP3, firewalld became the replacement for nftables. See changelog SLE-16300
- SELinux is used within the Ansible Collection. While introduced earlier with community support, full support for SELinux was provided as of SLES 15 SP3. See changelog SLE-17307
Execution of Ansible Playbooks using this Ansible Collection have been tested with:
- Python 3.9.7 and above (i.e. CPython distribution)
- Ansible Core 2.12.0 and above (included with optional installation of Ansible Community Edition 5.0 and above)
- OS: macOS with Homebrew, RHEL, SLES, and containers in Task Runners (e.g. Azure DevOps)
This Ansible Collection was designed for maximum backwards compatibility, with full compatibility starting from Ansible Core 2.12.0 and above.
Note 1: Ansible 2.9 was the last release before the Ansible project was split into Ansible Core and Ansible Community Edition, and was before Ansible Collections functionality was introduced. This Ansible Collection should execute when Ansible 2.9 is used, but it is not recommended and errors should be expected (and will not be resolved).
Note 2: Ansible Core versions prior to 2.14.12 , 2.15.8 , and 2.16.1 where CVE-2023-5764
(templating inside that
statement of assert
Ansible Tasks) security fix was addressed, will work after v1.3.4
of this Ansible Collection. Otherwise an error similar to the following will occur:
fatal: [host01]: FAILED! =>
msg: 'The conditional check ''13 <= 128'' failed. The error was: Conditional is marked as unsafe, and cannot be evaluated.'
Various SAP Software solutions have been extensively tested.
Prior to each release, basic scenarios are executed to confirm functionality is working as expected; including SAP S/4HANA installation.
Important note: it is not possible for the project maintainers to test every SAP Software installation and solution scenario for each OS hosted on each Infrastructure Platform, if an error is identified please raise a GitHub Issue.