So, now let's take a look at the Ansible use cases for SAP. So, the solutions that we have been building so far and a bit of the roadmap of what we want to build to make things easier for SAP maintenance and administration. So, the first use case and first solution that we've developed is the automation of the deployment of SAP HANA database with Ansible Tower.

It's an end-to-end deployment. So, since we are provisioning till we have the HANA database installed and running and we can hand it over to the SAP Basis team. Here we can see the diagram of the workflow of what we are going to do. So, it's similar to what we saw at the beginning of the introduction of Ansible and how things were done before the Automation came in play. So instead of doing every step separately and by separate teams, we are doing everything together as you can see. There's a box containing everything. So, we have the Hardware, so apart from that or from then on we do the rest of the things in just one workflow that's been defined in Ansible Tower. So, the installation of the operating system, the creation of the virtual machine, we're using virtualization and then the patching and the configuration of the operating system to make it suitable to the installer for the installation of SAP HANA. Then the validation and then as I said that we hand over to the SAP base team, so they can start managing the HANA database. Okay! So, we can see, as we saw before how the system admin will trigger the playbooks. In this case we're going to use just a workflow that's been defined in Ansible Tower. So, let's take a look at tower and let's first have a work around to see how it works, what its structure looks like etc. Okay! So, we can see here the URL for to connect to the Ansible Automation Platform.

It was called before Ansible Tower many people to call it Ansible Tower.

So, we just log on, we will log on as admin but you can log on as any other user that you have defined in your system. So, as we said to build a security baseline. So, each user will have access just to some views, to some playbooks, etc. Here we go to the Dashboard.

We can see here the number of Hosts that are connect are connected to our tower and then if there are Hosts where some jobs have Failed, the inventories that we have defined for the different hosts, if there are any issues with the dynamic inventory if we are using it. If its having issues to sync to some of the servers in our landscape. Then the projects that we will see in more detail in a bit and we will see what the projects are. If there are problems with those projects synchronizing and then well Job Status. So, this is a good way to take, I mean to keep an eye on what jobs have been executed, for statistics as well how the tower is being used, which are the servers that are being more affected or where more jobs have been running, if any of them are failing. For some reason we need to review the service, the connection, how the projects are  synchronized etc. So, then let's go to Inventories and we can see here for this training we have defined a group. A group of inventors that are on inventory group sorry that's called sap-hosts. Okay!

If we go to sap-hosts we can see some variables that we will see in a bit as well but let's go back to inventories. Let's see HOSTS and we can see more groups here. So, we have two servers. There are four HANA installations. Okay! where we will run the installation of the database and there's another server where we will run the S/4HANA installation, the application installation in another video. For the moment we're going to just to work with this to hana. If we go back to INVENTORIES we've seen that we had defined some variables. So, these variables are defined as our inventory level as we can see. So, they will affect to all the servers that are in our inventory. So, this is another thing about the level of nesting of variables and how we want to modify or add variables depending on the on the host that we are going to be using the playbooks on. As we said this is the top of of our inventory and those these variables will affect all of them. What have we do here so yeah some variables to be able to modify the etc hosts files in the server so that they can be talking to each other in the installation and and then in the normal activity. Some other variables for one of the system rows that I will explain later on what they what they entail and what they do and also about the host staging installation that we're going to use. So, host a sap host station has to be installed in all the servers. So, for the Hana servers and also we will install it in the application server as for HANA. So, since this is global, this is going to be this is going to apply to all the servers that's why we have defined all these variables in the topmost level and the type of installation for the support station where where the software will be placed and yeah all the path to the server. Then if we go to the GROUPS of HANA servers or we go to the hana server, sorry here we will have some more variables only for them. So, for example for this we will have the variables to partition the file systems and well the partition the disks and create the file systems that will be needed for the hana installation. So the hana shared the data file system and the log file system, so we can absolutely modify here the mount_points, also the size that we need. So this is good to have a template as I mentioned before. If we know that every so often we need to provision a new hana service with a certain amount of resources we can create our template here with a fixed amount of resources of disk memory etc and just run it whenever we want. We can use also dynamic variables and uh so that we can change this dynamically. It's another big advantage. There's also the type of installation that we will use for the database, the path to where the the server is. So, normally the most common practice is to have an nfs server sharing all the software and it will be accessed by tower or it can be even in the server where Ansible Tower is installed and it will be shared across the servers where we are going to perform the installations.

Okay! So, for the other HANA server we have the same because we are going to do an installation of exactly the same HANA system. So that later on in another video we can create what we can enable the HANA system replication and create a pacemaker cluster to have high availability that's why we have exactly the same variables for those two HANA servers. Okay! and then for the S/4HANA we will look at it in all the video and we will do the installation of the applications. We will take a closer look at the variables for it.

So, those are the inventories. Here we have all the access. So, the most granular parts of the access users in this example since I will be the only one running the playbooks. I'm using the admin user and that's it but here we would create a user for each person that will be logging on to the tower and running the playbooks. We will give the role based access control. So, depending on on the team the each user belongs to they will have different different accesses. So, as we said some of the users for example the network team will have access only to the network related playbooks that are stored in the tower. The SAP Basis team will have only access to this playbook for example to installation or some tables to monitor the sap host and things like that. So this is done at user level but also at team level and organization level. So teams we haven't defined any either because we just have one user as we said but here we would define for example what we just said the network team, the SAP Basis team, the infrastructure team, the OS team. We have all them here and we can add permissions also at team level and organizations that can be anything in your company. So for example if you want to have an organization for all the financial related hosts so you will have the teams that manage the host for that part of the organization. If you want to have another organization for the HR part of it you will have it here as well. As we said before AnsibleTower or Ansible platform is the way to control the only point of entering control of all your IT infrastructure and it provides the possibility of the features or allows you to treat and handle your infrastructure as code which is the tendency of many companies at the moment. So, anything that you need to do in your infrastructure be that application level, operating system or a virtual machine level can be done with Ansible Tower and Ansible as code. You don't need to physically do anything anymore and that's one of the beauties of Ansible. Okay! So, here we can create scripts that will be targeting inventories or servers of our inventory. For example, if we want to run certain tasks every day of monitoring servers or starting or shutting servers that are not going to be used overnight, we can have those scripts here that will apply to as we said a certain service in the inventory and then let's take a look at what it's really important when we are going to use the playbooks. So, the most basic part is to create a project.

Okay! Here we can see the different projects. So, there will be all the best practices to create a Project pair playbook okay or payroll that we are going to use. So, if we are going to for example create as we saw the or partition the disk and create the file systems for a SAP HANA installation, we will have a playbook for that and we will create a project associated to it. If we go inside we can see we can here also add variables at the project level if we need to but the main thing here is to say what the source for this playbook or this project will be. So, here we have put the URL of a Github repo where we have all our SAP related playbooks and roles. Okay! so, it will be connected to this. Another very good thing is that Ansible Tower uses CI/CD.

So, Continuous Integration, Continuous Deployment, that means instead of having to use for example other CI/CD tools like Jenkins you can just use tower but you can integrate those other CI/CD tools as well. You can also use Github, Github options and Github applications as a CI/CD tool as well.  

So that every time you modify or any developer modifies anything on the Github repository and pull request is created and that modification input request is accepted and it goes into production in the repository that will be fed back to tower. So, it will be updated and tower will be running all the time the latest update of the code. Okay! the latest version.

So that's very important as well so that we don't have differences or drifts between the code that developers are using and testing and what is being used in production. So, the moment it is accepted, it will be used in production with tower. Okay! We have all the other types of sources not only the Github repositories but we have also Mercurial, I'm sorry this can be also connected to Red Hat Insights towers so, they can integrate together. We will see this use case in a bit.

Okay! We can define notifications as well for the process for each time a playbook or the role is run. We can configure some notifications to make sure that nothing goes unnoticed. For example we can schedule their execution etc.

So, the next level is to create a Template using the Projects. So, here we can see that also we have associated a template to every project that we have. We go back to the sap-storage.

We have created a template for that. Okay! with a description here we specify the host it will be limited to or where where this template or this workflow will be run. So, it will be limited to sap-host. So, this way we make sure that these actions all these tasks won't be executed in a server that whether we don't want them to to be run. Okay! We can yeah here we specify the project that is linked to and here the Credentials. So, as we were saying SSH is used to connect to any server that uses a Unix-based so that has a Unix based operating system.

For windows system we said that we use WinRM. So, we would use a windows key but what we do is always to upload the keys securely to Ansible Tower so that we don't need at any moment to enter any password. We can do it as well at not a playbook level and we will see this as well. So, if we need some password for an installation that we are going to do we can specify it and we can see it here but the best practices are to use apart from the ssh key to use some other security features that are called Ansible Vaults so that all the passports are hashed. They are not in clear view you cannot read them. So you will still be able to run the playbooks if you have permissions to it but you won't see the passwords. So that's the best practice. Here we can see the options, so this enabled privilege escalation is what we saw when we were taking a look on a sample of the playbook where we said that we could become the user with elevated privileges to run tasks. Normally we enable concurrent jobs so that a job can be running different servers at the same time for example here that we are going to run the installation of HANA into servers at the same time. We will enable the concrete jobs here that's where we store the credentials. Okay! So, this is the ssh-key that will be used as we just saw to connect to the servers and run the playbooks there but we can add any type of credentials as we said like for example a hyperscaler's credentials if you haven't asked your account and you're going to run playbooks and on virtual machines that you have created with your account. You can store them there. So any type of credentials can be stored here.

As I said it has pretty complex layer of security, Ansible Tower. We go back to Templates.

These are the workflows that we have defined using the other templates. So, if we go to the HANA deployment for example, well this is, we can take a look at the WORKFLOW VISUALIZER.

So, here you will see I'm going to zoom in because otherwise it's going to be difficult to see. Just with drag and drop we can create a WORKFLOW with all the projects that means and all the templates, that means all the playbooks that we want to run to create a whole pipeline and end-to-end deployment. So, from here we will execute tasks to install the virtual machine, to install the operating system and then register the operating system which is RHEL. In this case it's a RHEL8, register it to the RHEL for SAP channels. So, in order to have all of the software that is related to SAP for RHEL, to have it available to with it will be registered with subscription manager and then we have this sap-storage that's what we saw to configure the file systems to install SAP HANA. Then we will install the sap-hostagent and then we will run some roles that are called SAP system roles and what they do is to apply all the nodes that SAP delivers or with the prerequisites to install SAP HANA. Well this one in particular is called sap-preconfigure. So, it has nodes that are common to SAP HANA installations and an sap-netweaver and S4/HANA installation. So, all the nodes that are common for both, it will be installed and here we have some other also sap-hana-preconfigure that will only apply the nodes that are for SAP HANA installations. Okay! so in this video we'll stop here. We will run up to here but won't go further with the installation of the application. The application layer we will do that in a different video. So what we will do is to edit this same this pipeline so that you can see how to edit it and what we want to stay with. So, it's as easy as just deleting the steps that we won't need here. We will need the sap-netweaver- preconfigure because that's to apply the nodes for the sap-netweaver for HANA installation.

So, we will just DELETE it. What else do we have in here. So, this is the sap-hana deployment that will install the sap-hana in both servers because we've seen that when we looked at the template it said host and we had the group of SAP HANA. So, it would be applied the scope of the playbook will be the two hana hosts and we will delete this because this is the next tier, the next layer the application of the S/4HANA application and we will delete this as well because this is the configuration of HANA system replication and also we will see this in another video. For the moment we will click this, we will DELETE this, we SAVE it and just before launching it another important point is that after any step we can ADD a SURVEY.

With this survey this is an acceptance step or a validation step. So, for example if after the host has been subscribed to the RHEL for SAP channels to the right repos if we need to validate that. We can ADD a SURVEY there. So, the Workflow will pause until we have accepted and validated this. Then we can continue the execution so that's another very useful and another very useful point for for workflows.

Okay! So, after we have done that we just need to go to the template that we want to run. This one for example and either click LAUNCH here or here in the rocket whatever we prefer. Let's do it here and let's see what it looks like. So, we will see the whole workflow that we just saw if I zoom in a bit and we can see that now this details word has appeared in the box that is currently being executed. So, if we go into details we will see the log of the playbook and how it is everything that it's doing. So, just what we saw before when we were taking a look at the playbooks and the syntax etc. We saw that for each task we give a name and a relevant name so that we can track and know what it's doing. So, here you can see what is being done at each moment. So, the task that is being used so as we said this playbook after having the virtual machine ready is registering the operating system to the RHEL for SAP channels and as I said making those reports available so that we can download the SAP system roles that apply all this sap pre requirements that we needed, gives access also to the high availability repository so that we can download and apply the software to deploy the pacemaker clusters etc.

So, yeah basically we will have a real-time following of the execution here. So, sap- repositories has finished, sap-storage has finished as well because we can see that step in green and now we are running this, the installation of the sap-hostagent. If we go to the sap-storage here we can see the same. So all the tasks that have been done. So set the list of volumes for verification, remove the obsolete mounts, if there are any, set up the current mounts, create the logical volumes etc but the host agent has been deployed already.

Okay! So, it's done everything that it needed and right now it must be in the sap-preconfigure step. So as we said this one is applying all the sap nodes that are required for both SAP HANA and SAP netweaver or SAP application installation so, it has quite a few nodes so it will take a bit longer. In the meantime, we can log on to the servers if we want just to see what's being done. Right now, I have logged on to the bastion server that we are using where the Ansible Tower is and what we are using as jump host to connect to the different hosts that are involved in this installation. So, we can connect to the hana1 server for example.

Yes, okay and we should be able to see already the file systems for the HANA installation because as we saw the playbook has succeeded, that part of the workflow has been done. So, we look at the yeah we can see there that we have the hana/data, hana/log and hana/shared a file system. So, just for those of you who don't know when you're going to install SAP HANA you need to create three file systems. So, the hana/shared will have all the installation and with all the binaries needed for them for the working for HANA to work and all the scripts and everything that's going to be created and copied to the hana/shared directory. Then the data files of the database are in hana/data and all the log files where all the transactions are being recorded are in hana/log.

Okay! So, this has been created we can see the size, that's that we saw that in the variables that we were given 128G to the hana/data file system, 64 to the hana/log and yeah 256 to the hana/shared. Okay! and we can already see since the host agent has been installed, we should be able to see something where some processes with that running with our user with the sub adm user. So, let's see sorry this is typo.

Okay! So, here we can see that the host station is running okay and with user sapadm, that's the admin user for the sap host agent. So let's go back to the tower now and let's see where we are.

Now it's applying the nodes that are particularly important for SAP HANA.

So, also installing the packages for that. So, if we go back to the operating system at the moment, we won't see any database or anything if we try to look for the sid, the name of the instance of SAP HANA that we are using, we are setting the variable as rhe. So, the user that will be created to administrate the database would be rheadm. So, at the moment since the installation has not started yet, we don't have that user. So just so you see that there's nothing installed at the moment here. We go to the other HANA server, we will see the same, we can see the right file systems being there.

Okay! We can see the the sapadm user running the sap host agent.

Okay! but no rheadm user so far, we try to change to rhedm there's nothing. So, we will wait until the installation of SAP HANA has completed. Okay! So, these notes for SAP HANA have been successfully applied. So, 73 different tasks, either there were 30, there were no that had no relevance for these servers. Now for this installation. Okay! So, we are now the last step of the HANA deployment.

So, now the database is being installed. That will be the last step of this video.

Let's see what it's doing. If we want to take a closer look at the tasks that are being executed here. Well another thing to notice here is that every time we run a playbook the first task is gathering facts. What it's doing is to gather all the features of the server or all the hardware, all the resources that it has. So, each time that a playbook is run by default is doing this.

We can skip this and there's a keyword or there's an option in Ansible, when we write a playbook to skip the gathering facts because we might not need it and it just takes time.

Okay! So, we have this whole workflow now the whole pipeline that has finished. You can see here the total ELAPSED time. So, it's been 22 minutes for an end-to-end deployment of SAP HANA which is really really quick and as we were saying compared to the time that it normally used to take with provision in the virtual machines installing the operating system applying all the nodes, node by node manually which is a real pain and now it's done by the sap system, also the sap-preconfigure, sap-hana-preconfigure. Then doing the installation of the host-agent and the installation of HANA, 22 minutes is nothing, really nothing. It makes the life of sap basis administrators much much easier. So, me coming from that background I really appreciate where what can be done with within Ansible and automation in general. So, if we look at the locks of the last step of the installation once more, you can see if we go back to the system and we now try to change to the admin user rheadm, we will see very oh sorry because I was not a privileged user so, let me go back I change to root first and then I will log on as the admin user and then if we look at the HANA processes we will see that they're all there so the HANA database is up and running with the indexserver, nameserver all of the processes, let's do the same on the other HANA host, log on to it, change to root and then to the admin user of the HANA installation and we do the same, we can see all the processes running there.

Okay! So when we want to enable the HANA system replication in later video, we will do we will do it between these two servers hana1 and hana2 and we will see how they communicate, how we can check the status of the replication with the Python scripts etc. The cluster will be created with both servers as well and the installation of the S/4HANA of the application will be done in the other server in the S/4HANA server. Okay! So, this is it for this use case for the end-to-end deployment of an SAP HANA installation with the provision of the server. So, I hope this is clear for you and that you've learnt how to do this and in a very very easy way with Ansible.