Have spent the past few months heavily working with Ansible and would totally recommend it for anyone wanting simple configuration management and orchestration. The barrier to entry is extremely low, because it uses ssh and there are no remote agents, so you can get going pretty quickly. I have an introductory screencast on in @ https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl...
The other thing that should be noted is that ansible feels like (shell scripting)++. Other competitors I've used needed a much heavier cognitive load to get started.
> The other thing that should be noted is that ansible feels like (shell scripting)++. Other competitors I've used needed a much heavier cognitive load to get started.
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
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.
And it's also not that it's just a /new/ DSL - every so often I find the DSLs annoyingly limited compared to having a full fledged programming language.
Love Ansible for its simplicity. For some reason it "just clicked" whereas I really struggled with Puppet / Chef / or old-school shell scripts. (That says more about me than Puppet and Chef)
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)
Started using Ansible last year, I use it to create up to date base images for AWS autoscale groups and to quick set up personal development environments for other developers, and have playbooks for creating all my security groups so I can version control them. Highly recommended. I tried other tools but by far and away Ansible was the easiest to learn and use with no loss of functionality.
One of the changes hinted at here is that you can now specify that a task will always run using the 'always' tag - handy for things like ec2_facts which was a long requested feature (https://github.com/ansible/ansible/issues/3157)
Ansible is really great, but for reasons some people might not think about.
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.
No it hasn't been a problem so far, just an update that gets pushed via the normal pre-ansible methods and requires a restart. Regarding XP... unless it's embedded get that shit outa there!
I've learned with Ansible never to be quick to update. There's always something that will break. I've been on 1.7.2 for a while, and will probably think about updating later this year.
Do they have any plans to support python3? I want to use it on Arch and Ubuntu. FAQ says they will address this issue by python3 becomes mainstream, but what does the mainstream exactly mean? When RHEL set python3 as default? Python2 maintenance continues until 2020, so seems have to wait for more several years.
Hi ynak, we're planning on supporting py3 in the core engine with the v2 codebase. As for modules, we're still working on the best possible solution there, since we do need to continue supporting python 2.4 for the foreseeable future.
There are still a lot of RHEL/CentOS 5 users out there, which run python 2.4. While py3 is moving forward, the number of users stuck on 2.4 is still considerably larger, and we will continue to support that until such a time as it's no longer the case. In the meantime, we are exploring options so that we can help those on newer distributions work by default in the same way.
This does not help when you want to manage Arch or Ubuntu machines, since you're not installing ansible there, you're just letting ansible connect with ssh and execute Python2 scripts.
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.
My own experience, which is fairly limited, is that Ansible is much simpler, "agent-less" (it uploads code as needed and remote executes it over SSH) and a mix between declarative and imperative in nature (a lot of the modules require you to use semaphore files or equivalent for idempotence.) Orchestration is pretty much built-in, including rolling deployment/restarts. Performance can be lacking on large cluster due to the many network round trips and lack of agent. Agents can be faked by rsync'ing config and running ansible in local mode. You can use ansible to do it and ansible is a great Fabric replacement.
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.
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.
Ansible is much easier to get into. The more complex your requirements are (complexity of your infrastructure, services, etc) the less useful it becomes IMHO. SaltStack feels much more feature-complete and much more powerful to me. Also Ansible has no dependency-graph which sometimes makes it hard to modularize your "plays". On the other hand, SaltStack needs to be setup on the minions first, whereas with Ansible you only need SSH. I myself now use Ansible to bootstrap SaltStack and let SaltStack do the heavy lifting.
1.9.0 includes convenient new gluster_volume and haproxy modules (among others) and will also update its DigitalOcean integration to use the v2 API shortly (in 1.9.1 - it's currently using the more annoying v1 API).
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.
Nice maintenance release with a few improvements. I'd say the core of Ansible's brainpower is focused on v2 which will have significant changes (easily available today if you want to try, check the v2 dir).
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.
"Production-ready mailserver" is horribly broad (for starters, outgoing mail or incoming mail?), but Ansible Galaxy has lots of mail-related roles. For example, Zabbix: https://galaxy.ansible.com/list#/roles/1879