
Ansible 2.0 released - tachion
http://www.ansible.com/blog/ansible-2.0-launch
======
loevborg
Ansible is probably the single most useful tool for doing working with servers
today. It somehow manages to be simple and very featureful at the same time.
Personally, a good chunk of my effectiveness in workings with servers and
cloud provisioning can be directly attributed to it.

I've been using pre-releases of 2.0 for a few months now, mainly for its
improved support for AWS services like dynamodb and IAM policies. I've had
nothing but good experience with the new version, which cleans up the code and
brings more consistency. Working with AWS, ansible shows its strengths by
exposing to the developer a simplified API which gets you 95% percent of the
way -- pretty much what you wish you'd get from Amazon. I feel that ansible
does cloud provisioning not just easier but better than most other tools,
including Amazon's Cloud Formation.

Ansible's playbooks (recipes for provisioning servers or infrastructure) read
like pseudo-code, and although it's sometime not obvious how to write an
idempotent playbook for a piece of software, it is always obvious what an
ansible YAML file does (despite the obvious shortcomings of YAML for this
job). This is important in the devops world: all knowledge about the
infrastructure is codified in version-controlled ansible code and doesn't get
lost when the job passes to a new hire.

This also means that you can often find a playbook for software you want to
deploy already written on github (search with "language:yaml"). Often you
won't be able to copy and paste it verbatim, but looking at how someone else
has solved a problem (install java, configure apache, etc.), it will be
obvious how to replicate it.

Every time I finish a piece ansible code, I smile -- about how many other
tools can you say that? Congratulations to the team and all contributors for
the new major release (and to the company for its well-deserved recent
acquisition)!

~~~
rdeboo
I fully agree. Ansible has a small learning curve.

There is little effort in getting started, since it runs over ssh without any
daemons or agents required on the managed hosts.

For finding playbooks, you can also look at
[https://galaxy.ansible.com](https://galaxy.ansible.com)

------
matt_wulfeck
Ansible and Salt were both huge steps forward for provisioning. However, after
switching to immutable resources I've largely replaced the need for such
services.

I don't mind that there's a panoply of bash scripts to configure docker
builds. It's simple and it works and nearly every engineer worth anything
knows how to read and write them.

A good bash script never goes out of style.

~~~
jgrowl
I might be the only one that does this, but I like using ansible with docker.

I use a Dockerfile for any long running tasks like installing dependencies so
I can take advantage of docker's cache. I then use ansible for fast running
configuration like using a template file for filling out user specific
configuration.

The biggest disadvantage to this is that you have to add ansible as a
dependency in all of your containers, which stinks. I feel like it produces
easier-to-read configuration.

Don't get me wrong, bash scripting is a great tool. I just try to avoid it
whenever I can because I personally don't like writing bash scripts.

I think in the future there might be a best of both worlds approach if docker
adds a caching api to where ansible could interact with it directly. There is
also a docker connection plugin added in this release that could add some
possibilities.

~~~
matt_wulfeck
I don't think you're the only one. I ran saltstack with my containers for
awhile, but it just created too many dependencies (as you notice yourself) and
made the build process difficult.

I find that if I keep things in bash the images become more "dumb" and
therefore more portable.

In lieu of a caching API you might find a package cache (apt-cacher-ng, squid,
etc) will help speed up installs a lot. I found one image that was pulling
down almost 5 GB with every build!

~~~
alexandrerond
Writing ansible is faster and less error prone than a bash script. It's
additionally better organized and maintainable. I use it for both immutable
and manual deployments.

~~~
nikolay
True... if you suck at Bash.

~~~
michaelmrose
Bash unequivocally sucks this is not to say it doesn't have its uses.

~~~
nikolay
No, it doesn't suck more than YAML-based scripting. I write complex Bash
scripts daily - if I have to write the same in, let's say, Python, it would
take longer, will possibly run slower, and will definitely take longer to
test. Again, Bash is a nice tool, but you need to learn it well.

~~~
Walkman
how do you test bash scripts?

~~~
cakeface
I've used bats[1] in the past. I also recommend the command line shellcheck[2]
for linting.

[1] [https://github.com/sstephenson/bats](https://github.com/sstephenson/bats)
[2]
[https://github.com/koalaman/shellcheck](https://github.com/koalaman/shellcheck)

------
oskarpearson
There are some good changes here:

[https://raw.githubusercontent.com/ansible/ansible/stable-2.0...](https://raw.githubusercontent.com/ansible/ansible/stable-2.0/CHANGELOG.md)

\- Given the dynamic includes, you can use variables in some places you
couldn't before , which allows you to pass items in on an include.

\- Error handling now uses a try/catch structure with block/rescue/always,
which is much clearer than capturing a 'register' variable and handling it
later

\- It has a new 'free running' mode, where operations can be run on remote
hosts as fast as they can be processed, rather than at the speed of the
slowest host

\- Lots more cloud-oriented modules

------
skywhopper
Love Ansible, but am I the only one who has found 2.0 to be unbearably slow?
Some patterns I use may now be anti-patterns I should factor out, but even
with some optimizations, I'm finding Ansible 2.0 to be 3-4x slower than 1.9.
Maybe it has to do with # of hosts or variable field depth, but it's really
really depressing.

~~~
LukeHoersten
Do you have connection pipelining enabled?:

[ssh_connection] pipelining = True

Ansible 2 is extremely fast for me.

~~~
skywhopper
Yes, pipelining is on. I've been doing some further testing and I suspect some
of the nested roles we're using are the source of the slowness, because for
simple playbooks and simple tasks, the speed is comparable (Ansible 1.9 still
comes in a little faster, unless I enable the `free` strategy in 2.0).

------
lifeisstillgood
I am starting with Ansible and pretty much my first thought was to write my
own "super" python scripts that called Ansibke instead of using playbook and
their DSL

But, is this a good idea? As the first six comments here are starting that
discussion, what are the pros and cons?

The API may be rich but it feels a second class citizen. But DSLs are really
hard to get right and often lack ... Everything.

~~~
loevborg
I would encourage you to start by learning Ansible's yaml syntax, which really
goes a long way and which represents a lot of best practices in the devops
world, such as immutability, configurability and config file templating. I
have yet to run into a situation where I had to reach for python, calling the
API directly or even extending ansible itself.

However, sometimes you may want to mix local actions (say, spin up ec2
instances) and remote actions (provision said ec2 instances). In these cases,
a simple wrapper bash or python script to combine these has proven helpful.

~~~
fideloper
This has been my use case. We spin up a lot of trial servers on aws for
customers, each with some unique data. I've written Python to call Ansible
(1.9) programmatically, which was a fun challenge, even if possibly more work
than was needed: [https://serversforhackers.com/running-ansible-
programmatical...](https://serversforhackers.com/running-ansible-
programmatically)

Ansible 2 changes a lot of that, so a followup for how-to in Ansible 2 is in
order eventually.

~~~
href
We wrote our own Api wrapper to run Ansible commands on our infrastructure. It
aims to encapsulate all the complicated bits. Maybe this is of interest to
you:

[https://github.com/seantis/suitable](https://github.com/seantis/suitable)

We use Puppet mainly, but depend on Ansible for updates, migrations and other
things where we want to control the transition, not just the end state.

~~~
senorsmile
This is actually pretty neat. Thanks for posting.

------
herge
Man, I am really happy that playbook parsing and error reporting has been
improved.

Almost all the frustrations I have had with ansible haven't been from
individual modules, but from the mini-language in playbooks defining what
modules gets run when with what input variables. Almost pushed me to do away
with playbooks entirely and just call ansible modules from a python script
directly.

~~~
davexunit
Ansible would be much better if they just used Python for the playbook API
instead of YAML. Ansible would be a clear win over over-engineered competitors
like Chef if they fixed this, but as-is I don't want to use it.

~~~
gerbilly
I think the reason they didn't use a procedural language is because they
specifically wanted to keep the playbooks declarative.

Ideally, the playbook should describe the state you want the system to be in.

This is 'almost' the case for most modules and I think this was a very good
design decision.

Having said that, the ghastly YAML format was almost a deal-breaker for me
too.

~~~
davexunit
Using a real programming language doesn't preclude a declarative programming
style.

~~~
moises_silva
No, but using a 'real' programming language doesn't force you to write in a
declarative style unless you use something like a pure functional language and
before you know it people would start making a mess in their playbooks using
the whole power of Python. Ansible is awesome for devops precisely because it
restricts what you can do and forces you to try to do things in a consistent
declarative (and hence idempotent) style, which is important to devops.

[edit: fix broken english]

~~~
lenkite
This could have been solved by choosing a language like lua and restricting
the runtime environment - which is what is done in game software. Lua also has
a tight, efficient interpreter. Making a mini-programming language in YAML is
_coding horror_.

------
jasonrhaas
Excited about the block functionality and the new execution strategies! I will
definitely try them both out to see if I can optimize my Ansible code even
further.

------
kyriakos
I'd love windows support on the control side.

------
smegel
I only skimmed over the release notes, but I hope they avoid adding too much
complexity and keep it's prized simplicity.

------
fnordo
Really looking forward to getting into this but it doesn't look like they've
documented all the modules yet. Specifically I'm trying to find more
information on the hashi_vault module

~~~
sheraz
I just finished a deployment using Hashicorp's vault and ansible, but we did
it without a module.

Do you have a link that references this?

Or, if you are interested in what we did I could probably put it into a gist

~~~
fnordo
It's referenced in the changelog as a new module:
[https://raw.githubusercontent.com/ansible/ansible/stable-2.0...](https://raw.githubusercontent.com/ansible/ansible/stable-2.0/CHANGELOG.md)

After looking more closely it seems like it's just used to pull data from
Vault. I'm currently using Ansible for Docker deployments and have been
planning on using it to push data to Vault during deployments so this won't
really suffice.

------
merb
it would be great if rolling updates would work now..

~~~
Florin_Andrei
What do you mean?

------
bovermyer
I was about to make some witty and intelligent comment about Ansible and its
usefulness for cloud orchestration, and then I remembered that I've drank over
half a bottle of wine and it's time to pass out, so g'night.

~~~
bovermyer
Wow, that was stupid of me.

Here, to make up for the above comment:

I've found that Ansible combined with Rundeck makes a powerful automation
engine, and can replace more complex systems like Jenkins pretty easily.

