 So let's just start a bit. I know that most of you already know Ansible, but I would like that for those who don't know Ansible or just to get a clear or a basic knowledge about Ansible, let's just start off why we need Ansible. Well, let's think about this Ops guy, okay, that he is working in a small company with just six servers, maybe typically, I mean, I work in that way, right? That you've got one database and then you've got another database server as a mirroring database, case of, you know, of a cap. But then you've got two vacans, maybe one from 10 and then one a Revers proxy, one proxy to just, you know, do some kind of load balancing with all these funny sticky sessions, right? So, yeah, that's fine. And you can maintain all this infrastructure manually, right? You just, yeah, you log in SSH, two vacans, SSH to database, yeah, that's fine, it works. The problem is when devs start releasing pretty more often. For example, they are start adopting continuous integration, continuous delivery, and then they start releasing versions every week. Then, okay, yeah, every week you need to do SSH and copying jar files, wire files, wherever you've got it into this server, so yeah, it works. Also, probably if you're getting more and more complex, you've got multiple environments to manage. Maybe you've got staging environment, performance environment, production environment, so it's not just six servers. Now, it's a lot of more servers that you want to deploy things inside. And another thing that can happen is that you are a successful company and you start getting more and more traffic to your application, to your, you know, web application. So now you've got high traffic, so you need to scale up your infrastructure, not just two vacans, you want more vacans, four vacans, six vacans. So yeah, it's not six servers anymore, it's a lot of more servers. So the ops, yeah, it may get, well, it's a lot of, you know, I've got a lot of work to do. And what is even more important is that since you are doing everything in the manual steps, all your infrastructure can collapse because maybe you missed to copy, I don't know which file to, in which specific directory, right? So Ansible comes to the rescue. So Ansible will help you to automate all of this. So what is Ansible? Okay, Ansible, first of all, it helps you on the automation of your environment. So it helps you automate the maintaining of your environments. You're gonna say the virtual machines, it helps you on the automation of deploying for also your application to also configure your application. It helps you to, you know, you have multiple environments and then you can configure your application depending on each of the environment. And as I said, it helps you also to deploy your application because at the end, if you are not in production, your application has zero value. Sorry to say that. You can just follow the best practices in patterns, in language and whatever. But if your application is not in production, it gives you zero value. So it's really important to deploy it and it's really important that you can automate it. And Ansible helps you on this, in this way, okay? So how it works Ansible? Basically Ansible, you've got a machine that is running Ansible, that you run Ansible and then there is the servers. These are the servers that you are maintaining, okay? This is your production servers, if you will. And then you've got two important pieces in Ansible. First one is the inventory. The inventory is where you define where are these servers? Okay, so you say this server is in this IP, this one in this other IP, this one in this other IP. Okay, so this is just the inventory. What are you managing with Ansible? And then we've got the playbooks. And the playbooks are the instructions that you want to run against these servers. For example, patching the kernel or copying some files or creating some users, whatever, this is what you want to run. And this local machine which runs Ansible will do an SSH connection to each of these servers and apply these playbooks. What is really also important to know is that these playbooks can run against these servers using SSH or it can also run in the local machine. So you can just run playbooks in the same local machine. So for example, if you need to install a testing tool in this machine to test that this application that you deployed here works, you can also use the playbooks to install these dependencies here. So you're just creating a complete solution. Let's say the process that it's reproducible, okay? That you do not need to install nothing manually. You just run Ansible and Ansible will configure everything. So let me just, in case that you have never seen Ansible, let me show you here, I've got my, well, I've got my virtual machine where, okay, it's fine. Okay, this is, I've got my virtual machine running and let's try to, let's say, for example, install a Quarkus application. The same thing that you've seen before with Kevin. Okay, let's deploy this application into a virtual machine, and wait, maybe it will be easier. I don't know if easier, but more visible here. Here, okay. So this is a playbook, sorry, it's just a ML file. Well, if you're using Kubernetes, probably you're super happy to just write more ML files, I know, but that's how it works. And basically it has the tasks and I said, what I want to apply to my virtual machine? Yeah, I want to install Java 17. So I just create, I just use the DNF module because I'm using a virtual machine, which is a rel. So since it's a rel, it means that, yeah, I can use DNF. So I just say, hey, run DNF, install Java 17 open JDK. Then I just create the directory slash bar slash hello. I copy my application. I copy my application from my laptop, my local machine to the remote machine. Then I configure Supervisor D, right? Because I want to have my application as a demon inside my virtual machine. And then I reconfigure Supervisor D and I run it. Okay, this is how it works. Now, let me go here, let me remove one of this last because it takes a bit of time. And finally, I print the result in this case, wait, let me in. Okay, now I'm going to run it. I'm going to run, you see here, Ansible Playbook Minus I inventory. So in this inventory file, it's just the IP, the port, the username and where are the keys to authenticate with SSH and then the playbook, which is the instructions that I want to use. Okay, you see that it goes pretty fast. Basically here what I'm doing is opening SSH connection automatically to my virtual machine. And in a start, in this case, installing the packages, the Java 17, then creating directories, copying my application, starting my application and so on. So it's something that you can see it works pretty fast. Just now creating, now I move it, I installed Java. I created the directory. Now I'm copying the jar file. I'm configuring the Supervisor D You'll see here, well, it's a bit of small, I know, but you'll see some, and at some point that Supervisor D is restarted and changed. And yeah, I've seen a few seconds. Okay, so now, okay, it's working. I just applied all this. And if I go inside my virtual machine here, you will see, or I do a crawl. I think that if I do a crawl, it should work as well, but I don't remember. I don't want to spend a lot of time here. Hello, I think that it's, yeah, you see that the application has been deployed. It's localhost because I've mapped the virtual machine IP to the localhost. It's easier to not having to check the IP, but you see that, yeah, then the application is here up and running. You can see that if I close the logs and I do a crawl to localhost now, you'll see that now it's getting fillet to connect. So you can see that I really updated the virtual machine. Then I'm going here. Let's continue because you might say, okay, yeah, it's nice. I mean that, you know, you run it one YAML file and it configures everything, but I'm using Kubernetes. So why I should take care of Ansible? You know, it's a full question. And I'd like to say that there is several reasons. Okay. Let's just start for the first one. Kubernetes at the very end are nodes, right? Are machines. Are machines that maybe are running on rail, maybe in any other distribution, but are Linux. Kubernetes is Linux. And you need to patch the kernel. You need to install Kubernetes, maybe. You need to maintain Kubernetes. You need to update Kubernetes. So, okay, there is still machines there, virtual machines or not, but are still machines. So you can, you still need Ansible to configure these nodes, even though they are running Kubernetes, but this doesn't abstract you from the machines. There is another reason. Maybe you are still using Ansible and after applying some kind of Ansible playbooks, you want to apply some Kubernetes manifest. And Ansible can do that. We'll see. You will see that sometimes you can just define YAML files inside an Ansible playbook and then apply it to the Kubernetes cluster. So that's another use case. And there are other ones, which is, for example, consuming changes from a Kubernetes cluster. So I don't know if you ever faced that problem. It happened to me in the past that I've got my application with a config map, right? A config map for all the properties of this application. I apply the deployment. I apply the config map. Then this config map is read and put it inside the deployment. So my application has this config map. And then you say, oh, I want to change the config map. And I want to change any value in the config map. So you change the config map. You do keep Karel apply. And what's happened? The config map object is updated, but your pod doesn't contain these new values. Because changing the config map doesn't mean that you are running update your application. So your application are still with the old values. With Ansible, and this is something that we're going to see, we are able to detect these changes, for example, and restart the application. Then how we can do this with one project that is named EDA or Event Driver Ansible. Basically, it's Ansible, but with a wrapper around Ansible, which lets you subscribe to events. And these events can be anything. For example, a webhook. For example, you can configure Ansible to react when someone merged a pull request to a github repository. So you configure the webhook. This webhook will send an event to the Event Driver Ansible, and you can react. For example, applying these Ansible playbooks. Or an event can be, as I said before, oh, I created a config map inside my Kubernetes cluster. So the creation of the config map can throw an event saying, hey, Ansible, there's a new config map out there. And then what you can do is just say, oh, there's a config map. Great. This config map is used in these pods. So I'm going to restart these pods. You can see that this is something that you do not get this out of the box with Kubernetes. But if you use Ansible, you can fix that problem that you might have. So as I said, Event Driver Ansible works in this way. We've got the event source, which it's a lot of events. It can be a Kubernetes event. It can be an alert manager event or Prometheus event. So you can start monitoring the performance of your application and react accordingly. We are going to see it in a few moments that you could, for example, start monitoring the memory used by a pod. And when it's reaching the limit that you put it in the deployment, then add the new replica automatically. So one of the great things about this approach is that you do not need to take care of taking any action in the case of getting the limit out of memory or any other, for example, business monitoring unit. Then if you are still using Ansible, you know that there is the playbooks. There is the demo, but now there is another file, which is the rulebook. And the rulebook is where you configure all this stuff. So where you configure the sources. So what are the events? Which are the events that you want to get it? The rules, where do you want to do something? For example, I'm listening for any creation of the config map, but I only want to apply something when I'm creating the config map, not when I'm deleting the config map. So you can do these kind of things. And finally, the actions. Which playbooks do you want to run when these conditions are met? Then there is some, well, there was this, I'm going to show you just with the sources because yeah, the demo is a bit complicated. So I just want to mention it and show you the files. Basically, as I said before, sometimes we've got a pod, this pod, we inject the config map, but then what's happened when I change this config map? This config map is changed into Kubernetes, but the pod has no clue that there is a new config map. So we need to restart it. You can do this manually, of course, but you can use Ansible EDA. Basically, when Kubernetes sends an event of A, there is a new config map there. Here, okay, this is the Kubernetes API. It will send an event to Ansible EDA. And Ansible EDA will be configured with some kind of rulebook saying listen for all the events that involves the creation of a config map. Then it will get this event and run Ansible, running some kind of playbooks. And these playbooks could be restart this pod, or it could be, for example, send an email to the Kubernetes administrator saying hey Kubernetes administrator, there is a new config map, please update the pod or trigger the rolling update. So let me show you the YAML files to do that and think that is this one. Okay, you see that here? It's just a simple YAML file. Well, I've got here, yeah, you need to create the roles to be able to listen for Kubernetes events. You know that you need to do a special roles for listening pods, deployment services, jobs and config maps that you can list, get, watch, create. So this is something that, yeah, if you're in Kubernetes, you already know that it's just giving permission to this pod to listen Kubernetes events. And then out there here, I'm just deploying the Ansible EDA. Now, what does this Ansible EDA contain? It's here, it's here, okay. We can see this one, which is the most complete. This, well, let me start with the first. So here, basically, I'm just configuring the Ansible EDA part saying, look, I want to listen for new config, or when a config map is changed or is added. And I do it in this way. It says sources is where I define what is the event and say, look, listen for any config map created in the default namespace. This is what I'm doing. I'm just saying, hey, listen for this. Of course, you could say things like listen for a webhook or listen for any other thing. In this case, it's the creation of a config map. And then I say here, a rule, say, hey, when the config map is an added, so I'm not deleting the config map, and the config map then run this Playbook, which is this one, Kubernetes EDA Playbook Mail. So every time that I create a new config map inside a Kubernetes cluster, it's going to run this Playbook. And this Playbook is here, which is just a Playbook. I'm saying, look, I want to run this in the local host, because of course I want to run it inside the pot, inside the Kubernetes, so I don't want to do an SSH connection to another pot. I just want to run something, and this something is just sending an email with a config map change. And you can see here that I'm using this Community General Mail plugin, which says, look, send an email to this host, to this port, from this to with this new, this subject, and the body says, okay, config map in name of space. And you see here that you can get the information from the event. I'm getting the name of space with a name, and here is the name of the config map. It has been provisioned. So, with just this, these 2ML files and deploying these to Kubernetes, what I'm doing is every time that someone deploys a new config map, sends an email to the Kubernetes administrator saying, hey, there is a new config map. Please roll out or run update this pot. Of course, you could do it automatically here. You could say, no, I don't want to send an email. What I want to do is, I want to roll out of this deployment. You can do it. It works. But in this case, I know that maybe sometimes people will say, doing an automatic rolling update, maybe it's not the best thing. So, I prefer to send in an email and someone will take care of it. Of course, you can send a message to a Slack or whatever. Then, that's just one of the great things that you can do with Ansible, right? And Kubernetes, just listening events. Again, it can be any event. It can be this, that new config map, new pod, wherever, and apply some playbooks. But also, you might say, yeah, I'm using Kubernetes, and I know that in Kubernetes, we are probably using microservices or services architecture. And all our services architecture should have these cross-cutting concerns, right? So, all your services, apart from being implemented with any language, you need to find a way to discover other services, to invoke other services. They need to be elastic. They need to be resilient. Pipeline needs to be the authentication. And one of the big changes in the microservices that we didn't have it before is all the observability way. So, we need to be able to know exactly what's happening inside your architecture. You need to monitor your service and say, look, I've got 50 server services, and seems that these services is getting out of memory, or seems that it's behaving not very well for performance issues, or it's failing more than usually happens. Let's figure out, right? So, this is something really important. You need to be always aware of what's going on inside my architecture and React. If you see that there is a pod that is getting out of memory, and, for example, create another pod, or maybe you're getting out of memory of your nodes. So, if you alert in advance, you can, for example, add a new node to your Kubernetes cluster. So, what we can do with Ansible is doing all these reaction of failures that can fix that problem automatically. So, you do not need to stay there watching the Ansible, I'm sorry, the Prometheus and the Grafana and say, oh, look, this pod is getting out of memory. So, yeah, let's create another pod, right? You don't need to do that. Ansible can do that for you. And what is even important is that you don't need to be at 3 a.m. trying to figure out why it's getting out of memory, Ansible can do that automatically for you. So, this is what we're going to see now in the demo. And it's a bit complex, hope that it works, because demo gods hope that are with me, because I've not burned any Windows CD today, so I don't know if demo gods are with me, but let's see it. So, the idea is I've got here my applications. It can be a Python application, a Springboard application, a Quarkus application, it doesn't matter. And as you know, in Prometheus, you're exposing the slash metrics URL. So, here I'm exposing the metrics of my service. The amount of memory that is using, the motor memory that is free, the, I don't know, the CPUs, the garbage collector, everything, it's there. Then, here we're going to have Prometheus. And Prometheus is going to start, you know, getting all this information from these applications. And I configure some alerts to Prometheus. Basically, I'm saying, hey, if there is any pod that is getting out of memory, then fire an alert, find an alert to alert manager. So, this is what I'm doing. I'm just sending alerts that there is one pod that is getting out of memory. And what is the tricky thing, is that then alert manager, it will send a hook to AnsibleEva saying, hey, Ansible, you know what? There is one pod, this pod, that is getting out of memory. Do you want to do something automatically? And what it's going to do, AnsibleEva, is say, oh, yes, I can do it. Just lend me, in this case, for example, a scale to two replicas, three replicas, or plus one replica of that pod. So, automatically, without doing anything, Ansible will detect the problem and will fix it automatically. Okay? So, let's see if it works, because it's here. Let me go to topology. So, here you will see all the pieces that I told you. This is the Prometheus. This is the alert manager. This is the Quarkus application. Okay? And this is the Ansible. So, you see that I've got all the pieces. And I've got here the Prometheus operator, because if you want to deploy all these things, all the Prometheus alert manager and so on, into Kubernetes, I recommend you to use the Prometheus operator, because it's super easy. Then, what else? Let me show you here. These are the YAML files to deploy everything. This is a deployment of a Quarkus application. Here, I'm deploying Prometheus. Here, you can see it's super easy. The Prometheus part is here. I'm just saying, hey, there is a kind of Prometheus, and basically I'm saying, and there is an alert manager, and this is how I want to match the pods that I'm running. These are the pods that I want to just get from a slash metrics, all the metrics that are providing and putting together. Then, there is also the alert manager. So, if you want to deploy an alert manager, you just need to do alert manager config. And what is important here is this one. Here, I'm just saying, alert manager, when you get a problem, Prometheus notifies you a problem, just send this problem to Ansible EDA. This is what you're going to do. This is the tricky part. Here, I'm just deploying the alert manager with just this small object. Now, I think that, more or less, everything is done. If you want, we can just check. This is, again, another deployment for Ansible EDA. So, nothing really complicated. And here, let's see if they hear. And this is the Prometheus. You can see Prometheus in targets. You see that this is the pod. This is my application. You see that my application has been monitored. And I think that in rules, I've got one rule, basically two rules. One rule is if the service is down, and the other rule is if the current memory, I mean, this is an example because for demo purposes, but I'm saying if the current memory is more than 20, I just said, okay, maybe I'm reaching the limit and then send an alert. And if I go here in the alert, you see that there is no alert done yet. Now, how I start consuming memory, well, I've done a tricky thing that basically here is an endpoint that I said, hey, I want to consume this amount of memory and it just start consuming this amount of memory. Now, it's five. You can see here that it's not here. Graph rules, if I click it here and I put it here at zero. You see that now I'm consuming five. Five backwards, okay? Now, I'm going to increase it to 25. So, I go here and put it here, 25. So, now I'm consuming 30. You see here, it's very executed. Well, now, you know what's happening in Prometheus, right? That it's polling, right? It's a polling process. So, you need to wait maybe 10 seconds until it is scrapped the data. When it has the data, then it happens the same with other managers. So, the process is a bit slow, but now it's 30. And if you check here in the rules wait, you see here that it says, oh, yes, there is something that it's failing. If I go to other manager and I refresh, one, usually it takes a bit of time. I mean, I'm not a bit worried of it. It's still not one. No other scripts found. Come on. Well, we're going to see it at the end. You'll see that this monitor, it just scales to two instances. Now it's one. But for now, come on. Oh, let me check the logs. But sometimes it takes a bit of time. I mean, it's possible logs. Okay, let's continue with the slides and then we'll fill it out. Then, yeah, but I know that this could happen. I mean, sometimes when I demo it this morning, it took me like three, four, five minutes until, you know, the Prometheus gets a change, sends it to other manager, sends to Ansible, Ansible React, and so on. So, yeah, it's a long process. But, yeah, then it works. But first of all, let's wind down, because as you've seen, Ansible can be used as a provisioning tool, but also as a configuration tool. So, you can use Ansible for provision virtual machines or for provision cloud virtual machines. You can use Ansible to create some kind of EC2 instances. That's fine. It works. But also, it can be used as a configuration tool to deploy your application, to configure your application. Probably, as I said, you can use Ansible for the cloud virtual machines. This is the most natural way of Ansible. But now, you can also use it in Kubernetes in some specific use cases, as I showed you today. And the last thing is that this is a super new project which is the Event Driven Ansible that you can make it to react to the events automatically and apply some custom countermeasures, as I showed you here. Okay, there is a problem. So, I react this change and I do some countermeasures like, for example, increasing the number of pods that I've got running. Also, remember that, I think that was last week, it's open the Ansible like the speed, right? Yeah, AI, a thingy that helps you creating all these Ansible playbooks. If you're interested in GitOps and Kubernetes, this is the books that you can download it for free in this QR code. And here are all the links that I've showed you today. These are the demos that you can run it on your own. They are plain Kubernetes, so you can run it in Minikube without any problems. It's a step-by-step explain how you can run them. And then, yeah, you've got here the end-of-depth-slash-learn. If you go here, you can just click it now, you see that here in the top you can see a lot of content. There is the Ansible. So, if you want to learn about Ansible, you can just click it here and there is this tutorial and there is a slide. You click it and in case of Ansible, yeah, you'll see that it helps you, for example, in templates, in roles, in other collections and the Kubernetes part. So, you've got everything here, you can see explain it very well in a step-by-step. So, you can always, I mean, I will say that if you want to learn about the Ansible and have a good overview of Ansible, then this tutorial is for you. So, yeah, here we are. You see here that we've got one alert. This is the alert that I created. Well, that created. I get it and then if I go here and go to topology you'll see that work was now, it has two pots. You see, I've not done anything. I know it has been a bit slow. I know that some of you didn't trust, said, oh, I'm sure it's not going to work. No, as I said, it takes a bit of time because it's all is appalling system. Depending on how you configure the amount of time of the appalling, then it takes more seconds, right? But you've seen that I just simulated that one pot was reaching the limit of the memory that can use and I just monitor it with Prometheus, send it an alert, notify it to Ansible to do something, apply some kind of counter-measure which in this case was, okay, let's create another pot. So now the load is going to be load balancer between both pots and it's going to reach the end. So this happens automatically. And that's all. Thank you very much for the session and if you need anything, as usually, here are my details. Thank you very much. So we have some questions. We start with the first one, Carol. How would that compare to using Puppet or Helm? Well, yes, I would say that maybe Puppet is in the long, long time ago. Now it's more like Ansible to reform and so on. I mean, I don't know exactly the space of Puppet nowadays about Helm. Yeah, you can even use Ansible with Helm. Basically, what I would say to you is that if you're using Helm, use Helm. It's fine. But if you are using Ansible and you want to transition to Kubernetes, then you can still use all the things that you know about Ansible for dealing with Kubernetes. There is no big difference. For example, if you love using Ginger templates, you can use Ginger templates instead of Helm for creating or for customizing the Kubernetes deployment files or manifest. So it's just a matter of how you feel more comfortable. Can not Kubernetes the scheduler react to such events directly without external tools? Some yes, some not. For example, in the case of getting out of memory, yes, you can do the vertical and horizontal auto scaler and yes. But this is just an example that I wanted to give you a simple example that everyone can understand. But it could be the memory, it could be the CPU. It could be any any value that you are monitoring in Prometheus. So if in your Prometheus you are having some kind of business metrics, you can react to the business metrics. Maybe it's not a problem of memory. Maybe it's a problem of performance. If the request start taking more than 10 milliseconds to react, then please scale up to one more. This was just a simple example, but of course you can make it run. This is a good one from Felix. Would you take the combination of Ansible and Kubernetes that far to not use K8 native scalers and instead only use Ansible? Yeah, this is what I was saying. Kubernetes is supported natively but sometimes or you cannot configure it or you feel more comfortable with Ansible because you have been using Ansible all the time. So, yeah. And we have time for one more. So could Ansible also rise another major duty upon an event? Yeah. I mean that keep in mind that when you run a playbook together, you're just reacting to an event and then you run a playbook and this playbook can be anything. So if you want to, you know, react to a page duty or send an event to Twitter saying, hey, we are down or sending an event to, I don't know, to your select channel. Yes, all these things can be done without any problem. Okay. And for the rest of the sessions, we are going to move ahead. Alex is going to be here in the corner to answer any further question. And we are going to be also at the booth and we need to move into the last session. We will start in five minutes and with that, thank you.