 Let's do this. So my name is Adam Miller. I've been in the Fedora project for a long time and a contributing member of the infrastructure team less so these days because life's busy, but Yeah, so the infrastructure team is heavily using Ansible to to automate and provision and Configure all of the infrastructure in Fedora and so part of my motivation as a fan of Fedora's fan of the infrastructure team And then also as a member of the Ansible team and a fan of Ansible Kind of hoping to kind of drum up some folks with a little bit of skill set to hopefully contribute back to that effort So oh really quickly Just attribution Did I change? Ha That's wrong. These are I Stole most these slides from James Hausnick. He's the lead of Ansible Galaxy But I left the wrong attribution on there because I stole a different slide deck from James, Kamarata. I Borrowed we shared Collective collaboration. Okay, so things we're gonna talk about today Things we're talking about it. We're quickly going to discuss what Ansible is we're gonna talk about ad hoc command orchestration inventory Playbooks and roles. So just quick show of hands. Who is familiar with Ansible is? Very cool. Okay, most of the room. So This is probably review for most of you, but just very quickly Ansible is a simple agent list Simple agent list item potent task automation tool And the reason I make that distinction is because a lot of people call it configuration management and technically We can't accomplish configuration management because some of the things that we can automate are effectively the automation of templating configuration files those kind of things just kind of traditional definition of state for the system But as an automation platform as automation tool, we can do considerably more than that We can provision our virtual machines. We can do bare metal bootstrapping we can actually You know work with networking devices Those kind of things we can provision your cloud All all sorts of very interesting things and we can do so between multiple sets of hosts So where we have the ability to kind of work Okay, sorry, I don't like being like tethered to this thing We have the ability to work between different sets of hosts and kind of jump back and forth and make conditional Action take conditional action based on some parameters of the environment. So A a task when we talk about automating things The fundamental component that we're going to be automating is a task. So tasks functionality is provided by a module Tasks are grouped together via plays. So a set of tasks is considered a play and a play is restricted to a group of hosts A play operates. Yeah, okay, so a play operates on a set of hosts hosts are indexed via an inventory And we'll talk about what that means in a minute Playbooks contain what can contain one or more plays Traditionally a lot of playbooks you'll see will only contain one play They only have one heading with one group of hosts, but you can actually put multiple plays in a playbook And then roles with the concept of a role a role is a bundled reusable set of content And that that can be you know, your templates that can be your files that can be your task lists those kind of things And they're meant to be kind of all encompassing and able to be redistributed and shared and reused So this is an example of an ad hoc command so in this example we were using the yum module We're using the arguments to the yum module package Instate and the values we're giving to those respectively are bash and installed So if you can see I don't know hopefully in the back you can see it's ansible local host So local host there is going to be our identifier for a host group and we were using local host which is a You can actually define local host in an inventory, but we also kind of just have a built-in inferred Local hosts so we know what we mean there Dash M we pass the module which is yum dash a is going to be the arguments and then from the command line You need to quote those so that we have a string that's passed in to be parsed So package equals bash state equals installed and then you get some output and so we have the host name Which is local host a status which would be success to me success success changed or failed Here we had no change so the status change was false And then message nothing to do there was nothing to do for that one So what if we want to do more than one thing? Well, that's where playbooks come in So getting started the Before we get into playbooks, there's a few things we're going to cover That kind of are in service of better understanding playbooks so really quickly module we kind of covered this but it's called by a task performs an action and You can actually use it to Take direct action through an API call It's potentially it's potentially possible that on the back end the module wraps a command line tool or something but the idea is that the module handles what is necessary to perform item potent task declarative state so you have the desire that your system has the package bash State installed you you request that of the module and the module goes out and handles that for you That's kind of the idea behind it and and in this you know in this instance of yum and DNF It calls the respective back-end Python APIs But in the risk in the instance of certain modules, it just there's not a you know reasonable Python API Something to note about modules so right now ants will include I think somewhere in the ballpark of 2,200 different modules So if you need to do something as a reasonable chance that we have the functionality now However, you can write your own and something to note about writing your own is you can write your own modules in any Programming language you want so long as it in its sec accepts json as input and will return json as output However to have your modules be accepted upstream into ansible core They need to be written in Python So facts facts are provided by the setup module Anybody who's ever done anything with configuration management in the past is probably very familiar with this It basically just kind of goes through and scans the system and provides you a set of facts about the system This can be Platform architecture distribution name Release major minor version It can be your network Interfaces what their IP addresses are you know IPv4 IPv6? Those kind of things and it provides us in a standard standard way with standard names so that you can actually use those as Variables inside of your playbooks to do conditionals those kind of things Oh and variable substitution so anyways It's using the the set fact so there's a there's a kind of like a high order Built-in called set fact and you can actually on a play define if you want to I'm sorry Gather facts so there's a high order thing in plays you can say gather facts true or false to whether or not you want to Have your play go out and do that scan or just skip it all together But you can actually create a fact Inline in your playbook using set fact so for any reason you've gathered some Output you've registered the output of a task and you therefore want to keep that persistent for the host For the duration of the play playbook for the host you're working on you can do a set fact and it will actually store that in Whatever means you have you can cache facts, but we'll get to that later So inventory inventory defines your infrastructure you can define it using a static file You can just write everything out you can do it dynamically We have dynamic inventories and those will query some system So in the instance of a infrastructure as a service provider such as AWS Google compute Azure Open stack those kind of things we have dynamic inventories that will go out and query what you've created within some confines or parameters return the metadata you can then Index your hosts that way on the fly Which is very powerful in in the sense of if you are using ansible to create Systems out there, but then they're immediately available in your inventory and you can you can work with them from there so as well provides a considerable number of Dynamic inventories we have them in contrived. There's also the new the new way There's inventory plugins. We're we're still working on getting those built up I think we've got about 10 10 or 12 of those right now, but there's a lot of There's a lot of them available in in the in the contrib directory of ansible So this is an inventory So inventories traditionally were any files. We also now support YAML files But if you're gonna do static file definition, you just this is it So you have a group name which would be web and then you have a list of hosts There are certain variables that you can list out here and there's different ways we can do that But that's a little bit outside of the scope here. This is this is an inventory at face value so we'll note here web being our group name and These being our hosts so anytime if I were to run that ad hoc command from before where I said local host and I do ansible web Dash M yum dash a package equals bash state equals installed It will actually run go out and run that on both of these systems now because the group is web and that's my identifier That's my filter So playbooks are text files. They're written in YAML They define a set of plays and they bring to vet together inventory and tasks So when and we'll actually we'll just go for it So this is a playbook and the idea here is that the playbook is relatively easy for somebody Who's never seen one before to understand what's going on. So let's read it from top to bottom So a name so the name of this play is to install and start engine X The hosts we wanted to run on our web hosts from our inventory, that's where it's gonna run So become means that we want this to actually become a privileged user Then we have variables. So these variables are going to be passed into the rest of the play So we have engine X packages. These are gonna be packages that we want installed engine X text message and engine X keep alive time out now in the tasks This is our task section. So just like we did with command line This is how we will this is how we will stream together many tasks is in the task section We would do what we would have done from the command line and just instead we define it with a name Which would be install engine X packages and then we can say yum And this should look pretty familiar name equals state equals And then the thing the the so name equals item state equals present So the thing where we throw a curveball here and what's new is this is how you Do a variable substitution? So we use a ginger to templating language. So if anybody's familiar with ginger to it's a relatively popular Python templating language and so you you know open curly open curly close curly Close curly the thing to note about item in this instance is it's a built-in loop So down here with items With items will loop through the list. So engine X packages up there We've defined as engine X Python pip Python develop in GCC It's going to iterate through each one of those now something to note is While this is still supported today, and we'll continue to be supported. We've recently introduced a new feature But it's possible that not everybody's using the develop branch of ansible But in the the new version we're we're actually just gonna have an inherent loop to where if you pass in The the list in a loop will will do some things for you. It'll be kind of like syntactic happiness The other thing to note is the yum module. Oh gosh it's a two Two four two five Remember at some point the young module actually accept a list so you can kind of just skip this these days And and if you do that with the young module of the DNF module You actually get a performance increase because it will accept it and parse it as a single transaction but for for the example of a Task the concept of doing with items to be able to loop you can do that with any Any module? It's specific modules are gonna have different capabilities based on what they're doing based on what the developer of the module Has implemented but with items as a construct of the playbook that we offer for anything you're doing so the next one is Name install you whiskey So we're gonna have pip. Oh did it not? Oh, I didn't highlight pip for you. Okay, so down here Pip we're gonna use the pip module to go and install you whiskey again state equals present And not I mean not all of the modules are just to install and define states some of them can get very very sophisticated, but Just for for case of example, it's you know keeping it easy. So includes the imports Let's say that we wanted to define a set of tasks and we wanted to reuse it over and over again and We didn't want to rewrite it or copy and paste it around to all of our playbooks We can do you can use includes an import so you can import a file containing a list of tasks They're kind of commonly known as just a task list or a task file You can pass it parameters. You can do it can you can include conditionally And the idea is to encourage code reuse So includes and imports that just a quick note is with includes I'm sorry with imports It's what we could consider static. So they are parsed They're preprocessed whereas include statements are dynamically evaluated when they're run into And that has two implications one for certain things like loops where you need to actually reevaluate it every time That can be very powerful, but two it does actually cause have a memory Implication on your control host so the the place where you run Ansible from is considered your control host So when you execute an Ansible command or an Ansible playbook command on a host We consider that the control host and all the machines that you're you're controlling from there to be your nodes And the control host is where you're gonna, you know, do most of your processing. It's where the templating happens it's where play plug-ins fire off those kind of things and So when you do includes there's a lot of memory being copied around constantly because everything's being reevaluated a lot So just note that your performance profile or your your memory profile is gonna be a little bit different Performance wise if you're using a whole bunch of includes versus imports and that's why generally if you don't need Anything dynamic import is is the way to go And then I mean that's not like a hard requirement It's just kind of like a best practice for huge air quotes on best practice. We hate that term Okay, so includes and imports so Let's say I had a task list called ad host name and then I Would then include all the tasks defined in ad host name And then here I would include tasks from ad host name with a parameter With the item so I would loop through and I would re-include that each time with a new parameter So let's say for some reason there was Maybe maybe the with items should have been like a list of host names or something so that way each time It gets loaded the param variable within the context of the ad host name could be variable substituted for whatever item in the list And then so The import tasks again, so if we're not doing any substitution import tasks is kind of the better way to go But here we can actually conditionalize what we're Importing because we can template the file so this can be very useful because you can name your conditional imports Things that are ansible facts. So for example, you know distro family. So if you've got Red Hat based family or fedora specific as opposed to centos Or Debian or Suza those kinds of things like you can actually Import specific tasks that are catered to those specific distributions conditionally doing this and there's also a We have conditionals for for specific tasks themselves Okay, so a role So we can kind of take everything that we've just done for you know tasks plays playbooks And we can bundle it up together into a role and then the role can actually be reused and distributed and shipped around and those kind of Things shared amongst teams Oh That's how to that's out of order Okay, we'll just go with it. So the plug-in so plug-ins augment ansible core functionality So action cache callback connection filter at a talk on Wednesday Tuesday, what's today? It's Friday Wednesday. I talk on Wednesday. It was actually about plug-ins I was hoping that schedule wise that those would be switch so I could say hey if you want to learn more about plug-ins go to this But here we are So what's interesting about these is you can enable different plug-ins to augment the functionality One of the most popular ones are gonna be for your timing profile So you can actually see which tasks are taking the longest you can see how long your entire playbook runs Those kind of things so if you know you have a quote-unquote hotspot in your in your playbook You can kind of have a very Well-defined or a well-documented, you know index of that Another thing is callback plug-ins. Those are very popular for the sake of being able to do take action based on The beginning end of a certain tasks success failure those kind of things So in the event that something Fails you can set a message somewhere to your IRC channel your bot or something or if something fails You can have your bot like ping people and say hey this failed. Maybe somebody go look at it those kind of things So yeah, so examples. Oh the other thing is connection plug-ins. So when you run on the inherent local host Using the answer will command line you actually get the answer will local connection So actually run ansible local instead of trying to do a round-trip, you know You're not doing Diffie helman handshakes to your local machine because you don't need to Whereas we can also do SH Docker charude. There's there's a number of connection plug-ins Some of them are gonna be specific for network devices. So like don't try to use, you know, like the Rista or Junos or Cisco iOS Connection plug-in for your Linux box. You're gonna have a bad time But we have all these different connection plug-ins that can kind of be used for optimizing Talking to different Devices or different systems in ways that might not That might be needed or necessary or might be more Appropriate than just a straight-up SSH connection But the default when you're doing remote host is gonna be SSH unless you specify otherwise So an action plug-in action plug-ins take action on your control host before Going out and contacting the remote host to run the module. So some of that's going to be, you know copy fetch synchronize and so like for synchronize it needs to Literally synchronize something from local host to the remote host and it has to sometimes do some prep work I don't know tar ball up something synchronize it on tar at those kind of things There's a full list and we have extensive documentation on those if anybody's interested in those, okay So back to roles. What is a role? So we've briefly discussed this so a roles are made up of plays. Why is this? Oh, okay. This is yep. Sorry I somehow got my slides out of order. All right, so in contrast of what a role is being all all-encompassing and defined playbooks are made up of plays and playbooks are opinionated so the reason that this is important is because a Playbook is defined to a set of hosts it will define whether or not you need to you know become privileged or not You're gonna gather facts or not depending on what you need For for that specific set of things you can set your connection plug-ins You're gonna have specific variables those kind of things and generally those definitions are going to be specific to the set of Hosts that you want to run the tasks in that play against So they assume a specific inventory and they target a specific use case and they're generally not very reusable In but but I by design like there's not a fault of them Normally, you're trying to accomplish a specific task and that's what your playbook is for But in the sense of wanting to so again, so this is the our example playbook. You're doing installing engine X and then You install whiskey you're gonna copy your default comp We're gonna put a template over there to our template file so dot j2. That's ginger to we also use ginger to for templating our files You can have a ginger to template file do Anything your heart's content for the ginger to templating language which we have pretty extensive documentation on Ginger to is very pythonic so if anybody codes in Python you want to do for loops and logic and all that kind of stuff inside of your templates to You know define different sections of configuration files based on multiple entries and lists that kind of thing we have all that functionality So and then you know, we'll copy our index HTML with the swap down change of our default message Oh handlers so We also have this thing called handlers handlers are effectively specialized tasks that only get fired in the event that something notifies them in in that allows you to conditionally Like restart services or reload services only when something changes So if you have a template file that lays down a configuration and you notify your handler and That template file didn't change Then it won't fire the handler whereas if you just define a task to reload your configuration file It's gonna reload the config or restart your daemon every time you run the playbook The handler is meant to conditionally execute something on your behalf in the event only in the event of a change And that's kind of the idea is to handle an event as opposed to always execute a task Okay, so The roles roles are meant to be coupled from the inventory in the place But they're not just a set of tasks So you can do the set of tasks that you import or you include and you can reuse Content that way and that's very powerful however roles kind of take it to the next next level it's because they're self-contained they're reusable and they're a Complete unit of work complete unit of work being kind of an operative term there They should depend on nothing and They should perform everything that they claim they do in its entirety And what I mean by that is if you're if you're attempting to install engine X and configure it and The role is meant to do that it should not assume anything about system state It should ensure that all the packages it needs are installed It should have templated files embedded in it and simply take variables passed in from Your playbook to populate those things So we'll kind of go through So if we switch to a role Let's say we have role install engine X and we pass it variables packages engine X text message and engine X keep a lifetime out That should carry out All of the operations that we previously did previously defined They should verify that our packages are installed. It should set up our test message with our default configuration file those kinds of things But we need to actually convert That playbook into a role so it can be reused and what's powerful about this and in the goal here is Let's say that you have multiple data centers or if you have different systems or you have different systems that are attempting to do different things based on Whatever your specific use cases and they all need this they all need a web server to then serve some purpose Well, you could just copy that playbook around or you could import it a whole bunch of places But when you get into really When you get into kind of higher order sets of logic in your playbooks and you're doing things conditionally and And those kind of things and you have templates well, then you have to copy around these templates and that kind of stuff Whereas with roles It's all all in one and we have various ways to Install roles discover roles that kind of stuff and we'll talk about that in a few minutes so There's a so really quickly ansible galaxy is our index our public index for it's kind of our forge it's our public index of All contributed content and roles if you need to install something engine x postgres ql those kind of things Look there. There's probably a role to do what you're trying to do That you can just go out and use it face value or potentially contribute to they they should all be open source But we have an ansible galaxy command and the ansible galaxy command allows you to install roles from that from a personal hosted galaxy or any arbitrary Remote file Because you just tar up a roll file or from a git repository. I think we also support SVN or mercurial. I don't remember which one There's a couple of them. So this is what galaxy looks like It recently got a redesign if anybody's familiar with Pattern fly we redid the UI pattern fly. It's very nice. I'm a fan So you can go out to galaxy galaxy dot ansible comm and kind of check out what we have out there Those kind of things but the galaxy the ansible galaxy command has an Init sub command and the init sub command allows you to initialize a module on your home directory And that's going to set up the directory structure that you need It's going to have you know various metadata files pre-populated that you can just go in They're all commented and documented and you can go in and just fill in some fields those kinds of things so Yes, you can download from galaxy already covered all this so This is actually how you would install so if you found one on galaxy that you wanted to The author in galaxy the author is the namespace. So your github username Is going to be your namespace if you upload get roll content to galaxy or you can just install one from wherever you want You can actually have a requirements.yml if you want to define multiple roles that are required for your task at hand So if you're if you're setting up in in one Playbook you want to set up your database server you want to set up your web front end You want to set up your load balancer you want to you know rotate things in and out that kind of stuff You can define multiple roles that you need to have installed and required and then just do a single install before starting your playbook. Oh Okay, so roles are traditionally going to be the default role Path is is I'm pretty sure Etsy Ansible I should know this I was running on my local directory because I run everything off of source I'll get check out. I should know this, but I don't You can in your ansible config you can set default role path You can set the environment variable at the command line ansible roles path to whatever you want You can use a colon to provide separate paths because of course you can And a roles directory next to the playbook So if you have a playbook in your current working directory and there is a roles directory in that same current working directory Any content any role content that is in that roles directory will be detected at runtime So what's in a role? Well, there's a lot of stuff. So previously, you know theoretically, let's just pretend that we ran that that ansible galaxy in it install engine X command. So this is what we would have been left with so we have Travis yaml because if you are running your Travis stuff You can we can report that through Galaxy a read me So it comes with a read me and kind of the idea there is to have you know Some sort of documentation for users who are potentially going to reuse your role whether that's locally on your team Or externally to the world for anyone who's going to upload something to Galaxy Default so these are your default variables Files so any kind of file that you're going to copy around and just lay down at face value That doesn't need to be templated should go in files Handlers again This is going to be a task list that defines your handlers that are conditionally executed based on something notifying them Your metadata metadata that the meta directories purely for Galaxy uses if you're not uploading the galaxy You probably don't need to bother filling that out, but please please contribute the galaxy Task so this is gonna be where all your task files are you can have one or many You can kind of the only requirement is that you have one called main and that's gonna be the entry point into your role Main meta so tasks main dot yaml Templates again, so files dot j2 for ginger to templating files that are put in there They get templated at runtime and you know copied around and those kind of things tests. So if you Have tests Probably gonna be related to your Travis yaml those who know travel Travis CI as a CI system hooked up to get hub You can put tests in a lot of people actually Interestingly enough your tests are written in ansible playbooks. There's a lot of assertion things that we can do with with playbooks All of the ansible integration tests are written in ansible It's very meta So and then vars so you can define your set of vars that can be passed in those kind of things Okay, so tasks that main this is gonna be your entry point It's gonna be what drives your role. So when somebody just in either includes or If anyone imports your role or includes your role or defines it in the role section of their playbook This is what what the entry point is this is kind of be your you know it main If you're a sea cutter So this is gonna tie together all your templates and handlers and tasks and and those kind of things and Hopefully be kind of the driving logic now And the main thing to know is you can actually have multiple other task files that can be conditionally Included or imported so you can actually combine some of this functionality together where it makes sense So your tasks so what we have before in our playbook the tasks section You can literally just drop that into the tasks file in main dot yaml and the idea there is Again, this is a very to this relatively simple example So it might seem a little like long-winded to kind of put this in a role But the idea is if you have something so let's say for example this playbook took into consideration various different distributions you have in your environment it also took into consideration different package names for those different distributions and you have You know various parameters and conditionals and it kind of just cascades and the next thing you know You have this relatively complicated or complex set of Tasks that are are you know ordered and and defined and then you need to use it a whole bunch different places well Instead of copying that around and you have this ability to to just reuse it through the role And that's kind of the the driving idea behind this so handlers handlers dot main The module that runs will indicate when a change has occurred when the change has occurred the handler handler will trigger You can also do topic handlers. This is a new answer will 2.2 I won't really go into that a whole lot, but the idea is that you have a Topic definition and you can you can notify or For the other vocabulary term was for that Basically the idea is just if something changes so for example, so our template. This is how we would do this Notify being kind of a top order instruction So name template being the module name and then notify and then we'll say start engine X that will Start or restart engine X if that file if the template Module reports changed so the idea there is the template module being item potent in nature Will only report changed if the templated file. It's putting out on the remote host actually changes Handlers by name. There we go. Listen So listen being the other vocabulary term and there are different implications on this Listen versus notify Remember to check the docs. I genuinely don't recall I Should sorry, okay files and templates files the base directory And templates is the base directory for template files the main thing to note there is when you're in a role and you have Templates and files in their respective directories that are namespaces are supposed to be you don't have to refer to their full path or Relative path you can just say the file name and the role knows where to go look for it because it's it's a standard directory layout those kind of things so That can be very useful just because you don't have to type as much Okay, so for example so our template file here You'll see these these file names are just source engine x.com. J2 index. HTML. J2 But we don't have a directory listing there and that's because they are in the template directory Therefore the role knows where to go find them And this is where we put them Okay, so this is our engine X config template file so We can in there define or a do variable substitution. You can also do other fancy things With the gen2 template language This is probably gonna be your most common thing to do is just in place of variable substitution for config files Those kind of things But if you have a lot of sections of a config file that you need to basically replicate So the virtual hosts if you're if you're doing virtual host entries and you want to put in a whole bunch of virtual hosts you could have a list of You know dictionary variable entries or something that defines all your virtual hosts And then you can loop through them and lay down those configuration files there. There are the configuration sections to the file So, you know, here's our index of HTML with a templated message and a paragraph Our variables so defining Variables the user can override in the defaults For for conditionals and configuration settings and then variables main which are gonna be used by the author So that's kind of you as the role author. Hopefully you as the role author Can can use to organize a role additional files And to dynamically kind of like change things up within the role So anything you want your your potential users that you are gonna consume your role to reuse them put those in defaults So defaults not main. So we have our packages. We have our engine X test message engine X keep a live time out and then those are kind of you know Used for the variable Substitution in the templates as well as in the playbook Meta main. So this is gonna be Specifically for galaxy or for if you're if you're pulling content from galaxy as a dependency for yours That's the other thing too is you can actually do recursive dependencies for roles. So if for some reason Your engine X role needs Probably a bad example, let's go the other way Let's say you're trying to install some web app and You have a role for that web app. You can say that my web app role Requires this engine X role so that way it will set things up And I know that this is a mild contradiction because I said before it should be a complete unit of work And that's true It should be a complete unit of work for the tasks that it sets out to accomplish However, if there's a different unit of work that you need to rely on that needs to be in place before your unit of work occurs You can set dependencies so that way at runtime It will install the role that you need and then it'll actually execute that role first So so those those are ways that we allow to kind of cascade Daisy chain those together Dependencies you can define dependencies role some parameter You can define them source if if they're not going to be from Galaxy if they are gonna be from Galaxy you can define them as name being namespace gearling guy is is a very Well-known contributor in Ansible land he has a lot of amazing content on galaxy. He wrote a book pretty sure His is Ansible for DevOps. I think that one says Yeah Anyways, great. I mean great community member. He's done amazing work. His book is fantastic. Check it out But anyways, so gillenguy.php FPM so we would then pull his role from galaxy Documentation we can talk about before metamane is gonna be for Galaxy specific stuff read me and you can also embed an example playbook tests again Ansible playbook tests and your Travis dot emil configuration Modules and plugins so you can actually add a library Directory with your custom modules if your role needs custom modules that we don't have and you want to distribute them on a separate Life cycle than Ansible core you can do that or you can have a type underscore plugin for custom plugins one thing to note if your users of Your role have a bug in your module and they come to us and they're like hey This thing broke. It's a module. Please fix it. It's what core will not fix your module I mean somebody might somebody might just be like, oh, that's really cool. I'll check it out. But no, that's that's kind of like you get your You get to play with your broken Legos if you if you break them so in a play to use a role You have a role section. You can do it that way You can also include roles as to make them seem a little bit more like tasks and this is very powerful for Nanana Passing different variables to different things at different places, but also Yeah, so we can say include role and we say tasks from so If for some reason you want to include a tasks file from a role but not execute the entire role you can grab just a One of the tasks file out of the tasks directory of that role by defining tasks from So for example, the name of this role will be my role and then in the tasks directory There's going to be other dot yaml and you would say I want the tasks from other Out of that role just that specific set of of tasks and and that can get you know That can allow us a little bit more flexibility and some of the things that we're gonna do Okay, do I not have Yeah, okay, perfect. This is what I was hoping I was really worried and have this example Okay, so you can do an include role with items you can include the role multiple times by passing different sets of variables Which is very powerful for hopefully obvious reasons and then the next one that I really like and this is what I think has a lot of I Think this has a lot of Applicability for various different workflows because the role section of a playbook or a play a role section of a play Always gets included and always gets executed so you can set some Variables you can set some you know when conditions in there But to be honest the syntax is just kind of weird and that's why I'm a big fan of include role or a or import role with a when condition Just as far as cleanliness of playbook the ability to you know Adhere to the simplicity of a playbook being something that somebody can understand who isn't well versed in ansible You can include a role by name only when a condition happens so Check out ansible galaxy. There's a lot of role content up there for anything that you need to do. Please Hopefully use Oh something to note just from a fedora infrastructure standpoint If you do find something from ansible galaxy that you want to use it needs to be imported into the ansible to the fedora infrastructures Get repository Fedora infrastructure does not actually pull roles at runtime on the fly. It has to be kind of like Sneaker netted over into the get repo just as a point of Note for for anyone wanting to contribute so hopefully this was useful Please automate the world and and please you know bring some of that magic back into from structure. Yes Dennis So the question the question is how do you handle package installs because there's DNF and there's yum How do you handle package installs for for different distros? So there there is a package module It has limited functionality because like the DNF and the young modules can can do all sorts of things like it You know do exclude repos enable repos that kind of stuff But if you just need to raw install or remove that kind of stuff the package module will automatically detect which Package managers and use on the back end and and pass that off Something to note in ansible 2.7. I Actually, it's like on me It's on the roadmap to have the yum and DNF modules have beef at feature parody and for them to be interchangeable So you will be able to actually run the young module against the fedora machine and get DNF on the back end Because I mean technically the young command is still around even though it's kind of a lie, but it's there Yeah, so we do have a package module absolutely the big kicker That we always tell people watch out for is your package names are going to change But you know probably from sent us to fedora or you know fedora to rel. It's pretty much the same right Right exactly. So the comment was Apache and debbing is patchy to whereas it's HTTP D in fedora And yeah, so that's where that's generally where like in the the variable substitution will come in People will have variables to define the sets of packages They need based on which distra they're working with and then there's pass the appropriate variable at runtime once we've detected the platform Based on the answerable facts question I'm not sure I understand the question. So you're trying to just grab a single file from a get repo So are you are you attempting to get clone or specifically like web URI? Request. Yeah. Yeah, you can get clone with the git module. Absolutely. Yeah Question so the question was in the past you had to install Python DNF because it didn't work out of the box So that is true if you use the default Python 2 interpreter Which is assumed if you actually pass in your inventory hosts file That a host should use the ansible Python interpreter for Python 3 it will work out of the box because it will then use the Python 3 libraries Do note that Again, because we're just gonna be talking about all the Python 2 features today or I'm sorry ansible Python 2.7 Can't talk the ansible 2.7 2.7 is gonna be a weird one for us the ansible version 2.7 feature We're actually the auto-detect the interpreter on the remote end and Python 3 will take precedent So you shouldn't have that problem in the future But right now for for ansible to support Python 3 you have to define a host variable That tells it to use Python 3 as opposed to Python 2 and then it'll find yeah, it'll find it that way There are a handful of other Things that we kind of in in fedora. I think since fedora 25 have to bootstrap. So you have to tell it to install the like the SC Linux Python stuff and various different things just because The things that the module use aren't default in the disher anymore But yeah, so there's there's documentation to handle different scenarios, but specifically for DNF Yeah, we just need to tell it to use Python 3 and it'll pick it up another question Shoot oh Okay, so the question is can you run like the ansible command for an ad hoc task but perform a roll No Now that needs to be a playbook Could be interesting. Shoot. Let's keep it going. Yes So The question is in Travis CI often times people will claim in Galaxy that they support multiple distros But don't actually support multiple distros because they're not testing on multiple distros There is I believe it's called kitchen kitchen CI kitchen CI does multiple distro and Things with Jeff and ansible and those kind of things. So from our perspective as far as Like I don't think it's an official Project recommendation, but me personally if you're gonna do that kind of testing things locally. There's a project called molecule That does it's has various providers in the back end vagrant AWS GCE those kind of things And it'll do multi distro and it'll do you know Effective verification of your playbook. So let's see. Yeah, so if you just go to molecule dot read the docs That'll take you there I can't remember who created this initially There was a startup that got bought. I think they got bought by Cisco But they originally made this and it's been amazing and we're we've been talking with them a little bit to do some Project integration that kind of stuff. But yeah, that's what I would recommend. I don't you know I won't claim that's a an ansible official recommendation, but me personally. I think that's what I would you know That's what I've done in the past. That's what I do Do you have another one? Okay, well, it's real quick. Well, let's go to Dave and then actually it's lunch time So if you just if you just want to come up we can chat. I'm happy to chat Latest yeah, so Kevin Fensi nirik fedora infrastructure lead He maintains ansible in fedora, and I think he probably lags behind upstream by maybe a week He generally has it packaged the same day in Koji. It's just takes a little bit to get through Bodhi Yeah, so latest we're always pushing latest stable in in fedora infra Alright, yeah, we'll chat. All right. Thank y'all