Do I need to include repositories field in Helmfile, If it is the local helm chart and It would not be needed to be donwloaded?
Right now I have folloving helmfile.yaml:
repositories:
- name: system-test
url: https://github.com/test/test.system.configuration.git
releases:
- name: system-test-release
chart: ./charts/test
namespace: system-test
values:
- ./charts/test/values.yaml
The repositories: would only get used if you're actually pulling a chart from that repository; for example
releases:
- name: end-to-end
chart: system-test/end-to-end
If you're just referring to local charts with filesystem paths, the repositories: don't get used.
Related
I have a following helmfile and I want for nexus, teamcity-server, nexus, hub to be depended on certificates chart
releases:
- name: certificates
createNamespace: true
chart: ./charts/additional-dep
namespace: system
values:
- ./environments/default/system-values.yaml
- ./environments/{{ .Environment.Name }}/system-values.yaml
- name: hub
chart: ./charts/hub
namespace: system
values:
- ./environments/default/system-values.yaml
- name: nexus
chart: ./charts/nexus
namespace: system
values:
- ./environments/default/system-values.yaml
- ./environments/{{ .Environment.Name }}/system-values.yaml
dependsOn:
- certificates
- name: teamcity-server
chart: ./charts/teamcity-server
namespace: system
values:
- ./environments/default/system-values.yaml
- ./environments/{{ .Environment.Name }}/system-values.yaml
dependsOn:
- certificates
I have tried to use dependsOn in helmfile.yaml, however it has resulted in errors
Helmfile calls this functionality needs:, so
releases:
- name: certificates
...
- name: nexus
needs:
- certificates
...
This means the certificates: chart needs to be successfully installed before Helmfile will move on to nexus or teamcity-server. This is specific to Helmfile, so you're allowed to helm uninstall certificates and Helm itself won't know about the dependency. It also doesn't establish any sort of runtime dependency between the two charts, so if something happens later that causes certificates to fail, nexus and the other dependents won't be automatically stopped.
I'm looking for insights for the following situation...
I have one ArgoCD application pointing to a Git repo (A), where there's a values.yaml;
I would like to use the Helm templates stored in a different repo (B);
Any suggestions/alternatives on how to make this work?
I think helm dependency can help solve your problem.
In file Chart.yaml of repo (A), declares dependency (chart of repo B)
# Chart.yaml
dependencies:
- name: chartB
version: "0.0.1"
repository: "https://link_to_chart_B"
Link references:
https://github.com/argoproj/argocd-example-apps/tree/master/helm-dependency
P/s: You need add repo chart into ArgoCD.
The way we solved it is by writing a very simple helm plugin
and pass to it the URL where the Helm chart location (chartmuseum in our case) as an env variable
server:
name: server
config:
configManagementPlugins: |
- name: helm-yotpo
generate:
command: ["sh", "-c"]
args: ["helm template --version ${HELM_CHART_VERSION} --repo ${HELM_REPO_URL} --namespace ${NAMESPACE} $HELM_CHART_NAME --name-template=${HELM_RELEASE_NAME} -f $(pwd)/${HELM_VALUES_FILE} "]
you can run the helm command with the flag of --repo
and in the ArgoCD Application yaml you call the new plugin
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: application-test
namespace: infra
spec:
destination:
namespace: infra
server: https://kubernetes.default.svc
project: infra
source:
path: "helm-values-files/telegraf"
repoURL: https://github.com/YotpoLtd/argocd-example.git
targetRevision: HEAD
plugin:
name: helm-yotpo
env:
- name: HELM_RELEASE_NAME
value: "telegraf-test"
- name: HELM_CHART_VERSION
value: "1.8.18"
- name: NAMESPACE
value: "infra"
- name: HELM_REPO_URL
value: "https://helm.influxdata.com/"
- name: HELM_CHART_NAME
value: "telegraf"
- name: HELM_VALUES_FILE
value: "telegraf.yaml"
you can read more about it in the following blog
post
I have the following:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: crm
namespace: default
spec:
project: default
source:
repoURL: <my url
targetRevision: argocd
path: argocd/
destination:
server: https://kubernetes.default.svc
namespace: default
syncPolicy:
syncOptions:
- CreateNamespace=true
automated:
selfHeal: true
prune: true
This is working to connect argocd with the main branch, but what if I want it to follow a different branch instead?
Thank you.
No, your example above will make the ArgoCD application load content from:
repo: "<my url"
targetRevision (branch): "argocd"
path (ie. path in repo): "argocd/"
meaning it won't load from main/master branch!
Use targetRevision to specify the branch you require if source is a Git repo URL.
See excerpt from the ArgoCD application.yaml docs:
# Source of the application manifests
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git # Can point to either a Helm chart repo or a git repo.
targetRevision: HEAD # For Helm, this refers to the chart version.
path: guestbook # This has no meaning for Helm charts pulled directly from a Helm repo instead of git.
Im trying to setup a Helm chart repo using Github pages. Everything appears to work fine with generating the index.yaml etc via Github Actions, awesome.
index.yaml
apiVersion: v1
entries:
test:
- apiVersion: v1
created: "2021-08-27T09:54:44.830905882Z"
description: Testing the chart releaser
digest: b41b263d236ef9eee0a75e877982a10ea73face093b4999c6004263b041f0fad
keywords:
- test
name: test
urls:
- https://github.com/xxx/xxx/releases/download/test-0.0.9/test-0.0.9.tgz
version: 0.0.9
generated: "2021-08-27T09:54:44.587113879Z"
And a test chart
name: test
description: Testing the chart releaser
version: 0.0.9
apiVersion: v1
keywords:
- test
sources:
home:
However, when i try to add the repo using
helm repo add test https://didactic-quibble-e0daddd0.pages.github.io/
I get the error
Error: looks like "http://didactic-quibble-e0daddd0.pages.github.io/" is not a valid chart repository or cannot be reached: error converting YAML to JSON: yaml: line 188: mapping values are not allowed in this context
The URL http://didactic-quibble-e0daddd0.pages.github.io/index.yaml returns the index.yaml file described above.
Any help would be much appreciated.
Cheers
I would suggest a different procedure and hope that helps you in hosting GitHub as a Helm Repo.
I have 2 Helm charts here:
Library- this is going to be used by other helm charts as a
dependency . This I am going to host in the below example as a helm repo on GitHub
App- this is going to consume the Library chart and extra
functionality.
Library Chart: In your Library Directory
helm package libchart
helm helm repo index .
Validate the index file is created and entries are correct
more index.yaml
apiVersion: v1
entries:
libchart:
- apiVersion: v2
appVersion: 1.16.0
created: "2022-11-30T08:57:01.109116+09:00"
description: A Helm chart for Kubernetes
digest: 8aa38d70d61f81cf31627a7d7d9cc5c293f340bf01918c9a16ac1fac9fcc96e9
name: libchart
type: library
urls:
- libchart-0.1.0.tgz
version: 0.1.0
generated: "2022-11-30T08:57:01.108194+09:00"
Commit "index.yaml" and ".tgz" files to the git .
Add helm repo:
#~: helm repo add mylib --username parjun8840 --password TOPSECRET-TOKEN-FROM-GIT
https://raw.githubusercontent.com/YOURGITUSER/helm-library/master
"mylib" has been added to your repositories
#~:helm-library arjunpandey$ helm repo update
App Chart: In your App Directory
#~:appchart arjunpandey$ more Chart.yaml
apiVersion: v2
name: appchart
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"
dependencies:
- name: libchart
version: 0.1.0
repository: https://raw.githubusercontent.com/YOURGITUSER/helm-library/master
#~:appchart arjunpandey$ helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "mylib" chart repository
...Successfully got an update from the "newrelic" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading libchart from repo https://raw.githubusercontent.com/YOURGITUSER/helm-library/master
Deleting outdated charts
I am new to this group. Glad to have connected.
I am wondering if someone has experience in using an umbrella helm chart in a CI/CD process?
In our project, we have 2 separate developer contractors. Each contractor is responsible for specific microservices.
We are using Harbor as our repository for charts and accompanying container images and GitLab for our code repo and CI/CD orchestrator...via GitLab runners.
The plan is to use an umbrella chart to deploy all approx 60 microservices as one system.
I am interested in hearing from any groups that have taken a similar approach and how they treated/handled the umbrella chart in their CI/CD process.
Thank you for any input/guidance.
VR,
We use similar kind of pattern where we have 30+ microservices.
We have got a Github repo for base-charts.
The base-microservice chart has all sorts of kubernetes templates (like HPA,ConfigMap,Secrets,Deployment,Service,Ingress etc) ,each having the option to be enabled or disabled.
Note- The base chart can even contain other charts too
eg. This base-chart has a dependency of nginx-ingress chart:
apiVersion: v2
name: base-microservice
description: A base helm chart for deploying a microservice in Kubernetes
type: application
version: 0.1.6
appVersion: 1
dependencies:
- name: nginx-ingress
version: "~1.39.1"
repository: "alias:stable"
condition: nginx-ingress.enabled
Below is an example template for secrets.yaml template:
{{- if .Values.secrets.enabled -}}
apiVersion: v1
kind: Secret
metadata:
name: {{ include "base-microservice.fullname" . }}
type: Opaque
data:
{{- toYaml .Values.secrets.data | nindent 2}}
{{- end}}
Now when commit happens in this base-charts repo, as part of CI process, (along with other things) we do
Check if Helm index already exists in charts repository
If exists, then download the existing index and merge currently generated index with existing one -> helm repo index --merge oldindex/index.yaml .
If it does not exist, then we create new Helm index ->( helm repo index . ) Then upload the archived charts and index yaml to our charts repository.
Now in each of our microservice, we have a charts directory , inside which we have 2 files only:
Chart.yaml
values.yaml
Directory structure of a sample microservice:
The Chart.yaml for this microservice A looks like:
apiVersion: v2
name: my-service-A
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: 1
dependencies:
- name: base-microservice
version: "0.1.6"
repository: "alias:azure"
And the values.yaml for this microservice A has those values which need to be overriden for the base-microservice values.
eg.
base-microservice:
nameOverride: my-service-A
image:
repository: myDockerRepo/my-service-A
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 300m
memory: 500Mi
probe:
initialDelaySeconds: 120
nginx-ingress:
enabled: true
ingress:
enabled: true
Now while doing Continuous Deployment of this microservice, we have these steps (among others):
Fetch helm dependencies (helm dependency update ./charts/my-service-A)
Deploy my release to kubernetes (helm upgrade --install my-service-a ./charts/my-service-A)