Learn you some Ansible for great good!

good afternoon everyone my name is David Lapsley I'm from Cisco OpenStack private cloud formerly meta cloud I'm an engineering manager there and this is Jurgen Brundle my co-presenter he's an OpenStack engineer also at Cisco today we're actually going to be talking to you about ansible and how you can use ansible or how ansible actually makes it easy to be able to unify your test development and deployment deployment workflow before we start can I just get a show of hands how many people here have used vagrant ok great how many people have used ansible all fantastic that's great ok so I've been using ansible for about a year and one of that's one of the reasons I'm here since I've been using it I've found it to be a huge boon to my productivity it's really changed the way I do my development and and that's the reason that I'm here talking to you about it when I first started I actually came across some work that Jurgen had done which is really cool we'll be talking about that towards the end and I'll also have that we'll also have some references there to the slides and then also to the source code all right so a number of you haven't used ansible yet so we're going to give a little bit of an overview of ansible first but this year the unified development test and deployment environments that's something that both David and I feel quite passionate about because if you don't have those unified you are ending up with all of these problems that you know from from in our industry for so many years already which is you don't catch the bug until it is in production or you can't reproduce issues in development environment you don't have access to certain test equipment new developers have a hard time even getting started because setting up a development environment might be difficult and so everyone ends up with a slightly different environment and in the end you just can't reproduce stuff right this is how often have we heard that we all have and it's the bane of our existence I don't know I don't control my volume have you have you heard anything of what I said almost okay good all right so yeah so this is not what we want there should be a better way right it would be it would be good if we could just with a single command set up a new development environment and your developer comes into your team and you just tell them run this and boom there they have the development environment just like every other developer and similarly with test environments and deployment environments and all of these should look exactly the same and that's that's what we're going to talk about today so to summarize we will give a bit of a background information for configuration management because that's what we'll use for this give an introduction to answer ball talk about how it can also manage infrastructure how we unify out our testing development environments and also have a demonstration all right so just to summarize a little bit the world of configuration management tools well first of all how do you how do you configure a server they have been we all have seen these these servers which are sitting around in an enterprise floor for a long time some system administrators knew how to set them up and they keep these are closely guarded secrets and you really hope nothing happens to that administrator because if they ever do you really don't want that server to fail you have no idea what went into the care and feeding of the server over the years that's not good so maybe it helps if you start writing down the instructions what does it take to set up the server that's a big improvement but still you know it's obviously manual and it's error-prone you can forget some steps as you write it down or as you try to go through them stuff might not be absolutely clear or ambiguous right so improvement but still not good this scripts is a big big step forward because now you can just run them and it's pretty unambiguous and automatically these scripts will set up a brand new server but if something has changed on the server do you just want to bring it back to the state that it should be in then if you want to script this you are writing all sorts of if conditions and error handling and exception handling and corner cases in your scripts and they get really convoluted really fast that is where these configuration management tools come in because they take care of all of this right and we'll see in a moment how that is done but at any rate those two areas they are the scripting and the cm2 will certainly are and we allow you to automate your setup you can bring up a hundred servers equally very quickly and reliably now cm tools you don't say you don't say install this you just say I would like to make sure that this is installed at this version so in a cm - you are describing the desired state of the server you say things like ensure that Apache is installed ensure that this user is it does exist the two sources are there or that you have a database of a particular version installed so a configuration management tool will see a description of the desired States that's all you have to provide and then goes through these desired States looks at the Machine and compares them to the desired state and said well okay Postgres isn't installed at all let me install version 9.1 let's say you accidentally did an upgrade and all the packages can upgrade on your machine if you run over this again with the CM - little say okay your version 9.3 installed but it says it should be version 1.1 it with an automatically downgraded for you back to the desired state right so you deliver a description of the of the state very succinctly don't have to write any if statements or whatnot you don't have to deal with all the corner cases you just describe what the state of the machine should be and the CM tool puts the machine into this state there are a number of these CM tools out there we all have heard of puppet and chef obviously they've been around for a while and they feel they're very powerful there's a learning curve pretty involved to setup sometimes to me it appears like it's a bit like the world of Java Enterprise sort of stuff there's too much stuff going on it gets its feel strangely complicated to me at least to other people too so a few years later people thought it's not necessary for this to be so complex there should be a simpler way to do this and so salt and on ansible came around and certainly ansible takes so simple approach to a to a whole new level I just for completion sake II I put in fabric which is which is more I guess good python-based script style deployment tool and also scripts themselves and they're not really CMS tools I just thought I'd put them in there right so ansible that's what we're talking about today it calls itself an orchestration engine for configuration management and deployment and it says orchestration engine because it doesn't just deal with one server and configure software on this one server it thinks about groups of machines and roles that that you can have across these different machines that can take information that it gathers as it sets up these groups it can take this information back and use it then to configure something else like you bring up ten machines and now you suddenly have IP addresses and you take those back and then configure a load balancer with it so it it ansible Vestas quite neatly and and easily and so that's why they call themselves an orchestration engine it's written on Python that's good and it uses llamo to as a format for its play books and play books those are these descriptions of the desired States you you can put in also explicit commands yeah so you can describe state but you can it also allows you if you want to do a shortcut or something directly to run a specific shell square for a specific command line or come out yeah you can do this as well so you can mix a little bit simplicity there are several points that come together to to make ansible a tool that is simple and easy to use so first of all there is no central server that you need to maintain but other tools you have to have a central server and with ansible you do not so you don't have to manage keys and who has access to what that all falls away you don't need to install anything on the target machine in fact you can bring up a brand new easy to image or or you would to image on OpenStack or whatever you have just point and simple edit and and off it goes and there's nothing you have to do ahead of time to prepare this image for ansible another interesting little thing is this explicit order that I mentioned there if you have tools like a puppet for example it tries to be very smart and tries to run as much in parallel as it can and then people end up with these strange surprise less about race conditions and so ok then we need to define dependencies now this depends on that so don't run this yet and an unstable that whole problem falls away because it just does things in that order so one less problem to worry about all it needs is SSH and Python on the target machine and most Linux machines these days just have this by default and there is now AM ansible version which can deal with Windows that uses PowerShell I believe I don't know anything else about it I just read about it I don't do windows but just thought I mention it so yeah so you can take ansible into the windows world as well known that's the architecture from your laptop or wherever you want to run your ansible playbooks from reach - straight out to the server's does stuff and leave some alone there's nothing else you have to set up modules is where probably the real power of ansible comes from there are hundreds of them they have been written by all sorts of people they're just small very specialized pieces of code which do just one thing for example they can execute a shell script on a target machine or they can copy a file or do a template style sort of replacement of of strings in there or operate on a line in the config file or maybe they can install a package there is an and simple module for apt that does nothing but do an apt install for example or said another one for setting abusers groups but also there are instable modules to configure rebbit or or databases the ansible modules for Postgres others for Apache which know how to configure that and even as you will see a bit later for to to access deal with cloud infrastructure from from different providers so how does it work it's really straightforward you have your laptop and just say to ansible that you would like to go and configure something out there so for example install Apache person there's an apt module for example what do we do we take SSH and copy this little module is being copied over to the machine where does run and then delete it and the results are returned so ansible goes takes a little bit of code puts it on to the remote machine rent it and deletes it so we're the time ansible is done there's no trace of it left on the machine right so not only do you not need to install anything you also don't need to set aside any space for all the crafts that accumulates there's nothing right so that's basically a small overview of how ansible and principle works and David's gonna take you through some examples now and get you up close with some of the playbooks thank you your gun so I'd like to dive into some of the details around ansible so ansible has this concept of an inventory file and groups so in the inventory file you actually are able to store all of the hosts that account currently under management and you're also able to associate them into specific groups you can group them by function by location by hosting provider so here's an example of an inventory file and so you can see that we have four groups here we have two groups for geographical location so Europe and North America and we have two hosts in each of those groups and we have two groups based on function or role so front end and back end the names of the groups are totally arbitrary you can make up any groups you want and the Association of hosts or group is arbitrary as well that's totally up to you as yoga Ned mentioned ansible provides both CMS type functionality where you're actually specifying the state that the desired state that you would like to see on your servers but it also acts as an orchestration engine as well so you can actually get ansible to perform specific tasks so here the first line there is actually telling ansible well it's telling ansible to perform a specific action in this case it's doing a you name for all of the hosts that are in the Europe group the - I there is to specify the hosts file so you can pick any you may have a number of these host files so you can pick a specific host file and load those group associations the second command there is actually running a different command it's rebooting all of the servers that are in the front end group so you can see that this is pretty powerful and this is a whole reason for having groups groups our actions are actually executed against either single hosts or against groups so the fundamental unit of description in ansible is called the playbook so player books are written in in Yama and they basically tell ansible what to do so here's an example playbook so this playbook applies to all of the hosts that are in the front end group it's going to execute with suit permissions and it has three separate tasks in there so the first task is to update the system and this is kind of a CMS type operation because you can see it's using the apt module to install an app package so the package is the nginx package but it's saying that it wants the state of the system to be to have the latest version of engine X so if nginx is not installed it'll install it if it's installed it'll make sure that it's upgraded to the latest version the second command there is creating a user account so again it's kind of CMS II because it's saying that it wants to make sure that the user app user is present and then the last command there is actually more of an imperative or kind of an action based command so it's basically copying files to from the localhost or from the host that the answerable process is running on to the remote users home ansible uses the ginger to templating language so this is so you can template configuration files that you're going to manage with your CMS and so it also provides a mechanism for providing variables that are going to be rendered by those templates so here's an example so again we have an animal playbook it's going to apply to the group all pseudo permissions and we're actually defining the variables here within the playbook you can also define the variables separately in other files and I'll talk in more detail about that in a little while and you can also pass them on the ansible command-line so here we're providing the username as a variable and you can see that in the task list below where it's creating the user account the name of the user is actually parameterised so the username variable will be inserted in here based on the value of that variable so ansible is very flexible so you can lay out your your project in many different ways so here's a very simple way till I add a project so we basically have the inventory file up the top there my hosts you have a set of group variables so these are all the ml files that contain structured variables that you can then use to render templates for example as we just saw so the nice thing about group variable is there automatically associated with the name of a group so if you're when you go and let's say we use our current example and we run against all hosts we run an animal command against all hosts say create users when it runs against a particular server the server the variables will be populated from the role that matches that server so for example in this case the variables in front end in the front end file will actually be used to populate templates when it's running it when when you're running against a server that's in the front end and so on then down the bottom there we have site yamo which is the top-level ansible file it's kind of the entry point for ansible execution so there's also a best practice layout it's a little bit more complicated there's a lot more to it but it's very extensible and once you start using it and getting familiar with it it's it's becomes second nature and you just you're able to navigate around very quickly one of the nice things about using this best practice layout is that if everybody in your organization or in your team actually uses it it's really easy to look into somebody's ansible repo and understand what roles there are and I'll talk about roles in a second understand what functionality there is and how you can reuse it so here's an example of the best practice layout so on the left hand side there you can see ansible config so these are default options that you might want to set for your ansible for your for your ansible application we have to inventory files in this case deploy hosts and staging hosts and I'll talk about this more in a little while but what's really cool is the reason that we have that is because all of these play books that are in the rest of the in the rest of the tree there can be executed against two different sets of hosts your your staging hosts if you want to test or your deploy hosts if you actually want to deploy and that's really really powerful so we've got the group fires over there as well we have host fires which are kind of like group fires but they only apply to a single server instead of a group of servers at the bottom there we have site gem on the entry point and then on the right here we have roles so roles are basically collections of tasks they're reusable units of functionality and they can be applied to either a group or a server so roles we've got three roles here so at the top there we've got common and then down the bottom you can see web and DB and so you can imagine that typically a common role will be used by all of the nodes that you have to install basic packages that everything needs may be monitoring packages or something similar web we have obviously for web servers or DB for DB servers so if we drill down into the common role at the top there you can see we have tasks handlers templates files and bars so tasks are where you actually put your top-level playbooks so typically depending on how complex the task is you may have quite a few playbooks in there the entry point for those is main Damo handlers are used for implementing functionality that needs to be triggered so at some point in a playbook if you want to trigger an action you can send a notification the notification will be received by the appropriate handler in in the in the handlers playbook and then some some action will be executed so reboot is kind of a typical example templates is where you would store all of the templates for the configuration files that you want to manage using ansible so in this case we're managing sshd so we have a config file there that would typically have a bunch of variables to be substituted by with the values that you pull in for from group bars or host bars and then files are just generic files it's kind of a catch-all for any other files you might want to copy over so scripts or data files whatever that happens to be and then we also have VARs so these bars are just for this specific role and so they do a similar thing to group virus and host fires they're imported when it gets executed but they're associated with a specific role so this is how we use this is how we use a role so we have a playbook this is for all the front-end hosts and it's going to use the common in the web roles and so all the functionality that you have in those two trees in the comment and the web trees that we just saw are now going to get pulled in and executed against all of those hosts so one of the trends in our industry is API so we've seen and working in OpenStack we've seen a huge proliferation and api's and these can be very useful so one of the really useful things that API is provide us with is the ability to actually manage infrastructure not just the application that we're deploying so in the past we had kind of local api's on unix it might be POSIX or it might be you could consider the command line to be an API we've got now we've got infrastructure api's where we can actually use api's on public cloud to be able to spin up servers and configure network interfaces and so on and then of course there's the API is for the services for services that we want to configure or applications that we want to run on top of infrastructure this is all really cool and it's very very powerful as we'll see in just a minute so ansible also has a bunch of cloud modules for both public and private cloud so there are modules for OpenStack for AWS for Google compute Rackspace has api's and so on and you can actually from within your ansible books you can actually create modules that will then go and spit up VMs in public and also private cloud on the private cloud side there ansible modules for OpenStack eucalyptus and so on so as an example the AWS modules will allow you to create instances images Virtual Private Networks load balancers you can interface interact with services like s3 DNS databases in case so let's have a look at a couple of examples so here are some examples for creating instances either via AWS or via OpenStack so here's an AWS playbook that allow you to boot an ec2 guest so it's pretty simple so we reuse the ec2 module and then you basically just have to populate it with all of the information there so the so your key name the the security group that you want to use the type of the instance which image you want to use which region you want to run it in number of servers you want to spin up and then at the bottom there you'll see there's this register construct which basically allows you to capture the output of that operation from the API so that'll include information about the hosts that you've just configured so their IP addresses names all that sort of stuff so it's pretty powerful just with this and a little bit of boilerplate code you can actually start speeding up instances in the public cloud and you can do the same thing for OpenStack and it's also pretty straightforward so you just provide a few more variables in this case we're actually substituting variables in the template that we're substituting variables that we could pour in from another place but it's all pretty much the same thing and then down the bottom we have the register where we pull information about the guests that we've just launched so one of the powerful things that ansible provides you with or powerful features is the ability to take the output from the operation so we just for example spun up all of these instances in a public cloud and now we have a bunch of output that is in JSON format and we can actually take that output and do operations on it so one of the useful things to do is actually add those hosts to our inventory file and so here's how you do it so we have our ec2 action at the top there it's running locally on the ansible machine and basically going over the API to spit up those guests we've got the register one thing that's different is that there's a count there so here we're actually spinning up three instances not just a single instance we're capturing the results in ec2 results and then we're doing another local action below and we're actually using the output of ec2 results so the with items is an Sable's looping construct so basically what it's saying is I want you to iterate through all of the items in the ec2 results instances list and I want you to feed that information I can access that within the loop as the keyword item so you can see that what we're doing here is basically going through three times and we're calling the module add host to add the public IP of each of those items each of those instances to our inventory file so we would have started with so basically we were started with a simple ansible script with no inventory file we've executed it it's gone out to ec2 it's spun up all of these guests and now captured the results and stored it in our inventory file so if we want to do additional provisioning or installing packages or in our application we can now do that so as yogin have mentioned before we both feel extremely passionately about this working with an engineering team it's if you don't have this it's extremely painful and so yeah so this is super important and the nice thing is Anton will actually makes this relatively easy so Anton works very nicely with vagrant as well so a lot of people here are familiar with vagrant basically you can use you can run in vagrant from the command line of your of your laptop or server to spin up VMs so you can spin them up locally it also has plugins so you can even spin up you can even spit up instances in the cloud and ec2 or Rackspace for example if you want you can use ansible as your provisioner so you use vagrant to manage the virtual machines that you're spinning up your your infrastructure and then you can specify that ansible is your provisioner and then once those VMs are spun up you can create an inventory file and then automatically kick off the provisioning process using ansible which is which is pretty cool so what I'd like to do now is actually go through and show you an example of that in just a second so vagrant uses a vagrant file and that's actually your configuration and it's it's actually written in Ruby it's a ruby language so you can tell you it's pretty powerful actually and you can tell vagrant within the bagra file to construct instances with a certain amount of RAM the certain number of CPUs you can specify network interface is public private and added interfaces and so on here's an example of a really simple vagrant file so basically at the top there we're creating a virtual machine and it's an Ubuntu so c64 VM we provide it with a URL from where it can actually download the machine image we give it a host name we specify a private network IP address and then we go and into the next block which is basically where we kick off ansible so in that block we specify where the playbook is how verbose we want it to be if we want it to be a path to the inventory file and then also whether or not we want to do house key checking so the if we were to execute that then basically we'd get an inventory file that would look something like this and so this is a little bit more complex than the one we had before so here we have a vagrant we have a number of different groups so we've got vagrant frontier house back end hosts DB access and so on and you can see that in addition to specifying the names we can also specify IP Cod IP addresses and so on we talked before about group variables so here's an example of a group variable that you might want to use and it's basically where we're specifying for the vagrant group the name of the ssh user and the reason that we want to specify that is because by default vagrant creates a user vagrant that has pseudo access and so here we're just telling vagrant and ansible what the name of that user is so once you've gone through and done that configuration all you need to do to spin up your virtual machine or your network of virtual machines is just type vagrant up the first time it runs it will actually go through and will create all of the instances and then after it's done that it'll go and run ansible against those instances and provision in your application on top of those instances after you've run it for the first time you can also just call the provisioning directly and so a vagrant provision will actually call ansible directly without trying to create the instances so one of the nice things about ansible is that it can make it if you capture your system configuration correctly you can have reproducible test environments as Juergen was saying before a single command to set up a test environment a single command to use exactly the same playbooks to go and deploy that to the staging environment for testing for example and and so the cattle versus pets saying I think is well-known we want our servers to be cattle not pets and this is the thing that enables that so this is this is the workflow that we want to move towards right so basically we want to be able to do local development and testing so be able to use vagrant and ansible to stand up from scratch your your environment on your laptop for example so that you can do your development do your testing unit testing and integration tests once you've done that and you're happy to move on to the next step you can actually answer more we'll let you then go and deploy that into the cloud so basically you all you need to do is just point ansible at a different set at a different set of nodes that are provisioned in the cloud and ansible will go it can even create or update those servers in your staging environment it can provision the servers with ansible if you want to using the ec2 or Rackspace or OpenStack api's and and you can also deploy your application with ansible and then finally once you're ready to take the next step you can go and deploy this out into production and it's again using exactly the same workflow exactly the same run books and that's extremely powerful so now I'd like to show you a short demo I cheated a little bit here and I'll explain why in just a minute so this is the work this is how I actually came to know uragan was because he's written some really nice and simple scripts that will basically set up an environment like this for you so what this is this is each one of those boxes represents a virtual machine so at the top there we have a cache or virtual machine and so this is going to cache both app Debian packages and also pip as well we've got I've used we've got MCP which is basically a controller so this is a node that's just going to run OpenStack services but not lower compute and then we have 2mh fees which are hypervisors and those are actually running Nova compute that's where your instances are going to be running and then down the bottom there we have a get cache where you can actually check out all of the repo so you're going to be working on and store them in that get cache so that they're completely fixed instead of pulling from the network from the remote git repos you pull from your local one which is totally fixed and not changing and these are this.get caches NFS mounted to all of these all of these virtual machines there and this is super powerful if you've ever run devstack you know how much network bandwidth it consumes and you also know that it changes very frequently and often those changes can break your development environment so one of the really nice things about this is that you're caching all of your apps and all of your Python dependencies and you're fixing the software that you're actually testing because it's all stored in that get cache and so that's that's really powerful so here's the demo and this is where I cheated I was trying to think of the best way to be able to demonstrate this and doing a vagrant up would take a very long time so what I did instead was take a video and cut out all of the all of the wait time so hopefully this will this will give you an idea so this is showing me do a vagrant up I'm provisioning 2mh fees so the hypervisor so the controller and the caches were already up so here you can see we're off and running it's identified that what the hypervisors there's no hypervisor box so it's downloading and installing the trusty image it's waiting for the machine to boot this takes a little bit of time now it's adding an ssh address adding a public key now we're on to the second hypervisor and so now you can see it's also written into slash Etsy host the IP addresses so you can reference these by name so we're almost finished now we're mounting the NFS folders for the get cache on the second mhv sorry the second hypervisor just checking to make sure all the devices are healthy starting the second virtual machine now the second hypervisor we're going through all the same steps we went through before by the way you can paralyze this as well in this case it's not it's all serial so setting the hostname mounting an affair now we're into ansible so now we're actually starting to execute the ansible playbooks Keysha needs nothing done it's all set so we skipped through that it just sorry that went a bit quickly so now it's going through the hypervisors and it ran through a bunch of steps so what it did was it actually installed a bunch of package after packages it checked out devstack from the git repo it copied configuration from local configuration for both of the hypervisors from the ansible repo and then it actually started their stack and then you get a nice summary there at the end and the thing that I really liked about this and this is the thing that's really changed my workflow is that it's reproducible I can do it every time I can lock my configuration down and it's also significantly faster because instead of having to go over the network to pull down a lot of packages you can do that locally as well so I have a reference to yogas repo at the end of this if you would like to have a look at that so the key takeaways here so you just saw me do this locally using vagrant using the ansible modules I can actually both using the same answerable playbooks I can do this against any set of machines either virtual or real as long as I have network access and I have SSH access that's super powerful and that's yeah so the other takeaway is that with these new cloud api's or relatively new cloud API so OpenStack AWS Rackspace and so on you can also use ansible to provision your infrastructure and that's pretty cool as well so here are some references for you so if you have any questions please feel free to contact uragan or me we'd love to talk to people about this the slides you can download from the URL there the ansible playbook that's a reference to your guns repo ansible Doc's source vagrant and there's an example project there as well so thank you very much any questions so oh yes sure if you have any questions please use the microphone over here thanks for the talk um when you're running ansible to provision infrastructure how does it know on the next run that these ec2 instances have already been set up so the easiest way is just from if we use the workflow that we showed there you'll already have an inventory file and that'll be populated and so you can use that inventory file when you run it so yeah okay so like the first time we run it we have no servers right so then we run it it'll go and spin up all of the guests and it'll pull back information which is the IP address and name of each guest and it'll put it in a file and then the next time when we want to run ansible we can just use that exact file and ansible will know all of the all of the hosts their IP is in the groups and then it will just execute against those okay and so the ec2 module will know if you said been up three hosts authority in 30 file not yeah it'll already yes and you would actually use wellmaybe uragan you can jump in it yeah yeah there different ways ways to go about this but basically once you have an inventory file that you dynamically created with these dynamic ec2 instances you can run ansible not in the provision infrastructure for me mode but here's some infrastructure I'd like you to use mode right so um I usually have a little bit of some control scripts around it where I can either I have a static deployment or a provision this deployment right so but but you are basically you create the inventory file dynamically and use that yes thank you for a great presentation my question is do you have any recommended ansible PlayBook editor oh I died not really I I use either VI or pycharm depending I think yeah the same same yeah it's it's pretty straightforward and actually for many editors you can get some plugins which can check the that your Yama files are correct in syntax so I usually just work with that thank you and so I thought the comparison of chef to the kind of older more enterprising ups and was kind of useful and explained why I might want to use ansible yeah and but how would you compare it against salt is there any kind of very obvious reasons why you might want any sounds a little or blast butter so I I don't know so I don't know much about salt I know that so we have a we have a team of DevOps engineers and all they focus on his configuration management for our clouds and they're very knowledgeable and I know that they've evaluated chef puppet and we also tried salt as well and we didn't have a this was about a year and a half ago and we didn't have a good experience with that in production so now we're a full steam with with ansible so yeah this looked at salt quite a while back and there was I thought there was more setup required there was a bit more complicated and as I said let me just go with answer Ball State with that and here we are now at this OpenStack summit and we have all sorts of talks which mentioned ansible and I don't think anyone mentioned salt its ansible has the momentum yes is there any bills and wane as well to deal with encryption/decryption of Secrets yes there is actually so ansible has a concept of a vault so you can actually encrypt sensitive data and store it if you want to and then unencrypted it when it comes out so definitely two questions one nice thing about puppet is you can set it up in cron or whatever so it re it checks every half hour and resets the state is that something that ansible is instead of doing can you set it up to run that way there's nothing left on the machine so I don't know how you were so so there is this something called ansible pool and ansible pool is just basically that are something you would install maybe with ansible at first on the target machine and you then run it in a cron job for example and all it does is it checks a repository you pointed at a repo and from the repo it pulls down whatever's in the repo and if something has changed it looks for a playbook file with a well-known name in that repo and runs it and she basically just do local actions so you can then go and let's say you're configuration for your cluster has changed then all of your instances get this and ansible pool will update then locally yes okay yeah that's a status for those who if you want to then keep a cluster that runs updated that's for and this might be a related question but you know with this sort of push mechanism it's great for a few hosts but if you have a hundred or a thousand hosts it can just take forever to do an update if it's you mentioned something about running in parallel one was curious what support ansible has if you're going to do a thousand updates and you don't want to wait for each one to execute yeah well if you if you have for example a group of 100 hosts and you want to make a run a playbook against that all those hundred hosts would run it in parallel yes we've been told time is up so I guess the last question just a clarification for when you're connecting to API is instead of SSH into the host and if copying Python so for example connecting to a piece of network gear right I mean I have Python loaded on it and you're trying to use the API are you then always using the local Python on your box you connect to those yeah that kind of thing yes yes okay yeah great okay thank you everyone thank you

Channel: Open Infrastructure Foundation

Views: 17,323

Rating: 4.9716311 out of 5

Keywords: Juergen Brendel, David Lapsley, Products Tools Services, OpenStack Vancouver 2015 Summit Session

Id: qEuk65few9I

Length: 42min 6sec (2526 seconds)

Published: Thu May 21 2015