Back to my earlier question, helmfiles are not used anymore by sweetops? Terraform is now used? or anchor helm chart?
We’re still maintaining helmfiles for customers, but we’re consolidating on terraform for most of the use-cases we had for backing services.
Opinionated, self-contained Terraform root modules that each solve one, specific problem - terraform-aws-components/modules/alb-controller at master · cloudposse/terraform-aws-components
The primary driver for this is we can almost never deploy a helm release without some other infrastructure level dependencies.
Some of the common examples are:
• IAM roles (to manage route53, read from SSM, upload or pull from ECR)
• RDS, Redis, S3 (for stateful backends)
• Route53 zones (for use with
• KMS keys (for use with
• ACM certificates (for use with
Create a helm release resource. Contribute to cloudposse/terraform-helm-release development by creating an account on GitHub.
We’re trying to mitigate what @Erik Osterman (Cloud Posse) mentioned by using K8s objects for cloud services. Therefore we can bake them into the app charts or create standalone charts. Since GCP is our main platform we’re leveraging Config Connector for this purpose. Probably Crossplane is another option here, however, they have an abstraction that makes helm charts redundant. We are not yet convinced to switch to it - too much effort was put on helm-related stuff)).
Hi, I’m trying to exclude a “test” file from rendering in helmfile when running helmfile template ex.
metadata: name: my-test-pod annotations: "helm.sh/hook": test
Is there a way to exclude tests from rendering during helm template or exclude the path via a .helmignore (or another way)?
Note that this would be applied to all releases of the corresponding helmfile. Afaik there’s no way how you can specify custom helm arguments per helmfile-release.
You might be able to work around that by putting the affected release(s) in a separate sub-helmfile, but I never tried that.
Well, but there is