Helm install in certain order

Question

I am trying to create a Helm Chart with the following resources:

1. Secret
2. ConfigMap
3. Service
4. Job
5. Deployment

These are also in the order that I would like them to be deployed. I have put a hook in the Deployment so that it is post-install, but then Helm does not see it as a resource and I have to manually manage it.

The Job needs the information in the Secret and ConfigMap, otherwise I would make that a pre-install hook. But I can't make everything a hook or nothing will be managed in my release.

Does anyone have a solution or idea to be able to manage all of the resources within the Helm release AND make sure the Job finishes before the Deployment begins?

My only thought right now is two make two Charts: One with 1-4 and the second with 5 which would depend on the first.

Answer 1

Warning: The order of v2 & v3 is very different. So you should be carefully.

You should check the order from latest release with InstallOrder like below helm/pkg/releaseutil/kind_sorter.go

P/s: You can easily guest the order of "Uninstall" via var UninstallOrder KindSortOrder = []string{...} with reversely order.

// Those occurring earlier in the list get installed before those occurring later in the list.
var InstallOrder KindSortOrder = []string{
    "PriorityClass",
    "Namespace",
    "NetworkPolicy",
    "ResourceQuota",
    "LimitRange",
    "PodSecurityPolicy",
    "PodDisruptionBudget",
    "ServiceAccount",
    "Secret",
    "SecretList",
    "ConfigMap",
    "StorageClass",
    "PersistentVolume",
    "PersistentVolumeClaim",
    "CustomResourceDefinition",
    "ClusterRole",
    "ClusterRoleList",
    "ClusterRoleBinding",
    "ClusterRoleBindingList",
    "Role",
    "RoleList",
    "RoleBinding",
    "RoleBindingList",
    "Service",
    "DaemonSet",
    "Pod",
    "ReplicationController",
    "ReplicaSet",
    "Deployment",
    "HorizontalPodAutoscaler",
    "StatefulSet",
    "Job",
    "CronJob",
    "IngressClass",
    "Ingress",
    "APIService",
}

Answer 2

Helm tries to install things in a certain order, but doesn't check if pods / deployments / jobs are running / completed before moving on. Also note that a chart and its dependencies are installed simultaneously, so you cannot use a chart with a dependency to re-order how Helm installs resources.

You can use chart hooks to change the order, but these aren't managed resources. In my case, the problem was that we needed custom resources up, then we needed a short script to run, and then we needed to start our deployments. With --wait, if the pod the script was in completed, Helm would mark the upgrade/install as a failure and rollback. The solution in this case was just to use a Job instead of a Pod, which commenters on that issue had more problems with than I did, and then accept that the deployments would restart a few times before everything finally became ready.

Helm 3.7 install order:

1. Namespace
2. NetworkPolicy
3. ResourceQuota
4. LimitRange
5. PodSecurityPolicy
6. PodDisruptionBudget
7. ServiceAccount
8. Secret
9. SecretList
10. ConfigMap
11. StorageClass
12. PersistentVolume
13. PersistentVolumeClaim
14. CustomResourceDefinition
15. ClusterRole
16. ClusterRoleList
17. ClusterRoleBinding
18. ClusterRoleBindingList
19. Role
20. RoleList
21. RoleBinding
22. RoleBindingList
23. Service
24. DaemonSet
25. Pod
26. ReplicationController
27. ReplicaSet
28. Deployment
29. HorizontalPodAutoscaler
30. StatefulSet
31. Job
32. CronJob
33. Ingress
34. APIService
35. this closed git issue tells us CustomResources are last to be installed.

Source. Only difference from above is more resource types and the ServiceAccount got pushed up slightly in the list.

Answer 3

Helm collects all of the resources in a given Chart and it's dependencies, groups them by resource type, and then installs them in the following order (see here - Helm 2.10):

1. Namespace
2. ResourceQuota
3. LimitRange
4. PodSecurityPolicy
5. Secret
6. ConfigMap
7. StorageClass
8. PersistentVolume
9. PersistentVolumeClaim
10. ServiceAccount
11. CustomResourceDefinition
12. ClusterRole
13. ClusterRoleBinding
14. Role
15. RoleBinding
16. Service
17. DaemonSet
18. Pod
19. ReplicationController
20. ReplicaSet
21. Deployment
22. StatefulSet
23. Job
24. CronJob
25. Ingress
26. APIService

During uninstallation of a release, the order is reversed (see here).

Following this logic, in your case when your Job resource is created, both the Secret and the ConfigMap will already be applied, but Helm won't wait for the Job to complete before applying the Deployment. If you split your Chart to two parts (1-4, 5) and install them sequentially you would still have the problem of the Deployment being possibly applied before the Job is completed. What I would suggest is splitting your Chart to two parts (1-3, 4-5), in which the the Job has a pre-install hook, which would make sure it completes before your Deployment is applied.