https://argo-cd.readthedocs.io/en/stable/user-guide/helm/

[ ] [ ]
Skip to content
logo
Argo CD - Declarative GitOps CD for Kubernetes
Helm
[                    ]
Initializing search

 
GitHub
logo Argo CD - Declarative GitOps CD for Kubernetes
 
GitHub

  * Overview
  * Understand The Basics
  * Core Concepts
  * Getting Started
  * [ ] Operator Manual Operator Manual
      + Overview
      + Architectural Overview
      + Installation
      + Declarative Setup
      + Ingress Configuration
      + [ ] User Management User Management
          o Overview
          o Auth0
          o Microsoft
          o Okta
          o OneLogin
          o Keycloak
          o OpenUnison
          o Google
          o RBAC Configuration
      + Security
      + TLS configuration
      + Cluster Bootstrapping
      + Secret Management
      + High Availability
      + Disaster Recovery
      + Git Webhook Configuration
      + Resource Health
      + Resource Actions
      + Custom Tooling
      + Custom Styles
      + Metrics
      + Notifications
      + Troubleshooting Tools
      + [ ] Server Configuration Parameters Server Configuration
        Parameters
          o Argocd server
          o Argocd application controller
          o Argocd repo server
          o Argocd dex
          o Additional configuration method
      + [ ] Upgrading Upgrading
          o Overview
          o v2.0 to 2.1
          o v1.8 to v2.0
          o v1.7 to 1.8
          o v1.6 to 1.7
          o v1.5 to 1.6
          o v1.4 to 1.5
          o v1.3 to 1.4
          o v1.2 to 1.3
          o v1.1 to 1.2
          o v1.0 to 1.1
  * [*] User Guide User Guide
      + Overview
      + Tools
      + Kustomize
      + [ ] Helm Helm Table of contents
          o Declarative
          o Values Files
          o Helm Parameters
          o Helm Release Name
          o Helm Hooks
              # Hook Tips
          o Random Data
          o Build Environment
          o Helm plugins
          o Helm Version
          o Helm --pass-credentials
      + Ksonnet
      + Jsonnet
      + Plugins
      + Tool Detection
      + Projects
      + Private Repositories
      + GnuPG verification
      + Automated Sync Policy
      + Diffing Customization
      + Orphaned Resources Monitoring
      + Compare Options
      + Sync Options
      + Parameter Overrides
      + Build Environment
      + Tracking and Deployment Strategies
      + Resource Tracking
      + Resource Hooks
      + Selective Sync
      + Sync Phases and Waves
      + Sync Windows
      + Generating Applications with ApplicationSet
      + Automation from CI Pipelines
      + App Deletion
      + Best Practices
      + Status Badge
      + Add external URL
      + Command Reference
  * [ ] Developer Guide Developer Guide
      + Overview
      + Code Contribution Guide
      + Toolchain Guide
      + Release Process And Cadence
      + Running ArgoCD locally
      + Debugging a Remote ArgoCD Environment
      + Use Gitpod
      + API Docs
      + E2E Tests
      + Managing Dependencies
      + Continuous Integration (CI)
      + Releasing
      + Site
      + Static Code Analysis
      + Contribution FAQ
  * FAQ
  * Security Considerations
  * Support
  * Roadmap
  * Releases 
  * Blog 

Table of contents

  * Declarative
  * Values Files
  * Helm Parameters
  * Helm Release Name
  * Helm Hooks
      + Hook Tips
  * Random Data
  * Build Environment
  * Helm plugins
  * Helm Version
  * Helm --pass-credentials

 

HelmP

DeclarativeP

You can install Helm charts through the UI, or in the declarative
GitOps way. Here is an example:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sealed-secrets
  namespace: argocd
spec:
  project: default
  source:
    chart: sealed-secrets
    repoURL: https://bitnami-labs.github.io/sealed-secrets
    targetRevision: 1.16.1
    helm:
      releaseName: sealed-secrets
  destination:
    server: https://kubernetes.default.svc
    namespace: kubeseal

Values FilesP

Helm has the ability to use a different, or even multiple
"values.yaml" files to derive its parameters from. Alternate or
multiple values file(s), can be specified using the --values flag.
The flag can be repeated to support multiple values files:

argocd app set helm-guestbook --values values-production.yaml

Note

Values files must be in the same git repository as the Helm chart.
The files can be in a different location in which case it can be
accessed using a relative path relative to the root directory of the
Helm chart.

Helm ParametersP

Helm has the ability to set parameter values, which override any
values in a values.yaml. For example, service.type is a common
parameter which is exposed in a Helm chart:

helm template . --set service.type=LoadBalancer

Similarly, Argo CD can override values in the values.yaml parameters
using argo app set command, in the form of -p PARAM=VALUE. For
example:

argocd app set helm-guestbook -p service.type=LoadBalancer

Helm Release NameP

By default, the Helm release name is equal to the Application name to
which it belongs. Sometimes, especially on a centralised ArgoCD, you
may want to override that name, and it is possible with the
release-name flag on the cli:

argocd app set helm-guestbook --release-name myRelease

or using the releaseName for yaml:

source:
    helm:
      releaseName: myRelease

Important notice on overriding the release name

Please note that overriding the Helm release name might cause
problems when the chart you are deploying is using the
app.kubernetes.io/instance label. ArgoCD injects this label with the
value of the Application name for tracking purposes. So when
overriding the release name, the Application name will stop being
equal to the release name. Because ArgoCD will overwrite the label
with the Application name it might cause some selectors on the
resources to stop working. In order to avoid this we can configure
ArgoCD to use another label for tracking in the ArgoCD configmap
argocd-cm.yaml - check the lines describing
application.instanceLabelKey.

Helm HooksP

    v1.3 or later

Helm hooks are similar to Argo CD hooks. In Helm, a hook is any
normal Kubernetes resource annotated with the helm.sh/hook
annotation.

Argo CD supports many (most?) Helm hooks by mapping the Helm
annotations onto Argo CD's own hook annotations:

  Helm Annotation                         Notes
helm.sh/hook:       Supported as equivalent to argocd.argoproj.io/
crd-install         hook: PreSync.
helm.sh/hook:       Not supported. In Helm stable there are 3 cases
pre-delete          used to clean up CRDs and 3 to clean-up jobs.
helm.sh/hook:       Not supported. Never used in Helm stable.
pre-rollback
helm.sh/hook:       Supported as equivalent to argocd.argoproj.io/
pre-install         hook: PreSync.
helm.sh/hook:       Supported as equivalent to argocd.argoproj.io/
pre-upgrade         hook: PreSync.
helm.sh/hook:       Supported as equivalent to argocd.argoproj.io/
post-upgrade        hook: PostSync.
helm.sh/hook:       Supported as equivalent to argocd.argoproj.io/
post-install        hook: PostSync.
helm.sh/hook:       Not supported. Never used in Helm stable.
post-delete
helm.sh/hook:       Not supported. Never used in Helm stable.
post-rollback
helm.sh/hook:       Not supported. No equivalent in Argo CD.
test-success
helm.sh/hook:       Not supported. No equivalent in Argo CD.
test-failure
helm.sh/            Supported. See also argocd.argoproj.io/
hook-delete-policy  hook-delete-policy).
helm.sh/            No supported. Never used in Helm stable
hook-delete-timeout
helm.sh/hook-weight Supported as equivalent to argocd.argoproj.io/
                    sync-wave.

Unsupported hooks are ignored. In Argo CD, hooks are created by using
kubectl apply, rather than kubectl create. This means that if the
hook is named and already exists, it will not change unless you have
annotated it with before-hook-creation.

'install' vs 'upgrade' vs 'sync'

Argo CD cannot know if it is running a first-time "install" or an
"upgrade" - every operation is a "sync'. This means that, by default,
apps that have pre-install and pre-upgrade will have those hooks run
at the same time.

Hook TipsP

  * Make your hook idempotent.
  * Annotate crd-install with hook-weight: "-2" to make sure it runs
    to success before any install or upgrade hooks.
  * Annotate pre-install and post-install with hook-weight: "-1".
    This will make sure it runs to success before any upgrade hooks.
  * Annotate pre-upgrade and post-upgrade with hook-delete-policy:
    before-hook-creation to make sure it runs on every sync.

Read more about Argo hooks and Helm hooks.

Random DataP

Helm templating has the ability to generate random data during chart
rendering via the randAlphaNum function. Many helm charts from the
charts repository make use of this feature. For example, the
following is the secret for the redis helm chart:

data:
  {{- if .Values.password }}
  redis-password: {{ .Values.password | b64enc | quote }}
  {{- else }}
  redis-password: {{ randAlphaNum 10 | b64enc | quote }}
  {{- end }}

The Argo CD application controller periodically compares Git state
against the live state, running the helm template <CHART> command to
generate the helm manifests. Because the random value is regenerated
every time the comparison is made, any application which makes use of
the randAlphaNum function will always be in an OutOfSync state. This
can be mitigated by explicitly setting a value, in the values.yaml
such that the value is stable between each comparison. For example:

argocd app set redis -p password=abc123

Build EnvironmentP

    v1.4

Helm apps have access to the standard build environment via
substitution as parameters.

E.g. via the CLI:

argocd app create APPNAME \
  --helm-set-string 'app=${ARGOCD_APP_NAME}'

Or via declarative syntax:

  spec:
    source:
      helm:
        parameters:
        - name: app
          value: $ARGOCD_APP_NAME

Helm pluginsP

    v1.5

Argo CD is un-opinionated on what cloud provider you use and what
kind of Helm plugins you are using, that's why there are no plugins
delivered with the ArgoCD image.

But sometimes it happens you would like to use a custom plugin. One
of the cases is that you would like to use Google Cloud Storage or
Amazon S3 storage to save the Helm charts, for example: https://
github.com/hayorov/helm-gcs where you can use gs:// protocol for Helm
chart repository access.

In order to do that you have to prepare your own ArgoCD image with
installed plugins.

Example Dockerfile:

FROM argoproj/argocd:v1.5.7

USER root
RUN apt-get update && \
    apt-get install -y \
        curl && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

USER argocd

ARG GCS_PLUGIN_VERSION="0.3.5"
ARG GCS_PLUGIN_REPO="https://github.com/hayorov/helm-gcs.git"

RUN helm plugin install ${GCS_PLUGIN_REPO} --version ${GCS_PLUGIN_VERSION}

ENV HELM_PLUGINS="/home/argocd/.local/share/helm/plugins/"

You have to remember about HELM_PLUGINS environment property - this
is required for plugins to work correctly.

After that you have to use your custom image for ArgoCD installation.

Helm VersionP

Argo CD will assume that the Helm chart is v3 (even if the apiVersion
field in the chart is Helm v2), unless v2 is explicitly specified
within the Argo CD Application (see below).

If needed, it is possible to specifically set the Helm version to
template with by setting the helm-version flag on the cli (either v2
or v3):

argocd app set helm-guestbook --helm-version v3

Or using declarative syntax:

spec:
  source:
    helm:
      version: v3

Helm --pass-credentialsP

Helm, starting with v3.6.1, prevents sending repository credentials
to download charts that are being served from a different domain than
the repository.

If needed, it is possible to specifically set the Helm version to
template with by setting the helm-pass-credentials flag on the cli:

argocd app set helm-guestbook --helm-pass-credentials

Or using declarative syntax:

spec:
  source:
    helm:
      passCredentials: true

 
Previous Kustomize
 
Next Ksonnet
Made with Material for MkDocs