How to run your whole Ansible lifecycle on one platform

uh you may have a CI/CD type program that's actually running your ansible playbooks. Uh you may have users that are running manually on servers and there's no real accountability beyond that just that hey it may have gone over to the logging server it may not have. It depends if they set it up properly on the Ansible server. So I mean there's lots of different things that you then have to maintain yourself that you have to make sure that okay well upgrade versions the is my plugin going to work still work with that for the logging? uh am I getting the correct type of stuff out of the logging that I need?

If I do a CI/CD, is it actually running correctly? Am I getting the correct ansible versions in there? Do I need to upgrade anible versions, all the dependencies? So, there's a lot of stuff to different maintain there that you know when you start talking about Ascender Pro, you're talking about the full stack plus beyond that what we add as far as the registry and the Galaxy proxy and everything else. So what does that actually look like if we wanted to kind of see um what that platform looks like? Is there like a unified kind of look to it? Do we have a user interface uh front end?

I know that like when I first started doing Antible stuff, it's all command line command line, lots of files. If I wanted to go look at a log, it's somewhere else. What does that kind of look like? >> Yeah, so we do have a unified UI. Uh it looks basically the same across them all. They are still four separate UI products plus a Galaxy program which is doesn't have UI because it's just a proxy. Uh within here basically the UIs they do their each little thing. Not everybody's going to be logging into all the different UI. So we kept them separate because you'll have some people that need to log into a sender to actually run jobs but they may not need to log into the login to actually look at that.

That may be all your auditors. Uh they may not need to log into the registry to actually add collections. that may be your administrators and they may not need to actually log into React because that may be your administrators of the servers themselves are doing things. So within here, you know, we kept them separate instead of trying to build just one single UI where you can access everything just because not everybody needs all that and it just clutters up the full thing. And here I can share my screen real quick. Okay, so we should be looking at ascender itself. So ascender is the first portion of the UI.

Again, we basically theme it in here. We do have other themes you can actually change to, but this is the CIQ theme we use by default. And within here is everything you need for running Ansible playbooks themselves. You know, it does all the logging for you. It does all the templates, it does all the jobs, it does all the containerizations, running everything uh workflows, etc. Uh we do have then the additional components on this. We're talking high level. We have our ledger. Ledger itself is a more robust logging system for Ascender. Everything that goes over on Ascender comes over to the logging system just so you can actually go in and see more details like every change that happened across every system.

Um go in and see, you know, Aada across all your system. Go in and see all the different packages that have changed across your system. What's been added? What's been removed? Again, literally everything that happens in the sender, all that data sent over here into the logging system. First of all, you don't have to send it somewhere else that's charging you by the megabyte like Splunk. You know, you're sending it over here. It's part of the actual price you get with a sender pro. It comes with it and you can utilize it for that to actually save you that sunk cost of Splunk. And then we have our registry itself, which is basically your collection system.

So, this is where you're pulling all your collections in. It's where you're pulling all your different containers in and then can push them out via a sender and pull them in for your playbook runs without having to go up to Galaxy. That's the other reason we wrote the galaxy proxy. So the galaxy proxy itself kind of came first before we wrote the ascender port or for we wrote the ledger portion sorry registry portion and within here this is just a small little container this is out there or you can even run the go binary for it that all it does is basically takes all your connections you would be doing to galaxy and caches them.

It makes everything run faster. Galaxy itself anal galaxy ran by red hat is really slow at times. you know, everybody in the world depends on that service. This helps you actually cache it locally to speed everything up. And then of course, we have our sender react, which is basically event driven type automation where as a ascender is logging over to ledger, react is actually getting logs directly from your system and then allowing you to act upon those and say, "Hey, if something happens, if I get this type of log message, log over into a sender and run this playbook against that host." About as simple as that.

>> That's great, Jimmy. Um, one of the things that I want to kind of just hit on is there's a lot of stuff that that seems to kind of surround around Anible and take that step kind of to the next level and give you a lot of that functionality. But if there was a scenario like let's say we took a scenario where something breaks on a system um at let's say at in an opportune time um what does that scenario look like anible versus sender pro and where are those parts where ascender pro is really going to help you shine and dive in deep. >> Yeah.

So to start thinking about something like that, especially against the Ansible side, it's Ansible, you would have to first off write a playbook. And either way, either one of these, you're going to have to write a playbook to figure out how to fix that issue in in basically because unless you're going to do it manually. So within here, we're talking about, you know, how do you actually fix stuff fast? How do you actually react to different things, which is kind of why we named it the product react. You're reacting to events that happen. you know, something breaks on a system in the middle of the night, you know, service dies, something happens, you're basically reacting to that.

So, within here, um, on the anible side, when you're thinking about it, okay, well, now you have to wake up, you have to go log into the system, you have to figure out what's wrong and say, okay, well, this is the same thing that happens all the time. We wrote a playbook to fix this. So, then we run our playbook manually, look at it, go check the service, make sure everything's working. So on the React side, you're basically doing that same thing, but you're taking yourself out of the equation. What you're doing, if I share my screen real quick, I'm just going look over directly into React.

So with React here, what we're basically doing is we have listeners. Listeners are basically what's receiving your logs. Uh these are kind of independent. They don't require UI itself to actually be running to do all their work. So you can spread them out as much as you want. They can be where your actual servers themselves live. They can be local to the servers parsing it without having to send them over the wire somewhere. But they are basically sending receiving your logs themselves. They do get the data from uh the web UI as far as what they're supposed to be looking for, etc. But what they're looking for is these rule sets.

And these rule sets are basically different sets that you can have for rules you can have for different servers that basically tell it hey if this right here happens if I see like in this example disc warning say in the middle of the night my disc fills up you know and everything's going to start dying I'm getting a warning that I have a warning goes off at 80% in my log so at 80% the logs goes off says hey something's about to go I get a disc error if it actually hits 100% or actually I think I have it at 95 but within here I

get a disc warning at 80% % and then what I have is in playbooks that I then run to say hey if it's at 80% let's first go in uh we'll do different checks say hey is this a docker system let's go ahead and purge some of the old build files of the docker system purge some of the old unused container etc to try to get that disc space down that's basically so I don't have to log in the middle of night you know I've had IT jobs for 20 something years at this point and that middle of the night stuff is what I hate the most it was always someone calling you that hey this backup didn't work hey this didn't where this server's down, this server stop, the service stopped, and it's usually a simple fix.

You know, it's not a lot of time uh consuming as far as have to fix the problem most of the time, usually because you've had to do it before, but it's the fact that I now have to wake up at 3:00 a.m. when my uh back then it was a pager. My pager went off and uh alerted me and I had to go and say, "Okay, now I was logged into the system, get on the VPN, look at the system, figure out what's going on, fix it, and then try to go back to sleep." Uh so when you're talking about this is basically as the

event happens immediately you get it within you know a couple of seconds at the most when this event comes in it's automatically kicking off a job over in a sender saying hey run this job over here and I do a lot of different things in here to basically tell it what job to do. So I have a file system um a repo out there that basically has a different file for all my different fixes. It's not in this UI here. Uh but I'll call this fix uh fix this warning and it's basically just a variable that I pass over there for what fix it is and that's technically the file name over there.

So it just includes in that playbook and runs it against that server. So that's how simple it is. We basically have simplified the process a lot. Uh there's no weird containers you have to spin up of decisions engines or anything else. It's just a listener. It receives an event. If that event matches a rule, it basically just goes down the list and says, "Hey, I know how to fix this." Goes over there and fixes it for you. And that's basically the difference kind of between this and Ansible is Ansible, you know, you get to log in, actually go do all that yourself versus having a system that just remediates.

>> So, this is a fundamental shift in kind of how things are are are run. with Anible, I probably would have to either have one playbook that actually goes and checks on a scheduled time frame. Um, and then another one that maybe does that remediation fix. Uh, uh, and this one essentially goes from instead of doing things on a schedule, it can, and again, you mentioned it, go it can actually react, >> uh, to something that's that that's triggered it and then go run that remediation automatically for you. So that's a it's a fundamental shift in kind of how you have to think about what you can do with it.

>> Yeah. I mean the only other option is you have someone who's up all night and they see the alert come in and then they have to go and fix it, run the playbook or launch the job in the sender or whatever themselves. Again, we we have help desk people and that's generally the people that wind up paging me because they didn't know how to fix the error and that's when I'd have to get on and actually do it. >> Got it. No, that's that's great. that that's a it it takes a little bit to kind of switch your mindset, but as soon as you do, you can start to realize kind of all the the different things that you can do with something that can kind of um react quickly to something that happens rather than polling.

>> Um let's switch gears for just a little bit and talk about like scaling of solutions and deployments. Obviously, typically if you're running Ansible, you're not taking care of one or two servers. You're probably taking care of hundreds or thousands of servers. You want to do things consistently across it. You might even be doing things across multiple locations and building that out. Um, one of the new features that's being released in Ascender Pro is around federated inventory. Can you break down like what that really is and more importantly kind of what that allows teams to do that they couldn't before? >> Yeah, let me share my screen a little bit just so I can show it while I'm talking.

So, one of the new features we added in sender is basically a federated inventory. It's a new type of inventory. Did it exist before out AWX anywhere else? And what this inventory does is it fixes a really common problem that we see across a lot of our customers. And it's usually around the fact that hey, I have lots of different inventories because I have sites all over. And those sites themselves in order to reach them I have to actually run a job in an external node or an instance group over there.

And that's basically saying for instance down here I have a US west that US west I have an instance group US west because again all my stuff's in my lab itself but I have servers out in US west I have servers out in US east and I don't want to have the latency issue in between the two and open up the firewall between my ascender and there so I instead push out everything when I go to US west to a node over in US west and it runs the job from there very very simple common thing with advanceable um ascender itself works wonderfully but I

have the problem of say I have an external system like ascender react ascender react doesn't know what server or what inventory that server is in it has no idea uh if I have another thing satellite or I have a logging system or anything else that needs to call into a sender it has no idea where that server is so the problem that uh federated inventories is basically fixing is kind of making it a routed inventory what you're doing within here you're basically just go in and make a group of other inventories. And what's going to happen is is when I run a job against these uh this inventory itself, it just figures out where the host is supposed to be and launches a job for that host in that inventory against that instance group.

So, it solves a lot of the complex problems that the smart and constructed inventories did not fix because again with those you're only selecting one single instance group that it has to run over here. it can't solve the problem that I have two separate hosts that I need to run jobs against and they live in two separate inventories and have to run in two different locations. So, as a quick example here, if I go I'll just do my gather facts one and I have my Amazon federated inventory here. So, it's pointing at both my federated inventories. Uh I have my limit set to prompt on launch but I'll just run it against everything.

I only have two hosts in here. Next. So what happens is it basically we start slicing at the inventory level. So we use a slicing mechanism behind the scenes. What slicing normally is is say I have a ho a job I'm going to run. It has a thousand host. What I'm doing is cut it up into say 100 host chunks and then I run 10 jobs. Fix a lot of issues with scaling and everything because now we can do more forks etc. Spread it across instead of having the job running on one node in a cluster. But within here, what we've done is it looks at it and says, "Hey, this is a federated inventory.

Let me figure out where this is supposed to go." And if I have a host or a host that's going to run inside a particular inventory, I'll spin off a job for that inventory. And I may have had 15 inventories in there, but if I only had two hosts, it's only going to run the job for the inventory those are in. If they're both in the same inventory, it's going to run at the same one. But what it allowed me to do is basically spin this off. So now it's running against both inventories are both running in the correct location in this correct external node and it doesn't know anything different and this is just a mechanism behind the scene for the slicing that we utilize and it runs beautifully pretty much all your jobs.

Uh it could even slice even further than that. You can use it inside of workflows. You can you know whatever you may need. But within here is solving that real problem of I have lots of different inventories and I don't know where the host lives. most of our customers before this and the reason why we came up with this idea is one of our customers was talking about it and they're like yeah you know we have 15 different uh inventories and because of that we make 15 different copies of every single template because we create one for each thing because we have an external thing

that calls out and it has to know okay if I'm coming from over here I'm going to call into this in uh this job template that uses this inventory but I'm going to call into the same job template that use a different inventory if I use another one uh they can't pass with the way they're doing it, they can't pass the inventory ID as a prompt on launch. So instead, there was doing 15 different copies. And with this, they just now have one. They point to a federated inventory, and it just routes the job to where it needs to go. >> So that federated inventory has the 15 other inventories inside of it.

It's kind of like a group within a group kind of. >> Yeah, it's just a just a little grouping of inventories. you can only pick normal inventories. So, it won't let you pick smart or constructive inventories for those groupings just because these are already constructed of other inventories. So, instead, you're just basically saying this inventory, this one here, it doesn't matter. And it just spins off the job where needs to go. If those jobs need to run in a particular interest group with particular group bars, etc., they're going to get them. Even if I don't have that and I just have one instance group that everything runs in, it's still going to split off the jobs just to make sure everything's correct with them.

>> Got it. Got it. That makes a lot of sense. And seems super powerful again if you're scaling up >> um that you're not having to do things over and over again in in multiple inventories and split them up. >> Yes. >> If we actually look at the job here, let me show that real quick. Uh if we look at the job, you'll see that hey, both these actually ran. This one here ran in the US East instance group with the US East inventory. And if I click on the other one, you'll see it did the same over there just to showcase it. So this one ran US West and it's ran because it literally all it is slicing the job up depending on where the host lives and you know simple beautiful and that's what I like doing most is a simple beautiful things.

Um, no, that's that's great. I have one last question for you, Jimmy. It's a real quick one. You kind of touched on it earlier, and it's around that Ledger Pro uh kind of look and feel. Um, typically when you are running Antible, um, you're logging doing limited logging or you're shipping those logs off somewhere and probably paying someone else to to process those things for you or you've rolled your own kind of solution and upkeep on that thing might be kind of a nightmare. Um, can we talk a little bit about Ledger Pro and kind of how that workflow works? like where is do you do I get to log into that separately or is there a way is that part of a sender pro?

Can I can I branch it off and say I want only certain people to have access to that uh uh ledger side of things and and let the people who need to run playbooks just live in a sender? How does that what does that look like? >> Yeah. So basically they are two separate applications themselves. You basically it's no different than if I had a sender and I had Splunk. Some people can log into Splunk. Some people are going to log in a sender. They they do their own separate tool or jobs and they do them both well. It's just that literally everything that happens in a sender gets sent over to Ledger via the logging system in real time.

So as a playbook is running all its logs are streaming over to Ledger itself and then Ledger is just parsing it out. We're basically parsing out all the important parts and dropping everything else. So like when I have a playbook run and it says, "Okay, this is okay. Hey, I did not make a change. I skipped this. I skipped this. We don't really care about that. That's just data taking up that we don't need. Instead, as an auditor, I just want to see what's all the changes that you made across all your systems. Who made the change? What happened? What did they actually change? And that's what ledger itself is recording is that all these different changes happening, all these different packages uh were added, removed, all these services stopped, etc.

All that data is being recorded over there and it's immutable. So like over in a sender itself I can go in and delete jobs. So that accountability is gone. You cannot delete changes at a ledger pro except for the set guidelines on the settings that hey delete changes after you know 360 days after 90 days whatever you may have set to. So you can kind of enforce some some audit trails so that yes >> and then you can build reports off it and you can do all that too to say hey show me everything that happened you know on this server uh in the last

two weeks you know it's kind of the stuff you can't get with a sender because again a lot of these other tools we completely rewritten them they're all written in go so they're all small little binaries small little container images that do their job do them well a sender itself we have not rewritten it is written in Python and the schema on the back end is not kind of where I would like it to be. It doesn't like it doesn't allow us a lot of the searchability and other things we would like in there as if it was changed to how I would want to do it.

Let's just say that. So within here a lot of the stuff like I can't go in and say hey somebody changed the cif.com file on this server uh and this is the change they made on it. Where did that happen in the playbook? What playbook did that? What run did that? who's the user that launched it, when it happened. You can't get that in Sender. It can't not go into that level of detail. Even all the stuff is in there. Uh the schema behind the scene makes it a little more difficult to actually search for that type of data. But because we're parsing out and keeping everything separate and changed how everything's displayed over in Ledger, we're able to look at those individual events and very easily just nail it down to, hey, this is exactly where it happened.

>> Got it. Got it. I you know, I have one other question. and it wasn't on the uh the the docket here, but I want to make sure I'm asking it here. Um, so if I'm running Anible or I'm running a system maybe like AWX and I want to I'm looking at this, I'm like, great, I love federated inventories. I like that ledger. It makes me feel comfortable. Um, I'm grasp putting my head around uh uh React and I'm liking it. if I want to kind of look and feel get into Ascender Pro, am I going to have to kind of like redo my playbooks? Um, or is it a heavy uplift to like take my existing kind of library playbooks and and port it over?

What does that kind of migration look like? Uh, >> yeah. So, if you're coming from Anible itself, you're not really going to change that much. Your biggest real change is back in the hit command line, everybody used vaults everywhere. stuck vaults in your repos and everything. You kind of get away from that with credentials in the sender. You know, you're supposed to be saving everything in credentials because not only can I save, you know, username and password type stuff in credentials, I can create my own custom credentials to do anything, you know, any type of data, security keys, uh, certificates, product codes, whatever I want. I can build a credential to save that and then hand it to a playbook to run or allow someone to utilize it.

So, you have to kind of get away from that vault mindset. But again, even in the transition phase, we have credentials for vault, so you can pass that in and still use a vault if you had it. But most everything else is going to run exactly the same. Your biggest thing is that if you're writing playbooks before for a particular ansible version you're running, you're going to have to build an e container, an execution um container for that to be able to run it with that ansible version. But that's very simple. And one of the next versions we're coming out with has the executional builder inside the sender itself.

makes it super easy. Just point at a repo and it'll build it out for you. And but if you're coming from like even the AWS side, you know, we have migration scripts that you won't lose anything. It's all you do is you take a backup your AWS, you export it out, you import it over into a sender, you install a sender, override the database with your AWS database, and then we roll back some migrations and then roll it back forward to where we are. And everything's back up and running. All your job logs are there, all your jobs, your templates, your users, everything. >> Got it.

Got it. I mean, it seems fairly easy. Also, making sure to kind of switching over to credentials is probably just a good security idea anyway. Yeah. Right. Yeah. >> Well, and that point you started thinking about even the ability to swap out into a external credential manager and go with Hashi Corb or any of the cyber arch or other products out there. >> Yeah. Yeah. No, it's it's a good excuse to do some other modernization that you probably should be getting getting done anyways. Yeah, absolutely. >> Awesome. Well, uh that was the whole loop that we just showed you. One Ascender Pro platform kind of catching the problems, fixing them, running it across your whole fleet, um logging it.

They're all working together, all kind of a unified interface. Jimmy, thank you. This was great. It was good to kind of get a baseline of kind of what what works. I loved looking at the some of those new features. Um, React is something I'm still getting my head around, not because it's hard to understand, but because it changes kind of how you can do things inside with Ansible. Um, so super exciting stuff. >> Thanks for having me. >> Yeah, absolutely. Uh, for those who are watching, if you're watching on demand after the fact, do us a favor. Drop a con uh comment on the video itself uh with any of your anible scenarios that you are that are giving you grief.

We genuinely like to kind of uh touch base with you, hear from you and maybe reach out and see what we can do. Um or you can reach out to us directly on ciq.com. We'd love to walk you through your environment. Um see see where the tools and features inside pro might help you and kind of step you through uh those scenarios to see if it would work for you. Um, with that being said, I want to thank everybody for watching. Um, and have a great day. >> Yeah. Thanks everyone.