
Ansible 2.1 Released, with Network Automation, Containers - taha_jahangir
https://www.redhat.com/en/about/press-releases/red-hat-debuts-ansible-21-network-automation-containers-microsoft-windows-and-azure
======
devy
I have not been a big fan of Ansible due to some critical bugs (at least in
1.x) and the way how its community core committers are treating community
requests like this.

For one: Ansible 1.x cannot even print out the syntax error file and line
number in the offending Playbook. [1] And their core committers ignored the
issue and refuse to backport the basic debugging requirement after issue being
opened 2 years.

That itself, is a deal breaker for me.

[1]:
[https://github.com/ansible/ansible/issues/5797](https://github.com/ansible/ansible/issues/5797)

Edit: Downvoting me doesn't make this issue go away. What was requested is a
simple basic debugging requirement - any mature syntax tree parsers should be
able to do it.

~~~
bcoca
disclaimer: i'm an ansible dev.

As the ticket shows, this was added in the 2.x release of Ansible, that is why
the ticket was closed.

Adding this info required a major revamp of the parser, which we did in 2.x,
for this and many other reasons. This is not a simple change in 1.x and we
decided not to backport it.

~~~
bpchaps
Could you? Tons and tons of companies are forced into using outdated versions
(for tons of reasons) where point release updates are still possible.

I'm sure it's a lot of work, but a lot of your core and original users would
appreciate it. Not implementing something as useful as that just has a "we got
'em, no need to do anything else for them" vibe.

~~~
devy
> Tons and tons of companies are forced into using outdated versions (for tons
> of reasons) where point release updates are still possible.

Exactly my point! Ansible devs should own up to it for admitting their BAD
design choice (I heard someone from here saying intentionally not use a parser
but use YAML.) of not being able to get syntax error file name + line number!

My story was that debugging ansible playbook with loads of nonsense cryptic
error messages due to syntax errors that I have to spent hours to figure out
what went wrong was a complete frustration. It was so bad that we eventually
re-designed our infrastructure to cut out Ansible and never look back again.
So much for Ansible 2.x that it doesn't even matter. Ansible lost its appeal
in 1.x, and that's it. No more 2.x upgrades.

Lesson learned here is that if a young software tools got adopted but early
version caused so many frustrations that the authors don't care about back-
porting bugfixes, all future version becomes irrelevant.

~~~
bpchaps
It's gotten so bad with these sorts of tools with their incredibly annoying
design flaws that I've been debating creating my own using rpm and ssh on top
of bash with some python.

I get why it's important to have a lot of the features, but when the devops
crowd thinks [0] is acceptable (or at the very least, doesn't scream about
it), then it might be time for something new.. with [1] in mind.

    
    
      [0] $ man salt 2>/dev/null | wc -l
      140905
    

[1] [https://xkcd.com/927/](https://xkcd.com/927/)

~~~
ymse
Which design flaws are you referring to? As a recent Salt convert (and Puppet
expert), I was perplexed as to why such a nice tool would have a man page 40x
longer than _bash_.

Turns out it includes extensive documentation for _all_ states supported by
Salt, generated from the online documentation. Compare this to the Puppet
manual:

    
    
        $ man puppet
        PUPPET(8)                Puppet manual                         PUPPET(8)
    
        NAME
           puppet
    
           See ´puppet help´ for help on available puppet subcommands
    

Obviously no-one will be using everything that Salt supports, so it would be
nice if it was broken into sub-sections. But I much prefer having all
documentation available in a manual to looping through every module and run
"rdoc" as in the Puppet case.

Any sufficiently popular configuration management tool will have equally long
documentation.

There are a couple of simpler options available:

[http://www.nico.schottelius.org/software/cdist/](http://www.nico.schottelius.org/software/cdist/)

[https://github.com/brandonhilkert/fucking_shell_scripts](https://github.com/brandonhilkert/fucking_shell_scripts)

~~~
bpchaps
"Design flaw" might not be right description. Maybe, "Naive implementations
with nearly useless documentation" is better.

When I first started using puppet, I would go home _absolutely exhausted_
every night. Their design choices, along with a lack of documentation, would
turn the equivalent of a 20 minute bash script into something that would take
days. Best example I can think of is the arbitrary ordering of module
execution. I understand why they do it this way, but if they documented it in
_plain sight_ , then maybe my desk wouldn't have a forehead shaped dent in it.
Similar goes for the other tools.

The only thing I can think of that prevents companies from releasing proper
documentation is because of their expensive support contracts. There's a lot
of incentive to make a standard incredibly difficult.

I just want accessible tools :(

edit: fss looks pretty neat! Kinda rpm-y, but it fits a nice middle ground.

~~~
ymse
I get your sentiment. I only started using Salt some months ago, but it was
really a breath of fresh air compared to Puppet. However it took me a while to
realize its true strengths since the documentation is very...dry.

IIRC Ansible, like Chef, does serial execution. That is, states are applied in
the order they are written. I think that's part of the reason it has gotten so
popular, as you'll have very few surprises in the vein of "what do you mean
there is no _ntp_service_ \-- it's right there next to the config
declaration!".

What Salt got right is the pillar, for which the Puppet equivalent (Hiera) was
an afterthought. The Salt engine allows you to generate _states_ from the
pillar, rather than making poor clones of Puppet modules (as most of the
formulas I've seen online).

However that flexibility is not documented anywhere, nor part of best
practices. Nevertheless I'm about to release a set of formulas that are truly
pillar-driven with no hard-coded stuff. Keep an eye out for the accompanying
blog post :)

Of course, if you don't care about data/code separation and just want to get
stuff done, there are better tools. And if you have full control of your
environment, I would strongly suggest using Guix and/or Nix rather than these
legacy configuration management tools.

~~~
bpchaps
I actually really like salt, just not its documentation. Like you said - it
was a breath of fresh air. :)

Last time I used it a few months ago, it was while helping out another admin.
He had a lot of confusion on how to do certain things, and the documentation
wasn't very helpful for either of us. The solution came from github, which has
become my go-to for these sorts of tools. Though, that could easily be
supplemented with some better examples on their site, or in their, erm, man
page.

I doubt we'll have some great tools with great documentation anytime soon (or
monitoring tools!), but a sysadmin can dream... :)

------
carrja99
It is unfortunate that Ansible has a complete lack of test cases around core
modules and, as a result, people act surprise when they're broken in a new
release.

For example see this fairly critical defect with the s3 module in today's
release: [https://github.com/ansible/ansible-modules-
core/pull/3347](https://github.com/ansible/ansible-modules-core/pull/3347)

~~~
shlant
Definitely agree with this. I use the docker module extensively and found 2
regressions[1][2] that I went through the trouble of debugging down to a
single commit, but still have no idea whether anyone is going to fix them.

I'm hoping now that they are done rewriting the docker modules, and
considering they are using docker as a selling point for 2.1, they will be
more proactive with these issues.

1\. [https://github.com/ansible/ansible-modules-
core/issues/3219](https://github.com/ansible/ansible-modules-core/issues/3219)
2\. [https://github.com/ansible/ansible-modules-
core/issues/3231](https://github.com/ansible/ansible-modules-core/issues/3231)

~~~
willejs
Look at Chef. Its extensively unit tested in both the core client & server,
but also the cookbooks associated with it. Check out the docker one for
example [https://github.com/chef-cookbooks/docker](https://github.com/chef-
cookbooks/docker) The interfaces and primitives for docker in this cookbook
are great too.

~~~
shlant
I used to be a Chef user, and although I do love it, it's overkill for the
current infra I am supporting. I haven't had too many issues with Ansible, I
love it's simplicity, just lately there have been some annoying regressions.

I do really appreciate that testing is a priority in the Chef community, cause
it definitely isn't with Ansible. It also seems like based on the naming
conventions in the Chef cookbook, that Ansible is playing catchup with 2.1
(imitation is the sincerest form of flattery?)

------
djrobstep
I love Ansible, and have been using it since it was a humble little git repo
with a single author.

Unfortunately it's probably the most important python package that doesn't
support Python 3, it would be cool to see it upgraded. Apparently the hold-up
is supporting very old 2.x python versions because of RHEL.

~~~
benhoyt
I think it actually makes sense for something like Ansible to use Python 2
because it's about controlling lots of remote machines on various Linux
distros, and the idea is that it's agentless. If you suddenly have to install
an "agent" (Python 3) on all the remote machines before you control them with
Ansible, that wouldn't be great.

On the other hand, Ansible itself could have a tiny bootstrap step which
installs Python 3 on all the remote machines before it does any work.

In our case, we use Ansible daily for deployments, but haven't actually
written any custom Python modules -- it's all just straight Ansible YAML. So
I'm guessing for a lot of use cases it doesn't really matter what language
Ansible is written in.

~~~
Aissen
Or, they could support both so that they can be an agent for distros that
won't have python2 installed and only python3 (AFAIK they don't exist yet).

~~~
rlpb
Ubuntu Server no longer has Python 2 installed by default (though it's
available if you want it). This is the case on 16.04.

~~~
Aissen
Ah, I thought I heard about that somewhere. I did tests on 16.04 recently with
ansible, but python2 was here, so I guess the image I was using wasn't a
vanilla ubuntu (from a VPS provider).

------
therealmarv
Can I kill Vagrant with this Docker compose approach on OS X?
[https://www.ansible.com/blog/six-ways-ansible-makes-
docker-c...](https://www.ansible.com/blog/six-ways-ansible-makes-docker-
compose-better) Does anyone know or has tested this with a normal (non beta)
Docker install on OS X?

------
Aissen
Does it support python3 yet ?

Also, why do we have to install aptitude to do system updates ? It has been a
long time since apt-get had bad resolution issues (and aptitude isn't
installed by default anymore (has it ever been?)).

~~~
sethish
Aptitude is installed by default on Debian Jessie.

~~~
Aissen
It's not on raspbian or Ubuntu Server.

------
hackerboos
I hope open sourcing Ansible Tower is still on the cards after it was promised
at a conference shortly after acquisition.

~~~
bovermyer
We've found Rundeck to be a more flexible alternative to Ansible Tower, and
Rundeck is open source:
[https://github.com/rundeck/rundeck](https://github.com/rundeck/rundeck)

~~~
coredog64
Not to hijack the thread, but any pointers to good resources to sell mgmt on
Rundeck? We're currently using Jenkins(!?) for role, something that enforces a
divide where developers are allowed to automate, but operations isn't.

~~~
acveilleux
I'm trying to parse your statement and I'm not sure if you _want_ something to
enforce that divide or if your complaint with Jenkins is that it enforces a
divide between dev and ops?

~~~
coredog64
Sorry for not being clear. We're using Jenkins because it was the shortest
path to a solution. It's not easy for non-devs to use, so I'd like something
that is ops friendly and won't cause the devs to want to repeatedly bang their
head on the desk.

------
code_research
now with extendended network support one question gets even more important:
how do you do rollbacks with ansible? There is no default mechanism or policy
that seems to help with that, so I have to hand-roll my rollbacks?

~~~
movedx
The simple answer is: you don't, you "roll forward."

In the event you deploy some code, a DB migration, a server configuration
change, etc, and your solution fails after the fact, you move forward, not
backwards. Let me explain further.

If you deploy v1.0 of your application and it works, great! If you then deploy
v1.1 and it falls over, you find out why, apply a fix, test it locally
(Vagrant?), deploy it to a testing environment and perform automated tests
(Selenium, jMeter, ...), and once it's working there, you deploy it to
production. This is called a hot fix, and it will now be working as intended
(unless something else is horribly off the mark in which case you have other
issues.)

The key to this example is the local and remote/network-based testing
environment(s.) In my opinion, it's very much a realistic goal for ALL
organisations of ALL sizes to operate local development environments using
Vagrant and VirtualBox; a testing environment that spreads out the whole
solution over multiple boxes (for testing networking code and configuration,
among many other things); a staging environment for running performance tests
(staging should match production bit-for-bit, cpu-for-cpu, ram-for-ram, ...)
using jMeter or your choice of tooling; and finally a production environment
to serve clients. This is the absolute minimum all organisations should be
aiming for, and it doesn't even have to be fully automated using CI and/or CD.

Also tests, such as unit tests, systems tests, integration tests, usability
and performance tests, and so on, are also critical to preventing the need to
roll back and instead, implementing a roll forward policy.

~~~
brudgers
Curious if "roll forward only" could create situations where a failed version
change could place the system of interest in a non-functional state until the
problem was diagnosed, the code revised, and an update released. If that's
possible, I would have concerns about the infrastructure meeting the core
needs of the business such as providing value to cutomers.

~~~
movedx
Your systems is already down, rolling back is the same thing, if not more
effort than rolling forward. At least that's what I've always found.

Another option is to have customers point at stage after it has been upgraded
and if it all goes horribly wrong, a load balancer change should be enough to
point people back at the older production environment.

All this being said, problems in production shouldn't be a thing with
configuration management, infrastructure as code (Terraform), and tests, not
to mention three environments (development,test, stage - at minimum) to work
your way through before pushing to production.

~~~
earless1
Keeping a system down while waiting for a hotfix is not an option for most
operations. Rollbacks have their place and hotfixes have their place.

~~~
jmcnulty
Taking a snapshot of a system before making a change and rolling back to that
snapshot would be faster. In any case, a strong policy of only pushing changes
to production that have been properly tested in staging will protect you the
most.

------
dflock
Could you guys stop doing new features and write some unit tests for core
modules please? So many regressions.

------
JTenerife
I love and hate Ansible. It has simplified so many things for me, but also had
some annoying bugs and regressions. Somehow I've lost trust in the codebase.
Also performance is a showstopper. I need a tool to develop, I just can't wait
> 10 min for an iteration. I usually end up modifying my server's config files
manually and then build the Ansible templates.

Unfortunately I'm not aware of a better alternative.

~~~
andmarios
Use tags and only play the role you fixed.

------
adamors
Can anyone comment on the speed of Ansible 2+?

I have a bunch of playbooks that still use 1.8 and they are dog slow. Changing
the contents of one file can take ~10 minutes. (Interestingly, running the
entire playbook on a clean server is actually faster).

~~~
vacri
> _Changing the contents of one file can take ~10 minutes._

O_o

That kind of simple operation just zipped by for me on Ansible 1.6, 1.8, 1.9,
and 2.0. The only noticeably slow kinds of operations for me are generally the
package installs (understandably). I don't use a ton of variables in my
templates, though.

~~~
adamors
I have quite a few variables, yes. One of the files I change frequently is an
external configuration file filled with credentials which is managed through
variables. It looks something like this:

    
    
        {% for cred in credentials %}
        {{cred.key}}: {{cred.value}}
        {% endfor %}

~~~
mewm
hey, kind of off-topic, but wouldn't you be able to like this?

    
    
      {{ credentials | to_nice_json }}

------
squeaky-clean
By Windows support, do they mean as a Control Machine? Because I thought it
has supported automating Windows remote hosts for a while now? The
documentation still reads as though it doesn't support Windows as control.

I just tried it out, and "pip install ansible" fails because of pycrypto. If I
install pycrypto manually from another source, ansible installs successfully,
but isn't recognized as a command. (I've double-checked it's installing
ansible 2.1.0).

------
itaifrenkel
Can anyone comment on ansible for CIS hardening (and docker CIS benchmark). If
not, perhaps other tools?

~~~
chucky_z
I use Ansible to do all of the CIS recommendations. Took about a day and
following along with the CIS guide to do it.

------
mmgutz
Unarchive module gets cert error on get.docker.com on Ubuntu 14.04 LTS. System
Python is too old.

~~~
therealmarv
I also had this problems in the past with SNI certs. Very annoying old python
bug, it's possible to fix old python but this makes no sense for an Ansible
deployment
[http://stackoverflow.com/a/29099439/756056](http://stackoverflow.com/a/29099439/756056)
Better approach: Use curl to download in some temp directory/file and then
extract from there. Curl does not have this errors. Example:
[https://github.com/ansible/ansible-modules-
core/issues/1716#...](https://github.com/ansible/ansible-modules-
core/issues/1716#issuecomment-121001546)

My dream would be that whole Ansible would use rockstable libcurl instead of
the requests library which has problems with Certs on (not so) old python
versions.

~~~
bcoca
we actually avoid the requests lib for this and many other reasons, we don't
use libcurl as we try to avoid extra dependencies when possible.

The issue is more basic than requests, the actual python http/url and ssl
implementations have these issues, we have patched and added warnings to
indicate which minimal python versions you can use and have SNI work.

~~~
therealmarv
thanks for clarifying!

