 This is Mark Cheshire, and I'm really excited to welcome you to the inaugural event, the Definition Day, focused around modern application development, and welcome all of you to this fantastic event. We've got more than 30 sessions, three labs, and a great keynote lined up for you today. To kick things off here, I'd like, well, my name is Mark Cheshire, and I'd like to introduce you to Roma Pellis. Roma works with Red Hat in the area of Ansible, and for many of you that were at Red Hat Summit just less than a month ago, we'll have seen just how important automation with Ansible has become to Red Hat. You may have seen some of the headline announcements like Event-driven Ansible and bringing the ability to bear with you, Generative AI, to define your Ansible playbooks with Ansible Lightspeed. Today, Roma is going to share some more insights on best practices of how to automate the software development lifecycle. Before we get onto his talk, just some logistics. If you have questions, by all means ask questions in the chat. This is a very short presentation. We'll try to get to some of them if possible. Otherwise, there's also opportunities in the chat during the breaks on the main stage where I will be happy to answer more of them. All of these presentations are being recorded, and you'll be able to find them on YouTube. We'll let you know as soon as they're available and hopefully viewing. With that, I'll hand over to Roma. Let me just get the presentation up here and take it away, Roma. Thanks. Hi, guys. Welcome to my talk about breaking silos with Ansible. I cannot stress that everything that Marc just said is completely true. Automation on Ansible is very important for you and hopefully also for Red Hat. I'm also very excited by Ansible, even driven Ansible, but sadly I won't talk about that today. I'm going to talk about silos and Ansible. Before we jump right into the topic of the day, I'm just going to get you situated with who I am. First of all, in case you haven't noticed by my adorable accent, I'm French. I'm a French guy living in Germany. I've been working for over a decade for Red Hat now, and actually I've been working in the Red Hat universe for longer than that. My career already started into G-Bus, which became part of Red Hat rather quickly. My focus has been, for a very long time, my focus was middleware products, and I have shifted to be more and more into automation solutions. One of the reasons for that is that I was not an early adopter of pipettes, an early adopter of Ansible. I've been an advocate, a supporter, an enthusiast about open-source since forever, since almost 20-20 years. That's why I love working in Red Hat, and actually my whole career has been built on open-source. I think I have never used proprietary software in my career as a software engineer. So I'm a lead software engineer of something called Ansible Middleware. We'll talk a bit about that later on. I don't want to dwell on that right now. You may also know me by other mediums, which is the Red Hat Developer Blog. I'm a regular contributor. I'm writing an article every three months, lately for the Red Hat Developer Blog. I'm also one of the few ones that started contributing content at the beginning of this project. For those of you who read French magazine, if you happen to read Nanook's magazine France, the French edition, you might see my name. I've been writing for them for almost 15 years now. On a more personal note, I'm playing drums, and my music, the band of my music, the music of my band is on Jamendo because my music is also open-source. For those who know that, I love Shadowrun, but it has zero bearing with today's talk. Okay, let's get started with the next slide. That's the agenda. Basically, it's a very small slide deck. I think I have less than 20 slides. It's going to be a short and hopefully nice presentation. It's basically two parts. I'm going to state what I think the problem is and describe what I mean by having the need to break silos. And the second part, I'm going to discuss how Uncivil might help or not with this problem. Let's go right away. One more slide. This is SOTA of App Deployment. By SOTA, I mean State of the Art. Before we delve into what is the issue, I'm going to try to describe how in a perfect world we want everything to work in our industry. If you are deploying a new application or update an application on your production environment, what would be the perfect dream scenario and how it will work? First of all, you would like to be able to deploy in a way where there is no downtime. Users can keep using the application without any issue. You just click and it was running version one and now it's running version two and everything is fine. And you want to be able to have no downtime even if you have to update the app or the infrastructure below the app. The second thing you would like to have in a perfect world is something as a one-click deployment. Actually, zero-click would be better, but something where you just say, I want this version to be running live. I push a button or I fire a command line and boom, magically, my production environment is using the new version. You want to do that in a secure and a repeatable way, meaning that I have 2,000 server running this instance of application. I run my magical deployment solution and boom, my Android server are always using the new version. Or if there is an issue, if something fails, then you automatically roll back and the whole version is running instead and you can figure it out and just schedule a new deployment for it all. Another part of this magic world we want to have is of course security because we are in the 2010s. We no longer in the early 2000s where people didn't care about security. So it's a good thing. So we need to have like authorization being managed, credential being managed and all of that should magically be happening. Like, oh, I deploy my new application and all the users that need to access to the application have access to the application. They are all authorized to do whatever they have to do with the application and everything is magically done. Another aspect of this magical world is auto-scales. So of course, you want to deploy about 3 instances of your application but if you need more power at some point you want the application to scale to 5 and if you need less power you want the application to don't scale to 2 and actually don't scale is probably the most important part here to save money. So that's the dream world. So if you are familiar with the product called Red Hat OpenShift and if you are attending DevNation you probably are, it does describe a lot of things that OpenShift does. It's very good but I want you to keep in mind that here I'm trying to discuss the features, how we want it to work. The fact that it is OpenShift or not below these requirements is irrelevant at this point. It's very much about what do we want to achieve. I describe that as OpenShift level of comfort. Like if you don't have OpenShift you want OpenShift level of comfort. Last note here, I have not found a way to make that very well go in my slide but do remember that in this perfect world behind the scene you have DevOps. You have people matching the description of DevOps engineer. You can't build this perfect world with a regular ops or regular dev. You need DevOpskin people. Okay, switching to the next slide. I forgot to put the picture. With a bit of chance I think the quote will remind you this video. If you have never seen the video on the internet of the expert in a meeting I want to say, stop listening to me go watch this video. It's an Elias video which is so true. If you have ever attended a meeting in your life you will watch this video and there will be a piece of truth in it. And one of the very few moments of this video is that the expert, the technical expert is trying to convey to the rest of the group that what they're asking make no sense or it's not simply possible. And at some point the product manager put his fist on the table and say what's stopping us? Geometry? So that's a bit of something here is that everything I've described earlier is very nice on a paper but you can't just say you need to work for everybody. So first of all, even if you have the option to use OpenShift, if you can buy OpenShift or just deploy the OpenShift the issue is that it won't fit all your use case. It might fit some use case very well but there is some case where you won't be able to use OpenShift so not all organizations can use OpenShift whether for budget reason for also like maybe not having the right skill set to use OpenShift or having a lot of legacy systems still running on internal infrastructure that cannot be easily moved to OpenShift evidently not all app can work in OpenShift as there is some scenario where there is some old app or very monolithic app that's going to be a mess to make to transfer to OpenShift and buy a mess meaning that it won't work and even if you can even if you're lucky enough to be working in a big company and they're like no problem we have a plan in three years everything run on OpenShift yes but you still have to run for three years without it and even if OpenShift or Kubernetes is an option you're going to be very quickly running into an issue with silos because even if you have this old magical infrastructure you still need your dev to work with your ops and you need them to kind of communicate in a way that the automation is going to provide what you need and that's the main blocker in the picture of this crap earlier is that you need this to break those silos otherwise you will never get to this perfect world I've just described to you up again so that's a part two already I told you it's going to be short and sweet hopefully how Ansible can help so very simply for me I oppose it or I hope or suggest or think or believe put whatever you want that Ansible can be used in Iguafranca so I have a common language for everybody where everybody involved in the company can use the automation provided for Ansible to automate each of their part so let's hold back a bit to understand why this is important if you go back to this OpenShift level of comfort I've described to you where everything is click click click done like I don't have to do anything the key word or the main requirement of everything is automation I told you you deploy an application it failed you all back that's an automation I told you you want to have all the security part done the authorization part done automatically that's an automation and so on and so on and so on of course OpenShift can be a huge part of that it can do most if not everything of what I've described but it's not the only solution and the very important part is that when now we realize that everything is to be automated so absolutely everything and trying to not have part where it's becoming manual so perfect example in large organization is the devs have built a new version everything was automated attack the release so build like everything was automated at the end there is this one little binary file to be deployed somewhere and then it's like oh and now we are sending an email to the Ops guy that's not automation you need to go the pipeline needs to go down to the Ops level and be deployed automatically and stuff like that so everything needs to be automated and as I put as a joke in the slide and if you don't, if you have a doubt automate anyway or automate more however the parameter of salary is coming up quickly because again who is going to do the automation if we talk about automating the build of the application most likely dev if we talk about automating the deployment of the configuration file of the automation it's going to be dev but also Ops maybe both, maybe none of them and then if you talk about like provisioning the system the target system then the Ops are going to be here and the dev disappear and that's very much where the salary is becoming in many organizations so the problem with whatever or rather the issue with whatever I've been discussing since I started this implementation is that it's a very abstract high level stuff so I'm pretty sure that you are all nodding your head saying yeah I know I know but that you know it's very generic and if you're not familiar with the problem you might be like thinking okay I have enough time seeing how uncivil can help with this big high level problem so I'm going to try to take a very simple example to show you exactly what I mean by uncivil as an ingua franca so it's going to be a very a very real life but simple problem because it's to be understandable by everybody but hopefully it's concrete enough for you guys to have a better grasp of what I've been aiming since I began speaking so let's assume we are working for for a big organization called Big Organization and we want to release a new major version of Magic App it's a Java-based web app or good old-fashioned Warfile for people who know a bit about Java and it's running on top of a product called Red Hat Jibos EAP which is an app server so you put Java application on EAP and you have application running in your system I picked the product name from Red Hat because I'm used to those but of course this is completely working with the open source version we are talking about definition here so it's not about all about product so if you know you could replace Red Hat EAP by Warfile if it's making your life easier in your head now this feature this Magic App application has a new feature they added an audit trail in the app because again we are in the 2020s security matter so this feature this audit trail feature is using a data source which was not used previously by the application to give you the context just to give you the context and also kind of make it more real let's assume that big organization is still using a VM infrastructure it's based on VMware everywhere they're running ran machines and if you care about this kind of low-level detail the application is running OpenJDK GVMs it has no bearing to the discussion it's just to make you situated and try to have a full picture of the organization ok so what's need to be done to deploy this magic new version of Magic App as always you have to push the Web file like the Warfile on the server ok and you have to have the container EAP run again like start deploying the application and running it fine you also need to tweak the EAP configuration because now we have this new data sources which is a configuration thing that need to happen in EAP so when you deploy the app you have also to ensure that this configuration is already there which means that if you want to automate the process of deployment of the app you also have to automate this part the configuration of the EAP server let's start by the EAP server on the automation part so in our big organization the Ops people because again we are a big organization that is not ready to be fully developed not yet so the Ops people are in charge of the EAP install they mean that those are the guys running some kind of automation in our case on Cible that ensure that at the end of the provisioning of a virtual machine you got an EAP server running on top of the system in this case a real system so they prepare the machine they provision it and at the end of the run you have a system disservice on the system running EAP however those Ops people have no idea about the configuration of the app server they don't deal with the sub-system of EAP they don't deal with the GVM tuning a side note in your organization it can be quite different maybe your Ops people are doing more there is some organization where the Ops people configured more stuff on the EAP level or go deeper on the configuration they are doing for the developer there is other organization where they do even less and some organization are still providing a real system to the developer and the developer are taking over setting EAP themselves wherever the cursor is it's not really important because there is a cursor and this cursor is where your salo begins okay let's take a quick look at the Ops part they are going to use Uncivil to install the EAP server and thanks to us thanks to us Red Hat but thanks to us the Uncivil middleware initiative that I have mentioned at the beginning of this talk there is specific extension for Uncivil to ease the use of EAP with Uncivil to ensure that you can fully automated the EAP installation with Uncivil in the most easiest way so this is why the playbook I am showing you on the left side of the slide well left for me maybe right for you the playbook I am showing you on the slide is very simple because all this playbook does is just say hey I am importing the collection collection is basically extension for Uncivil so I am importing the extension for Red Hat EAP and then I just add this extension hey can you do the two following steps install the EAP server and ensure that each EAP server is running as a system de-service on the target system that's all on the right side of the slide you can see that I am showing you what's happening when you go on a target system when you do a system CTL Status DuBoss EAP you have an EAP server running on your target system all of that has been fully automated the box was empty there was a basic rail on it Uncivil arrived install erasing dependencies open gdk any kind of configuration file you need too for EAP blah you have an EAP running so that part is fully automated the silo on the left the ops has done is done now let's look at the silo on the right which is a dev those guys are in charge of the app deployment automation so in this case I need to deploy the warfile on EAP you just push the file in the right place and they also need to update the configuration of EAP because this new version again as mentioned needs to have a specific data source configuration update to work fortunately thanks to the collection I've mentioned the relatively EAP collection I've mentioned there is a feature making that very easy because you can you just need to provide a template for the configuration of EAP that's going to be automatically loaded by the collection and applied to the remote server so how do they do it like? before I do that again same disclaimer your organization may be a bit different maybe dev are doing another one doing the driver part or another one doing the data source part but that's fine again it's a detail for this presentation okay so how the automation will look like here so same thing here as you can see with the command lines the unsealed playbook is still going to be the same it's going to be running as I showed you with inventory and stuff of course if you don't run unsealed from a command line it could be run by unsealed automation platform again that's an information detail conceptually there is the same playbook being run and dev just provide a template for this playbook which is going to describe the configuration they want to have on the Deboss EAP server carrying the application which they want to deploy so the fight being a bit long I had to cut it into pieces on the slide on the left side you have the beginning of the file you can see that there is something called wildfire configuration it's basically the top root layer of the configuration file for EAP which is called upstream wildfire and here we just say hey it's a bit cryptic if you don't know very well EAP but I'm going to decipher that it's very simple basically this configuration is telling you hey now you have to use the new data sources it's a PostgreSQL server so please use this driver so that there is a GBC driver a Java database driver to communicate with Postgres that's fairly easy on the right side it's a bit more interesting this is a bit lower on the file this is the data source declaration itself so the application needs to have a data source named something that is going to look up and connect to to put the audit trail data in and this is the part happening there and what's interesting on the slide here if you are familiar with Ansible is that you can notice that I have used Tompetting format there is some variables like DSNAM DSPoolMaxSize those are Ansible variables so the dev can put them there saying ok we don't know what the prod is going to use as the data source's name they are going to take care of that we just put the variable name DSNAM and we trust them that when they run the playbook down the street they will valorize this variable with the right name for the data source and the same thing with the username of the password so the dev environment can run this automation build their own environment exactly that prod is going to do it except that they are going to use the data source dev name they are going to use the data source dev credential and so on and that's basically going to work magically and they are going to run the same thing on qualification and then same thing on prod is going to work so that hopefully this little example has kind of drive my point I hope it has if not I apologize if it has not driving my point if you have a question or comments this is now your time to do it because I am going to switch to the last slide called the end I just generally yeah I just generally so if you have any questions like please fail them I am going to look at the comments but just to conclude yeah just to conclude generally when I talk about what we do on Siebel Middleware I start by hey this is how we can automate on EAP using on Siebel and people are not always really much understanding the bigger picture here so this is why I wanted this presentation to do the other way around showing you the problem you have on silos and how when you drill down from that you need this level of integration between on Siebel and your applications to make that work and if you do that if you do that if you have this level of integration and hopefully in the case of the Red Hat Middleware product we provide that for you then you can build your own automation that can be as complete as powerful as what I've described as open shift level of comfort and you can get that now with your bare metal with your virtual VMware environment you don't need to wait to be able to run open shift to get to this level of comfort and I want to say it's even more important because you want to know how this works and I've built that before getting to open shift so that when you arrive to open shift your whole application and organization have already been tailored in this direction okay I don't see any question so I have either I was boring for everybody and everybody slept I hope you had a good nap or hopefully I was clear enough for you to understand but in any case I'm done that's fantastic thank you so much Ramam for joining us thank you for inviting me as I mentioned this recording will be available on YouTube we'll share information as soon as that's posted and right now you've got a bit five minutes to make a transition to the next session you can either hang out on this track the Java and app modernization track following this we're going to have a session called Java life is short or you could switch to one of the other two stages where you can see listen to a session around containers to pods on Kubernetes or you could go to the one on the intelligent apps track around developing a stream processing app with Kafka and Quarkus so enjoy the next sessions and look forward to hanging out with you in the chat during the day bye