9 ms·

On Ansible

128 points by _pius 13y ago

nwj 13y ago
We've also been using Ansible where I work and it's great. Chef/Puppet are probably more powerful, but I also found them more complicated to setup and use. Ansible seems to hit this sweet spot between easy of use, flexibility, and functionality that is really great for people or organizations that are managing modest numbers of servers. Cases where Chef/Puppet would be overkill.
- julnepht 13y ago
  That is the feeling I get from Ansible, its seems easier to get up and running but I wonder if it is more powerful than Puppet as you expand beyond the initial phase. I have been implementing Puppet at work and the ramp up was hardeous but I am now at a state where I can do powerful things with Puppet(ENC, Hiera, Dashboard).
rvanniekerk 13y ago
Can't say enough good things about Ansible. Just finished migrating 90% of our provisioning scripts away from Chef (they were due an overhaul anyways) to Ansible. It feels liberating to say the least and knowing that I no longer have to train people to use Chef or worry about my remote Chef server going down unexpectedly is a big benefit. Ansible: - faster - drop-dead simple syntax (easily extendable with modules) - did I mention modules? There are a TON. - readable playbooks - just plain fun
WestCoastJustin 13y ago
Anyone wanting to play around with Ansible should really check out Vagrant too. Quickly spin up Vagrant instances (VirtualBox, etc VMs) in seconds to test things. I use Vagrant heavily to test puppet manifests/modules, and have thrown together several screenscasts about Vagrant @ http://sysadmincasts.com/episodes/4-vagrant http://sysadmincasts.com/episodes/4-vagrant and one about Learning Puppet with Vagrant @ http://sysadmincasts.com/episodes/8-learning-puppet-with-vagrant http://sysadmincasts.com/episodes/8-learning-puppet-with-vag... but you can do the same things with Ansible. See Vagrant & Ansible docs @ http://docs.vagrantup.com/v2/provisioning/ansible.html http://docs.vagrantup.com/v2/provisioning/ansible.html
- bscofield 13y ago
  (Post author here) Absolutely -- I developed my entire setup in Vagrant. It was fantastic, especially in the early stages where I'd just share my playbook folder into the guest machine and run them locally.
- jwn 13y ago
  Agreed, I set up our dev team on Vagrant+Ansible+Github to ensure that we all have identical development deployment environments. Now pushing out configuration changes is as simple as doing a git push and telling everyone to pull and re-deploy their dev hosts.
benatkin 13y ago
Ansible still has this problem: http://david.heinemeierhansson.com/posts/6-why-theres-no-rails-inc http://david.heinemeierhansson.com/posts/6-why-theres-no-rai... It's also GPLv3. The WordPress community (oops nevermind, they aren't in the community because Matt Mullenweg says they aren't </s>) has plenty of problems with GPLv2. The GPLv3 is even longer and has more possible interpretations. I'm sure someone could interpret the GPLv3 such that YAML playbooks are GPLv3.
- deckiedan 13y ago
  YAML playbooks can be under whatever licence you choose. They aren't /linked/ in to or in any way part of ansible. They are completely input to ansible. Saying that playbooks would be 'infected' or something is absurd. It would be like saying if I use GNU tar to compress a file, that file is now GPL. And, after all that, even if your playbooks were GPL, there is no reason at all that you'd have to release them. It's perfectly fine to have internal non-released mods to GPL software.
  - benatkin 13y ago
    Most of the talk about linking is gone from the GPLv3. It's mentioned multiple times in the GPLv2 [1] but only once in the GPLv3 [2]. This to me means that it doesn't matter much whether it's a compiler or an interpreter. As for your tar example, the input to tar, to me, is pretty clearly data. The YAML from ansible, on the other hand, straddles the line between code and data. If I consider it to be code, though, in most cases it calls out to Ansible's GPLed modules. If it was Python doing this it would be pretty clear to me that it would fall under the GPL. I'm not sure I see the distinction between a sequence of function calls in Python and a sequence of tasks in YAML for ansible. When you flatly state that "YAML playbooks can be under whatever license you choose" you are doing something common in the GPL world, which is making a specific interpretation for the GPL for a specific project. This has been done with WordPress. The distinction between JavaScript, CSS, and PHP code has been made by the leaders of the WordPress project. It doesn't come directly from the GPL. I don't like this at all. I think if they want specific rules they should state them in the license, and not do some hand waving so it looks like they're just using a standard license. [1] http://www.gnu.org/licenses/lgpl-2.1.html http://www.gnu.org/licenses/lgpl-2.1.html [2] http://www.gnu.org/licenses/gpl.html http://www.gnu.org/licenses/gpl.html
andyl 13y ago
I converted from Puppet to Ansible - best decision ever. Much easier to maintain - much easier to train others.
nitins 13y ago
Yes, found Ansible to be really simple compared to salt stack which I used earlier.
- est 13y ago
  Here's a good post on Ansible vs Saltstack http://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/ http://missingm.co/2013/06/ansible-and-salt-a-detailed-compa...
- bastop 13y ago
  I'm finding quite the opposite. IMHO saltstack, more importantly sls files are insanely simple and clear whereas ansible playbooks appear very "busy" for lack of a better term. It's likely a personal preference in my case but I've found salt to have a relatively clean interface and to be very readable even when coupled with templating.
  - mpdehaan2 13y ago
    Ansible is generally designed around being maximally auditable. For instance, an IT manager said he can write a list of tasks and take them to someone and it's easy for him, not knowing Ansible, to see what is going on. That's important to us because they are quick to prototype and don't end up looking like Perl. Generally we discourage templating except in playbooks, because we don't like the idea of playbooks turning into code, and I don't like the idea of mixing a lot of Jinja2 syntax along with YAML syntax at the same time. Playbooks can be broken up into small files if they get long. This also keeps them machine readable, so if you wanted to later write a script to analyze them, you could. So it's very important for us that our files are actually valid YAML. Because they are, they aren't a description that gets compiled for one server at a time, but are instead a process, so it's easy to have the steps on one server influence a server later on down the line. I'm not sure of an example of a 'busy' playbook you've seen, but I'd suspect it's probably just needing some whitespace in between lines. To me, while they may have taken some interesting choices here and there, I don't care for their format since it seems to have taken Puppet syntax and made it more obscure -- and the idea of mixing template loops and such in there and having two interlaced languages is too much.
bradhe 13y ago
Ansible is great, but I've just burned an entire day (well, half a day) fighting bugs in it after doing a pip install --upgrade. So IMHO: The model is sound but it's still really unstable.
- mpdehaan2 13y ago
  Hmm, that's interesting, and not something I hear often at all. What github bugs have you filed? Have you stopped by the mailing list to ask for help?
drsintoma 13y ago
the thing that keeps me away from ansible is the pricing model. I find 100$/year/server way too much. and nobody can ensure me that the OSS version is all I'll always need.
- andrewflnr 13y ago
  I find this a curious objection. Would you still have hesitated when, as was the case until very recently, there was only the OSS version?
  - drsintoma 13y ago
    Probably I wouldn't have. I now they have to monetize the product, and for a software with simplicity as the strongest selling point, doing it through consulting/support I guess would be a conflict of interests. But when I saw the prices I was a bit shocked, and made me doubt about the company's strategy in the long term.
    - mpdehaan2 13y ago
      Hey guys, I'd suggest you look at some competitors for pricing and come back with me, they aren't really that different. We're not going to be holding back on anything in Ansible, in fact, we're seeing several hundred contributors each month and are adding an average of 20 new modules to core each release. This release also adds role dependencies and lots of nice new performance features. For those looking for better solutions to things from proprietary software vendors, this provides a lot of options. If you're looking to not need those kind of features, Ansible is still there. One thing we're not going to do is keep making Ansible more and more complicated over time -- there's a major focus on keeping it simple. When I started this project I said "if I can make a consultancy out of this I'm doing it wrong" :) Actually being a company is good for us -- it allows us to hire extra people to work on Ansible, and it's allowing us to do more for the community not less!
- Argorak 13y ago
  Thats quite interesting. A somewhat potent piece of hardware with basic administration and on-call-service can cost you ~200$ a month (Thats an EC2 large instance with one hour of an reasonably competent sysadmin). Thats ~2400$ a year. In the light of those numbers, I find 100$/year for a tool that eases your work with those expensive beasts reasonable.
mattjaynes 13y ago
Just finished writing a book where I compare the experience of using Puppet, Chef, Salt, and Ansible. I use each tool to build an identical system so you can get a sense of how each one approaches the same problem. The most valuable thing I got from that project was my introduction to Ansible. It was really a shining star in the pack. I have to give credit to its predecessors (CFEngine/Puppet/Chef) and its competitor Salt all for being great tools in their own right. But it is Ansible that has the power and simplicity to really take on the ultimate competitor: manual installs and hodge-podge shell scripts. Many of you would be shocked at how many tech companies still don't use any kind of configuration management (CM) tool. When you think about it, a company's server setup is essentially the foundational "app" that the actual business app runs on. So, not using a CM tool is kinda like having no tests and no version control for your most important software. Sound insane? It is. Most developers would laugh at a company that had zero tests and didn't version control or even backup their code. But that's exactly what many companies do with their systems. Yet, for many businesses, they don't realize the astronomical risks and costs of this neglect. At a recent client job, the former system administrator set up all their servers manually and left ZERO documentation. I had to spend a few weeks devining what he did and try to capture everything into a CM tool (Chef in this case). Not one week after I finished doing that, one of their key servers inexplicably failed. Fortunately, I had done the work needed and they were able to bring up a replacement within minutes. Had that work not been done, the company would have been severly crippled and might have even died due to the days of downtime that would have been inevitable. That's just a tiny example. The cost savings for a business are huge when the team uses a CM tool. When it takes a couple minutes to bring up a new server instead of hours/days/weeks, that's a huge savings (assuming your engineers cost greater than $0). With Ansible, there is no more an excuse for not using a CM tool. It's so simple that it can actually be easier than doing a manual install or writing a shell script. Some of the more complex CM tools take difficult weeks to learn, but with Ansible you can be up and running with confidence in a couple hours. Not only that, but Ansible gives you robust remote execution capabilities right out of the box along with a lot of other cool stuff. Shameless plug: If you want to see Ansible in action and how it compares to the other CM tools, check out my book. Just barely launched a few days ago: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-ansible.html http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...
mbenjaminsmith 13y ago
Hope no one minds me sharing this here: http://lattejed.com/first-five-and-a-half-minutes-on-a-server-with-ansible http://lattejed.com/first-five-and-a-half-minutes-on-a-serve... I'm not surprised most of the comments are positive. Ansible is a great tool. I recently started using it and would recommend it without qualification. The linked post contains a simple Ansible playbook for hardening a virgin (Linux, Ubuntu in this case) install as well as how to install Ansible (on OS X) and some of the basics.
- harrytuttle 13y ago
  Great notes - thanks for posting. I do pretty much the same (literally!) but I don't set up unattended security updates after Ubuntu fucked up MySQL a couple of years back which took us down. We stage everything now using apt-offline. http://apt-offline.alioth.debian.org/ http://apt-offline.alioth.debian.org/
- joeyh 13y ago
  I was a bit put off by the very first thing being a download of unverified source code over a non-encrypted protocol, which was then run as root. Later worked out that you only did that on the ansible server, not on every server you deploy, but still. The use of files in /tmp in the ansible rules is also asking for trouble (unless ansible goes to lengths to securely write to files in /tmp without eg following symlinks). debconf-set-selections can read from stdin, or you can put the file somewhere better.
  - mpdehaan2 13y ago
    Just to be clear -- by "unverified source code", you mean a github checkout. You can definitely clone github by HTTPs if you like. Ansible does in fact use your home directory for writing files by default and the locations are not predictable. There are also OS packages available.
smoyer 13y ago
I had a very similar "epiphany" when I was looking choosing a CM tool (see http://www.selesy.com/news/14 http://www.selesy.com/news/14). I'd add one reason to your list (and it's a biggie for me) - You don't have to install a client on every machine. Since I'm already using public/private keys for access, I'm ready to provision new machines immediately. Recently I've been pairing Vagrant and Ansible so that developers' workstations are provisioned by the same playbooks that build the production infrastructure. This is a huge win as there's no variation in how someone set up their machine. My next step is to use Cobbler to actually manage booting new machines and adding them to specific profiles (the phase prior to Ansible's CM role). In essence, cobbler provides the hosts file for Ansible. Nice article and please share tips and tricks as you go!
- bscofield 13y ago
  (Post author here) Re: agents -- yep. I should've called that out explicitly, as it further supports the provisioning vs. ongoing factor in my decision-making.
pjan 13y ago
If you're new to ansible, I just released a quite extensive set of roles (basic server setup, security hardening, firewall, mailserver, nginx from source, oracle jdk, scala, monit, ...) on github [shameless plug]. I was missing these when I started out, so I hope it will help others. There's even a complete personal cloudbox setup (including an extensive idiot-proof tutorial) based on this included, as well as a vagrantbox to test the others. https://github.com/pjan/the-ansibles https://github.com/pjan/the-ansibles
- mpdehaan2 13y ago
  Thanks for sharing! Looks like you can eliminate the playbooks in the 'roles' directory with all of the manual includes if you've moved over to roles.
  - pjan 13y ago
    Hi Michael. You're welcome. Tried working with roles, but it didn't allow me the fine-grained control I was looking for, at least not at the scale I'm currently using them. I like to have the ability of just adding a new 'role' (wrong official terminology, but applicable to this use) to a machine (so adding it in a [x:children] in my examples here) without having to create a specific/exceptional role for it, yet also keep track of it (rather than just pointing a role to a machine without an audit trail). - If this makes any sense (Happy to discuss on another channel if you're willing to :-))
sohooo 13y ago
The widespread use of Puppet also has some benefits: - lots of documentation - Foreman ( http://theforeman.org/ http://theforeman.org/ , backed by Redhat) as a great alternative to Puppet Enterprise - projects like GitHub's Boxen ( http://boxen.github.com/ http://boxen.github.com/ ) to bootstrap your devel machine - a large repository of modules available: https://forge.puppetlabs.com/ https://forge.puppetlabs.com/ - a couple of books, training, conference, if you like those things However, I'm very aware of those ugly warts, so there's a lot of potential for a successor.
- mpdehaan2 13y ago
  Yeah, to us it's not just a configuration focus. One of the focuses in creating Ansible was to have an easy-to-use system where it was just as easy to push apps, so you don't have to strap things like Fabric and Capistrano on top. Another major example is how easy it is to do zero-downtime rolling upgrades on top, from the core language, without having to provide any glue on top to get there -- so it can easily say "target 50 out of my 500 servers at once", and work with load balancing and outage windows to walk across your infrastructure and upgrade production applications.
karlmdavis 13y ago
I've been using Puppet on a project for a few months now, and I'm definitely not 100% on it: it's... very rough around the edges, and far more fussy than it should be. But it does have one major thing going for it: wide OS support, specifically including Windows. Ansible doesn't seem to have this, which makes it a non-starter for me. The project mentioned above that I'm working on is a build farm, and that farm includes Ubuntu, RHEL, and Windows boxes. Ansible also doesn't look like it was designed to shield Playbook writers from the underlying OS much, either. At least, it doesn't seem to have any analogue to Puppet's OS-independent `package` resource; Playbooks all call yum or apt specifically. That's a shame, because it does look a lot simpler to get up & running with. Learning Puppet and building up useful manifests for it has been a real slog.
- mpdehaan2 13y ago
  Actually ansible has quite a few abstractions available, namely you can use the 'group_by' module to dynamically select machines by OS, and 'roles' which allow abstracting away behavior from applying state. The 'when' conditional can also be used for OS variance. One thing you may want to look at are the playbooks that we use to set up AWX, our UI, which works on both CentOS and Ubuntu and has some very different steps in place. You can also see some examples in github.com/ansible/ansible-examples We don't believe in hiding too many OS details from you -- for instance, not only do package names vary between distributions but think about how Apache is managed so very differently between Ubuntu and CentOS -- in fact, we've observed in many cases that trying to pave over those things can make content a lot harder to work on. Generally people know what infrastructure they are running on and I think it's best when you take advantage of that, though you can easily have certain steps (see the 'when' conditional) that apply to specific OSes. Another thing Ansible does is make it easy to do conditionals at runtime, such as "if this file is present, then do this", etc.
  - karlmdavis 13y ago
    Sorry, but I'm not finding a link to those playbooks anywhere in the Ansible docs. The only cross-platform example I could find in the examples was the riak one [1]. Based on that example and the modules you mentioned, I'm guessing that the only real mechanism for multi-OS playbooks are separate sets of YAML files for each OS? If so, that's not exactly a great abstraction, though I'll agree it is workable. Still seems to be leaving Windows out in the cold altogether, as well, which is a show-stopper for my mixed environments. [1] https://github.com/ansible/ansible-examples/tree/master/riak https://github.com/ansible/ansible-examples/tree/master/riak
jonpaul 13y ago
Shameless plug (just wrote it yesterday): Getting Started with Ansible on Digital Ocean - http://procbits.com/2013/09/08/getting-started-with-ansible-digital-ocean http://procbits.com/2013/09/08/getting-started-with-ansible-... (instructions will work with just about any remote Linux server)
bradleyland 13y ago
Sprinkle deserves a mention if you're looking for to visioning only. It's Ruby, so it may be more appealing for Rubyists. * DSL and wrappers for common shell tasks * Uses Capistrano, which you're probably already familiar with * Uses eRB for templates (more familiar friends) * Does not require Ruby on the server * Simple application structure (easy to extend) https://github.com/sprinkle-tool/sprinkle https://github.com/sprinkle-tool/sprinkle

128 points by _pius 13y ago

nwj 13y ago

We've also been using Ansible where I work and it's great. Chef/Puppet are probably more powerful, but I also found them more complicated to setup and use. Ansible seems to hit this sweet spot between easy of use, flexibility, and functionality that is really great for people or organizations that are managing modest numbers of servers. Cases where Chef/Puppet would be overkill.

julnepht 13y ago
That is the feeling I get from Ansible, its seems easier to get up and running but I wonder if it is more powerful than Puppet as you expand beyond the initial phase. I have been implementing Puppet at work and the ramp up was hardeous but I am now at a state where I can do powerful things with Puppet(ENC, Hiera, Dashboard).

rvanniekerk 13y ago

Can't say enough good things about Ansible. Just finished migrating 90% of our provisioning scripts away from Chef (they were due an overhaul anyways) to Ansible. It feels liberating to say the least and knowing that I no longer have to train people to use Chef or worry about my remote Chef server going down unexpectedly is a big benefit. Ansible: - faster - drop-dead simple syntax (easily extendable with modules) - did I mention modules? There are a TON. - readable playbooks - just plain fun

WestCoastJustin 13y ago

Anyone wanting to play around with Ansible should really check out Vagrant too. Quickly spin up Vagrant instances (VirtualBox, etc VMs) in seconds to test things. I use Vagrant heavily to test puppet manifests/modules, and have thrown together several screenscasts about Vagrant @ http://sysadmincasts.com/episodes/4-vagrant http://sysadmincasts.com/episodes/4-vagrant and one about Learning Puppet with Vagrant @ http://sysadmincasts.com/episodes/8-learning-puppet-with-vagrant http://sysadmincasts.com/episodes/8-learning-puppet-with-vag... but you can do the same things with Ansible. See Vagrant & Ansible docs @ http://docs.vagrantup.com/v2/provisioning/ansible.html http://docs.vagrantup.com/v2/provisioning/ansible.html

bscofield 13y ago
(Post author here) Absolutely -- I developed my entire setup in Vagrant. It was fantastic, especially in the early stages where I'd just share my playbook folder into the guest machine and run them locally.
jwn 13y ago
Agreed, I set up our dev team on Vagrant+Ansible+Github to ensure that we all have identical development deployment environments. Now pushing out configuration changes is as simple as doing a git push and telling everyone to pull and re-deploy their dev hosts.

benatkin 13y ago

Ansible still has this problem: http://david.heinemeierhansson.com/posts/6-why-theres-no-rails-inc http://david.heinemeierhansson.com/posts/6-why-theres-no-rai... It's also GPLv3. The WordPress community (oops nevermind, they aren't in the community because Matt Mullenweg says they aren't </s>) has plenty of problems with GPLv2. The GPLv3 is even longer and has more possible interpretations. I'm sure someone could interpret the GPLv3 such that YAML playbooks are GPLv3.

deckiedan 13y ago
YAML playbooks can be under whatever licence you choose. They aren't /linked/ in to or in any way part of ansible. They are completely input to ansible. Saying that playbooks would be 'infected' or something is absurd. It would be like saying if I use GNU tar to compress a file, that file is now GPL. And, after all that, even if your playbooks were GPL, there is no reason at all that you'd have to release them. It's perfectly fine to have internal non-released mods to GPL software.
- benatkin 13y ago
  Most of the talk about linking is gone from the GPLv3. It's mentioned multiple times in the GPLv2 [1] but only once in the GPLv3 [2]. This to me means that it doesn't matter much whether it's a compiler or an interpreter. As for your tar example, the input to tar, to me, is pretty clearly data. The YAML from ansible, on the other hand, straddles the line between code and data. If I consider it to be code, though, in most cases it calls out to Ansible's GPLed modules. If it was Python doing this it would be pretty clear to me that it would fall under the GPL. I'm not sure I see the distinction between a sequence of function calls in Python and a sequence of tasks in YAML for ansible. When you flatly state that "YAML playbooks can be under whatever license you choose" you are doing something common in the GPL world, which is making a specific interpretation for the GPL for a specific project. This has been done with WordPress. The distinction between JavaScript, CSS, and PHP code has been made by the leaders of the WordPress project. It doesn't come directly from the GPL. I don't like this at all. I think if they want specific rules they should state them in the license, and not do some hand waving so it looks like they're just using a standard license. [1] http://www.gnu.org/licenses/lgpl-2.1.html http://www.gnu.org/licenses/lgpl-2.1.html [2] http://www.gnu.org/licenses/gpl.html http://www.gnu.org/licenses/gpl.html

andyl 13y ago

I converted from Puppet to Ansible - best decision ever. Much easier to maintain - much easier to train others.

nitins 13y ago

Yes, found Ansible to be really simple compared to salt stack which I used earlier.

est 13y ago
Here's a good post on Ansible vs Saltstack http://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/ http://missingm.co/2013/06/ansible-and-salt-a-detailed-compa...
bastop 13y ago
I'm finding quite the opposite. IMHO saltstack, more importantly sls files are insanely simple and clear whereas ansible playbooks appear very "busy" for lack of a better term. It's likely a personal preference in my case but I've found salt to have a relatively clean interface and to be very readable even when coupled with templating.
- mpdehaan2 13y ago
  Ansible is generally designed around being maximally auditable. For instance, an IT manager said he can write a list of tasks and take them to someone and it's easy for him, not knowing Ansible, to see what is going on. That's important to us because they are quick to prototype and don't end up looking like Perl. Generally we discourage templating except in playbooks, because we don't like the idea of playbooks turning into code, and I don't like the idea of mixing a lot of Jinja2 syntax along with YAML syntax at the same time. Playbooks can be broken up into small files if they get long. This also keeps them machine readable, so if you wanted to later write a script to analyze them, you could. So it's very important for us that our files are actually valid YAML. Because they are, they aren't a description that gets compiled for one server at a time, but are instead a process, so it's easy to have the steps on one server influence a server later on down the line. I'm not sure of an example of a 'busy' playbook you've seen, but I'd suspect it's probably just needing some whitespace in between lines. To me, while they may have taken some interesting choices here and there, I don't care for their format since it seems to have taken Puppet syntax and made it more obscure -- and the idea of mixing template loops and such in there and having two interlaced languages is too much.

bradhe 13y ago

Ansible is great, but I've just burned an entire day (well, half a day) fighting bugs in it after doing a pip install --upgrade. So IMHO: The model is sound but it's still really unstable.

mpdehaan2 13y ago
Hmm, that's interesting, and not something I hear often at all. What github bugs have you filed? Have you stopped by the mailing list to ask for help?

drsintoma 13y ago

the thing that keeps me away from ansible is the pricing model. I find 100$/year/server way too much. and nobody can ensure me that the OSS version is all I'll always need.

andrewflnr 13y ago
I find this a curious objection. Would you still have hesitated when, as was the case until very recently, there was only the OSS version?
- drsintoma 13y ago
  Probably I wouldn't have. I now they have to monetize the product, and for a software with simplicity as the strongest selling point, doing it through consulting/support I guess would be a conflict of interests. But when I saw the prices I was a bit shocked, and made me doubt about the company's strategy in the long term.
  - mpdehaan2 13y ago
    Hey guys, I'd suggest you look at some competitors for pricing and come back with me, they aren't really that different. We're not going to be holding back on anything in Ansible, in fact, we're seeing several hundred contributors each month and are adding an average of 20 new modules to core each release. This release also adds role dependencies and lots of nice new performance features. For those looking for better solutions to things from proprietary software vendors, this provides a lot of options. If you're looking to not need those kind of features, Ansible is still there. One thing we're not going to do is keep making Ansible more and more complicated over time -- there's a major focus on keeping it simple. When I started this project I said "if I can make a consultancy out of this I'm doing it wrong" :) Actually being a company is good for us -- it allows us to hire extra people to work on Ansible, and it's allowing us to do more for the community not less!
Argorak 13y ago
Thats quite interesting. A somewhat potent piece of hardware with basic administration and on-call-service can cost you ~200$ a month (Thats an EC2 large instance with one hour of an reasonably competent sysadmin). Thats ~2400$ a year. In the light of those numbers, I find 100$/year for a tool that eases your work with those expensive beasts reasonable.

mattjaynes 13y ago

Just finished writing a book where I compare the experience of using Puppet, Chef, Salt, and Ansible. I use each tool to build an identical system so you can get a sense of how each one approaches the same problem. The most valuable thing I got from that project was my introduction to Ansible. It was really a shining star in the pack. I have to give credit to its predecessors (CFEngine/Puppet/Chef) and its competitor Salt all for being great tools in their own right. But it is Ansible that has the power and simplicity to really take on the ultimate competitor: manual installs and hodge-podge shell scripts. Many of you would be shocked at how many tech companies still don't use any kind of configuration management (CM) tool. When you think about it, a company's server setup is essentially the foundational "app" that the actual business app runs on. So, not using a CM tool is kinda like having no tests and no version control for your most important software. Sound insane? It is. Most developers would laugh at a company that had zero tests and didn't version control or even backup their code. But that's exactly what many companies do with their systems. Yet, for many businesses, they don't realize the astronomical risks and costs of this neglect. At a recent client job, the former system administrator set up all their servers manually and left ZERO documentation. I had to spend a few weeks devining what he did and try to capture everything into a CM tool (Chef in this case). Not one week after I finished doing that, one of their key servers inexplicably failed. Fortunately, I had done the work needed and they were able to bring up a replacement within minutes. Had that work not been done, the company would have been severly crippled and might have even died due to the days of downtime that would have been inevitable. That's just a tiny example. The cost savings for a business are huge when the team uses a CM tool. When it takes a couple minutes to bring up a new server instead of hours/days/weeks, that's a huge savings (assuming your engineers cost greater than $0). With Ansible, there is no more an excuse for not using a CM tool. It's so simple that it can actually be easier than doing a manual install or writing a shell script. Some of the more complex CM tools take difficult weeks to learn, but with Ansible you can be up and running with confidence in a couple hours. Not only that, but Ansible gives you robust remote execution capabilities right out of the box along with a lot of other cool stuff. Shameless plug: If you want to see Ansible in action and how it compares to the other CM tools, check out my book. Just barely launched a few days ago: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-ansible.html http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

mbenjaminsmith 13y ago

Hope no one minds me sharing this here: http://lattejed.com/first-five-and-a-half-minutes-on-a-server-with-ansible http://lattejed.com/first-five-and-a-half-minutes-on-a-serve... I'm not surprised most of the comments are positive. Ansible is a great tool. I recently started using it and would recommend it without qualification. The linked post contains a simple Ansible playbook for hardening a virgin (Linux, Ubuntu in this case) install as well as how to install Ansible (on OS X) and some of the basics.

harrytuttle 13y ago
Great notes - thanks for posting. I do pretty much the same (literally!) but I don't set up unattended security updates after Ubuntu fucked up MySQL a couple of years back which took us down. We stage everything now using apt-offline. http://apt-offline.alioth.debian.org/ http://apt-offline.alioth.debian.org/
joeyh 13y ago
I was a bit put off by the very first thing being a download of unverified source code over a non-encrypted protocol, which was then run as root. Later worked out that you only did that on the ansible server, not on every server you deploy, but still. The use of files in /tmp in the ansible rules is also asking for trouble (unless ansible goes to lengths to securely write to files in /tmp without eg following symlinks). debconf-set-selections can read from stdin, or you can put the file somewhere better.
- mpdehaan2 13y ago
  Just to be clear -- by "unverified source code", you mean a github checkout. You can definitely clone github by HTTPs if you like. Ansible does in fact use your home directory for writing files by default and the locations are not predictable. There are also OS packages available.

smoyer 13y ago

I had a very similar "epiphany" when I was looking choosing a CM tool (see http://www.selesy.com/news/14 http://www.selesy.com/news/14). I'd add one reason to your list (and it's a biggie for me) - You don't have to install a client on every machine. Since I'm already using public/private keys for access, I'm ready to provision new machines immediately. Recently I've been pairing Vagrant and Ansible so that developers' workstations are provisioned by the same playbooks that build the production infrastructure. This is a huge win as there's no variation in how someone set up their machine. My next step is to use Cobbler to actually manage booting new machines and adding them to specific profiles (the phase prior to Ansible's CM role). In essence, cobbler provides the hosts file for Ansible. Nice article and please share tips and tricks as you go!

bscofield 13y ago
(Post author here) Re: agents -- yep. I should've called that out explicitly, as it further supports the provisioning vs. ongoing factor in my decision-making.

pjan 13y ago

If you're new to ansible, I just released a quite extensive set of roles (basic server setup, security hardening, firewall, mailserver, nginx from source, oracle jdk, scala, monit, ...) on github [shameless plug]. I was missing these when I started out, so I hope it will help others. There's even a complete personal cloudbox setup (including an extensive idiot-proof tutorial) based on this included, as well as a vagrantbox to test the others. https://github.com/pjan/the-ansibles https://github.com/pjan/the-ansibles

mpdehaan2 13y ago
Thanks for sharing! Looks like you can eliminate the playbooks in the 'roles' directory with all of the manual includes if you've moved over to roles.
- pjan 13y ago
  Hi Michael. You're welcome. Tried working with roles, but it didn't allow me the fine-grained control I was looking for, at least not at the scale I'm currently using them. I like to have the ability of just adding a new 'role' (wrong official terminology, but applicable to this use) to a machine (so adding it in a [x:children] in my examples here) without having to create a specific/exceptional role for it, yet also keep track of it (rather than just pointing a role to a machine without an audit trail). - If this makes any sense (Happy to discuss on another channel if you're willing to :-))

sohooo 13y ago

The widespread use of Puppet also has some benefits: - lots of documentation - Foreman ( http://theforeman.org/ http://theforeman.org/ , backed by Redhat) as a great alternative to Puppet Enterprise - projects like GitHub's Boxen ( http://boxen.github.com/ http://boxen.github.com/ ) to bootstrap your devel machine - a large repository of modules available: https://forge.puppetlabs.com/ https://forge.puppetlabs.com/ - a couple of books, training, conference, if you like those things However, I'm very aware of those ugly warts, so there's a lot of potential for a successor.

mpdehaan2 13y ago
Yeah, to us it's not just a configuration focus. One of the focuses in creating Ansible was to have an easy-to-use system where it was just as easy to push apps, so you don't have to strap things like Fabric and Capistrano on top. Another major example is how easy it is to do zero-downtime rolling upgrades on top, from the core language, without having to provide any glue on top to get there -- so it can easily say "target 50 out of my 500 servers at once", and work with load balancing and outage windows to walk across your infrastructure and upgrade production applications.

karlmdavis 13y ago

I've been using Puppet on a project for a few months now, and I'm definitely not 100% on it: it's... very rough around the edges, and far more fussy than it should be. But it does have one major thing going for it: wide OS support, specifically including Windows. Ansible doesn't seem to have this, which makes it a non-starter for me. The project mentioned above that I'm working on is a build farm, and that farm includes Ubuntu, RHEL, and Windows boxes. Ansible also doesn't look like it was designed to shield Playbook writers from the underlying OS much, either. At least, it doesn't seem to have any analogue to Puppet's OS-independent `package` resource; Playbooks all call yum or apt specifically. That's a shame, because it does look a lot simpler to get up & running with. Learning Puppet and building up useful manifests for it has been a real slog.

mpdehaan2 13y ago
Actually ansible has quite a few abstractions available, namely you can use the 'group_by' module to dynamically select machines by OS, and 'roles' which allow abstracting away behavior from applying state. The 'when' conditional can also be used for OS variance. One thing you may want to look at are the playbooks that we use to set up AWX, our UI, which works on both CentOS and Ubuntu and has some very different steps in place. You can also see some examples in github.com/ansible/ansible-examples We don't believe in hiding too many OS details from you -- for instance, not only do package names vary between distributions but think about how Apache is managed so very differently between Ubuntu and CentOS -- in fact, we've observed in many cases that trying to pave over those things can make content a lot harder to work on. Generally people know what infrastructure they are running on and I think it's best when you take advantage of that, though you can easily have certain steps (see the 'when' conditional) that apply to specific OSes. Another thing Ansible does is make it easy to do conditionals at runtime, such as "if this file is present, then do this", etc.
- karlmdavis 13y ago
  Sorry, but I'm not finding a link to those playbooks anywhere in the Ansible docs. The only cross-platform example I could find in the examples was the riak one [1]. Based on that example and the modules you mentioned, I'm guessing that the only real mechanism for multi-OS playbooks are separate sets of YAML files for each OS? If so, that's not exactly a great abstraction, though I'll agree it is workable. Still seems to be leaving Windows out in the cold altogether, as well, which is a show-stopper for my mixed environments. [1] https://github.com/ansible/ansible-examples/tree/master/riak https://github.com/ansible/ansible-examples/tree/master/riak

jonpaul 13y ago

Shameless plug (just wrote it yesterday): Getting Started with Ansible on Digital Ocean - http://procbits.com/2013/09/08/getting-started-with-ansible-digital-ocean http://procbits.com/2013/09/08/getting-started-with-ansible-... (instructions will work with just about any remote Linux server)

bradleyland 13y ago

Sprinkle deserves a mention if you're looking for to visioning only. It's Ruby, so it may be more appealing for Rubyists. * DSL and wrappers for common shell tasks * Uses Capistrano, which you're probably already familiar with * Uses eRB for templates (more familiar friends) * Does not require Ruby on the server * Simple application structure (easy to extend) https://github.com/sprinkle-tool/sprinkle https://github.com/sprinkle-tool/sprinkle