Comment by grey-area | Hacker News Reader

Comment by grey-area | Hacker News Reader

I tried Ansible just last week for automating server config and setup as it happens and was really impressed.

I was using shell scripts previously but like the idea I can just spin up a server and from the base OS, run a deploy which will install everything I need from a local recipe, including configuring and restarting services, and have the server ready to use in a few minutes. It took a few hours to learn the ins and outs of their concept of playbooks (just simple recipes for deployment), but I liked the way you can nest these so once you have a setup for say Postgresql that you like it is usable in any other recipes combined with other components.

The best bit is that it can be run multiple times when new configs are added - this means any config changes to say nginx can be done on the playbook and then replayed to send them to the server(s), over and over till the recipe is right. This avoids the biggest problem with fragile servers which is an agglomeration of config changes and ad-hoc installations over original setup scripts. The playbook becomes your server config documentation.

It'd be great if VPS providers had a library of Ansible playbooks - perhaps AnsibleWorks should consider having a library of playbooks which they manage on their website for common OS/setups and are downloadable from there? Their examples don't really cover all the bases as yet (I wanted Nginx/Postgresql for example), and it'd be nice if whatever setup you want there's already a playbook ready for.

I'm sure similar things are possible in other comparable tools like Chef and Puppet, but I liked that Ansible requires nothing on the server, doesn't require git etc. and has a simple declarative language rather than a dsl to learn - the configuration language is very simple - you can start just by executing commands and installing packages and build up from there.

Would anyone care to compare to Chef/Puppet for those who haven't used them?

I've used Puppet in a network of a few hundred hosts, mixed Linux and FreeBSD, and I can't complain.

However, I also started using ansible shortly after it came out and I much prefer their push model.

One sad note about the fast open source development we all love so much though, I setup ansible when it was still in 0.x, everything worked fine.

Just a couple of weeks ago I had to modify that ansible configuration for the first time since the setup so I pulled a fresh copy. Everything had changed and I couldn't even get it to work. Not even after purging all the installed files of ansible. So now I have some studying to do. :)

Just a couple of weeks ago I had to modify that ansible configuration for the first time since the setup so I pulled a fresh copy.

Thanks for the heads up, I'll be sure to test before updating ansible in future. I suppose going from 0.x to 1.x you can expect some breakage, but hopefully after 1.0 formats will be pretty stable?

Note: author of Ansible here.

I'd be interested in feedback as to what that was specifically, can you stop by our mailing list perhaps? If it was the 0.X conditional support getting that in line was a very major priority, to streamline it so we all have something we like going forward.

In general, we take a pretty hard line on backwards compatibility -- though some things with regard to "only_if" were pretty legacy and I think you'll like the newness a lot more. Anyway, please do stop by the list!

Thanks!

Puppet supports a push model using mcollective. You can also just use ssh the same as ansible and use any CF tool to "push" changes.

Well, it's a message bus, and requires initial setup, so you don't get the zero-boostrapping capability, and require the agent to stay running and have an open port continuously open to the server.

Yes, you can initiate local runs on other CM tools, but with ansible the multi-tier orchestration and rolling updates can be accomplished from the central server without it -- just set it up and run from a laptop.

Props to the ansible folks. After trying the more established tools I quickly appreciated not having to install their various runtimes and servers.

Also I came across an new alternative the other day which I find even simpler (maybe too simple) called pave: https://bitbucket.org/mixmastamyk/pave ... anyone else heard of it?

Ansible has done a great job by including out of the box modules for most commonly used resources like PostgreSQL, ec2, NTP etc. It provides users standard code base which can be evolved/forked by community members. Of course, one can create a completely independent module code base, but it's nice to have a standard/curated code base.

Puppet: It's really difficult to find quality modules on the Puppet forge. Sometimes modules can give a false configuration impression. For example, when I had tested PostgreSQL module, the database owner wasn't being set properly [1]. I agree this can happen with Ansible modules as well. Also, badly written community modules can cause dependency issues (e.g. user1-http module uses user1-iptables module, but you are already using user2-firewall module etc..). It can be difficult to find good Puppet modules.

Chef: I haven't explored it much, but found it too complicated compared with Puppet and Ansible.

1. https://github.com/puppetlabs/puppetlabs-postgresql/issues/1... .

Chef/Puppet have a much higher learning curve and typically require you to set up a master. You can do things masterless but most of the docs I've read assume you have a master set up. Chef's documentation is incredibly awful and the only way to learn it seems to be by suffering through it. I would recommend Puppet over Chef but Ansible is just easier. If you have the time to learn Chef/Puppet then I guess go for it and you may find things you like more but if you're trying to get stuff done and want new folks to also be able to come up to speed fast then use Ansible.

The only problem with Ansible is that it is less mature so sometimes there may be features it doesn't support but the project is moving at an incredible pace and it is very extensible.

The amount of time I spent in Puppet writing modules to install things to a master was ridiculous. I could have not automated and done it manually, but I preferred bootstrapping Puppet with Puppet.

And that time you spend setting up a master? It's hopefully limited. But the joy doesn't end. Once your master is set up, then you get to install Puppet on every client too, and configure the client to point to your puppetmaster.

Ansible is really a data (or as they say, model) driven massively parallel shell scripting system with advanced templating, tailored for configuration management. It does a lot more, and it's design footprint is at the same time far less. ++

I was running into the same problem. So I wrote a playbook that deploys puppet agent using Ansible. https://github.com/rothgar/ansible-playbooks/tree/master/pla... After writing that, and a few other playbooks, I really like Ansible and could see eventually replacing Puppet or at least using both in my environment.

> This avoids the biggest problem with fragile servers which is an agglomeration of config changes and ad-hoc installations over original setup scripts. The playbook becomes your server config documentation.

If you're not careful, you can do just that with Ansible pretty easily. Put a dotfile or something under ansible management, change your mind, and unless you do a complete run where you explicitly tell ansible to delete the file it will hang around and potentially cause issues.

Not that that's unique to Ansible or anything, but it's totally possible to have servers under configuration management for their whole lifetime, and have a subtly corrupt "master" config that's unable to be applied to a fresh OS install.

If you changed the file to state=delete it should store the fact that file should not exist though - that would avoid this problem wouldn't it?

Granted you're trading in a bit of convenience for having state controlled in this way -everything would have to go through your config tool (ansible in this case) - I found commenting out tasks after I was happy they were complete in order to experiment with the next part of the config was a good way to make config changes like this painless and quick though.

Yes, that's exactly how you'd do it properly.

I'm with you on just commenting out or deleting things as you experiment up a new system config, but once you're using that config in production it's not as safe.

Reply on news.ycombinator.com