5 ms·

What are the benefits over using helmfile? https://helmfile.readthedocs.io/ https://helmfile.readthedocs.io/

• seabrookmx 3y ago
  Or dependencies? https://helm.sh/docs/helm/helm_dependency/ https://helm.sh/docs/helm/helm_dependency/
  • MuffinFlavored 3y ago
    Or just kubectl apply a bunch of yaml files? or argocd / helm charts?
    • SOLAR_FIELDS 3y ago
      Those two are not like what grandparent is saying. Helm dependencies are native to helm like docker compose is native to docker. Kubectl apply a bunch of yaml files is like saying “run a bunch of docker files instead of docker compose” and argocd isn’t the same realm, that is a hosted solution that requires a remote k8s cluster. I guess you could run it locally but you would be making commits to a git repo for iteration which would be slow annoying and painful. It solves an entirely different problem set to this one, it’s not meant to solve local dev iteration loops. The comparison of helm compose and helm dependencies is much more apples to apples as they essentially solve the exact same problem in similar way
      • MuffinFlavored 3y ago
        Well said/good points. What's your preferred way to orchestrate deployments/configs/resources/workloads into k8s?
        • SOLAR_FIELDS 3y ago
          Into k8s? I do like Argo/flux as it’s declarative. It works for most normal use cases. I would recommend that if you have a typical use case go with that first. Declarative and pull based deploys are quite powerful. For local/hybrid stuff there’s things like Tilt that can be combined with a push based approach that is a simple helm install. If you have something fancy though you’ll probably have to write some custom orchestration pushed based tooling. I would reach for a tool like Dagster, Prefect or Temporal for that kind of thing. You probably don’t need custom orchestration tooling unless you’re doing multi tenant multi cloud deployments though. Even terraform is a decent deploy tool if you don’t want to go all in on helm/flux/argo etc. I would especially recommend that approach if your use cases are not fancy and you already use terraform. It would be push based but still declarative and quite simple to use, albeit clunky and a bit slow like everything terraform.
          • MuffinFlavored 3y ago
            > Even terraform is a decent deploy tool Terraform for k8s pods/workloads instead of `kubectl apply` YAML files?
            • SOLAR_FIELDS 3y ago
              Terraform gives you better declarative state management out of the box. In other words you can view and rollback changes to configuration in a more and robust way. It’s also nice to do both infra provisioning and deployments in the same place. Helm has historically been pretty garbage at handing robust rollbacks. It’s not something I recommend for every setup, as like I mentioned terraform is pretty clunky and slow but I could see it being a pretty good solution for a place that already uses terraform heavily and doesn’t have a complex deploy story.
        • deleted 3y ago
          [deleted]
• remram 3y ago
  > Helmfile complies to Semantic Versioning 2.0.0 in which v0.x means that there could be backward-incompatible changes for every release. You're not following semver if your software is used in production, and you recommend using it in production, but you label it 0.x. I hate this cowardice of "we believe in semver" and "we stick to the area of it where everything goes". That's the exact thing it was created to avoid! https://semver.org/#how-do-i-know-when-to-release-100 https://semver.org/#how-do-i-know-when-to-release-100