 Okay. Thank you for introduction. So, I actually wanted to introduce myself, but I only requested 30-minute slots, so we don't have time for it. So, feel free to ask me out if you are interested in anything. So, today we'll be talking about Ansible and Builder. And I would like to introduce both tools, because I'm pretty sure that most of you know all of them. But let's be nice with the newcomers and introduce what are these. But I'll do it on my way, and I'll introduce those, how I feel about those tools. Okay, let's start with Ansible. So, for me, Ansible is actually two things. First, it's a tool. So, I can just go DNF install Ansible, and that's it. I just install it on it. I can start using it right away. It doesn't need any clients or servers or demons or any special configuration. Just like you install it and you can use it right away. So, it's a tool. Then other thing, it's actually language or definition language. And there's an example on the right side. So, you just write this Ansible playbook. You define what you want to achieve, and then you just use the tool and run it on some target system. So, the target system could be your local machine. It could be a virtual machine. It could be your 10,000 servers in the cloud. So, you can use this tool to do such things. So, Ansible provision infrastructure. Then we have Builder. So, what's Builder? Again, it's a tool. You just DNF install Builder, and you can use it right away. You don't need to, like, system control, start anything, then edit some crazy config file, just install it, and you can use it right away. It's a tool. Builder actually, okay, so, what Builder does, it creates container images or builds them, like, whatever. And you can do it in multiple ways. So, you probably know the one when you use Docker files. So, Builder can create container images using Docker files. It can also create container images from scratch. So, you just do Builder from scratch, and then you have empty directory, and you can put whatever files you want in there, and then have your container image the way you want. And finally, you can script the process yourself, like, you don't need to use any Docker files at all. You can write simple batch scripts or whatever you want. You can create container, put some files in there, run some commands, then commit it, and you have your image. You don't need to use any Docker files, anything special. I've already seen people writing very simple shell scripts which create their container images, and they are very happy about it. They are not constrained by any special formats or anything like that. Okay, these are the tools we'll be using today, this presentation. So, I just talk about tool which does provisioning and tool which does building images. So, the question is, like, how can we make them work together? And so, this is DevConf, and we love all these technical details. Please, I love to. And we already had some very technical presentations, so let's keep up the pace. And I'll describe how this work, like, how this can work together. So, luckily, in Ansible Team, we have some very smart people working in there, and the way Ansible actually connects to the target environment is actually a plug-in. There are dozens of plug-ins for connecting to, like, virtual machines or containers or your local host. And if you're using Ansible, you're probably using mostly SSH plug-in or local plug-in, so that, like, SSH plug-in connects to some environment, and you already have this all set up because you're in SSH, right? And Ansible just takes advantage of it and runs all the commands, copies files over there. And with local, it just, it doesn't need to copy or run anything. You just run it locally on your local host. So, these are probably the most too-known connection plug-ins for Ansible. So, and there is also a connection plug-in for Builda. And what does it actually mean to write such a connection plug-in? It's actually very simple. You just need to implement two simple methods. Two of them are copying files to the environment, copying files from the environment, and the third one is running in the target environment. So, how do we do this with Builda? Okay, so, we have our container. It's, like, probably some, like, mount point somewhere. And we just need to do Buildamount. And then we can copy files to that directory or copy them from them. Okay, so we have two done. So, the third one is running commands. So, how do we do that? Luckily, we have Buildarun command. So, we can do Buildarun, our container, and then it's being run in the container. So, that's pretty much it. So, this is how the connection plug-in looks. And there's an example on the screen. So, we can see that we, first we are doing Buildamount. Then we have a path where we can interact with the container. And then we just do Buildarun. And we can run containers, commands inside. So, pretty simple, right? Okay, so, let's try it. So, here is probably the simplest way how you can use Ansible, use your Ansible playbooks, and build images with them. And, to be honest, like, I actually took this example from one of our projects. Like, this is what we are using in production. We, we actually started with Ansible. We were running it directly on the VM. But then we realized, okay, we want to put it in a container. So, it doesn't mean that I have to rewrite it as a Docker file right now. Nope. So, we just did this and it works pretty nice. So, the only downside is that there's no caching. So, we always need to run from scratch. That's actually pretty bad. But it works. So, this is how we are using it. But then after a couple of months, I was like, yeah, it's pretty neat. I can use Ansible. But I would like to get all those, like, very nice build features like caching or, I don't know, even like one command, not running these five crazy commands. So, I realized that, okay, so I'll start the new tool which will pretty much wrap these five commands and I'll use it. And then I keep adding more and more features. And right now, I'm using it in like a couple, in a couple of projects. You're actually the first crowd I'm talking publicly about the tool. I'm working on it for a couple of months. And it actually works very nice. So, its name is Ansible Bender. Actually, Dan has the name. I need to work on it probably. So, we have Futurama reference. So, the tool bends containers and makes them, turns them into container images. And obviously, it has shiny body parts. So, what it can do? So, the first thing I wanted to have it in there, like, to have builds as first class citizens. Like, in the tools such as Docker or even Builda, you can do builds, but you can't say like, okay, I would like to know the state of the build from three weeks ago. Or I would like to know what builds I just did. Or I would like to see build logs from my previous build. So, in the tool, I actually, like, there's, every build has its build ID and you can reference in bunch of commands to the build. So, I'll show it in the demo. Where's the time? Oh, never mind. Yeah, I'll show it in the demo. Then, whenever you build the image, you can push it to, like, registry or even Docker or even to a file. And this is just a simple wrapper on top of Builda push. So, it's very simple. And finally, it has configurable layering and caching. So, you can, like, in half of your playbook, you can say, okay, I don't want to cache anymore and I want to run next task, like, forever. Or like, every time. This is very useful when you are doing commands such as git clone when you want to be sure that you have the latest tip of your branch. Obviously, it's, like, the tool is only a couple of months old, so there's still several downsides. So, one of them is that it doesn't work in rootless mode with overlay. But luckily, we met together with the container team yesterday and we were able to figure it out. So, I'll probably fix it in couple, in next week. And final thing is that, right now, when you are running the tool and you want to set some metadata on to the final image, like, some ports or labels, you can do it only from command line, which is really stupid because it, like, your command line can be really, really long. So, I want to change this and include this metadata inside the playbook and that's what I'll probably do next as well. Okay. So, this is my last slide. Or actually, this wasn't my last slide yesterday, but I realized that, okay, so, I talk about some tools and how I'm using it, but you probably feel like, okay, I'm using my way and it's very, very okay for me. So, what does this guy trying to tell me? So, I realized that I should probably speak why, like, why should we care about this? But for that, I actually need to put my ansible hat off and, like, think about it like, I'm not using ansible, so why should I care? So, first things are that, like, right now, the industry standard for building images is Docker files. Like, everyone using it, that's pretty much a standard. And what I really don't like about Docker files, especially when a couple of years ago, when we were trying to do build system within Red Hat and in Fedora for building images was that Docker files are custom formats. It's not a JSON or YAML or anything like this. It's a custom format and there's no specification. So, obviously, there's no library to manipulate them. So, we actually need to write our own and, yeah, it wasn't easy. So, the first thing, second thing is when you write a Docker file, you can only use it to build a Docker image. And that's it. Like, you can't use it to provision your VM or to try to run locally. Like, you can do only images. So, then, you should duplicate your work. You need to write some shell script or ansible playbooks and Docker files. And they can do, like, the same thing. Next thing, what I really hate or probably just, like, it's not actual anymore, but a couple of years ago, I was really frustrated that there was no features being done in Docker site for Builder and Docker files. They actually canceled all the pull requests, closed all the issues and said, like, Builder, right now we are trying to get it out of Docker and we don't accept any contributions. So, sorry. And this was for a couple of years and people were, like, okay, but I want to do volume mounts during Build, but, yeah, sorry, we don't accept any things. And this was really frustrating. So, actually, these two talks about this, they've come so we're interested to do some other links. And then Ansible Designer project came and I realized that I can actually use something else, no Docker files to build my images and actually, like, light bulb on top of my head and realize that I can do it differently. And then Builder came and actually, I really love Builder, that it's a tool, it's not a demon or anything like it. It allows you to do all these different things. You can pretty much set your own workflow. You can build from scratch, build from Docker file, write a shell script and it's actually, like, you can do it on your own. You don't need to be locked to, like, single format, single platform. You can do it however you want. Okay, so this is the talk and are you interested in a demo? Okay, let's do it. Okay, so right now I'm inside the repo of the tool and I have a bunch of tests and testing playbook. So, let's try it out. Okay, so this is how you run the tool. It's like Ansible Bender, Build, then pass to the playbook, then the base image you want to use and then name of the image. So, I just hit enter. Yeah, if you are familiar with Ansible, this is the normal Ansible output. It's actually running the playbook. And then if you are familiar with Builder, this is the normal output from Builder when the image is done and ready for you. So, right now I can do, actually Build Images. Don't be scared. And this is my image I just built. As I said, I treat, like, Builds as a first-class citizen. So, I can do List Builds. And I did two builds, one in the morning when I was trying it out and the other one right now. So, I can List Builds. I can, I can get logs. If I don't specify ID is the latest build. So, I can see the logs. I can even inspect the build. And here are all the metadata about the build. So, if you want to tinker around or play with it or see what's going on, you can see everything in there. So, this is the tool. So, I'm not saying, like, this is the best way to build your images and you should use it right now. So, this is how I do it and it works very well for me. So, maybe it will be useful for you. And maybe not. Maybe you keep using dogger files or use Builder with scratch, with the scratch method or write or simple shell script. The point is that there are multiple ways of doing it and it's really up to you what suits you best. So, I guess we can turn it to questions. All right, yeah. Thank you. That's a very good point. So, what was the playbook? Okay, so the playbook is very simple. So, first two tasks are actually related to debugging when I was playing with it and it didn't work and I had to see all the environment variables. And the second, two tasks are really what you do in your builds all the time. Run commands and copy files so that I'm sure that it, like, works to some extent. As I said, it's very simple. So, are there any more questions? So, the question was how the resulting image looks with the layering strategy. So, the tool UncivilBender has dedicated Uncivil callback plugin and this plugin is involved during the task execution. So, after every task is executed, like the container state, it snapshots it so it has all the layers. But you can, as I said, you can easily turn it off. So, I should be able to do some, like, tags, no cache. If I do this, like, from that point onwards, like, caching is disabled and all the tasks afterwards will be run every time. There was also a question over here. Sorry, I don't understand the question. So, is the question whether the resulting image will contain this file? Yes. So, this is actually the limitation of Uncivil that you need to have Python interpreted on your target environment. So, I actually didn't speak about it too much. I'm really sorry. It was this slide. So, if you look in the middle, in Uncivil, you need to define your inventory file so that Uncivil knows to which host or to which environment it should connect. So, we are doing it over here. So, our environment is the container. We'll be using the build up connection plugin and then we tell it where the Python interpreter is located in the target environment. So, you need to have Python inside your container. So, yes, there is a base image. And when you saw how I run the build, so this is the command line to run the build. It's build command. Then pass to the playbook and this is the base image. So, we are using Federa 29. So, are there any more questions? So, if not, feel free to stop by, say hi and I can speak about anything you want. Thank you very much for attending. Thank you very much.