i just upgraded helm to the latest version. We were still running on a version before the breaking changes of 3.7.
So far we have pushed a chart (in Azure Pipeline) into the repo (ACR) as follows:
- script: |
helm chart save Chart $(ACR_NAME).azurecr.io/helm/storage-api:$(BUILD_VERSION)
displayName: save new chart
- script: |
helm chart push $(ACR_NAME).azurecr.io/helm/storage-api:$(BUILD_VERSION)
displayName: push new chart
in this example we call the repo storage-api. But in our chart.yaml the chart name is specified like this: name: storage-chart
Since the documentation is not so deep for the new version i dont find an option to specify the name, if i append the name like before a new subfolder will be created in the ACR.
so now we push them like this:
- script: |
helm package Chart --app-version $(BUILD_VERSION) --version $(BUILD_VERSION)
displayName: save new chart version
- script: |
helm push storage-chart-$(BUILD_VERSION).tgz oci://$(ACR_NAME).azurecr.io/helm/
displayName: push new chart version
helm package ... creates a .tgz with the name specified in Chart.yaml
this has the consequence, that our repo for this service has a new name, the one which is specified in the Chart.yaml. So now its storage-chart instead of storage-api
Since we have an public ACR changing the names is no option.
Is there a way to specify the repo name in the helm command? Or do I have to change the name in `Chart.yaml``
I found out that it is no longer possible to determine the repository name.
As of v3.7, this is always derived from the chart name in chart.yaml.
see here
Related
I'm think I'm about to reinvent the wheel here. I have all the parts but am thinking: Somebody must have done this (properly) before me.
We have a a jenkins CI job that builds image-name:${BRANCH_NAME} and pushes it to a registry. We want to create a CD job that deploys this image-name:${BRANCH_NAME} to kubernetes cluster. And so now we run into the problem that if we call helm upgrade --install with the same image-name:${BRANCH_NAME} nothing happens, even if image-name:${BRANCH_NAME} now actually refers to a different sha256 sum. We (think we) understand this.
How is this generally solved? Are there best practices about this? I see two general approaches:
The CI job doesn't just create image-name:${BRANCH_NAME}, it also creates a unique tag, e.g. image-name:${BRANCH_NAME}-${BUILD_NUMBER}. The CD job never deploys the generic image-name:${BRANCH_NAME}, but always the unique image-name:${BRANCH_NAME}-${BUILD_NUMBER}.
After the CI job has created image-name:${BRANCH_NAME}, its SHA256 sum is retrieved somehow (e.g. with docker inspect or skopeo and helm is called with the SHA256 sum.
In both cases, we have two choices. Modify, commit and track a custom-image-tags.yaml file, or run helm with --set parameters for the image tags. If we go with option 1, we'll have to periodically remove "old tags" to save disk space.
And if we have a single CD job with a single helm chart that contains multiple images, this only gets more complicated.
Surely, there must be some opinionated tooling to do all this for us.
What are the ways to do this without re-inventing this particular wheel for the 4598734th time?
kbld gets me some of the way, but breaks helm
I've found kbld, which allows me to:
helm template my-chart --values my-vals.yml | kbld -f - | kubectl apply -f -
which basically implements 2 above, but now helm is unaware that the chart has been installed so I can't helm uninstall it. :-( I'm hoping there is some better approach...
kbld can also be used "fully" with helm...
Yes, the docs suggest:
$ helm template my-chart --values my-vals.yml | kbld -f - | kubectl apply -f -
But this also works:
$ cat kbld-stdin.sh
#!/bin/bash
kbld -f -
$ helm upgrade --install my-chart --values my-vals.yml --post-renderer ./kbld-stdin.sh
With --post-renderer, helm list, helm uninstall, etc. all still work.
One approach is that every build of Jenkins CI Job should create docker image with new semantic versioned image tag.
To generate the image tag, you need to tag every git commit with a semantic version which is an increment of the previous commit tag.
For Example :
Your first commit in a git repository master branch will be tagged as 0.0.1 and your docker image tag will be 0.0.1
Then when the CI build runs for the next git commit in master branch, that git commit in the git repository will be tagged as 0.0.2 and your docker image tag will be 0.0.2
Since you have single helm chart for multiple images, your CI Build can then download the latest version of your helm chart, change the docker image tag and upload the helm chart with same helm version.
If you create a new git release branch, then it should be tagged with 0.1.0 and docker image created for this new git release branch should be tagged as 0.1.0
You can use this tag in the Maven pom.xml for Java Applications as well.
Using the docker image tag, developers can checkout the correpsonding git tag to find what is the source code corresponding to that docker image tag. It will help them with debugging and also for providing fixes.
Please also read https://medium.com/#mccode/using-semantic-versioning-for-docker-image-tags-dfde8be06699
I'm following Helm's document here to install a package, a.k.a. a helm chart:
$ helm install happy-panda stable/mariadb
It's really convenient to have a ready-to-use package. But in case of a package doesn't belong to stable repo, for example appmesh-grafana then I have to do more than this:
$ helm repo add aws https://aws.github.io/eks-charts
$ helm install aws/appmesh-grafana --version 0.1.0
Therefore, it forces me surf around the internet to find repo url, package name, etc. I don't want to do it every single time!
Is there any way to specify the repo and chart to install using Chart.yaml? I prefer Chart.yaml than shell script.
The short answer is no, if a chart is not in the official repo, then you always need to add the repository first before installing the chart.
However, starting from the Helm 3, you can look for the chart directly in the Helm Hub. In your case, if you wanted to find appmesh-grafana, you can execute the following command.
$ helm search hub appmesh-grafana
URL CHART VERSION APP VERSION DESCRIPTION
https://hub.helm.sh/charts/aws/appmesh-grafana 0.1.0 6.4.3 App Mesh Grafana Helm chart for Kubernetes
But then, yes, you need to open the link, find the address, and anyway execute $ helm repo add aws https://aws.github.io/eks-charts.
Disclaimer: I'm new to Kubernetes and Helm.
I am trying to install a Helm chart using the brand new Helm Hub and for the life of me I can't figure out how this is supposed to work.
A new version of Helm (3.0) was released only a few months ago with significant changes, one of them is that it doesn't come with any repositories configured. Helm released the Helm Hub which is supposed to be a centralized service to find charts.
I am trying to install a CloudBees Jenkins chart. This is what I get when I search the hub:
[me#localhost tmp]$ helm search hub cloudbees -o yaml
- app_version: 2.222.1.1
description: The Continuous Delivery Solution for Enterprises
url: https://hub.helm.sh/charts/cloudbees/cloudbees-core
version: 3.12.0+80c17a044bc4
- app_version: 9.2.0.139827
description: A Helm chart for CloudBees Flow
url: https://hub.helm.sh/charts/cloudbees/cloudbees-flow
version: 1.1.1
- app_version: 9.2.0.139827
description: A Helm chart for CloudBees Flow Agent
url: https://hub.helm.sh/charts/cloudbees/cloudbees-flow-agent
version: 1.1.1
- app_version: 2.204.3.7
description: CloudBees Jenkins Distribution provides development teams with a highly
dependable, secure, Jenkins environment curated from the most recent supported
Jenkins release. The distribution comes with a recommended catalog of tested plugins
available through the CloudBees Assurance Program.
url: https://hub.helm.sh/charts/cloudbees/cloudbees-jenkins-distribution
version: 2.204.307
- app_version: 2.0.2
description: Helm chart for sidecar injector webhook deployment
url: https://hub.helm.sh/charts/cloudbees/cloudbees-sidecar-injector
version: 2.0.2
So it looks like the chart I am looking for is available: cloudbees-jenkins-distribution.
However, I can't find any way to install from the hub or to add a repository based on the hub output. Some of the things I've tried:
[me#localhost tmp]$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "incubator" chart repository
...Successfully got an update from the "gitlab" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
[me#localhost tmp]$ helm install myJenkins cloudbees-jenkins-distribution
Error: failed to download "cloudbees-jenkins-distribution" (hint: running `helm repo update` may help)
[me#localhost tmp]$ helm repo add cbRepo https://hub.helm.sh/charts/cloudbees
Error: looks like "https://hub.helm.sh/charts/cloudbees" is not a valid chart repository or cannot be reached: error converting YAML to JSON: yaml: line 8: mapping values are not allowed in this context
[me#localhost tmp]$ helm repo add cbRepo https://hub.helm.sh/charts/cloudbees/cloudbees-jenkins-distribution
Error: looks like "https://hub.helm.sh/charts/cloudbees/cloudbees-jenkins-distribution" is not a valid chart repository or cannot be reached: error converting YAML to JSON: yaml: line 8: mapping values are not allowed in this context
The documentation really doesn't say much about how I'm supposed to go from the Helm Hub to an installed chart. What am I missing here?
Helm Hub is NOT like a repo that you can add and install from it helm charts. It doesn't expose valid repos urls either. That's why you're getting the error message like below:
Error: looks like "https://hub.helm.sh/charts/cloudbees" is not a valid chart repository ...
when you're trying to run helm repo add on https://hub.helm.sh based urls.
I know it may seem pretty confusing but it just works like that, by its very design. Please refer to this discussion on Github. Specifically this comment explains it a bit more and I hope it also answers your question:
hub.helm.sh is not the helm repo, so it will not work the you trying,
it is only meant to view and search for charts. check in there for
chart repository and it that way, then you will be able to install the
charts.
Unfortunatelly the official helm documentation doesn't explain it well enough. It mentions only:
helm search hub searches the Helm Hub, which comprises helm charts
from dozens of different repositories.
But it shows "no explanation how to get from helm search repo which shows hub.helm.sh to helm repo add which magically shows the a new url to use." - as one user wrote in the thread mentioned above.
Despite that Helm hub doesn't have a convenient way to get a repository url, it has a github repo that contains all vendors repository in one file.
We can use that fact to create a workaround, that you can improve using automation tools like bash,awk, sed, perl, python, etc.
Let's imagine we want to get the helm chart url using helm v3 and command line tools only.
(helm3 is just a symlink for helm v3.1.2)
Let's get the repository name for jenkins distribution for cloudbees vendor
$ helm3 search hub jenkins --max-col-width 1000 | grep cloudbees | tr "\t" "\n"
https://hub.helm.sh/charts/cloudbees/cloudbees-core
3.12.0+80c17a044bc4
2.222.1.1
The Continuous Delivery Solution for Enterprises
https://hub.helm.sh/charts/cloudbees/cloudbees-jenkins-distribution
2.204.307
2.204.3.7
CloudBees Jenkins Distribution provides development teams with a highly dependable, secure, Jenkins environment curated from the most recent supported Jenkins
release. The distribution comes with a recommended catalog of tested plugins available through the CloudBees Assurance Program.
As we can see the chart page on Helm hub is
# https://hub.helm.sh/charts/cloudbees/cloudbees-jenkins-distribution
# ^^^^^^^^^
so we can assume that repository name is also cloudbees
Let's find the url for cloudbees helm repository
$ curl -s https://raw.githubusercontent.com/helm/hub/master/config/repo-values.yaml | grep cloudbees
- name: cloudbees
url: https://charts.cloudbees.com/public/cloudbees
Now we can add this repository using helm repo command:
$ helm3 repo add cloudbees https://charts.cloudbees.com/public/cloudbees
"cloudbees" has been added to your repositories
Don't forget to update:
$ helm3 repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "cloudbees" chart repository
Update Complete. ⎈ Happy Helming!⎈
To find the chart name let's repeat search in repo
$ helm3 search repo jenkins
NAME CHART VERSION APP VERSION DESCRIPTION
cloudbees/cloudbees-jenkins-distribution 2.204.307 2.204.3.7 CloudBees Jenkins Distribution provides develop...
cloudbees/cloudbees-core 3.12.0+80c17a044bc4 2.222.1.1 The Continuous Delivery Solution for Enterprises
And finally we can install the chart:
$ helm3 install cloudbees/cloudbees-jenkins-distribution --version 2.204.307
Happy Helming3 ! :)
True, helm search hub cloudbees does not return the url of the repo.
What you can do from the result of helm search hub cloudbees is helm install $urlFromBefore:
$ helm search hub cloudbees
- app_version: 2.222.1.1
description: The Continuous Delivery Solution for Enterprises
url: https://hub.helm.sh/charts/cloudbees/cloudbees-core
...
$ helm install cloudbees https://hub.helm.sh/charts/cloudbees/cloudbees-core
from helm/helm#7419
To get the repo url, you can do the search on https://hub.helm.sh or
do a work around when you want the repo url from console:
$ curl https://hub.helm.sh/api/chartsvc/v1/charts/search?q=rancher | json_pp
The repo url is in key url in repo (data[...].attributes.repo.url).
(json_pp is optional. It pretty prints json, which helps me to read it.)
Now continue with
# variables names show the place in json output from above
helm repo add $data_attributes_repo_name $data_attributes_repo_url
helm repo update
helm install $data_attributes_repo_name/$data_attributes_name
I have a private helm repo using apache, after migrating to helm3 I cannot install/search charts anymore.
Using helm v3
helm repo list
NAME URL
mas http://localhost:8080/charts/
helm search repo mas/devops-openshift
No results found
Using helm 2.*
helm search -r mas/devops-openshift
NAME CHART VERSION APP VERSION DESCRIPTION
mas/devops-openshift 7.0.0 Devops (OpenShift)
Same happens when using "helm install" command, it cannot find the charts.
I guess it could be something related to the helm repo index file. Maybe helmv3 is expecting a different structure? But same happen when generating index file from helmv3.
Thanks all for the answers but I've found the issue.
My repository were using development version of the charts so I had something like this 1.0.0-pre.dev (Semantic Versioning 2.0.0).
By default helm 3 does not look at non production charts.
You have to set the flag -devel. something like:
helm search repo mas/devops-openshift --devel
While migrating from helm 2 to helm 3 remove private repo and add it after migration, then run helm repo update to refresh repository file.
If the chart is available locally, run helm repo index <DIR> --url <your_repo_url> to create new index.yaml for this repository.
Running helm env will show you the directory where the repository.yamlis located so check if the file is generated correctly.
I do have multiple repositories like Project1, Project2, Project3.
I do have 1 repository where Helm charts are managed (deploy1).
I do this on Azure DevOps.
I now added a build Pipepline to Project1, which is working as expected.
Now i went into project deploy1 and wanted to create a new Release Pipeline, which is to be triggerd from Project1 build.
Now i would want to use the Helm chart from deploy1 to deploy to my kubernetes Cluster based on the published build from Project1.
Is this possible, is this even the correct approach?
Some might suggest that i keep the Helm Chart within Project1, but isnt that counter intuitive?
I also do not want to keep a copy of the same Helm Chart in every Projectn repository.
As i understood a Helm chart is used to manage a set of kubernetes Resources.
And if possible i would like to be able to remove my entire applicationstack, Project1, Project2 & Project3 with the unstill command from 1 Helm file.
well, I'd suggest using Azure Container Registry (acr) to store helm charts. That way you can use repo1 as source for all helm charts, when you'd build the charts, you'd package them and push to the acr. Then in other releases you'd use the same acr to pull those charts and apply them.
this can be done with az cli:
helm package --version $(build.buildId) --destination $(build.artifactStagingDirectory) %name%
az acr helm push %name%.tgz
you can pull them with az as well