6 ms·

Programming with string templates, in a highly complex and footgun-rich markup language, is one of the things I find most offputting about the DevOps ecosystem.

by pkkm 1y ago

sph 1y ago
I believe Satan itself decided to mix YAML, Jinja and Turing-complete logic when it created Ansible. It truly is the sendmail of the modern era.
- senderista 1y ago
  Several years ago when I was writing a deployment system for a cloud distributed database, I tried to automate everything with Ansible playbooks and the Ansible "API" (LOL). I pretty quickly gave up on implementing anything but the most trivial logic in templated YAML and switched to Python (wrapping maximally-dumb Ansible playbooks) for everything nontrivial.
- Fizzadar 1y ago
  You might like pyinfra.
  - mdaniel 1y ago
    Just about every time someone complains about ansible, there's a comment to plug this project but pyinfra seems to opt-out of the cloud provisioning part, instead delegating to its terraform connector, which drags in all the nonsense that entails. That makes it not only less useful but (IMHO) a horrible name for a project that only does "remote execution" and not infrastructure. The fact that it's even missing @aws @azure @gcp connectors further solidifies "who is the audience for this thing?"
    - sph 1y ago
      Not everyone runs cloud servers. pyinfra seems to fit my needs like a glove, so I guess I am the intended audience. I never liked the provisioning overlap Ansible has with Terraform, so it makes sense to me: provisioning servers with tf, configure them with another tool, whether it’s ansible or pyinfra. Well, at least in theory
    - sofixa 1y ago
      > Just about every time someone complains about ansible, there's a comment to plug this project but pyinfra seems to opt-out of the cloud provisioning part Which Ansible is absolutely atrocious at, so that makes sense. Use the best tool for the job (so Terraform, maybe Pulumi/tfcdk if you hate your future self/future teammates for infra.
    - Fizzadar 1y ago
      There’s a lot more to infra than the cloud, pyinfra is designed to work in any of these environments not just the over-abstracted, over-hyped cloud. There’s plenty of good tools for setting up the infra, any pyinfra can easily be integrated.
nicktelford 1y ago
This is why I generally use Terraform for Kubernetes. It's not perfect, but it's miles better than the various different YAML-templating solutions (Kustomize, Helm) popular in the Kubernetes ecosystem.
- mdaniel 1y ago
  Two different stateful recordkeeping control planes with disparate opinions about the current state of the world. What can go wrong.
  - sofixa 1y ago
    To be fair one of the most common ways of managing Kubernetes clusters and what is deployed on them is to use ArgoCD, which gives you the same issue of dual stateful control planes. Even more fun is if you then run your Kubernetes cluster on top of a VM orchestrator such as vSphere, that way you have multiple layers of stateful control planes and compute orchestrators fighting each other.

Programming with string templates, in a highly complex and footgun-rich markup language, is one of the things I find most offputting about the DevOps ecosystem.

by pkkm 1y ago

Programming with string templates, in a highly complex and footgun-rich markup language, is one of the things I find most offputting about the DevOps ecosystem.

sph 1y ago

I believe Satan itself decided to mix YAML, Jinja and Turing-complete logic when it created Ansible. It truly is the sendmail of the modern era.

senderista 1y ago
Several years ago when I was writing a deployment system for a cloud distributed database, I tried to automate everything with Ansible playbooks and the Ansible "API" (LOL). I pretty quickly gave up on implementing anything but the most trivial logic in templated YAML and switched to Python (wrapping maximally-dumb Ansible playbooks) for everything nontrivial.
Fizzadar 1y ago
You might like pyinfra.
- mdaniel 1y ago
  Just about every time someone complains about ansible, there's a comment to plug this project but pyinfra seems to opt-out of the cloud provisioning part, instead delegating to its terraform connector, which drags in all the nonsense that entails. That makes it not only less useful but (IMHO) a horrible name for a project that only does "remote execution" and not infrastructure. The fact that it's even missing @aws @azure @gcp connectors further solidifies "who is the audience for this thing?"
  - sph 1y ago
    Not everyone runs cloud servers. pyinfra seems to fit my needs like a glove, so I guess I am the intended audience. I never liked the provisioning overlap Ansible has with Terraform, so it makes sense to me: provisioning servers with tf, configure them with another tool, whether it’s ansible or pyinfra. Well, at least in theory
  - sofixa 1y ago
    > Just about every time someone complains about ansible, there's a comment to plug this project but pyinfra seems to opt-out of the cloud provisioning part Which Ansible is absolutely atrocious at, so that makes sense. Use the best tool for the job (so Terraform, maybe Pulumi/tfcdk if you hate your future self/future teammates for infra.
  - Fizzadar 1y ago
    There’s a lot more to infra than the cloud, pyinfra is designed to work in any of these environments not just the over-abstracted, over-hyped cloud. There’s plenty of good tools for setting up the infra, any pyinfra can easily be integrated.

nicktelford 1y ago

This is why I generally use Terraform for Kubernetes. It's not perfect, but it's miles better than the various different YAML-templating solutions (Kustomize, Helm) popular in the Kubernetes ecosystem.

mdaniel 1y ago
Two different stateful recordkeeping control planes with disparate opinions about the current state of the world. What can go wrong.
- sofixa 1y ago
  To be fair one of the most common ways of managing Kubernetes clusters and what is deployed on them is to use ArgoCD, which gives you the same issue of dual stateful control planes. Even more fun is if you then run your Kubernetes cluster on top of a VM orchestrator such as vSphere, that way you have multiple layers of stateful control planes and compute orchestrators fighting each other.