Comment by Azeralthefallen | Hacker News Reader

Comment by Azeralthefallen | Hacker News Reader

Parent Full thread

Azeralthefallen

My life resolves around Ansible and has for the last year and a half. Ansible is a great tool, unfortunately it has a bunch of short comings. Especially now some of these are becoming a major issue.

- Its dependence on Python 2.X, unfortunately all the newer OS's have Python 3.X installed by default. While i have a role for installing this manually it isn't super nice.

- My main devops project consists of 11 different environments, and it manages nearly 2k servers. Trying to write environment agnostic roles is an absolute nightmare. Furthermore my group_vars, host_vars, and dynamic inventories have turned into spaghetti. Why? Because of how confusing variable precedence becomes, when you get into extremely complex hierarchy of group_vars which can randomly break.

- It is really hard to handle cases where playbooks/roles fail and deal with it cleanly. Blocks have helped a bit, but there is no way to grab the exception that caused the playbook to fail.

- The yaml syntax becomes messy fast, Jinja2 is powerful but there are times i wish you could just shove a single line of python into places to prevent the huge mess of with_items, register, set_fact, etc.

- AWS modules are a very mixed bag. A lot of them are missing features, and there is some very weird issues that apparently boto is the cause of (e.g. they should move to boto3). Even then i need to do a huge amount of boilerplate to launch ec2 instances.

- There is no way to share a common group_vars between inventories (all is specific to inventory). Which leads to a lot of duplication. (Yes the symlink trick does work, but causes a bunch of other issues).

I still love Ansible and i would pick it over Chef/Puppet. Salt is also another decent one that has made a lot of progress lately.

That's interesting - I just received a request for ShutIt to work with Python3.

Regarding failure, ShutIt drops to a shell on error (if there's a tty), so you can correct manually before continuing (pause_point). These can also be triggered directly for debugging purposes.

I don't like YAML for anything complicated. The bash scripts I saw embedded in YAML felt wrong. Why not just use shell?

Env-agnosticism (eg 'install' packages rather than yum/apt) was built in because it was created in a bi-OS env (ubuntu and CentOS).

We rely heavily on Ansible and your description seems very accurate. I worry we have too much invested at this point to consider anything else. Still would pick it over Chef/Puppet.

Salt does look interesting but it was too young when we started. I don't know if we would be trading Ansible's shortcomings for Salt's.

I use ansible to manage several hundred servers. So not your scale, but I've felt some of this.

I stopped trying to write completely agnostic roles. This does result in some duplication but much less hair-pulling overall.

Yes ansible is what made me grow to dislike yaml.

As someone who has previously used Chef and is currently using Ansible, I can understand those pain points. For me it's not as much of a problem as I have 10x less servers, but I have heard a lot of complaints about Ansible scaling. I definitely miss being able to just use Ruby in a cookbook, but it's usually very rare that I can't find a reasonable workaround.

Usually I describe Ansible as the tool for people who don't come from a programming background and won't be administrating a huge amount of servers. Otherwise, if you need scale then use Chef (as why would you want to have to deal with scaling AND Puppets terrible DSL).

Regarding variable precedence, it's pretty simple to grok in 2.x+, and well-documented now (it was a serious nightmare, and a very valid complaint... but isn't as much anymore).

For sharing common group_vars, what I do is my inventory passes an environment-aware variable which I include in the playbook by doing like:

`- include: "env_vars/{{ environment }}/main.yml"`

I feel I sidestepped some of the AWS modules issues simply by using Terraform. I still build all my images in Packer using the Ansible builder though.

Unfortunately the above way will load the vars at a higher precedence then group_vars. Also if you have multiple groups with the same var but differing values you will need to start loading multiple files (or you can do |default, and use an alias to the value in group_vars (which leads to even more spaghetti)).

Ever consider CFEngine?

Reply on news.ycombinator.com