3 ms·

"Pre-k8s, that was just bespoke scripts, e.g., in something like Ansible" How are these 'bespoke scripts' but helm charts are not 'bespoke'? Or do you conside

• deathanatos 4y ago
  Because they're completely different things you're comparing. The functionality that I describe as having to have built out as part of Ansible (needing to check that the deploy succeeded, and not move on to the next VM if not) is not present in any Helm chart (as that's not the right layer / doesn't make sense), as it's part of the deployments controller's logic. Every k8s Deployment (whether from a Helm chart or not) benefits from it, and doesn't need to build it out.
  • morelisp 4y ago
    > needing to check that the deploy succeeded, and not move on to the next VM if not It's literally just waiting for a port to open and maybe check for an HTTP response, or run an arbitrary command until non-zero status; all the orch tools can do that in some way.
    • deathanatos 4y ago
      … there's a difference between "can do it" and "is provided." In the case of either k8s or VMs, I supply the health check. There's no getting around that part, really. But that's it in the case of k8s. I'm not building out the logic to do the check, or the logic to pause a deployment if a check fails: that is inherent to the deployments controller. That's not the case with Ansible/Salt/etc.¹, and I end up re-inventing portions of the deployments controller every time. (Or, far more likely, it just gets missed/ignored until the first time it causes a real problem.) ¹and that's not what these tools are targetting, so I'm not sure it's really a gap, per se.