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.
Ansible 1.9.0 Released
21–30 of 42 posts
Re: Ansible 1.9.0 Released
#22OK I am gonna ask the obvious question here: How does Ansible compare to Saltstack?
Re: Ansible 1.9.0 Released
#23Have 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
Re: Ansible 1.9.0 Released
#24Earlier quoted context omitted.
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…
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.
Re: Ansible 1.9.0 Released
#25OK I am gonna ask the obvious question here: How does Ansible compare to Saltstack?
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.
Re: Ansible 1.9.0 Released
#26OK I am gonna ask the obvious question here: How does Ansible compare to Saltstack?
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.
Re: Ansible 1.9.0 Released
#27Do 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.
Re: Ansible 1.9.0 Released
#28I'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.
S3 module and something else was b0rked in this release that I ran into last week (can't remember atm). Very annoying.
Yes, very sorry about that. The 1.9.1 rc1 will be out today, which will address this.
Re: Ansible 1.9.0 Released
#29Earlier quoted context omitted.
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…
> Having used Chef, Puppet, and Ansible
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.
Re: Ansible 1.9.0 Released
#30Ansible 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.