On Ansible
benscofield.com
benscofield.com
See Vagrant & Ansible docs @ http://docs.vagrantup.com/v2/provisioning/ansible.html
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.
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.
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.
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.
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
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.
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 :-))
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!
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.
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.
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
We're going to be adding Windows support this year but have been concentrating on *nix operating systems as that's the core of our user base.
Definitely would like feedback on what specifically on Windows you are managing and for what use cases.
Both of those environments are mixed-OS. The build farms are composed of a Jenkins master with multiple slaves of various OSes: Ubuntu, RHEL, and Windows. My home network is running Kerberos and OpenAFS (amongst many other random things [1]) on Ubuntu and Windows.
> 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.
I don't know... the Puppet module for Apache [2] seems to do a reasonably good job of managing this. Admittedly, pretty much none of the "main" Puppet modules support Windows, but the underlying resource system absolutely does, so adding that support is just a matter of submitting pull requests to the modules.
[1] Everything's documented here: https://justdavis.com/karl/it/
If you are looking at the core language for either, it doesn't hide those things but you can put whatever logic you want in the role/playbook/manifest/etc.
Hope this explains things!
Thanks for more info.
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-a...
Where can I gain that perspective?
It really depends on your situation. Please shoot me an email and we can discuss in more detail: matt@nanobeep.com
All of the tools will scale to at least several thousand servers, but they each have slightly different ways of doing it.
I'd recommend choosing the tool that makes the most sense for you at your current scale since they all can probably scale to what you need.
I mention that the book is for folks with less than 100 servers because I don't go into how to set up these tools for higher scale in the book.
So, to get the info on how to scale up to very large pools of servers it'd probably be best to first pick a tool and then look at its specific documentation for scaling up.
http://missingm.co/2013/06/ansible-and-salt-a-detailed-compa...
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.
- lots of documentation
- Foreman ( http://theforeman.org/ , backed by Redhat) as a great alternative to Puppet Enterprise
- projects like GitHub's Boxen ( http://boxen.github.com/ ) to bootstrap your devel machine
- a large repository of modules available: 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.
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.
* 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)
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!
There are no separate versions of Ansible such as what Nginx has done. Ansible AWX adds no further functionality to Ansible except for the UI.
It adds role based access control, centralized logging of what all your playbooks have done, and a way to keep up with the history of your hosts over time. Yes, there's definitely a focus on making things push button, but one of the major ideas here is that I can easily delegate roles to particular members of my team -- lab staff might be able to work with inventory, QA might be able to deploy to the test environment, ops may be able to deploy to production, etc.
This is just our first release but the main goal here is to make the absolutely simplest/best ops tool for teams we can make. If people have ideas, definitely pass info along (info@ansibleworks.com). It would be greatly appreciated!
The next release comes out in about a week and adds some extra bonus features on top as well.
So far, I see no need to use AWX.
I can't ensure you of anything but why not install it in a test instance and give it a try?
It also includes support -- which is not just asking for bugs, but also us helping provide advice on how to manage your infrastructure.
You should find pricing pretty well in line with some of the competing solutions. If you have questions about pricing not fitting your usage model, definitely contact us for details and we can work with you.
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.
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.
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 [2] http://www.gnu.org/licenses/gpl.html
The LGPL linking clause is based around the concept of a derivative work. If additional code is used to extend the original licensed work, GPL consider the new program to be based on it. Linking is thus considered to be a clear general example where such extension of the original work has happened. A WordPress module is simply considered an extension of WordPress.
If, and at what point a compiler like Python is considered to be "extended" simple run-time interpretation of python code, is not something the license or the courts has ever made a decision on. Copyright owners, and project communities has speculated on the question, and others has spread FUD, but the question has never seriously been handled as a matter of law. While it might be useful if the court decided on it, I doubt it would be worth the judge's time. Nor do I think it would be worth the license drafter's (for GPLv3, the community's) time.
> 'A compilation of a covered work with other separate and independent works, > which are not by their nature extensions of the covered work, and which are > not combined with it such as to form a larger program, in or on a volume of > a storage or distribution medium, is called an “aggregate” if the > compilation and its resulting copyright are not used to limit the access or > legal rights of the compilation's users beyond what the individual works > permit. Inclusion of a covered work in an aggregate does not cause this > License to apply to the other parts of the aggregate.'
Doesn't that cover it pretty much?
You can distribute a GPL program, such as Ansible, and even bundle it with your playbooks, modules, etc, as those are explicitly NOT extensions of ansible, they are separate, you now have an "aggregate". And as long as you aren't modifying the original GPL program, then "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate". So you could licence your modules and playbooks in whatever licence you want. To be honest though, you don't need to licence them at all, if they are just for internal company use. And if you're going to distribute them, it doens't matter what licence it is.
Next, you aren't actually in 90% of circumstances, actually distributing ansible, or your playbooks. You're running it yourself (either you, or your company). That's actually one nice thing about it, you aren't installing extraneous software on the machines you're managing.
GPL covers the distribution of software, and requires the source to also be distributed along side it. It does not cover the use of it.
Wordpress, et al, are a slightly different situation. There, you actually are distributing and installing it on multiple computers. You're also distributing parts of it, in that quite a bit of it (javascript, templates, etc) are going to and from client machines, and even running bits of it on client computers. It's a bit more complicated.
The part of common code that gets mixed into modules is also BSD, so modules you write are your own.
For those that want a GUI and REST API on top, we've got a commercial product that allows you to use the API without any concern of GPL-things, or you could just shell out to Ansible-playbook too.
What code that gets mixed into modules is BSD? This says it's GPL: https://github.com/ansible/ansible/blob/devel/library/packag...