3 ms·

I read the addendum. I think it was a good, understandable rant. When I had to invent a complex HA-solution including infra for an ERP product I went with Ansi

by cess11 3y ago

I read the addendum. I think it was a good, understandable rant. When I had to invent a complex HA-solution including infra for an ERP product I went with Ansible, and yeah, fine, it worked, but it was also really hard to figure out a good design for the orchestration. YAML is awful, I actually hacked up a decrepit YAML editor for the specific usecase to not have to deal with formatting details and whitespace myself. If I had stayed there I would probably have designed an XSD/XML to YAML pipeline to have an easier time structuring configuration and allowing quick edits to certain values in the Ansible scripts. I.e. reinventing a GUI administration of the code. I've also been on OpenShift, and time spent on fiddling with details in YAML on the team was a lot. The tradeoff was fine, it allowed us to run test stacks with several Oracle databases and a swarm of supporting applications locally with relative ease. But I don't find the IAC way to be some kind of messiah, or really have much novelty. We've always had more or less arbitrary DSL:s for common remote operations, right? Sometimes in bash, sometimes in PHP, sometimes INI, sometimes XML. Sysadmin is a mess, and you should say thanks to your dedicated sysadmins every day for putting up with it.

sgarland 3y ago
Terraform isn’t Ansible, and vice-versa. I’ve seen both being shoehorned to do the job of the other, and it isn’t pretty. Terraform should spin up infra, period. The image it uses may well be custom-built with something like Ansible + Packer, and that’s fine – great, even. Terraform should not be used to manage configuration of the image or its applications. Similarly, just because you can use Ansible to do anything (hello, builtin.shell) doesn’t mean you should. You should ideally make idempotent plays, of course, and if it gets to the point that you’re spending as much time post-provisioning as the TF deploy, consider baking a new image.
- cess11 3y ago
  Sure, there are many tools in this area, and they can be used in many ways. We used Ansible for infra management, we ran it against a VMWare cluster, not just patching up virtual servers managed by something else. To a larger extent than we did we could have designed the system through VMWare GUI, including a fair amount of automation but opted not to, in part because higher-ups thought it sounded nice to have YAML in git and IAC and all that jazz. As far as I understood Ansible at the time idempotency in provisioning was easiest to achieve through a let it crash style, VMWare errored on naming being in use already and broke Ansible, and things like that.
- xorcist 3y ago
  Not sure about the vice versa part. Ansible is pretty much a superset of Terraform. I've used in multiple places to manage vm:s and other cloud services and generally been happy with the setup.

by cess11 3y ago

sgarland 3y ago

Terraform isn’t Ansible, and vice-versa. I’ve seen both being shoehorned to do the job of the other, and it isn’t pretty. Terraform should spin up infra, period. The image it uses may well be custom-built with something like Ansible + Packer, and that’s fine – great, even. Terraform should not be used to manage configuration of the image or its applications. Similarly, just because you can use Ansible to do anything (hello, builtin.shell) doesn’t mean you should. You should ideally make idempotent plays, of course, and if it gets to the point that you’re spending as much time post-provisioning as the TF deploy, consider baking a new image.

cess11 3y ago
Sure, there are many tools in this area, and they can be used in many ways. We used Ansible for infra management, we ran it against a VMWare cluster, not just patching up virtual servers managed by something else. To a larger extent than we did we could have designed the system through VMWare GUI, including a fair amount of automation but opted not to, in part because higher-ups thought it sounded nice to have YAML in git and IAC and all that jazz. As far as I understood Ansible at the time idempotency in provisioning was easiest to achieve through a let it crash style, VMWare errored on naming being in use already and broke Ansible, and things like that.
xorcist 3y ago
Not sure about the vice versa part. Ansible is pretty much a superset of Terraform. I've used in multiple places to manage vm:s and other cloud services and generally been happy with the setup.