Ansible 1.9.0 Released(groups.google.com) |
Ansible 1.9.0 Released(groups.google.com) |
Having used Chef, Puppet, and Ansible, this is exactly why I prefer Ansible for all my projects now.
If you can write a shell script, you can write an Ansible playbook. It won't be a great playbook, and you get benefits from using their modules instead of shell commands (like idempotency). But you don't have to worry about learning a new DSL just to do write a basic playbook or tweak an existing one.
As a functional programmer, I understand the benefits and appeal of declarative syntax. Unfortunately, systems programming is the one place where it's really hard to be 100% declarative, because systems are inherently all about state[0].
[0] At least in 2015 - perhaps things will change as we move toward better containerization models
For me, YAML files and fantastic documentation made more sense than the DSLs of the other two.
Currently we use it to setup our 12-factor app in production, staging, and development environments. (Django, Elasticsearch on Ubuntu)
I'm far closer than ever to not use ssh on my server manually.
Ansible has support for powershell, which is essentially now the backend of windows. (your new servers are gui-less right?) Powershell is also not a bad language at all, and while for those of us that are bash/zsh/fish natives, it will take some getting used to, I find it a really powerfull and more intuitive way to interact with windows, even if it is very overly majorly verbose-verbose.
Being able to work in my very mixed environment (Solaris/OSX/Linux/Doze, etc) via a central ansible server group is awesome.
I wish I could use ansible with all those XP workstation a work.
So, before being able to run your playbooks to do your provisioning/deployment, now you have to handle credentials outside of ansible, connect to the remote machine manually and install an old version of Python.
It's only a minor annoyance for me, but it could get worse.
Salt is much heavier to setup. Has explicit agents ("minions") and a server ("Salt master") whereas ansible can be run from anywhere as long as SSH connection exists. Salt maintains metadata ("grains") about the remote hosts, ansible gathers whatever data it needs on demand. Salt is heavy on the custom terminology and concepts. You have to work with the metaphors. Salt states are much more declarative.
Both make use of YAML for a lot of things.
My impression was that Ansible is a far better tool for smaller environments with, say, less then 20-50 hosts being managed and the learning curve is surprisingly shallow. When I got it to work, I had more difficulty getting Vagrant to like Ansible than Ansible to setup a complicated stack (Islandora for the curious.) The semi declarative nature of the Ansible modules was easy to work with but getting idempotence was actually a bit of a pain.
I've not fully setup Salt because of the level of effort required. It's comparable to a full Chef setup.
If you want to use the latest and greatest, it's easy enough to set up Ansible from source. Otherwise, use brew, apt, yum, or pip (they're all up to date).
P.S. 1.9.0 was released on Mar. 25th, I think there's an older thread on it somewhere around here.
But still I think it would be a great idea to have a community playbook for critical things like mailservers where it is so easy to make a mistake and the fight against spammers is so hard to fight when you are only a small group of people or alone.
It was recently declared production-ready, but it isn't intended to be an alternative to the standard Salt fileserver. Seems like it's more of an easy way to bootstrap machines.
I don't see an iredmail role, but having used Ansible previously, if you can install it chances are you can write an Ansible playbook for it.
We're also stuck with Windows Server 2003 for now :(
I grew up thinking that the technology move so fast...
The only comparable system that I believe is a match for Ansible is SaltStack.
> As a functional programmer, I understand the benefits and appeal of declarative syntax. Unfortunately, systems programming is the one place where it's really hard to be 100% declarative, because systems are inherently all about state[0].
Have you looked into Nix/NixOS/NixOps? I think they have a really good approach to "functional configuration mgmt".
> perhaps things will change as we move toward better containerization models
I agree. When using scrappable VMs/containers (deploy to a new one, then scrap the old one) that are build from a description, it is in some ways quite close to approach in the Nix-camp.