 We're going to touch upon a different thing to do kind of application rollouts and other things as well. So a quick question here. So how many of you are or you know your company, your businesses are using physical machines to deploy application or serve application from? Raise hands. Physical machines? OK. How about virtual machines? Your code is running on VMs being served, all right? Containers? OK. So assuming you guys are on-prem, on-prem environment, OK. And rest, remain as it is all public cloud and private cloud, right? Fantastic. Thank you. Let's understand the software development journey of workflow and stages, like how it looks like. It all starts from someone from a business team sitting in a glass cabin, comes to your door, hey, I need to have these features. So this goes to, if you have setup of agile scrum teams, it goes to product managers, the standard loop, the kind of record your requirements to do a scrum, the open up stories. And this is then assigned to engineers to write codes, right? So eventually, these requirements end up into a Jira board, a Kanban board, from where the engineers picks up. They start writing some code locally on the machine. And then once the code is good, they're going to do some testing. And they are good to release. They produce, you know, content images or EXE files or, you know, Golang build files. That's the release part. And then eventually they will ship it out and deploy it. So this is very superficially a workflow looks like in software development, right? Nothing, a lot about it. If you go a little bit deeper into it, just to understand a couple of terms that has been popping around. So as I told, it starts from code, assuming that the Jira thing is not considered as a part of this. But yeah, it is part of the bigger circle, like for agile development, your requirements, begins with code. Code is then converted to builds. You build it, build the things. It's called agile development standard. Then it goes to the next stage, which is integration. I'm talking about microservices. I have multiple different moving parts of my business. It has to work together in a cohesive module so that we'll integrate it and make sure that it works. My overall application works. It's not just about a single microservice or a single kind of component of it. The overall bigger application should have to be working. So this is typically called as continuous integration doing some testing around it. Let's go to the next stage, which is continuous delivery. Here you will kind of produce the output of what you have built, image file, content image, push it out to registry so that it could be deployed on. So typically it's called a continuous delivery stage of your application rollouts. And then once you have the new images, your software bits, your binaries, you need to deploy it somewhere in the cloud, on private, onto the edge, or maybe onto the physical machines, virtual machines. You have to have a way to deploy it. So it's continuous deployment as a term that we say. And then once it is there, somebody has to keep it running. If your service is down, your customer is gonna call a call center. They will fix it. So it has to be there to be someone who is always on page duty and solve the problems for you. And make sure it's all, the operations will be taken care of. So this is how it looks like at different stages if you break into a different way. So why CI CD? Do we need it? I think you need it because it solves a lot of problems, but has covered I think almost all of them. But it helps software delivery process efficient by collaboration with your, within a team, multiple teams. They collaborate together. They deploy together, right? So it helps in that part. It gives you automation. It forces you to have automation in the system so that you use the tools right for your business problem. There are a lot of tools out there. I'm gonna talk about it, but you need to figure out the right tool for your business. And then it helps you to release often, fixes new features for your existing app. And overall, if you just submit out, it helps you reduce the cost of your overall software kind of deployment. Talking about tool, how can you practice CI CD? You need to have, choose the right tools to do it. Every environment is different. Every use case is different. Every business needs are different. And there are a lot of tools out there that you can pick up and practice CI CD and CD. And just double clicking on this one, I have written two things here. CI CD, continuous integration, continuous delivery, and then continuous deployment tools. Burr gave amazing demo around Argo. Argo comes in the category of CD, continuous delivery tool. Jenkins is very, how many people are using Jenkins right now? Dev, test, prod, amazing, right? We have Jenkins for CI CD, we have Tecton. He showed about Tecton Pipelines, which is open to pipeline, which is based on Tecton. GitHub and GitLab, they have their own versions of providing CI CD. So we have a lot of tools available on CI CD. And it is not the exhaustive, I can fill this slide with all CI CD tools out there in the market. But that's what the intention is. So talking about the other side, CD, Argo, GitOps, it's the most popular tool out there to practice and implement GitOps. We have Ansible. Ansible is there to deploy application, not only on cloud native, but even non-cloud native apps. You still have your physical machines, you still have your virtual machines running out. You might be having some kind of edge system around, which is not using Kubernetes, which is not using, we're still using virtual machines. We're not using containerized way to deploy apps. In that kind of use case, you can use Ansible as your launching vehicle of your application. Imagine you don't have Kubernetes, you don't have containers. You have to have a good way to deploy your apps across pan India or globally, right? Then other tools like Flux and Spinnaker are also comes into the CD category. But why Ansible? Okay, Ansible is a very amazing tool, a very interesting one. It is like a Swiss Army knife, one tool to rule them all. Irrespective of the genre you belong to or category you belong to, if you're a dev, you're a DevOps, you're a sysadmin, and if you're a SRE, you can kind of leverage Ansible to automate your stuff, automate the things that your manager asks you, your team has asked you to do. You can automate that, bundle into Ansible Playbooks, and kind of deploy it to any target. And a target could be any. It could be physical machines, irrespective of the OS, Windows and Solaris or Unix, and then virtual machines. It can provision these resources, it can provision virtual machine, it can provision network for you, storage for you, why deploying containers as well, deploying on Kubernetes as well. It can go and configure and provision databases. It can interact with third party application using web APIs, whatever. It can also deploy your apps onto remote edge. Imagine like you're running, for a given use case you have Raspberry Pis installed on various customer locations which are accessible over the internet and you have to deploy something around those Raspberry Pis which is not running Kubernetes or containers. You can kind of use Ansible to do that. So that's what Ansible is pretty interesting in those kind of aspects. It can cater a wider variety of deployments. So now, let us now see Ansible Automation Platform in action and I'll handle with Nagesh. Nagesh gonna give you a demo where he gonna use multiple things together which includes JNK and obviously OpenShift because it's easier for us to set up OpenShift cluster because of Manage OpenShift. Rather than spinning up a virtual machine form somewhere and using it, I could do that as well but we found it slightly easier. So he gonna go over workflow of the demo. So Nagesh, over to you. Let me introduce the Ansible Automation Platform CD in action. This is the diagram which I'm going to show you the while demo as well. Let me start from the, this is the entry point you can say. Let me start from here. The developers are, or junior developers are, they are doing its own job like creating new feature and pushing the new things into the gate. And later on, after these, actually the action or the, whatever the things will start with the help of the webhooks and all those things are there. JNK will detect the thing and later on with the help of the build config. So it will build the image and it will push it into the Quake Container Registry. And later on the Ansible Automation Platform will come in, comes in a picture and it will face all the files which are present in a gate. Those are can be the manifest file, the configuration file, the playbooks, you can say. And it will launch the deployment into the development cluster. But when you think about the production, things become more like sensitive. The management or the higher authority have that permission because we don't have. So Release Manager is responsible for deploy the things into the production. So we made one mechanism like the manual intervention. Whenever the Release Manager decide to launch certain features into the production, so it will come in a Jenkins. It will log in into it. And later on when he make a decision, later on the pipeline make a CI, CD and it will deploy into the production. Let's see all these stuffs in a, you make sure before starting this demo and whenever you are following this, make sure you have a privileges of administrator, otherwise you can't do it. And this is the Ansible Automation Platform. We are short on time. So that's why. No, we are good on time. We are good on time. Okay. So couple of things I already installed and configured. So we can make things more, show you more demo more reliably. So. Yeah, just wanting to add on this one, so on this, on this very, very screen. So we are into operator hub, which is another amazing feature of OpenShift through which you can install operator. You don't need to go to any random GitHub repository or run a shell script to install anything on OpenShift. It's kind of a way to install packages on OpenShift, right? So through here you can search a different operator that you want to install on your system. It has nice categories, developer databases, monitoring networking and storage, streaming. So Ansible is one of the operator available on the operator hub. Okay. Then after you can see, I already installed it. That's why it is not getting anything. So instead of installing uninstalled, you will get it one install button here. Just keep everything as it is, as a default, and install it. And later on one, three cluster pod will be appearing in your Ansible Automation Platform namespace. And also we required a console access of Ansible Automation Platform. So for that, we have to go into the install operator. And you can see, I already installed the controller as well. You can see. See the Ansible it is showing. So let me show you how the exactly things are created by using typology view. These three pods are here. Those actually handle the workload, whatever the pod creation, executor pod with the interaction, interacting with the cluster and all those things. And these two pods will ticker off the console access and all the steps. So let me click on the route icon and it will show the console of Ansible Automation Platform. Let me log in into this. You have to go to administrator to grab the password of Ansible Automation Platform. And meanwhile he's setting up. So once Ansible Automation Platform is up and you get to it's UI, you can go and provision resources on non-open-shift, non-communities environments like spinning up EC2 instance for us to say conferring that instance and with your security policies. You can set up all those rules and all those playbooks once AB is there. Okay. You can see a couple of graphs is here because no doubt before this demo and this presentation, I did a couple of it and try. That's why it is getting here. So for this, whenever first thing we have to create a credentials, the credentials, let me go into the credentials. These are the ones. If I create a new one and select the open-shift, you can see the three dependencies are here. First is a endpoint, second is a token and third is a certificate of it. So we can create with the help of a service account. The endpoint, we will grab it from the console. And this is like a one-time setup. Like you're telling Ansible, hey, please use these keys and credentials to access this cluster, like one-time setup, unless you kind of refresh that as per the policy. For token and certificate, you have to create a service account with the create one role and role binding as well. So whatever the dependencies or whatever the configuration, the authentication it requires to interact with the cluster, it will do it without any issues. And this file is your like rollback access control. You can let that Ansible, the service account, have just enough permissions to access the source of the cluster, right? So you can define all those parameters here. Make sure you have a CLA access. I'm in DevGam app right now. So the things are created. It is showing unchanged because I already applied it. And for token and the certificate creation, we have to run this couple of commands. Like this is like a 404 stuff, 400 stuff. Like, you know, you need to run those commands so you have to grab the token from the system, from the service account, right? Can you see this token and certificate? These two files just created right now. So we have to just copy it here and paste it into the Ansible automation platform. And it will store it in an encrypted manner. Hey, just one more thing I'm gonna show here. Go to credential drive drop down. Okay. And just slowly scroll it. So look at this one, you know, how many things are supported here? Like AWS and, you know, Vault, CyberR, GitHub, GitLab, Google, HashiCorp, OnSites, machines, you know. It's a very exhaustive list of, you know, other services that Ansible can go and connect to. And, you know, make sure that it can go and launch resources of that type. So it's pretty, pretty popular and it's pretty wide. It covers a lot of bigger use case for your automation. Okay. Please continue. Okay. For now, after this, we have to create a instance group. Instance group is nothing but them. It will create a one executor pod. The executor pod must have attached the service account and the role which we created. We have to pass into it. After that, the executor pod will be appear into that namespace or the environment, you can say. And it will do the things for us. The deployment, actually. Let me give you this as a and credentials are the DevGam app. And here exactly we have to give the namespace. We are using for, as I shown you in the diagram, the for development, we are using DevGam app, one namespace for production. We are using product game app. These two namespaces, we are considering as a two environments. Right now. Let me give this as a DevGam app and the service account which we created. Let me grab that service account name. Let me just save it. After this, we have to create inventories. Inventories are nothing but the inventory file where we just list all the host and all the stuffs which we want to interact with it. So let me create one that. It is very similar to the inventory files which we follow, create during the traditional Ansible. Let me give you this as a DevInventoryName and instance group, dev container group. After the saving, we have to create one host here. This is the IP for now. We are using OpenShift cluster. So I'm giving as a local host. Let me go back. Let me go into that. How many of you use the ping module to check whether that host is responding or not? I don't like that way. Yes, lot of. So actually we are doing the same way here. Let me just go into the run command and select the ping module. And next, next. I'll select this democrat and show. Okay, got it. It is responding from our environment that we are able to interact with our OpenShift dev game app environment. So what Ansible.in the background is, it has launched temporary container onto the OpenShift cluster, set up little bit of the Python thing that it needed and then you invoke the ping module, got the response and put it here so that we are sure that things are in place, things are working. A quick question. Right now, we have to create a project. Project is nothing but a local SM for the Ansible automation platform. So it get the things from the gate and doing the things like it will do it very quickly if the things are in locally present. So we have to select gate here. And it's nothing but our configuration file which are present in a gate now. We have to just give the repo endpoint and all the steps. This is the repo which I'm using. This is the public repo. So I need not to give any credentials. Let me save this. And right now, we have to create a final thing that is the template. The template is nothing but the execute, it execute job for us. And it is one kind of a blueprint which execute the things for us and whichever the things we created, the credentials, the inventories, the project and the instance group or a container group, we have to pass all these dependencies to the template. So it will, with the help of these dependencies, it will create or deploy the things into the OpenShift cluster. Yeah, and just for the record, don't get confused, right? We have a lot of things here on stage. Using Ansible APIs, you can literally automate everything what we have shown here. To show you credential creation, inventories and templates and configuring the good thing, it's all configurable directly using Ansible APIs. Just to show you guys how it looks like, what it takes to Ansible automation the hard way, we're just showing you at the moment. The inventories which we created, they have an entry. Can you see the, okay, I have to select first project, Devian, the playbook is here. And credentials, OpenShift, Devgam app, which we created just now. And the instance group, Devcontainer group, select. I think we are one too. And here, meanwhile, this is coming up. Here, if you create, assume that you need to deploy this through, let's add different cluster, like AKS, EKS, right? You will select the right credential type, create a new template, select the right credential type, and your system is kind of ready to deploy it to, other destinations as well. Okay. Let me just save it. Instance group. No, actually the instance group will be just an help to that executer part to help us to execute the things into. The project and all those stuffs are now, we have a playbooks and all those stuff. What he need to deploy it there, he don't have any kind of idea. So we have to give it with the help of project and the template we will give passing that information to it. Let me just show you. Let me show you how these things will fit into the, our Jenkins pipeline. Let me go into the Dev pipeline first. In CD, let me go into the configuration. You can see, yeah, before this stage now, you have to create one freestyle project and make sure the two plugins are in place, the Ansible and Ansible Tower. These two plugins are not installed. This build Ansible Tower option will not appear here. So then this credential which you are seeing here, you have to go into the manage Jenkins and if you scroll it down, after the plugin installation, configuration, you have to pass it the endpoint of Ansible automation platform, the console login for which we use the credentials, the admin and the password. Like you have to pass it here. After this word, it will get it here. And the template ID is nothing but the template name which we just created. Let me just save it now. And right now, let me create one commit and ideally the Dev pipeline should start. This is the same repo which I've shown you. Let me make one small change here. Just let me add hash to hash here and save it. And save it. Let me check the status. Can you see? The readme.md file is changed. Let me add this. So now as a developer, you are just working on a local machine doing the changes. Okay, let me push the things. Okay, hopefully our pipeline will start. The polling are in place. It will check every minute whether the new changes are there or not. And if the new changes it will detect now, it will start the pipeline. Unless it is broken somewhere. Yeah, Nagash is praying, I think. Oh, hopefully it started. Oh, they've accepted. Yeah, yes, it started. The image building is started. So this is a very familiar UI for you guys, right? Jenkins, so what we're doing is you know this, right? So Jenkins is kind of doing the CI, it's needed. And yeah, it will then hand over the ball to Ansible. Hey, Ansible, please take it up and go and bust up over the internet and deploy my app on the remote edge as well as to VM or somewhere else where I wanted to. Yeah, favorite, yeah. So what's your favorite? It's good. Yeah, we love Jenkins too. Whenever the pipeline is succeeded, after this, the QA container registry, the new image will be here. So let me refresh this. You can see 233, it is showing right now. So new image is pushed and hopefully the CD stage started. Yes, it is started. And let's see what is exactly happening in the Ansible automation platform. Oh, it is running. And let me show you one executor pod which has said it appeared. Can you see, this is the I'm talking about. Look, this pod is deploying our application. When the things are done, it will again, it will, these are the temperate pods which does the job for us and it will delete it. Our application is here. Okay, this is all about the dev environment. What about for the production? Yeah, it is just to make it more interesting to show them the app, is it really running or is it just container? With the app? Is it running? Yeah, try to play some game. Show some skills. Okay, the production is left too. Okay, first test in dev, right? Huh, you can't release once it's in dev. It is released in dev, it works, right? Okay, yes, it works. Okay, so with sound, without sound. Without sound, actually we have to play in them. Okay. Yeah, so the app works for us. Right, now we're gonna push a button and our manager will get the approval request if they are happy with the performance of the app or the quality of the app through Jenkins and then they're gonna push the button and then we'll kind of deploy this in production. So Nagesh, please do it. Okay. Ideally in industries or they create a pull request for one environment to another environment or one branch to another branch. So let me create one pull request here from dev to prod. Yeah. For dev, I'm considering main branch and for prod, it's a prod. So follow your company policies with respect to this. It varies a lot, right? So as a dev one, you are kind of pushing your new feature onto the main branch or the mainline code base and yeah, requesting an approval if you like to. Let me refresh this just a second. Doing anything? Yes, yes. The create pull request button will add there. The first? No, no, no. We have to give title. If the multiple commits are there, we have to give title. Okay. Okay. Let me just click on create pull request and this is on me. You can consider as a senior developer as well. That dev environment is done by junior and this is given assigned to me for production deployment. Okay. The pull request is created. I think I pull request, the merge option is not getting just a second. I mean, you got the idea, right? So. Add recent issues. Okay. Is it? That's the last try. We are not running out of time. So, but yeah, you know, so dev is working. We are having some issues in releasing the production, which is not foreign, it happens, right? So, which is a real software engineering thingy that we have here. So, if this does not work, then Nagesh has to kind of fix it before he end his day today. Okay. Hopefully. Okay, look at this one. This works. Confirm merge. I'm just accepting right now. So pull request is done and hopefully the prod pipeline will start within a minute. Yes. It is actually already started and it came on a manual approval. So, as you guys remember and that manual, the release manager is responsible for the deployment. So, he will log in into the Jenkins and come here if he about it, he can and if you want to proceed and deploy the things into the production, you will just click on a proceed and later on the things will start it and after this, the CD pipeline will also start it as well. Can you see? The CD pipeline is started as well. So, yeah. And at this time, you should be getting new pods into the right namespace for which you have configured the credentials. And your app is about to go live in prod. Yes. This is the executor pod which we're... There's Ansible kind of trying to launch the app. You can also go and see the logs meanwhile. Go to Ansible, click on the view logs. Let's see what it's doing. Yep. It's actually kind of running the ML file that you are used to with Ansible in a pod and once it is done, it will self-destruct and you should get your app pod up and running and yeah, click on the app and then it will basically work. It will typology. Right. So, that's all we have. We are running short of time here. App is running. Thank you, thanks so much. Thanks so much for the time and just to clarify, we are here to provide you the tools, right? We provide you the right tools, right open source tools, support open source tool. It's up to you, your business use case, your needs to choose which tool you want to go on. Burr explained about GitOps and our Go CD, how GitOps is super simple to kind of roll out from New York to Amsterdam to Bangalore, right? So it's a tool for kind of practicing GitOps but if you need a different tool, kind of provisioning over the ground like VMs, physical machines, Ansible kind is a great tool to kind of automate your, you know, sysadmin stuff, devop stuff, your developer stuff to a lot of extent, right? So, that's all we have, guys. Thank you so much and we'll take questions in the end. Yeah, that's the idea, that's the idea, right? Ready? Please continue, please continue. So, I mean Ansible is definitely the configuration management system available, right? People used to deploy provision resources, physical resources, virtual resources on the cloud, on non-cloud, right? We are kind of showing you another capability of Ansible that it can also deploy applications for you to certain extent, right? As long as you can, for example, if you want to deploy something on XYZ environment, Ansible could be used, if you guys are already using Ansible, right? If you know how do you work on Ansible, you could kind of, before kind of checking out another tool out there to do just application deployment single-handedly, you guys can give a double shot on Ansible. Hey, can Ansible be extended because I have in-house expertise on Ansible? I've been using Ansible since last, you know, five or six years. Can we adopt this as our deployment mechanism for two? So, okay, that's Google Siri or Google Now, sorry about that, right? So, yeah, it could be used, that's the whole idea, right?