I have a lot of comments in my helm chart in my repository.
I want to deliver my helm chart to others without these comments.
I am hoping to be able to do this during my CI pipeline. I have a step in my pipeline which performs the helm package command. I am hoping to have this package completely stripped of comments (in the templates, values, etc)
I have not found a way to do this directly with helm.
Is there a simple solution to my problem?
I have already considered some ways to solve it but I feel like I am missing a simple solution here.
I know I can parse the values files and re write them using something like yq which will strip all comments. But that won't work for the template files as they are not valid yaml with the helm/go templating in them.
Related
I need to install a helm chart with a key/value that is not present in one of the templates and I prefer not to edit the already existing templates.
In particular, I need to change resources.limits.cpu and resources.limits.memory in k8s-job-template.yaml but resources is not even mentioned in that file.
Is there a solution for this?
The only customizations it's possible to make for a Helm chart are those the chart author has written in; you can't make arbitrary additional changes to the YAML files.
(Kustomize allows merges of arbitrary YAML content and is built into recent kubectl, but it doesn't have some of the lifecycle or advanced templating features of Helm.)
For future reference, I found a solution to this.
Simply download the chart using the following command:
helm fetch <chart> --untar --destination /local/path/to/chart
Go to the folder /local/path/to/chart/<chartname> and make the desired changes.
After this, simply install the helm chart based on the locally edited chart:
helm install /local/path/to/chart/<chartname>
I noticed that many official charts hosted on Google or Bitnami repositories are including Username/Password/Credentials in the Values file, without giving you the ability to use an existing secret.
Can you helm me understand what would be the reason behind such approach?
As far as I know, including clear credentials in helm charts is not a best-practice.
Because it's quicker and it will work out of the box.
If you try to use the already existing secret, it has to be in the same namespace as the deployment. If it's not then it has to be copied and validate if it was moved correctly.
You should not rely on unchanged charts in production environment, as #switchboard.op mentioned.
I think most apps that are being rewritten for GoogleCloudPlatform/click-to-deploy are using secrets.
I think the maintainers expect you to override those default values when you create a release for something that's worth protecting. You can do this with your own values file or with the --set runtime flag.
I think it's not a good practice, however as mentioned by #Crou, it's quick. In general, I think each Helm Chart should give an option to define your credentials as secrets.
We do it in the Hazelcast Helm Charts by giving this option. I think that's the best-practice for Helm Charts.
I've been using terraform for a while and I really like it. I also set up Atlantis so that my team could have a "GitOps" flow. This is my current process:
Add or remove resources from Terraform files
Push changes to GitHub and create a pull request
Atlantis picks up changes and creates a terraform plan
When the PR is approved, Atlantis applies the changes
I recently found myself needing to set up a few managed Kubernetes clusters using Amazon EKS. While Terraform is capable of creating most of the basic infrastructure, it falls short when setting up some of the k8s resources (no support for gateways or ingress, no support for alpha/beta features, etc). So instead I've been relying on a manual approach using kubectl:
Add the resource to an existing file or create a new file
Add a line to a makefile that runs the appropriate command (kubectl apply or create) on the new file
If I'm using a helm chart, add a line with helm template and then kubectl apply (I didn't really like using tiller, and helm3 is getting rid of it anyway)
If I want to delete a resource, I do it manually with kubectl delete
This process feels nowhere near as clean as what we're doing in Terraform. There are several key problems:
There's no real dry-run. Using kubectl --dry-run or kubectl diff doesn't really work, it's only a client-side diff. Server-side diff functions are currently in alpha
There's no state file. If I delete stuff from the manifests, I have to remember to also delete it from the cluster manually.
No clear way to achieve gitops. I've looked at Weaveworks Flux but that seems to be geared more towards deploying applications.
The makefile is getting more and more complicated. It doesn't feel like this is scaleable.
I should acknowledge that I'm fairly new to Kubernetes, so might be overlooking something obvious.
Is there a way for me to achieve a process similar to what I have in Terraform, within the Kubernetes universe?
This is more of an opinion question so I'll answer with an opinion. If you like to manage configuration you can try some of these tools:
If you want to use existing YAML files (configurations) and use something at a higher level you can try kustomize.
If you want to manage Kubernetes configurations using Jsonnet you should take a look at Ksonnet. Keep in mind that Ksonnet will not be supported in the future.
If you want to just automatically do a helm update in an automated way, there is not a tool there yet. You will have to build something at this point to orchestrate everything. For example, we ended up creating an in house tool that does this.
We have a bunch of services that run off of the same Docker image: some long running services, some cron jobs, and a webservice.
I'm wondering what the current best practice here is? I essentially want some basic templating for reusing an image and its config, keeping all of them at the same revision (so sirensoftitan-image:{gitsha1hash} is used where gitsha1hash isn't repeated everywhere).
Should I be using a helm chart? Kustomize? Some other type of yaml templating? I want something light with as little added complexity as possible.
I found helm chart heavy compared to kustomize. Give kustomize a try, very simple and easy to use.
You can deploy the same template for different environments by adding new labels, updating the deployment objects name by prefixing with environment value. So you can have unique naming convention for different environments.
More over it uses YAML format which makes it easy to learn and adopt it.
All custom configuration goes into one YAML file unlike helm in which you manage multiple files. I personally like kustomize as it is simple and flexible and not the least comes from Google community. Give it a try
I have a helm repository set up for my CI/CD pipeline, but the one thing I am having trouble with is helm's versioning system which is focused on a semantic versioning system as in x.x.x.
I want to be able to specify tags like "staging", "latest", and "production", and although I am able to successfully upload charts with string versions
NAME CHART VERSION APP VERSION
chartmuseum/myrchart latest 1.0
Any attempt to actually access the chart fails, such as
helm inspect chartmuseum/mychart --version=latest
Generates the error:
Error: failed to download "chartmuseum/mychart" (hint: running 'helm repo update' may help)
I don't really want to get into controlled semantic versioning at this point in development, or the mess that is appending hashes to a version. Is there any way to get helm to pull non-semantically tagged chart versions?
My approach to this, where I do not want to version my chart (and subcharts) semanticaly as well is not to use helm repository at all and just pull whole chart in CI/CD from git instead. If you are publishing them to wider audience this may not suit you, but for own CI/CD which is authorized to access our repositories anyway it works like charm.
I found something that worked for me. Since the semvar allows you to append values after the last number like 0.1.0-aebcaber, I've taken to simply using 0.1.0-latest and overwriting that in chartmuseum on uploads.