Fast and Secure Patching of SAP Landscapes
Start course
2h 10m

This course covers Ansible automation for SAP. We'll start off with introductions to both SAP and Ansible and then we'll present the use cases of automation with Ansible that we have built for SAP. You'll then be guided through a demonstration of an end-to-end deployment of SAP HANA and SAP applications like NetWeaver and S4/HANA.

Learning Objectives

  • Learn the fundamentals of what SAP and Ansible are and how they work
  • Learn how to patch SAP landscapes
  • Understand SAP HANA and SAP Netweaver maintenance
  • Automate the deployment of SAP S/4HANA databases with Ansible Tower
  • Automate the creation of SAP HANA and SAP S/4HANA Pacemaker Clusters
  • Automate the migration of SAP workloads from SUSE Linux Enterprise Server to Red Hat Enterprise Linux
  • Learn how to carry out SAP Application Server Autoscaling

Intended Audience

This course is intended for anyone who wants to learn how to learn how Ansible automation can be used with their SAP workloads.


To get the most from this course, you should have basic knowledge of Ansible and SAP.


So, here we have some other interesting use cases that are very useful for customers and that save them very I mean a lot of the effort and time. So, this solution is about the fast and secure patching of SAP landscapes. So what we have here is for customers that are using the cloud, so mostly Hyperscalers and that they can spin up and shut down servers as they want.

These use case what we'll enter is to create a copy of system of a productive system or a sandbox system or a development system of SAP that they already have. In order to try to test with it or apply SAP super packages on it, so that they can do their tests before doing all the patching chain. So, before starting the patching and development of sandbox they're moving it to quality and they're moving it to production. If they want first to make sure that the patches contain the features that they need to use. They can just spin up temporary system and do all the tests and then shut it down and decommission it and do all this patching in the real systems. So for this, the mechanism of the workflow it's quite similar to what we saw when we were deploying the SAP HANA database. So, we will just provision a new server on the cloud or if we're using any of the virtualization like REV or even VMware, we can do that and create and provision the virtual machine for that. Normally what we do in this solution we integrate it with Red Hat Satellite which is Red Hat's a life cycle management tool with which we can keep up to date all our servers and keep the same Patch level in all of them and we Patch all the servers with that. So we use satellite from Ansible, we trigger playbooks that will use satellite to patch the servers to the same level as the source servers that we are copying from. Then we will install SAP HANA whatever we have in in the source system and then we'll do a system copy a copy of the database from the source system to this new system that we have provisioned. We will patch it to the last level so to the same level as the source system is also at SAP level and then we will apply the SAP super packages for example that we want to try. It's important to note that this application of SAP super packages is not done automatically because it makes no sense as you know or some of you might know if you're acquainted with SAP. All the super packages when you install them you need to or the functional teams need to review all the objects that are being affected in the system in the SAP system by those patches. So, this goes back to the same question we presented or we introduced when we were having the overview of SAP.

This relates to the code custom code that customers develop in SAP. So since they, when they're developing their code, they're touching and modifying many of the standard objects of SAP. Whenever we are performing an upgrade we are applying super packages or whatever they need to check if these packages touch those objects that they have modified. So, there's a lot of manual interaction there, that's why it makes no sense to have a solution to apply automatically super packages. So this is the part of the solution that needs to be done manually but all the creation of the system or the virtual machine installation of satellites and the patching with satellite installation of the database and of the SAP application all that and the copy of the database is done with Ansible playbooks and automatically.

The tests can be also automated. We can define a test battery or a test set to try all these new functionalities that the super packages or whatever we've applied in our system will do and then yes we can define as we said an acceptance or approval change, a change sorry for this. So once all the tests have been conducted and the users don't need this system anymore, it can be decommissioned automatically also with Ansible and all the virtual machines can be destroyed, decommission etc resources will be freed and that's all done automatically.

About the Author
Learning Paths

Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).