 Alright, so we're going to talk a little bit about Ansible today, and before I tell you a little bit about myself, the reason for this title, DevOps for Humans, is mostly because I think that a lot of the world of DevOps has been about automation and machines and getting into it from a perspective of a lot of heavy code, but a lot of the emphasis hasn't been as much on using DevOps in a human context, getting deployments done, getting everybody involved from end to end, so that's why I chose this title. Also, someone stated a couple days ago, the longer the title is and the more exclamation points and things like that, the more people come to the session, so I think it worked. So I'm Jeff Geerling, you might have seen me as GeerlingGuy on Drupal.org. I've been in the Drupal community doing stuff since 2005. I started with Drupal 4.7, have done sites with pretty much every point released between, and right now I'm working with Mercy. It's a healthcare system in St. Louis. I also own Midwestern Mac LLC, which manages hosted Apache Solar and server check-in, so between all those different things I'm managing personally like 30 or 40 servers and then through Mercy I work with teams that have projects across many hundreds of servers, so I get a lot of work with infrastructure and so this presentation is kind of a growth from that. I'm also writing a book right now called Ansible for DevOps and a lot of people seem to immediately be put off by the word DevOps. They think I'm meaning DevOps and DevOps is a plural, but that's not what I mean. DevOps is the word I'm talking about Ansible and the whole DevOps movement, which I'll talk about a tiny bit. Right now it's 50% complete, but you can buy it now and you'll get updates forever, so go ahead and buy that, please. In this presentation I'm just going to go through three basic things. First of all, talk about Drupal deployments. Drupal especially can be a lot harder than some other kinds of applications that you might be deploying. Talk about how Ansible is not hard, it's simple, but it's also still powerful and then of course why Ansible is good for Drupal deployments. Also before we get started, I wanted to know a little bit about you people in the audience. How many of your developers raise your hand? How many would call yourself a sysadmin? You don't do much development, mostly sysadmin work. Then how many servers does your project use? How many people don't really manage servers at all? How many have 0 to 10? Okay, 10 to 100? Okay, more than 100? All right, a couple people good. All right, so let's get started. Before we can get into Ansible, I want to stress some of the pain points we have in the beginning and still this is the case in some places too, so don't want to exclude people. Development was done locally through MAMP or WAMP or something like that. Basically every developer had his own machine, he set it up however he wanted, got things going and then once he was done with it, you'd put it in your repository and then your deployment would be somebody doing a Git pull, doing some Drush commands and then also maybe 15 or 20 other steps. Eventually you have a finished deploy, but a lot of manual process there. Servers would be set up either with some shell scripts or something, but it would be a big manual process. You order a new server or you provision a new server and it might be few hours, few days, some cases few weeks or months. I have experience with that. Basically the principle is a lot of things were heavily manual, so we wanted to get through that. What would happen with a lot of deployments is basically this. That's your beautiful Drupal site that was ready to go out, launch it and it gets destroyed by the process. This is something that still happens for some of you who are fully automated already. I don't know why you're in this session, but for some of you this might not be the case, but for a lot of people there's a big fight between the developers, the project teams and the admins who get things done on the servers. Then the problem is that back in those old days and still again for some sites, server setups were like this. There was a big server with lamp basically. This is how things were back when Drupal was created. That's trees for people who don't know back in his college days. He didn't have the big hair at that point, but it was one server, not too hard to manage. It was still annoying to have to do some manual things, but you'd have a big huge snowflake server that was beautiful and unique, but also hard to maintain and hard to recreate if you ever had to. This is a bit more what current modern Drupal deployments, especially for bigger sites, looks like. Your site might have more or less of these parts, but often there's more than one server involved and there might be some load balancers and there might be some other parts of the infrastructure that are only controllable through APIs and things like that. If you're on Amazon or digital ocean or line out or something. So that's bad, but then when you think about it, a lot of places have four environments that are exactly the same with tons of servers. So you're not talking about one server or two servers. You're talking about 50, 100, 200 servers that you're managing and there's no way that you can do a manual process and have good uptime and have good deployments all the time. That's where we are today. In the future, things could get even more hairy when you have containers, thousands of containers running on hundreds of servers, but you don't even think about the servers anymore. So we need things to help us get through the situation without us wanting to kill ourselves. So DevOps, as I said earlier, I don't mean a person. I mean a movement, a idea. There's a lot of argument over the word, but basically to me it's a holistic view of development and operations. It's all one and the same. There's still CIS admins and there's still developers. A developer's not going to be the guy who's doing all the gritty server work. If you manage your own server, he's not racking up servers, but you can work together more. There can be silos, but the silos can work together instead of being brick walls. So three things that we want to fix nowadays is we want to make sure that when we have tons of servers, it's not just LAMP. It's Linux and Apache and Linux and MySQL, Linux and PHP or whatever kinds of applications you're using. I'm going to manage those easily. I'm going to be able to scale up quickly. So if you're using a cloud service and you have an infrastructure where you might be having a million visits in an hour one day and then the rest of the week very little, you don't want to be paying for some huge server or a ton of small servers that whole time. So you're going to be able to scale up and scale down automatically without you having to do a lot of manual work. And then finally we want to have testable infrastructure. And this is big in the software development community. Test driven development or at least well tested development is a big important part of our process. And in the infrastructure world, this is just beginning to catch on. We want to be able to test our infrastructure just like we test our code so that we know when there's a deployment, the failures are not going to be because of our infrastructure. The only thing it could be is lightning or earthquakes, things like that that are completely out of our control. We can't test for that. We might be able to if you had Google's money. So one principle that I think is that kind of sums up the a lot of what the tooling around the DevOps movement would be is that it would take less time to rebuild a server from scratch than to log in and fix it. So a lot of people aren't to that point yet. Right now, I know a lot of places that I've worked with, if our server goes down, it's going to be everybody gets on call, you're wasting 45 people's time, you're wasting tons of money, and your site's down for a while, and then eventually 30 minutes later somebody logs into the server and reboots a service or something. But if a server goes down or some service goes down, you should be able to have another server up in a minute or less, I would say. So that's one principle. I'm going to take it a step further and reuse this classic Drupal meme. Every time you log into a prod server, God kills a kitten, so please, please don't kill the kittens. This was a slide from, I think, five years ago, 2007, eight. I don't remember when it was. And it said, every time you hack core, God kills a kitten. So in my mind, if it's not this way now, it will be within five or 10 years. Logging into a production server is not going to be a normal thing to do for deployment, for a fix, for anything. So what do we have available on the market today? Puppet came out in 2005. I know a lot of people use it. It's a very good product, very reliable. One thing I don't particularly like about it, but it's not a big issue, is that it uses a DSL, a domain-specific language that's kind of based on Ruby. So you have to learn a new kind of configuration language. You have to learn a different kind of template language. You have to install something on every single server you manage, which is a little bit annoying. There are ways with Puppet and Chef to do it differently, but it's hard. And no matter what, you're going to have to do something on every server you manage, whether it's automatic or not. And also there's no simple, easy, built-in way to do something like reboot all your servers. You still have to use some other tool to do something like that. Chef was built in 2009. It has a little bit more standardized Ruby-ish syntax, but in my mind, a lot of the ways it does things are basically the same as Puppet, just a little different here and there. So I usually group Puppet and Chef in the same thing. They're both great products. They both do a lot of great work and they both have a lot of tooling around them. Salt came out in 2011 and like Ansible, it changed a few things. First of all, it doesn't use some language, some programming language or some domain specific language to do the configuration. It uses YAML, which is a language that was built for configuration and readability. So it's easier to manage your configuration that way. It uses Jinja 2 for templates, which is a templating language. It's built for making templates. It's not built for programming. And Jinja 2 is exactly like Twig. In fact, the author of Jinja 2 is the same guy who worked on Twig. So one takeaway from this is if you are learning YAML and Jinja 2 for Ansible, you are actually learning YAML and Twig for Drupal 8. So there's transferable skills there. Nice selling point. But Salt, as with the other ones, requires something to be installed on all the servers. There's a way, again, to run it in a different mode, but that's not the default and it's a little harder, a little trickier. But Salt also introduces a simple way to execute tasks across your servers. So run a command on your servers or call something on your servers. So that's another improvement. Ansible came out in 2012 and has some more... It also includes the ability to manage your servers through SSH, and that's pretty big. Instead of having to install extra software that's running on each of your servers to do certain things, you can have Ansible go through SSH, manage everything, and everybody has SSH on their servers running right now. And it has all the other nice features that Salt does, and it has the most stars on GitHub. But as I say down at the bottom, that doesn't mean much. It's just a reference point. Now, a lot of times people, especially if you are... I think a lot of developers and admins are very much into my tool is the best tool. But in the Ansible community, it's not about Ansible as a replacement for X, or Ansible is better than X. It is, but we're about hug apps. We like Chef, we like Puppet, we know their heritage, CF Engine 2, I have to throw that in there even though I've never used it. And the cool thing about Ansible is you can use it for what you need or what you want to, and it still works great with your existing infrastructure, your existing tooling. You could use Ansible to coordinate the deployment and run some Puppet or Chef things and set things up through Ansible to continue using whatever you're using now, or if you want, if you have a team that already knows something else, you can throw Ansible in and it's easy to pick up and learn to do simple parts. So we're not against anybody in using Ansible. So these are just a few companies that use Ansible. You might have heard of some of them. It's had a lot of big adoption. There was the first Ansible Fest was this year in New York City. There were some great presentations there. A lot of them recorded. The slides are all available. You can see they're doing some neat things at Twitter and NASA and other places that are using it. I think Rackspace is getting into Ansible in a big way. They actually have some sort of fork or it's like Ansible but built for Rackspace basically. And I'm also using it for the things that I do. That's why I'm giving this presentation. So let's get started. It's been 15 minutes but we can start getting into it and by the end of this presentation you'll be able to automate everything with Ansible, I guarantee. So Ansible needs a way to describe your infrastructure and it's pretty simple. If you've ever edited a hosts file it's practically the same. You just give it a list of hosts and with Ansible you can also give it a list of variables. So this is a basic inventory file. It can be even more basic than this but I'm going to show you a little bit about how this is more flexible. First you give a group name. So this could be a group of web servers or database servers. In our instance we're just going to call it LAMP. And then you give it a list of hosts. In our example we're just giving one and some variables to use with that host. You can put in any kind of variable that you want to use in your playbook later that I'll talk about. But in this case a lot of times you'll be wanting to use a user that's not your current user name and or a port or some other kind of settings. And let's see. And this file, the inventory file by default would be in Etsy Ansible hosts. So everything would be configured in that directory but you can also do things to put inventories other places. And then after you've described your infrastructure you need to tell Ansible what do you want to do with it. So you have playbook tasks. That is then that's like the smallest module of code that you can do in Ansible, not code configuration. And this is YAML. So you have documentation built in. You don't have to have the documentation but it sure helps when you have 300 tasks and you're trying to figure out the one that failed. It just has a bunch of descriptions instead of your actual documentation. Then you have a module and Ansible right now has 268 different built-in modules that do anything from configure packages to interact with load balancers to do pretty much anything. And you can extend and add your own modules using PHP or Ruby or whatever language you want as long as it outputs JSON. And then you have some arguments to that module to tell it what to do. So in this case we're making sure Apache is installed. We're using apt or if you're unsent to us at Red Hat you can use YAML, giving it a package name and saying the state we want the latest version of it. You could also just say installed and it would install whatever version it is or just leave it if it's already installed. And then here's a little bit more realistic playbook. So in this case in the example we're going to have here we're going to save this playbook as web.yaml and first we are I don't have my thing. Let me grab my pointer so I can point this out. So first we have the documentation. We're making sure that Apache and PHP is installed. Next we're using apt again and then for package we're actually giving a variable. For anybody that's used twig at all in Drupal 8 you'll notice that this looks just like that. The two curly brackets. This is a variable and we're telling it use these items here with items and it will run through and do each it'll do this command each time with one of these. And then again we're using state latest because we want the latest version. The second task is just making sure that Apache started. So there's a service module that uses the service command and it's platform agnostic so it works with whatever kind of Linux distro you're using. And we want to make sure that Apache 2 is started. So that's web.yaml. And then we need a playbook to run that file that we just saved. We could do this all in one playbook but I'll show you why that's not desirable later. So this is kind of our orchestration playbook. We're telling it first the host that we want to run this on. So we defined in our inventory lamp and now we want to run this playbook on all of our lamp servers. And then we're also telling it here that we want to use sudo because we're going to log in as our non administrative account and use sudo to do the actions instead of logging in as root. And then at the bottom here we're including that web.yaml file that we just created. So we want to run this playbook and get our server set up how we want it. And it looks something like this. And once it's finished it gives you a little recap that shows how many servers did it do things on how many servers was everything fine already matched your configuration. Pretty quick and easy. I'll go into the Ansible playbook command a little bit more later. But for now I want to also say that these all the commands I'm running today are running through Vagrant on my local host. And Ansible works perfectly fine and easily with Vagrant and an advantage to that is you can test all of your infrastructure including many server infrastructures on your local computer using Vagrant very easily. And to do that all you do is define a provisioner give it a playbook and give it an inventory file or if you don't get an inventory file use the one at Etsy hosts or Etsy Ansible hosts. So let's get past just a basic Apache and PHP installation and get to Drupal 8. So this playbook here we start off and we're using a new set of hosts the d8 hosts. We're again using sudo and then we're going to make sure our app repositories are updated. And for Drupal 8 it requires PHP 5.4 or later. So we're going to install Andridge I don't know how to pronounce his name. The the an extra repository to get that in this case we're going to run it on in Ubuntu 1202 host. And then down here I'll talk a little bit more about roles but basically these are sets of playbooks that's what we'll think about right now. And yes this actually works this one playbook right here will install everything you need in about three minutes and 14 seconds on a decent internet connection. And in the end you end up with a fully installed Drupal website. And let me give you a quick demo of that before we get into roles. So here's our Drupal site that we just installed. And this is Drupal 8 head was installed with Drush head and it all works fine. And what happens I ran the playbook it had like 60 or 70 tasks it ran all the tasks got everything installed and then if we run it again now this is live on my Mac. So it gets through everything and at the end of it it tells you I didn't change anything. That's a nice feature of Ansible you can either run it as a straight-up script or run it with dash-check and it'll give a report what is your current configuration is there anything that's changed from what you described. So when you're debugging something you can run it with dash-check see what's going on or if you have a script or some sort of monitoring on your servers you can just run Ansible playbooks with check mode and then make sure that they're in the state that they need to be in and alert you if they're not. So Ansible roles you notice that I showed you there were a few things prefixed with gearling guide dot whatever those are roles that I got off of Ansible Galaxy but your roles can be named anything you want basically it's a way to put together a set of configuration variables and things like that all in one little package for different kinds of things now in my case I was using like gearling guide dot php in my SQL so basically like a package to a role but you can do it any way you want you could have a role called web server setup or a role called nginx php or something and do different things in it but it's a way to put together things into one small package in a reusable way. So an Ansible role can have a few different parts to it in in most of the cases with the roles that were being run there most of these were used so tasks would be the the web.yaml file it'd be things to do on a host the configuration to run on a host handlers are things that are called if you have a certain task that needs to restart a patchy you'd put a handler which is just a task but in the handlers folder called restart a patchy and it would restart a patchy and then verrs is variables and you can also have default variables variables are very flexible and ansible so you can use one role and use it across your entire infrastructure for different kinds of servers templates would be ginga files that way you can have configurations and things that are different across servers files would be just files to copy up to the server but there's many different ways to do that besides just throwing them up on the server and then meta describes information like dependencies and if you're going to contribute the role back it will be on ansible galaxy put some information in there. So we're going to make a quick Drupal deployment role we have our Drupal 8 site setup now and we want to deploy an update to it so inside of a roles directory or you can put roles wherever you want you can configure it for your system we're going to make a site-deploy role and ansible will pick this up as the folder name basically that's the role name and then in this role we're going to have a tasks file so this task is going to run some drush commands a couple notes here ansible the command module basically runs a command on the server it's pretty simple and in this case we're going to run a drush command and some a note on yaml syntax formatting this little greater than sign basically tells the yaml parser everything on every other line after this just add a space between it so that'll be helpful if you're doing Drupal 8 configuration too and you have something that takes a lot of lines you can just throw that in there and have your multiple lines so we're going to run a drush command with the items down here again that's what this item does and then we're also going to change the directory before we run the command and we're using a variable here i'll get to that in a second Drupal core path we want to be inside there to run these drush commands and we're going to run cset which does a configuration setting change and then wrap is the role add permission and then at the end of it we're going to notify a handler that i was talking about earlier called restart web server and i call it web server because i want to make this role more flexible it could be used with nginx it could be used with lydie it could be used with apache whatever you want and again save this as tasks slash main dot yaml ansible automatically picks up whatever main dot yaml file is inside of a folder inside your role so next we have our vars file and we have a site name which if we go back here you saw there was a variable site name right here so this will be picked up and thrown in there by ansible and the role has this variable but also any playbook that you have for any server could override these variables and then we have a Drupal core path right here and then finally we have our handlers like i was saying when you do any of those drush commands you want to restart the web server in this case we don't need to restart apache necessarily but if you had something like reset something or flush a cache or whatever you want to do add handlers and then call them with the tasks that need those things done and we're going to make sure that even if we didn't use sudo for our playbook because you don't need to for some deployment steps we still want to have sudo used for restarting the web server so we have those three files we put them in the site deploy directory under tasks vars and handlers and we want to make a playbook to use that role and it's as simple as this we just tell it what host to run the role on and then we add the role in a list of roles save that as playbook.yaml and whoops delete that so let me switch over here so this is that playbook that i just added so it's running these drush commands and restarting the web server and if i pop over here you'll notice that the site name changed and since everybody can search now the anonymous user has a search block so a couple notes on that let me get back to here so a couple notes on this one is when you're running commands obviously this is pretty contrived most deployments aren't just running a drush commander two there's a git module for ansible i'm not going to go into all the different parts that you can use there's a git module there's a shell module if you need to use special variables and things inside of there plenty of modules to do all the things that you need to interact with and your playbooks can be as long or short as you want but one thing that i usually do with my roles is i'll have my main yaml file with the tasks and it'll just include different sets of steps for that role so if it were a drush site install i'd have the drupal core checkout using git there'd be a git command and then i'd have i'd have a drush install if i need to install drush with composer that would be in another included task file and then i'd have the site install command through drush and any permissions changes and folders and things like that database setup so and and you'd be surprised ansible has so many different modules almost anything that you're going to do on a server even if it's third-party software there's modules already made up for it or if there aren't there probably will be by the next time ansible updates to a point release so let me pop back to our demo slide and there's another nice thing it was just added an ansible 1.5 i think maybe yeah it was 1.5 there are tons of notification models built in so whatever you're notifying whether it's irc or email or whatever or if you're using some third-party services to do notifications and and get into chat channels and whatever you need to do there's tons of different notification modules built in like this one is irc and it will you just give it the parameters you need and in our case we'd be adding another variable called irc message and ansible has another option you can pass called delegate to which tells it run this command on localhost don't run it on the on the server that the playbook is running on and so this is powerful not only for notifications but for other things where you need to call some other service or you need to do some other kind of task that you can do through your local computer but you wouldn't want to do through your server especially if it requires extra software installed you don't want to install junk on your server just to do some little api task or something like that so you can delegate a task to whatever server you can use tasks you can put in a user attribute and then tell it what user to run the task as so i'll give a quick demo of that too so this is the same playbook but with that irc task added and if anybody is on the drupal com channel you'll be able to see this message in just a second and the reason why i did this separately was because if the network was having an issue you guys won't make me feel too bad i know from running server check in that the internet is a horrible horrible place if you're considering doing presentations or considering uptime so anyway it did it and anybody that might have been on the channeling might have seen it was any okay somebody saw it good all right so let's pop back in all right so so once we have our site deployment set up a lot of people will do a deployment completely separate from their operations of provisioning servers and setting up things in ansible the principle really is you have all of your configuration and all your deployment everything packaged up in one big package but it's all in small chunks so you could take out a site deployment and just do a deploy using a separate playbook or in our case we can have we can throw this role in with the whole server provisioning so when you provision a new server it deploys the site there's no separate step it's all together and this is the same exact playbook that we had earlier just with site deploy added in so now when we have a cluster of servers like this which is the modern way of doing things we have playbooks for each one of the sets of things so we'd have a playbook to set up the web server and deploy Drupal to it we'd have a playbook for the caching servers and setting up all their firewall rules and everything playbook for search servers and database servers everything and then on top of that we'd have one playbook to do a full deployment across everything and this playbook can do things like pull three or four servers out of a load balancer do the stuff on them put them back in pull the next three out do some stuff it's pretty easy to configure with Ansible don't have time to cover it today unfortunately but once you once you granularize your infrastructure like this using a bunch of simple YAML files in Ansible it's easy to do whatever you need to with your infrastructure and with your deployments and instead of having a ton of setup work for new servers or your entire infrastructure you just put a new server in a pool and Ansible picks it up and Ansible does whatever it needs to do to it while you're deploying everything else so what this would look like is this would be that master YAML file doing everything the first one up here the first set of tasks is the for all it will just do it on every server in your inventory so you could use a custom inventory or you want to be careful when you use this if you're using it with a global inventory because it will literally run this on every server that you've ever managed in your inventory so but anyway so that it would maybe install some security software monitoring file share users whatever kind of stuff you need on all your servers then you have your web servers using whatever roles it needs for those and then database server so this way you have a role for every kind of setup tasks that you have and then you have a set of hosts in your inventory file that defines what servers to run it on and then you just throw the roles on those servers so I think with Ansible it took me about an hour or two to get started and have my first task being run on remote servers since it all uses SSH if you can connect your server through SSH you can set up some tasks run it with Ansible playbook it'll kick them off to the server you're done and even if you're just trying to confirm a configuration use the service module say make sure this is started make sure this is enabled at boot that kind of stuff you can do that in maybe five ten minutes if you already are familiar with Linux administration and it's just YAML so you don't have to learn some new syntax that's hard to use it also solves problems that we have in our in our world where there's solid silos and walls between development and operations there's no more excuse for having a developer have everything working perfectly because he spent three and a half hours working on some tweaking some config files and then he puts it on prod and it all falls apart it also helps with sysadmins not getting burnt out not wanting that alcohol anymore instead they can have family time probably still want the alcohol though and for me I know and hopefully for a lot of you if you get into it you'll actually start enjoying the automation because when you're using YAML when you're using Ansible when you have your host described in that inventory instead of spending time wrestling with syntax and wrestling with the way that things are interacting and why is the server not responding oh the thing just shut down on it the demon's not running anymore you just focus on getting your servers set up and running and everything is done through SSH so it's not hard to get set up it's not hard to keep it running and it's fun to be able to iterate so quickly but also beware the golden hammer just like with Drupal Ansible is not suited for everything I've seen people go off the deep end and start using Ansible to do builds and do things that are not suited to a more of a configuration management system Ansible is not a configuration management system it's great at it but it's actually an infrastructure management system it's good for helping with deployments and things like that but if you're doing things where Jenkins would be a better fit do Jenkins and then use Ansible to do some stuff on the server itself there's a lot a whole lot that I wanted to cover today but I wanted to open it up for questions a little earlier because I know there's enough variety in this audience that you guys probably have better questions than what I could think of up here so I wanted to cover some things like Ansible and Packer for setting up things like AMIs and Amazon or images in digital ocean images for virtual box one cool thing that we have going on where I'm working now is I have one Ansible playbook that has like 15 roles or something and we use that same playbook to set up a virtual box and I can use it we don't yet but I can use it to make a VMware image and basically have the same Ansible stuff set up to make a pre pre-made box to put on to Amazon or your local host or wherever you need to to run your entire application within a few seconds so start up instead of having to install Linux and then run Ansible on it and that takes like seven minutes and who has seven minutes Ansible also works very well with Docker I know some people see Docker and they say oh I don't have to do any of that system administration stuff it's like no you still have to do a lot of that with Docker and Ansible can help it helps you get things set up and it helps you move around Docker containers and Ansible works great with Docker there's some integration already and it's being improved every day as Docker is getting closer to a 1.0 release I think I personally have done very little with Docker but from what I've done I see the power and I think that that's where things are moving towards so tool like Ansible will evolve with it and become key in infrastructures that are based on containers Ansible also has deep integration with Amazon, DigitalOcean, Linode, Rackspace pretty much any cloud provider including ones that are self-hosted Ansible already has modules that will provision servers will use dynamic inventory so you're not sitting there defining servers but it will call an API grab the list of servers out of it put them into groups and things and then you'll be able to have the servers provisioned automatically helping with your auto-scaling and then even if you're not doing auto-scaling if you just want to set up a new server it's nice to have dynamic inventory so you can just through Ansible add a server in your variable file and then it will provision it set it up get it in your load balance do whatever it needs to and also there's at least five, six hundred things that I couldn't cover today and I couldn't cover if I had a full day and even at AnsibleFest they couldn't cover about more than like 10% of this but there's a lot there's a lot that Ansible has out of the box already and a lot of cool stuff that's in the works to the point where I have not had a situation yet where I have not been able to do something inside of Ansible that I've needed to do in my infrastructure and I have to say once I got up and running once I got everything in my inventory for server check-in I have not logged into one of my server check-in servers for three or four months now I don't need to and it's very easy to get everything going especially if you have simpler servers simpler services or infrastructure that has you know different applications on different servers so there's a ton of resources out there besides this talk there's great documentation I think in the Drupal community we have amazing documentation but if you go out and read the Ansible box you might be ashamed they have really well written documentation good example for our community to pick up most of their documentation starts with a guide of how to do something and then it gives you all the details about here's the different things here's the different modules you can use but it's all organized really well searchable very easy to read and there's already over I think 700 different people that have contributed to the documentation but it looks like it was written by one person so they're doing a great job they have a very vibrant IRC channel Ansible there's usually seven to eight hundred people in there and that's been rising every month so if you ever have any question no matter how ridiculous you'll probably have an answer within a few minutes I've had some interesting questions and it's like nobody's going to answer this and then somebody has the exact question or the exact answer in a gist somewhere they just post it to me and then I know there's also a Google group mailing list there's one for the Ansible project if you want to get involved with it there's also one for the development so if you're helping develop in Python or if you're just helping with docs or things like that of course my book which is being written as we speak and has taken a short hiatus in preparation for this presentation but it's being being written I hope to be able to take somebody who's used to either basic puppet and chef or shell scripting or even manual provisioning and take you from there to fully managing your infrastructure through Ansible probably by a chapter three or four so finally there's Ansible Weekly which is a really good newsletter that has some great articles great videos great discussions and that is that comes out every Friday I think one just came out today so sign up for that if you're interested and I have three takeaways one is please go download Ansible it's really easy to install especially if you have a Mac or Linux if you have windows teeny tiny bit harder but it's more motivation to switch to Mac then after that go ahead and take a server that you have and write one task for it run that task using the Ansible playbook command it's not very hard at all I think for most people in this room we could probably get it done in 10 to 20 minutes from the time that you install Ansible and that's powerful you don't have to do extra steps I know the first time I started using puppet it took me three or four hours before I was running anything on a server and I was with a fresh brand new server now it's you know it might be quicker if you know what you're doing but that was the first time I'd ever started reading puppet docs and it's powerful to be able to pick something up and start running with it right away so and then finally buy my book please so I want to open it up for questions I basically covered the basics of here's a playbook here's what you do run it and how to describe your infrastructure but I know a lot of people here have different questions I've since writing this book I've been getting so many different kinds of awesome questions that have helped me and them so so I bought the book thanks I was I was aware of Ansible but I was always thinking of Ansible and the as as strictly in the the server config space so we're using Chef and my friends are using Ansible so I figured it was just a matter of time but when I you showed us here wrapping up a Drush site install and Ansible well that's not really server config anymore we're talking about actually build automation yes and so we do build automation in Fing right now can I can I think about like rewriting our Fing and Ansible and we're going to find limitations in terms of like the flex more is there more flexibility in Fing in terms of during the stuff or yes that's a very good question and that comes in with the don't use it as a golden hammer Ansible is it you could do everything you can do in Fing and Ansible but Fing is actually really good for PHP deployment so we still use Fing where I work for parts of it and we use Ansible for other parts of it usually more of the server config goes into Ansible and more of the PHP stuff doing different Drush interaction goes into Fing but I would say try it out see see which things are better suited to Ansible because Fing is it feels very Java like to me and Ansible feels more Drupal like where it's like get it done in the simplest way possible so Fing has some really nice features and but it can be verbose and it can be a little bit obtuse I think so things that are better suited to Fing keep them in Fing and especially if you have it working leave it in Fing just use Ansible to call Fing that's it yeah verbose and obtuse they do seem appropriate for that but it works yeah it's good stuff it's great it's great and Ansible is not made to be a build system or anything like that so I wouldn't consider it using it to replace Fing by any means but some parts of Fing I would but awesome this was really really valuable presentation thank you thank you so Ansible seems pretty awesome small disclaimer I do work for Xface but hey we're awesome too so I've I'm more familiar with Puppet and one of the Puppet's big things is getting away from SSH in a for loop and idempotency and things like that how does Ansible deal with that because if you're just writing like shell scripts and things like that are the modules that Ansible creates idempotent yes I actually since I didn't since I had this on the mirroring I didn't have my presenter note to mention that because every time I've practiced this presentation I forget to talk about idempotence idempotence is when you do something twice it's a mathematical concept if you run a function twice it does the exact same thing every time if you run it 500 times same result so with Ansible and with Puppet and Chef and pretty much every configuration management system the idea is you give it a final state and then you run it and then what should end up happening is your server is in that state at the end of it and then if you run it again it's still in that state so you could run it continuously and never have an issue so Ansible every module built into Ansible is idempotent by default so that service module and when I ran that demo the second time it ran through and said okay 56 or whatever it was changed equals zero so every time you run it it'll be the same result and it'll tell you if anything changed and Ansible uses SSH as a transport it doesn't run commands through SSH so I know one time I saw a admin doing a deployment where he had eight terminal windows open and he had some little utility that would chain put his command over eight terminal windows now I'm younger so I don't know why that is so enticing but I guess in the old days or nowadays doing that was powerful but Ansible doesn't do that it doesn't just like log into eight servers and then do one on one on one it transports it takes the module the tasks that you build puts it into a small python module sends it to the server through SSH and then it runs it on the server then the server reports back through JSON to Ansible good or bad or whatever so that's powerful because you can write modules in any language you want so you can use PHP to make Ansible modules all it has to do is report back some JSON like here's the error or here's the success did it change or not and it's very simple the API for it if you're going to contribute it to Ansible core you have to write it in Python but Python's not too difficult so just delete all your semicolons and you'll be fine wait is that Python or I'm confusing it that's Python and brackets yes yeah so so anyway and then you had did you have another question about that slightly related since I started working at Ransack space I was introduced to Ansible and Ransack is the tool that we're using internally it's really neat to see that Ransack uses the Ansible API as well as the Ransack space API to see like gather information about customers and Ansible can also interact with the Ransack space API for customers on your end and we can help you you know manage your servers through Ansible had a question there but I forgot it so I'll come back yeah no Ransack space had a couple really good presentations at AnsibleFest if you're interested I encourage you to go there the slides are somewhere online I don't remember exactly we're just search AnsibleFest Ransack space you'll find it I want to applaud you for your use of Postgre and Nginx I don't think enough people use a very solid software foundation much better than Apache and MySQL but anyway and my question actually is one can Ansible deploy through an SSH proxy I'm not too sure but I would presume is it using just SSH protocol basically yeah you can write an SSH command so like everything we do there's a proxy server in the middle you have to go through first it should be able to I have not had a deal with that so don't take my word on it but if you have a problem with it pop on Ansible's IRC channel ask about it I would presume it could as long as as long as it follows SSH protocol you're going to be fine and there's also different like if you have some older servers too I forgot to mention Ansible interacts with SSH in different modes and it auto detects what kind of mode it needs to use for your servers if you have really ancient Red Hat 5 servers then it will switch down to a slower old school mode but if you have most modern servers it'll use control persist and some other little tricks to make the connections a lot quicker and it'll save one connection even though it's connecting a ton of times it'll use the one connection for all your commands so it's not making a ton of network connections either the other question I have is can Ansible do any form of like monitoring so like watch for something to change and then do something in response to that yeah and that was I think it might have been in that list way down if there's there's a few different ways one is there's wait for wait underscore four and you can wait for a time limit so wait 60 seconds for something restart if you ever work with Java applications a lot of them are so sluggishly starting up you can wait for that way you can also wait for a port to be available so like let's say you're restarting the SSH demon you can wait until port 22 is available again then it's like okay now I know then you can continue on and you can also register variables so like if you run a Drush command you can register a variable with the command's output and check the output and if the output has a certain word do something else that kind of stuff so there's a lot of different ways to interact with the results of some other command thank you you're welcome thanks this was a great summary of Ansible I've spent about an afternoon worth of time with Ansible and also with SaltStack and based on my experience and also your description of them it's hard to see much difference especially since SaltStack can run agentless mode so I'm wondering how much time you've spent with SaltStack to decide that you prefer Ansible if you have any other comments on the the differences I spent when I first found out about Ansible I was looking into what's better than Puppeter Chef at that point and I found Salt at that time so I I tried them both out and at that point Salt Salt required the zero MQ or is that what it's requiring? Yeah so it required that running on the server at that point so my my thinking was kind of soured by that taste but now Salt is if I were starting now it would be a hard decision between Salt and Ansible because Salt is actually slightly faster for some things but to my eye what I've seen so far it seems like Ansible has a little bit more community a little bit more more widespread support in terms of if I want to do something Ansible already has something to do that whereas Salt has been slightly less like that for me but if you're using Salt I say go for it because it I think there's space for more than one as we know Puppeter and Chef have been existing since 2005 and nine and they're still going strong so but I personally enjoy using Ansible a lot Salt is very much the same Sure one more question if I can it seems like the Ansible actions run synchronously is there an option to designate certain tasks to be run asynchronously in a way yes if you have a playbook you can you can have you can set how many servers at a time it wants to run the command on so that's one way that you can have if you have a ton of servers I'm thinking more about commands on one particular task in particular there are ways to do that but it's not the norm in Ansible normally Ansible's set up to do a list so you start at one and end at 10 because a lot of the things that Ansible does are dependent on the task completion sure so it's that's not the norm for Ansible okay thank you so back to me if I you say that Ansible is not really configuration management but it does allow for templating and things like that if I already have a puppet infrastructure set up and I already have my machine set up to be at the end state where does Ansible fit into there so in that kind of situation A you don't need to start using Ansible right away or anything like that yeah you might never use Ansible but if you want to start using it Ansible can help you with in tandem with maybe Jenkins or something to do deployments to that infrastructure where you are taking servers out of a load balancer running something on it you know installing an update to Drupal or whatever and then taking them back into the load balancer that kind of stuff is where Ansible really shines and is simple as opposed to some other tools like has anybody here used funk or Capistrano or something like that okay so a few people have yeah so so those tools are built just for that but Ansible can do that stuff too and it's the nicest thing is if you have your infrastructure described in a way that Ansible can pick it up either using dynamic inventory or just handwritten inventories you can you can start off doing like just a deployment type thing and then as time goes on if you want you can use it more for configuration or you know use it just to do some deployment type stuff and then go back to Puppet for the stuff you already have written in Puppet one thing I did notice when I was looking at the Ansible website is as far as Faxco it's when you're getting your initial inventory and information about the boxes if you already have Factor or Chefs Ohio I think it is it'll grab those Fax and use them in Ansible type books which I thought was really cool yeah it is yeah Ansible the guy who wrote Ansible Michael Dehan I think it's Dehan hopefully he doesn't kill me for saying his name wrong he worked for Puppet and Red Hat was it Puppet? I think it was Puppet he worked for them for a long time and he he was the main guy behind Funk and he FUNC not FUNK he's not that old but he he saw the problems people were having with infrastructure orchestration that's the the keyword for Ansible is orchestrating your infrastructure not just managing your configuration and so that's that's how he developed Ansible he wanted a tool that could do everything pretty well if not the best and do it in a in a little bit more modern way using YAML and GINJA 2 for the to make it easier for the end users to get it set up and everything so any other all right thank you and also I know that there's the closing session coming up but could everybody here please pick up any trash you see since this is the last session that'll help the organizers get things going a little faster so thank you again