> Why this over Ansible? It's a long story :)
As someone who just spent the last year of his life using Ansible, something tells me I already know this story. I feel for you.
As someone who just spent the last year of his life using Ansible, something tells me I already know this story. I feel for you.
- 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.
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).
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.
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.
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.
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).