Helm Hooks vs. Replicated Helm Chart Weighting

Packaging an application
1

I have a job that needs to run before other workloads can be deployed. Helm has a few different features for sequencing including hooks and hook weights that are supported by Replicated. I know Replicated also provides functionality for sequencing individual helm chart installations. It seems most of this could also be accomplished using a parent chart and using hooks/weights internally in the chart. What is the preferred or recommended method for sequencing deployment of helm-based workloads?

2

In general, if you can use the Helm internal features to manage sequencing, that is the preferred / recommended path to use. The weight field in a Replicated kind: HelmChart resource should only be used if the sequencing problem cannot be solved with internal hooks and weights across subcharts of a parent chart.

3

There are several moment when ordering is important, I use a combination of all, but probably the hooks alone would also work.

Weights and --wait --wait-for-jobs (prevents manifests to be sent to the cluster if the previous thing is not done yet)

apiVersion: kots.io/v1beta1
kind: HelmChart
metadata:
  name: besu-manager
spec:
  chart:
    name: besu-manager
    chartVersion: 0.1.0
  helmVersion: v3
  useHelmInstall: true
  weight: 20
  helmUpgradeFlags:
    - --wait
    - --wait-for-jobs
    - --timeout=120s
  values:

Hooks in my custom charts to wait for things to be up and running, this hook makes sure my pod does not launch until vault is up so that the agent injector mutating web hook is active.

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ include "besu-manager.fullname" . }}-vault-hook
  labels:
    {{- include "besu-manager.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
spec:
  template:
    metadata:
      name: {{ include "besu-manager.fullname" . }}-vault-hook
      labels:
        {{- include "besu-manager.labels" . | nindent 8 }}
    spec:
      restartPolicy: Never
      containers:
        - name: vault-listener
          image: "alpine"
          command: [sh, -c]
          args:
            - for i in $(seq 1 200); do nc -z -w3 vault 8200 && sleep 15 && exit 0 || sleep 15; done; exit 1

Extra init containers you can set on many external charts, this is an example from vault where I need to pre provision a db connection which will fail if it is not up.

extraInitContainers:
        - name: postgres-listener
          image: "alpine"
          command: [sh, -c]
          args:
            - for i in $(seq 1 200); do nc -z -w3 postgresql 5432 && exit 0 || sleep 15; done; exit 1
1 Like