 All right, everyone, I'm going to get started here. My name is Tim Appnell. I am a product evangelist for Ansible. Long history with Ansible. I was an Ansible contributor from, I think, 0.5. It's my first involvement with Ansible. Ansible customer, then I became an Ansible consultant and now product manager. So I've seen it from all sides. I have a lot of material to cover in only 25 minutes. So I'm going to attempt not to unleash my full New Yorker on you and talk too fast, but I will apologize ahead of time if I whip through this too quickly. Stop me in the halls if you have any questions or come up and speak to me later. So what I wanted to talk about today is how you can work with and manage Kubernetes applications with Ansible. A lot of people say, oh, Ansible, that's a configuration management tool for traditional IT. It's not cloud-native. It's dead. It's irrelevant now in the Kubernetes world. And actually, I really think it is. And I'm going to show you some of the different ways that you can use Ansible today. So the first thing I want to talk about is how Ansible fits naturally into Kubernetes environment. They both make hard things easier through automation and orchestration. They also are very active, widely used tools with really thriving communities. Look up GitHub's Octoverse. Ansible's been the top 10 the last four years. And now Kubernetes has been there at least two years. So we're both extremely active, large projects, very large communities and ecosystems. And the other thing is that they both use YAML to describe their desired state of the world. Here's an example of what I mean. On the left side, you have a YAML file for creating a configuration map. You can use it with cube control, for example. On the right, we have an identical Ansible task. And if you look at the part that's in red up there, you'll notice that there's almost identical to what's on the left. The one difference here being that we're able to use templating in Ansible. And that's a really, I think, useful thing that you can template out what you're going to do. And you're going to see as I talk through some of these other things where that templating that Ansible has built in natively can be very useful to doing multi-cluster management. There we go. There's a bit of shorthand that you can use. If you don't want to have these definitions in line inside of your playbook itself, you can store those files externally, read them in to your playbook. So it's a nice little piece of shorthand. I always like to show people when I'm talking about these things. OK. So that's a little bit of how the two of them are similar. I want to talk a little bit about how you can use them to do multi-cluster deployments with Ansible. Does this look familiar? This drives me crazy when I see this stuff, because I'm an automation guy. And one of my theorems of automation is anything you type in on the command line or any type of UI that you click on is an opportunity to automate. And this is actually a pretty tame one. I actually tried to go through a workshop. I spent 90 minutes typing in stuff like this, trying to get an operator to come up. And after 90 minutes, still didn't have it up, and the workshop was over. This is where, and this is the type of thing that we think we can solve better with Ansible. So here's an example of what I mean. You can take, excuse me, you can take variable inputs. This is just a variable file. This could have been an Ansible inventory, host file, groups, whatever you get your variables from to define what it is that you're trying to do. And then use the built-in templating to lay out, well, where are the different inputs that I'm giving this thing going to go into to send this definition off to Kubernetes? And at that point, you can write a test that takes that template and those variables, that configuration, pull them all together and ship that off to a Kubernetes cluster through the Kubernetes API using, in this case, the kates module. And at that point, you run it and you can pass in these different variables to point the configuration or modify the configuration as needed to send it to different clusters or with different namespaces or whatever else it is that you need to do and need to get done. So this is what it would look like roughly at a high level that you have the parameters, you have the template getting pulled together in the playbook that gets run through the Ansible engine. This could also be an AWX or tower and then that can go out to different Kubernetes clusters. So it's a way to do consistent, repeatable Kubernetes application and service deployments using Ansible itself. And I'm gonna show this stuff by way. I'm gonna hopefully get to the demo which is why I'm moving along here as quickly as I can. All right, so another way that Ansible can be used with Kubernetes is with Kubernetes operators. For those of you who aren't familiar with Kubernetes operators, they're a way to simplify the management of complex Kubernetes applications. So Kubernetes does a lot out of the box, especially when you're working with the primitives that are in there. But if you need to do something, if you have an application or service that needs special handling, what operators does is gives you a way to teach Kubernetes that extra smarts, that what it needs to know about your application to manage it on the cluster, manage it effectively, efficiently. So it's encoding the human operational knowledge to manage the entire lifecycle of your application or service and to do it in a Kubernetes native way. Now the thing is, is typically operators or at least when the idea was put out there was written in go. And so there's, that takes some expertise. But more importantly, you need to understand the internals of Kubernetes and the Kubernetes API to do a lot of common plumbing operations, things that you need to do in order to write an effective operator, keeping your owner references straight, caching your calls to APIs, to the API server so you don't create essentially a denial of service attack on yourself. We've seen that happen before, things of that nature. So what our, some of our engineers came up with and said, well there's a lot of things that we could abstract away and make this a lot easier for the 80 or 90 or we're actually hoping for more like 99% of the cases when you're writing an operator out there by using Ansible for this. So we've created the Ansible operator SDK. I should mention that the whole operator SDK is right now in the process of going into the CNCF. This is something that Red Hat is open source and wants to donate to the wider CNCF world. And part of that is this Ansible operator SDK. And what it does is it allows you to create a fully functional operator with just using Ansible code. And I'm again gonna be showing that some more here. So some of the advantages we see of this approach is that it's already an existing tool that's tried and trusted. There's a lot of people out there already using Ansible and know it. They don't have to learn something new. And that you're able to use the same tool to support both cloud native and traditional IT automation through this. The other is that it's lowering the barrier to entry. We all know that Kubernetes as powerful as it is isn't the easiest thing to work with. And it really requires a lot of expertise to use. Well, this is a way of making at least a part of Kubernetes more inclusive to more people by not requiring programming skills necessarily to get this thing done. And that helps you then iterate faster, use your staff more effectively. And like I was saying earlier, you can take advantage of this templating and the declarative state that the two share together. And then the other thing that this SDK brings is this abstraction layer in the helpers that help you avoid all this common plumbing and redundant work that you have to do with any operator that you write. I actually heard someone speak and they had, at KubeCon and they talked about that they had written a microservice that was only a few hundred lines of code. And then they went to write an operator and ended up writing like 10,000 lines of Golang in order to service this one thing that was a few hundred lines long and that he talked about the use of Ansible or another similar tool called Kudo that was much more effective for those sorts of things and more, let's say, the right size. Anyway, moving right along because like I said, don't have a lot of time, this is the overview of what a Kubernetes operator using Ansible looks like. Everything's generally the same except for if you wanna look at what's in the dotted box there, what's inside the operator, there's three significant parts. You wanna be aware of there's the operator SDK binary. This is a generic go binary that our engineers have written that goes in there. It gets packaged up when you do a build. You don't need to think about it. The parts that as a developer that creating an operator with Ansible you're focused on is this watch's file and what that does is maps a Kubernetes resource to group version kind to a playbook or role that has been included. So this is how you map Kubernetes events to Ansible automation and then of course there's either an Ansible playbook or a role that's inside of that operator and then from there, all of that talks to your Kubernetes application manages it does all that work. So for you as a developer, all you have to do is worry about what is in that white box up there. Create that watch's file, write your Ansible automation. By using the Ansible operator SDK you get everything you see in the gray box for free. That's part of the build process. You don't think about it. You just run it and you're good to go and this all gets put together into one container that you can deploy that works as an operator in managing your app. It's worth mentioning one of the criticisms or maybe it was even kind of a slur I've gotten is that well this Ansible stuff is a toy when it comes to cloud native. It actually, I disagree highly and it really is able to do the full lifecycle much like go. There are some edge cases where you really need fine grain control of what's happening at the API level but we find that those are really gonna be rare exceptions than the norm. So that's why we really think this Ansible tool is really effective. There's a third option in the operator SDK with Helm but that is only effective for what Helm can do which is an install and a bit of upgrading. You can't do the whole lifecycle with it. So to do a development with Ansible to create an operator, a few quick and easy steps. I said this is built into the operator SDK. This isn't a plugin or an extra. If you install the operator SDK you already have this. So when you run a new, it can create an entire skeleton project for you with a few parameters. The key one is the one I have there in red which is to say type equals Ansible. So then that way it creates an Ansible project for you instead of a go project. That point you write your automation, you update your watch's file because actually that new will create a watch file for you. I often don't even have to modify what it creates but it's there if you need it and you can tailor it as you see fit. And then you do a build. The build is a very shallow thing but it pulls together all those components that you get. The operator SDK binary, things like that into a container image that now you can put in a registry and deploy to your Kubernetes cluster to show, not to show to manage your apps as they go out there. Bit of fun, this is our mascot. This is the operable. He's like I said, our little mascot. We had a little bit of fun. So I got stickers. Sorry, I don't have any of the t-shirts but stop by and see me. Afterwards I got swag on this guy. Okay, so I think, I'm gonna take a breath and I'm gonna switch over to do some demos and show you these things here. Hopefully get the, if I wasn't clear enough to make it more clear. So the first thing I do is to show you, I'm pardon me for sitting down but it's just easier for me to see. I'm a little too tall for this monitor. I'm gonna show you what it's like if you create your own operator here. So let's see, I hate to type so I'm just gonna use what's in my history. So this is a, I'm gonna create an operator called a null operator for this case. Give it the API version, kind equals null, type equals ansible. So this is what you saw on my previous slides. Run that, get a whole bunch of status messages out there, ran really fast, which is great. And let's see here, make this easier for all of you to see. Created a whole bunch of things, build directory, deploy, which has all the different resource definition. Actually let me just show you this, what am I saying? So in the build we get a Docker file that helps you do the build of the image in the deploy. We get a whole bunch of YAML files that you can use with kubectl, the CRCRD, the roll bindings to service account, things like that. And then we get under rolls, we have a null roll that's already created for us, it's ready, it's a whole bunch of stub files that now we can build our automation around. And then this is a watch file that I talked about earlier. So you have the group version kind, so it's looking for this null resource, and then it's calling the roll that it generated for you. Like I said, this could be modified, but it's a good starter, okay. So that's just Cray one, that's not terribly interesting. Let me show you one that's already been built and then I'm gonna use in the rest of my demos here. So this is one, while I explain what McRouter is, what I will show you though is, let's show some of the tasks under the rolls. So this here, it's doing three API calls to the Cates, taking advantage of that shorthand that I showed you and some templates that I'll also show you in a second here to create the stateful set for memcache, create a service for memcache and then do a deployment of this thing called McRouter. Should have explained what that is first, but let's just get through this code. And then just to get an idea of what a template might look like in this case. So here's a template. So this looks like a definition file, but we see the double mustaches, which is part of Jinja 2, the templating engine that Ansible embeds. And you can have all type of stuff in it, like down here we have logic for the type of pool setup that we're using. In this case, you're sharded or replicated and then how we build out the parameters based on those switches. So it makes it easier to replicate and like I said, bring together all that operational knowledge into one thing. Okay, so let me go back to my slides here for a second. So that's building an operator really quickly and showing you what one looks like at a very quickly high level. So this is a slide I should have showed you first. So I'm gonna show a demo here, deploying an operator and also showing you, using doing it in a multicluster way. So there are two components to this particular app that we have this scalable caching service. It's Memcache, which we've all heard of it. I know it's been around a long time, 15, 20 years. A lot of people use it and one that just happens to be Facebook. I was involved in the Memcache community, like 15, whatever it was, years gone and remember when this new startup, Facebook showed up saying, yeah, we're making use of Memcache. Well, they apparently still are today because they took, they say, Memcache is great, but they're kind of dumb. It's a node, it can't replicate, it can't do all this sophisticated stuff. So they built something called McRouter that sits on the front of a pool of these Memcache nodes and adds all this additional functionality like connection pooling and flexible routing and replicated pools and a whole bunch of other stuff. It's a pretty neat project that I haven't heard of much, but I thought this will make a really good demo because when you put it into Kubernetes and you have all these different nodes, these Memcache nodes out there in the pool, you have to inform McRouter as you add more or drop some and you have to keep telling McRouter what's in its pool. So you don't wanna be doing that manually. This is a perfect use of an operator which is monitoring what's happening on your cluster, can pick up an event and go, oh, I need to adjust my configuration here. So it works with the pool. So that's essentially what this diagram shows and I should have had up sooner. So we have the operator up front that's talking to McRouter and letting it know as a node drops off or new ones come online to adjust its configuration to do this dynamically and it happens within a split second of the event firing inside of Kubernetes itself. So it's kind of a hands-off management of this app. All right, so back to my terminal window. All right, so I'm gonna move to another project I have here and so what I do is I created a configuration file for that's feeding in parameters to my operator here and I'm giving it a service name and I'm saying since this is dev, I only need a pool of one and here's my cube control config file to use when I run this playbook. So at this point, actually let me do this. That was me tearing it down before I came here. Okay, so I'm just running a playbook. Actually, you know what? I should show you I'm not cheating here, shouldn't I? All right, so I already deployed, I forgot, sorry, I deployed my operator ahead of time but as we see we don't have any of this app running at this point. So this is running locally in Minicube on my machine right now. So now here's why I wanna run. So I'm feeding in that dev configuration file I just showed you into my playbook. Like a good boy, I encrypted my credentials so that no one else can see what's going on there and then if I check within cube control, oh, which has happened there. Oh, there it is, all right. Just a little minor delay because it's my pokey MacBook here. We see that it deployed a, if we look up at the pods it deployed a memcache node in the McRouter instance came up there. So now we've deployed that entire application by running that playbook. Now that is in terribly exciting, I can tell but now that I've been doing my dev work, I've tested it out, I know I got it, what I wanted to do, let's push it now to my test cluster. So in this case, let's see, if I have a different file here we look what I have running up there. This'll be a little bit slow. Okay, so here we have the operator that again I've already deployed ahead of time just to save time here. Let me run the playbook again but now actually let me show you what I'm gonna send it. So now I have a different configuration where I'm giving it a different service name. I'm putting in default namespace. This time I'm saying I want a pool of five and I'm gonna use the replicated pool setup and I'm giving it a different config file so it goes to a different Kubernetes API endpoint. All right, so there's that. This one's all the way back at the state. So now if we go back to do kube control, come on you, this server's running back at the state. So now we see our app is coming up, it's still deploying. All right, so now it rolled out a pool of five in our caching service here. So let's make a quick change here because I think I have a second. So let's say, all right, we say, oh, you're using up too much of our testing infrastructure. You gotta scale it down, five's too many. We can just go to the end here, do, do, do. I miss a physical escape button. Constantly make typos because of this. All right, so I'm gonna run it again, put it into that finger that, great, that ran. Actually, let's just show the pods this time. All right, we see here, it's now scaling things down by taking down, it already took down one of the memcache nodes and another one's still terminating. So that was just by changing one thing there. The one other thing I'd like to say with the minute or two I have left that I could have shown here, but like I said, not a lot. Yesterday I gave a presentation on how you can use all this stuff I just showed you in a GitOps workflow. So I could have very easily set this up using Ansible Tower or AWX, where it would monitor my Git repo that when I would do a commit and push that, it would automatically pick it up and run the playbook for me. So I would never have to leave Git itself to have made that change that you saw me do to go from five to three or whatever configuration change I made. So that was yesterday's talk, sorry you missed it, but I guess it was videotaped. So that, I believe, yes it is. Any questions in the one minute I have? I maybe have time for one. Yes, it was not. No, it was not. Our OpenShift engineers are highly proficient in Go and are more comfortable with that. So to my knowledge, the majority of those operators were written in Go. Absolutely, especially if they don't have Go expertise. I used to work for Bank of America and I tell you they have very few Go people and if they got them they're just learning that skill to get another job. So it's very hard for them to, so one of the things that we've seen that we think this can really help with, particularly with customers, is when they don't have that expertise this gives them a lower barrier to entry in order to automate what they're doing in Kubernetes on the cluster itself. Versus Go which is a little onerous and then trying to learn the internals of Kubernetes that we abstract them away from here. So I am out of time here but by all means, if you see me in the halls, please stop me contrary to public opinion, I do not bite and I'd love to hear from you and talk to you. So thank you for listening. Thank you. Thank you.