Ansible best practices for startups to enterprises

all right I'm good sorry I'm in doubt they're great good afternoon everyone thanks for coming out we're going to get started here in a moment my name is Tim Apple I'm a principal product manager until recently I was actually with our professional services group here working for James prior to joining ansible I've been with danceable about a year but before that I actually acted I was a user of ansible since version 0.5 which means I've actually been using ansible longer than ansible has been a company so I kind of know this product pretty well and this is hey guys I'm James Martin I am the automation practice lead for ansible so we deal with all things services related for ansible professional services related like Tim I was working for ansible prior to the acquisition by Red Hat and also was ansible user although maybe ansible 1.0 not point zero five so so you're newbie yeah I'm a newbie no in all actuality James and I have seen a lot a lot of different ansible installs a lot of different ansible usage so we thought we'd do a presentation on you know the things to do right and not - right before I get started though I just want to get a sense of who's out there how many people are using ansible ok was about half the room 2/3 how many would consider themselves expert all right all right we want to hire you to come talk to me yeah you don't work for redhead already yeah so okay good that's just giving an idea so what we're going to be covering here is mostly related what we call our core product the open source tool the command-line tool that everyone knows and loves this was a topic that as as James are working through it we realized how big best practices really is if we went into the development and tower and all these other things it would become so this is going to focus on the essentials the core part of ansible usage so I'm going to start off with what we call the ansible way ansible is a Swiss Army knife of DevOps out there it is incredibly flexible and can adapt to a lot of different automation tasks a lot of different environments a lot of different workflows we try not to force one on you that being said not all approaches are created equally so what we're here to present is a way to not undermine the simplicity and power of ansible and to get the most out of the tool so with that said we're going to start off with these core principles of ours that everything that we're going to talk about falls under one of these themes or maybe multiple versions of this theme and so the first is that when you're building your ansible content when you are creating your place really strive for simplicity that is a core principle of everything we do at ansible like our core engineers all of us always are talking about this as simple as we can make it is this going to keep things simple for the end user to get their work done so we suggest you try to do the same another thing is to optimize the ansible content and what you're creating to be readable one of the things to keep in mind is that your playbooks as being llamó based and very English base and not being programming code is that it can become living documentation for your system and how your system works one of the advantages and one of the reasons that ansible has had such upkeep is that you can pull out a playbook and show it to someone who's not an ansible user a little bit technical but not an Ansel user and they can read that along and see what is happening what is going to happen when I run this playbook what is the state the machines going to be left in I've had sales people look at ansible play books and understand what they do exactly I Bank auditors they're even less intelligent but anyway I work for a large bank in America I'll just say before coming to ansible so the other third concept is that to think declaratively our play books the is not they are not for programming they are not the the yamo based syntax that we use is not a programming language we occasionally get ugly tweets that people think it is but it's not so really think about how what is the state I want to achieve here and declaring what that is and then letting ansible do its thing to get you to that point so as I said a lot of these are the most theoretical points that we're going to talk about in the least concrete but hopefully you see as we go through this that these points well these themes are a lot of the other best practices fall under these and we'll keep referring back to these type of things okay so now we're going to talk a little bit about workflow so one of our first recommendations and best practice as you're working with ansible content is to create a style guide for you and your developers to work from ya Mille works really great with having a certain white space but it also helps to have things like tagging how are you going to name your tasks name your place name your files how are you going to layout the project directories and your repos that your ansible content is going to live in and then to have a way to enforce that style use things like post commit hooks that check that hey you did the right thing here that this is meeting the style that we've laid out I was just going to say some of the customers we've had they've been working a lot of independent siloed teams and they're all doing something a little bit different yeah and it's makes it difficult for you to share your content if people aren't using and constructing their their ansible content in a similar way right another thing and this this almost comes without the same but we still run into people that don't do this is to version control your ansible content version control your plays your roles you know treat your ansible content like it's code it's not code but treat it like code and version it is such version it put it in your version control system whatever that is whether it's get subversion or I know what other tools of I guess we don't yeah oh yes oh yes CVS I don't know that we even support that but if you want to you can use CVS go ahead the other thing is to iterate your work one common mistake that I see when I talk to a lot of enterprise customers who first pick up ansible for some reason there always seemed to be Java programmers they immediately go to like modularizing the everything that they're doing and dependencies on top of dependencies with it's it's sort of madness what I really recommend you do start off with a simple playbook something that that works enough and then refactor a module arise once you have that playbook working because it's a lot more difficult to debug a lot more difficult to work with when you're dealing with six eight different files all over a file system it just goes a lot faster when you can do it that way so we're going to talk a little bit here now about some project layouts in the way that we recommend or at least guidelines for how these things work in this case here this is just a basic project layout so we have a project name basic project we have our dot llamo files which are a few different play books that we have in this project and in this case we're using static inventory so we have a subdirectory called inventory that has our host file and it sub-directories for the different variables that are associated to our hosts and our groups in there so pretty basic starting point for just getting something quick done as time progresses you may find in as you iterate and expand you might want to start to organize your playbooks and break them up and modularize them into roles in this case here we're embedding the roles in the same project repository the reason is that the roles were assuming here are only relevant to your current play books you're doing this for organizational reasons you wanted to package it up modularize it kind of you know tuck that off to the side while you work on some other things so here we have what's different in this one is we have a role subdirectory and under that you have a subdirectory for each of your roles and they have all the files that go as part of an ansible role under their overtime and if you're in a large enough organization you will want to start sharing your roles so that is hey I have a you know I'm a DevOps team and I've created a my sequel role an Apache role maybe it's a in-house made proprietary application that you've created a role for and you now want to share it because other teams in your organization in other regions or other business units want to make use of your role so in this case here you can use or this requirements that llamo file and the ansible galaxy tool and then that allows you to very easily pull from a shared repository different roles whether those are the ansible galaxy public roles or if they're your own internal ones that are held in some type of version control system behind your firewall will be going over roles more and we'll come back to this in a bit last thing is under workflow here not the last best practice but is to use an editor with syntax hi lighting there's a number of different you know the most popular editor supported there's been plugins for it that they really help out you identify maybe a syntax error or something maybe you got a little bit off or wrong I also thinks it makes it a lot easier to read when I open it up like ok there there are my tasks here here are my parameters things like that so it just makes things a lot easier to use an editor that has that type of syntax highlighting available content I think what we have pictured here on the right is Adam yes that's Adam yeah right ok alright so we're going to talk a little bit about some best practices around using inventories with ansible firstly one of the key components especially when using static inventory is to give your inventory some meaningful names we're going to talk about each of these bullet points in the following slides using inventory groups as much as possible on in using a single source of truth when you can and anybody here using dynamic inventory by any chance and ansible okay just one two three four five okay just a few people okay good so what do we mean by meaningful names well on the right hand side you see a collection of IP addresses and host names and these would live in your inventory but they don't make a lot of sense they don't really describe what those machines in the inventory are doing on the right hand side what we've done is taking those same IP addresses and hosting it but giving some logical descriptors if you will of those devices so the very first string you see like DB one or web one is what we would call an inventory host statement that's a logical name it doesn't have to be resolvable followed by ansible underscore host and then an IP address or a host name of resolvable hosting that actually points to the device that you're managing with ansible so that makes it a lot easier when you're executing a playbook you can see the results as you know web 1 web to web 3 and makes it also easier to describe the functions of those machines in your inventory as well inventory groups so taking what we did on the previous slide and we had those logical names DB 1 through 4 and web 1 through 4 we can now assign these two groups so here I have a DB group and I'm using a shorthand mechanism here to say that the DB server is 1 through 4 belong to the DB group and I'm saying the web server is 1 through 4 belong to the web group then I've also have additional groups based on the region where they live their geographic location there is a group based on their environment production testing staging etc and and you can do nice you can do really neat things and inventory groups such as intersections so when you're running a playbook you could say I once all I want to execute this playbook against all my DB servers in the dev environment right and you can specify to do an intersection with that so the more groups you've subdivided your hosts into the more targeted ansible plague rooks the PlayBook runs you can make okay that sorry if you just one say that's a very common pattern that we see that in large organizations is they will break they will have groups for application type or stack region and then stage and then a one host will belong to a group in one of those major categories like that so that they can target like James said DB servers in the east that are in testing so good dynamic inventory so there's only a handful of folks that are using dynamic inventory so how many people have custom cmdbs in-house so not okay so what what a dynamic inventory can do for you with if you have a custom CMDB dynamic inventory would allow ansible to talk to your CMDB and use that as its system of authority for the machines that live in in your inventory owner to be managed by ansible so rather than having to go into your CMDB and copy and paste IP addresses and hostname service EMV be to the ansible inventory file you would write a dynamic inventory script that would fetch that data displayed in a particular JSON data structure the ansible can interpret and and then you don't ever have to do that transcription anymore right so that's going to reduce your human error because you're not going to have to manage those IP addresses by hand inside of ansible in addition to doing working with custom C and D B's there's a ton of dynamic inventory scripts that are included with ansible core already I think there's 41 of them the most popular ones probably are like the the open stack in the ec2 in the cloud related dynamic inventory scripts yeah back to me all right so we're going to talk some about variables which are in a lot of ways the lifeblood of what's happening in your playbook so another very good practice is to use descriptive unique human meaningful variable names this is very much you just heard the same theme in the inventory section ahead another and it's related to that is to prefix roll variables if they're going to be in a roll name or if they're to a specific application so we have down here an example of kind of both of those things at play where you have a patchy max keepalive and also an Apache port and a tomcat port now the bottom to eye point your attention to because if you're creating roles and you have a tomcat role in an Apache role and you put the variable port they're going to start beating each other up and overriding each other depending on which one loads first and you want to avoid that so a good way to do that type of thing is to prefix it with the name of the role that you're putting this in and it dramatically increases your chance of or decreases your chance of avoiding that type of naming conflict happening between roles as you bring them into another thing is also did not use we call Baer variables this is I have to admit a practice I sometimes mess up myself when I'm banging out play books it is now deprecated in version 2 oh so if you written a play book and done this you'll see now you get a warning that this has been deprecated there's technical reasons for why we need to enforce this a little bit more so at the top here I have an example of what you don't want to do and then below you want to wrap it in the mustaches and the quotes the main reason for this is that they had to guess in the top example the core developers had to guess that you mean that that is a variable not a string whereby the bottom one they know you mean a variable and they don't think guesswork is a good idea in software though they want to discontinue that practice another and this is a good use of variables is to you use them to separate your logic your tasks from the variables and also reduce repetitive construction of strings and let me let me put up an example that might explains a little better here on the Left we have example a where as if you look down like you have the file path it's going to the users home directory then you're doing the deployment key which is the users SSH subdirectory in their home directory again you see the home directory being used in the destination the key file you keep repeating that same pattern through on the side of B we've broken it out it's a little bit more verbose but we've set that at the top once and we don't need to now worry about that that down below I can use a much more descriptive variable and only use it once Oh actually I should point okay so we use user home in the variables that follow it and then we're able to create variables that below tell us where that goes and what that is so we have user SSH not that home user name dot SSH the other thing that this also opens you up to the possibility to an exhibit B is that you can now override through fax or through inventory variables you can override these variables up top where if they're embedded over here you have no chance of being able to do that sort of thing so you've reduced your flexibility on the left side where on the right side for a little bit of extra organization you now have that new type of flexibility or the possibility of that flexibility please and text this is long one yeah all right placing tasks so pretty much all the work you'll be doing in ansible revolves around writing plays and tasks one of the one of the things we've we've mentioned recently is try to stick to native yam bowls and tax for your syntax for your plays and I'll show what that means but essentially it's going to make it's going to make reading your playbooks easier and another key component of using native EML syntax is it supports complex parameter values for your tasks so when you have things like dictionaries or arrays you can very easily pass them as parameters to your tasks so this is an example of what not to do and this is how we all started writing ansible playbooks how I started writing ansible playbooks where you have your your module names such as yum and they start giving these key equals value parameters the problem is some of these modules take a lot of parameters at some point they're going to stretch really long far past maybe the the length of your screen you have to scroll to read these and you're going to be scrolling back and forth and it's going to be difficult to read so a minor improvement you might have seen some people do is using this greater than character and that allows you to specify these keys on a multi line instead of going across horizontally but as you can see it doesn't it's not giving you any syntax highlighting right that's to to the syntax highlighter that just looks like one big block of text and you still aren't able to pass a complex parameter values in a very clean way so what we recommend is is using this native yellow format so every this is a gamma list and you'll have the module name and then beneath the module name are the parameters to the module and the values to the module so you know no longer using key equal value to describe the parameters to your tasks you are using District native EML format human meaningful names again the same thing we've been talking about four variables and talking about for inventory do the same thing with with your tasks here in a hosts exhibit a rather we have a playbook that's starting installing and starting Apache and we don't we're not giving those tasks any name Exhibit B I've given so we're not giving the play any name nor are we giving the tasks a name Exhibit B I'm giving the play a name which is installs it starts Apache so that's the name of the play and then the name of the tasks are install Apache packages and starts a patching packages but what does this get you what what's that what difference does this make well this is the difference exhibit a with doesn't have any names doesn't really it's not really descriptive when you run the ansible playbook what what is doing this is the output of ansible playbook for those two plays all I see is it's running a play against the web host and it's it's running yum and it's and it's running service not very helpful Exhibit B which have the descriptive names tells me what the play is doing and then tells me what each individual tasks task is do it so make it a point to name all of your plays don't be verbose but name them succinctly enough to for someone to who's reading to understand what they're doing when you're when you're working with play books try to stay away from having large monolithic play books play books that are trying to do everything across your inventory and are very very conditional focus I don't really have an example of this because it's it would be a massively long play book and probably take the rest of our time to describe to show you what it looks like but we've come across customers we'll have like a site yeah Milland in that site DML there are referencing you know a hundred different inventory groups and after every play it's like when this host is belong in this group and when this host is belonging this group and so they run this play book anytime they want to do any work on on their site and just end up with an unnecessary amount of tasks that are being skipped and it's just not a well organized a well way to run your ansible folks we instead recommend you split up your playbooks into more focused and purpose-built play books and rather than monolithic play books and good luck debugging that monolithic playbook ryan yeah if you have them breaks in your you're trying to figure out why and you have to wait five minutes for it to finish yeah yeah this the smaller you units of your PlayBook are the better of course there's always considerations there but try to keep it simple separate your configuration and provisioning tasks so for folks anybody using ansible on the cloud here eight OpenStack AWS okay so think about splitting up your provisioning phase spring your configuration phase so when I say provisioning phase I am talking about the steps that are needed to provision your cloud infrastructure so I might be you know setting up a elastic load balancer and sending up some ec2 instances and the second phase would be configuring those machines so that might be you know installing Apache on those machines you configured the benefit to doing that is if you ever decide to change cloud providers or VM providers you can still reuse the same configure playbook because it doesn't care where you actually did the provisioning so you would just change the provision or you add a different provision you get a provision you see to provision OpenStack etc right and the other thing you can do is with a site gamal you can include playbooks inside of an inside of a playbook so I could say let's if I ran the site UML playbook go ahead and include the provision apply playbook and after that's run it's going to run the configure plate configure playbook so it gives you the ability to run it as a monolithic playbook but also run it as individual play books as well when you are using ansible and you're writing ansible tasks let's try to stay away from using the command module and only use it as a last resort and I'm going to show you show you why that in a second the second the second point is the command module if you have to use it is safer than using the shell module so sometimes when there aren't ansible modules you have to you have to run a shell command on that system if you were to use the shell command the the shell module it can evaluates shell characters like piping and redirect and that sort of thing the command module cannot so it's a little bit safer in the sense that if you passed as a variable to the command module some redirects it will escape those so you don't get any people doing the various things with variables and trying to do some variable injection of shell read erectors inside of your ear plays the one other thing about run commands I always point out to customers who are just like I didn't want to read the manual and I know how to do this in shell so I'm just going to use this is that said that the ansible in general is a desired state engine so when you tell it install something with yum it checks is that already installed oh it is alright I don't need to do anything I'm going to move on right oh I'm sorry darn always seek out a module is gonna be quiet now I was also going to say cuz it the shells don't always come back as a change sure it doesn't have the logic to say oh yeah that that directories already been removed right it'll try to remove it an error out right for example so like Tim was saying Exhibit A versus Exhibit B here I Exhibit A have done pure all commands because say I'm new to ansible and I didn't I'd never read the documentation which please read documentation so I decided I'm just going to run shell commands well this is this is dumb for a couple of reasons mainly because if you're doing this you're essentially just writing a shell script and yeah mol and that doesn't make any sense so don't do that secondly like Tim was saying these commands are typically aren't smart enough to know what the state of the machine already is so if you were to run the user ad app user the first time you you ran it and nobody was the app user wasn't created it would create it and not giving it problems if you were to run it again it would most likely give you an error some of these commands are smarter the young command obviously knows if the packages is already installed and service already knows that it's installed that a service is started or stopped but you can see here I've done things with using the command module then I'm using the shell module here which is a bad thing which was showing in the last slide and using ampersand to spin off another command on this successful run of the httpd start well instead of doing that if you used all native modules you get not only a much cleaner looking playbook you you get the benefit that ansible is going to do the state checking for you and you won't have to you don't you don't have to worry about the commands failing because they're not smart enough detecting to detect this the the state change that needs to happen there's two ways to look for that our ansible modules you can run ansible dock on the command line and give it a module name so there's I think around 500 - 500 different modules now you can also go to the ansible documentation website we have a module split out by category and index of all the modules as well so a feature that was added in ansible 2.1 helps a lot with debugging you can specify a deep ugh tasks that always displays so maybe you just want to dump some value out in your PlayBook output all the time but then you also have the ability to dump a debug message only when a specific verbosity level is defined on the command line so that's the second example here so this this that message or only just be displayed when you give a double V to ansible playbook and you can define that level of verbosity in the ansible dot config file this is just kind of a hygiene thing it's I've seen production code where the developer of the PlayBook left in all these debug messages so an Ops guys running it and they're seeing all these like JSON dumps a lot of noise a lot of noise flying through and they don't know is that bad that doesn't look good here you know one one point I wanted to make here a lot of people when they're using ansible will just start a service and then walk away a service started we're done it doesn't really work that way as most of you have probably experienced dealing with systems you either have an some enterprise java application that you ran the NIT script you ran the startup script and it said it started but in reality you know that it takes you know 198 seconds to do it and you actually have to wait for that thing to be running before you can continue so you should instead of just starting the service you should actually check and pull it to make it make sure it's actually up one of the ways you can do that here using the URI module checking a URL that's local to the machine where ansible is executing scripts and I'm waiting for hello world to return in this response once hello world has been returned I consider it up and running and I'm doing this with a essentially an until loop where I am trying to do this 10 times the delay of one second between each try and if that fails if it goes through 10 times it never finds it then the task fails you can also use what the wait for module that can look for ports to become alive it can also do a really neat thing and look inside of a log file and wait for regular expression to appear in a log file before you move on to the next task for folks who are using the command module a lot again I've seen this happen where people are using I've made up this command called certify just going to pretend it's creating certificates so somebody needs to create a certain sign assert if you had to do this without a module becomes very painful right the first thing you would have to do is write a shell task that is going to list out the certificate that you currently had to see if you needed to create one and you had to register an output and then you needed to create a cert when the output of when the output of the previous tasks did not find the certificate name that you've defined as a variable and the third task then you got to sign the cert but only when what only when the Create cert task was created this is a pain and it's hard to read it's hard to understand and if you start seeing patterns like this where you're running some command in your environment over and over and over again it's making your playbooks again start to look like shell scripts consider making your own custom module for it now we're not going to get into writing custom modules in detail here because that's a whole nother hour-long session but here I've combined all of that logic into a fake module I've called certify where I'm just saying certify module state present sign yes user Chris name cert name and sir soar now the modules behind-the-scenes is doing all that similar logic but it's abstract in a way from your user and keeping it clean simple easy to read human readable etc there's a link at the bottom there on developing modules you can just search for developing modules with ansible and there's a whole lot of guidelines there about how to develop modules with ansible the great part about the modules is now you have the full power of Python at your disposal and like I said play books are not a very good programming language because they're not it's not a programming language at all so by moving it into a module you now have all Python to work with and to do much more sophisticated things in logic and that's the whole point of modules modules are there do the heavy lifting and abstract users away as James just said from all that complexity so we're going to do a little bit on templates so ansible embeds the Jinja - template engine and that is very powerful if anyone's work with flask and there's a whole bunch of other ya Django more or less right even though we've put it there and we're both embedded and make it available to you you don't have to use all of it this is where you want to keep things simple want to keep things straight forward keep it readable so you know things like we shy away from most not doing all this variable substitution or excessive amounts of conditionals you know we saved it well actually yeah sorry the head towards more simple control structures you know design your templates for your use case not to handle every possibility in the world of a configuration file so conversely I just realized I was getting ahead of myself again was these are the type of things you actually want to avoid in your templates things like setting and managing variables inside of your template doing extensive and intricate conditionals conditional logics based on hostname I was one that James and I were taught about when we were putting this together as he was just in a client that they wrote template and then they hard-coded the name of certain hosts in there and had all this conditional logic if it's this used that if it's this group used that it was they've effectively recreated the functionality of inventory variables but did it inside of a template right right right and they put a ton of a ton of different logic in there they probably would have been better off having separate templates and then making a conditional call to the right template based on that host and one other thing you know it's any type of really complex iterations you might be misusing templates inside of like a five-level deep dictionary or something that's right yeah yeah things yeah yeah fun stuff like that yeah this is a little little helpful thing I found here is when you are creating a template to put a comment in there that labels that hey this was generated by temp by ansible it it helps someone understand if another ops person comes across that config file like hey where did this come from it also kind of puts out a warning to that person like don't manually change this file because it's going to get overwritten the next time a playbook runs so it's like I said it's I find it's a it's a good idea we do have something in there called ansible managed it's a variable that outputs the the file and the modification date and some other good stuff and if you mix it with the comment filter it'll automatically comment it for you so you don't have to worry about doing that escaping or any of those that yeah I know isn't that cool and yet you can even pick the commenting type it uses pound but you can do like C and yeah yes the one caveat and the reason that you see two asterisks is there is that ansible managed puts the date in there so the problem with that is every time the template generates it's going to be different than the one that was there previously even if nothing else inside it changed I'm not a fan of that but I'm not on the core engineering team and I'm not even actually specify what that manage tree is and override it but by default it outputs the date in there and then you run into this cycle of your template always you know your template always updates the file every time you run your playbook and you may not want that so a little caveat but I still recommend looking to use it alright so that was it for template we're going to talk a little bit about roles we've been dropping it there hopefully you knew what we were talking about we're gonna talk a little bit embarrassing that so first one like play books keep your roles purpose and function focused common mistake I see people do is they create one uber role role that does the provisioning does the installation does the configuration of sometimes multiple system component in one big role I recommend not doing that keep it keep it focused on what that role does it has a specific purpose leave it at that also put your roles in a subdirectory when it's for organizational clarity this is referring back to when I a slide earlier when I had talked about organizational roles and the type of layout when you want to use those when your playbooks are starting to become a bit big and unwieldy and you want to start to modularize it and break it up into concise packages that you can better maintain and manage the other thing is to follow the ansible galaxy pattern for roles especially if you're going beyond a you're heading towards having shared roles and that are going to live beyond a certain project the reason being that gives you the possibility of using the ansible galaxy command line tool and a good way to enforce that roles layout is to use the init sub command so start your roles off with the in its sub command develop your stuff or cut and paste your basic playbook material into the different spots within a role the one other thing this is my one little pet peeve I see is people run ansible galaxies and they get all these stubs and they get all the different sub directories you might need and then they use maybe three of them and then they leave eight of them and I'm going through to understand what that role does and I'm opening up empty files and then they never change the thing that information they never change it I met information so they have all this like all the possible choices and if you're going to submit it to galaxy my email address is me at example.com and yeah so another best practices to them once you use the initial role developed is to clean out all those stubs that the an it built for you and the other is to use ansible galaxy to install your roles ansible galaxy is is is a public repository for roles but it is also this command line tool that lets you work with your own internal private repos so if you're following the the ansible galaxy outs and you're putting a roll each roll has its own repo you can use ansible galaxy to install your rolls using that requirements that llamo file I had in my was that the shared project layout so it makes things a lot easier that you can just put that manifest file in there run this boom you get you pulls the rolls from all the different parts of your repository or some from galaxy and some from your internal and brings them all down for your project your playbooks to use rolls can live with your app code so manage your rolls in an applications repo if it's makes sense you can also make it something separate that can be shared so the way to do that is that it can be it can be part of your build process so you can build these and push the roll to an artifact repository and then use ansible galaxy to pull it down so one use case we've seen is what some application developers are writing their their ansible roles to do the deployment of their product and they might have like 50 different template files and it becomes a pane then if you had you know your project sort your application source code and then you had your ansible role and that was in a different repo then you have to copy the the files back over every single time that your application changed so to make sure your ansible role is in sync with your application source code right so in the turn in the sense of the of the template file so the idea here is just put a ansible directory and you're in your den your applications source code and develop your role your deployment role for that application right there that way the ansible to the playbooks the logic for the deployment is all sitting along with the particular version of the application that as it existed in get and then you know as part of your build process essentially that ansible rules directory is getting chunked away zipped up and sent to some artifact repository artifactory nexus whatever and then use using ansible galaxy like tim was talking about before to pull that that role from that artifact repository so then and then your role is always in sync with exactly what your what's your application what version of your application trying to deploy okay alright and so starting to wrap up here scaling your ansible workflow so if you're using the ansible command-line tool and you are finding yourself in position you've now created ansible automation you know you have different people and your team's using it you start to run into these situations you need to coordinate the ansible usage across distributed organizations different locations different continents different business units you need to control the access to the credentials the private keys the passwords to databases and things you need to track and audit who ran what when what were the results of that or you want to tell and then you are you you want to offload responsibilities this mundane stuff from your ops team because they don't have an intern to do it for them you can give them some type of self service or a delegation or the others that you need to integrate ansible with an enterprise system these are the reasons that you need to start looking into or deploy ansible power i'm not going to give a sales pitch more than that if you want to just come to our booth yeah if you want a pitch come to our booth there you go thank you I love how Google slides does this by the way this looked beautiful last night and that was before I started drinking so anyway so a couple things though before we take some questions I just want to point that in a month we're having our user festival we have three of these a year just so happens in a month our next one is going to be here in San Francisco so if you're local the Bay Area or you can travel back here please come join us yes July 28th there it is it'll be I believe the st. Francis up here by Union Square so not very far from where we're at now please come and join we talk about a lot of different topics business technical meet end-users things like that and then tomorrow a team member from my team John Davila will be doing an interactive discovery session so in the consulting side the discovery session is when we go to a client's office and we get all the stakeholders from a client in a room and under try to get understanding what their automation use cases are and how a consulting discovery sorry a consultant and ansible consulting solution could help them reach their automation goals so you come on you can come out to that tomorrow 3:30 to 4:30 p.m. and I believe they'll be serving free beer which is always a plus those are interested right all right and with that if we have any questions yes we'll be giving it to the the conference organizers and they'll be posting with all the other slides that we have yeah so yeah yes I would say you for every for every roll you would have its own repo yeah and then you manage which version of the roll you want to deploy using the requirements KML file and using ansible galaxy's ability to pull that tagged version droll from your version control system right so so the question was how do you version rolls what's about yeah and as James was just saying the answerable galaxy lets you pick a let's say a tag and get or even a specific commit by the head and we actually recommend that probably should have made it in the slides to peg it to a certain version so that you don't find yourself accidentally being upgraded and things suddenly breaking on you so you have any other yes oh I'm sorry yeah yeah so okay so take it and try to deconstruct what the end state is and work backwards from there so we've done a lot of ansible consolidated agents or people who are migrating off of different platforms to to ansible and you can't do a one-to-one migration it's more what is this what is this puppet recipe attempting or whatever they're called I forget chef's ever get the terminology confused what is it trying to do right and what's what's that end state and let me work back forwards from there because it's the the way the route you get there might not be the same with ansible so you have to understand what the end state is right right exactly yeah yeah you come talk to me more after the weekend yeah yeah after this come talk to me with some more yeah so for the camera the question was how to migrate from puppet to ansible and what strategies right though all right oh yeah I know which one you mean I don't think it's made it into our core yet because I was the one doing part of the pole request code review yeah that right and we do also have a puppet module in ansible itself there actually is a small sub community that managed puppet with ansible so and and someone in the community not us submitted that module to us so are we doing on time by the way I think we're pretty close at 5:45 38 so we still got seven minute able so yeah so we're here yes yeah tagging you now with that we have the block feature you can tag like a block of tasks so you don't have to keep saying the same tag over and over and over again so that might make tagging eat easier but yeah try to describe what you're doing so if you're if you're altering services like starting stopping services tag them with service for instance and maybe and then you can use roles and tagging when you're executing a role you can say apply this tag to this role so that means if if I had a patch ear OL I could say in my playbook assign the tag of Apache to every single task in that role it automatically fill it in you wouldn't have to do it manually so then you just sort of you could give tags based on what that what the action a particular task is doing but I always find tagging to have a bit to do with taste yeah like I'm I try not to put too many tags in I see some people that put like twelve tags on every task and yeah I see where they're coming from and it's one of those it's hard to say this is the hard and fast best practice rule on that so all the way in the back hmm so break it out can you break it out into its own playbook or so spit split those up into four discrete play books and then you cite that Yambol to include those other ones and you could just run the discrete playbook when you need to do and you can even you can even tag the inclusion of a playbook so that if you wanted to run two or three of them consecutively you could just at that point call the site dot Y amel and give it those three tags and it will run the three sub place sorry I lost you in that last part I think it's in the area of too many conditionals if it works for you yeah it starts though for me personally it starts again it may be too much conditional logic and then that's where we said you know break them out into separate ones and then use the ability to include play books and kind of create those like merged hybrid ones in your as a separate thing that you could do on the side so yeah any more question we got one there and then we'll go there so are people using pull model a lot with danceable not really not at all I mean there there are some but not many yeah it's not anything we recommend people using really I mean it's there and like James said a few people use it but for the most part it's not where our effort is it's not how we differentiate ourselves or the value we think that we bring is a lot of people come to us because they don't like the pull model of other tools and you lose the orchestration capability you don't obviously you don't get the push base which is a lot of people come to ansible you don't get the agent list because well it still is agent list but you have to install ansible on the machines that are using ansible pull so and set them up to run vertically and graph and make sure they keep running right in there yeah so there was one other question yes okay okay okay so how to use cloud forms and Tower together and I'm not sure are you asking from the Tao are you asking to the integration from tower to cloud forms of her cloud forms I'm not sure that information is available yet yeah you know we are gonna have to check back with us on that that's yeah not an area okay there we go yeah so one who might know a little better than we do right now so yes question there yes formally no I would say if you look at intervals are redheads history they've open sourced everything everybody they've ever yes yeah that's all I know above my paygrade yeah tomorrow yeah official answers Oh what James said is true is is is red hats track record is pretty consistent with what they've done when they've acquired a coming that has a proprietary licensed tool what's what happens eventually the question is what is eventually I guess is what you're asking more than anything and I think to add to that just because now I'm partially on the business side of the house is that there's a lot to do with licensing and business issues that need to get worked through more than technical ones to go from a proprietary to open-source some of them if you look at the history also some of the redheads acquisitions have taken a couple of years for the Alex McManus right here was two years yeah yes yeah and we're only into six six role I would say really six months yeah they converted all the systems over so true we're only six months into it at this point so it's pretty early to speculate I think yes a Publix all right could you speak up yeah for tower probably once they open source it if when if and when they decide to do that I would assume they would be it would be on github or some repository you can file issues right now it's all through our support team yeah any more questions right alright great well thank you for coming out there's a lot more ansible presentations that are going to be happening thank you please come see us at ansible fest if you don't get to see us some more of the sessions here

Channel: Red Hat Summit

Views: 59,384

Rating: 4.8759122 out of 5

Keywords: Red Hat, ansible, it, management, devops, automation

Id: 5BhAJ4mEfZ8

Length: 58min 44sec (3524 seconds)

Published: Thu Oct 20 2016