Helmfile: Ordering

Created on 10 May 2018  Â·  18Comments  Â·  Source: roboll/helmfile

Firstly,
Thanks for this project, it's awesome - you've saved me a big headache.

However, quick Q. I need to control the order in which the charts are deployed.

Is there any way (hacky or not) that I can do that, without using labels and having two helmfile runs?

Most helpful comment

Yes it would so long as the files were processed in order 👌

On Fri, 25 May 2018, 8:30 am KUOKA Yusuke, notifications@github.com wrote:

@Stono https://github.com/Stono Hi. Thank you so much for the detailed
explanation!
Makes sense.

Btw, would this suggested feature #151 (comment)
https://github.com/roboll/helmfile/issues/151#issuecomment-391165364
help your use-case, too?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/roboll/helmfile/issues/137#issuecomment-391967309,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABaviRcqT5qDyVTJxY9m4HSUjtGLu8vQks5t17MWgaJpZM4T5faL
.

All 18 comments

not currently

@Stono Hi! Just curious but why do you want the ordering?

Hello @mumoshu!
Great question, let me try and explain...

We have a helmfile which can take an empty kubernetes cluster and turn it into what we call the "delivery platform", however the components need to be deployed in a certain order, for a variety of reasons:

  • We need to deploy a chart which contains CustomResourceDefinitions before we deploy a chart which creates instances of those CustomResources
  • We use a service mesh, which uses a MutatingWebhookHandler in order to inject the sidecar into Pods as they're deployed. This needs to be configured before any Deployments, ReplicaSets or Pods are deployed.

As a result, we've ended up with a bit of a hacky script that looks like this:

echo "Creating MutatingWebhookHandler certificates..."
cd manual
./install-sidecar-injection.sh
cd ..

echo "Deploying istio (first phase)..."
helmfile --selector component=istio,order=1 sync --args="--wait --timeout=300"

echo "Adding the MutatingWebhookHandler..."
kubectl apply -f manual/istio-sidecar-injector-with-ca-bundle.yaml

echo "Deploying istio (second phase)..."
helmfile --selector component=istio,order!=1 sync --args="--wait --timeout=300"

echo "Deploying everything else..."
helmfile --selector component!=istio sync --args="--wait --timeout=300"

screen shot 2018-05-11 at 09 22 26

@Stono Hi. Thank you so much for the detailed explanation!
Makes sense.

Btw, would this suggested feature https://github.com/roboll/helmfile/issues/151#issuecomment-391165364 help your use-case, too?

Yes it would so long as the files were processed in order 👌

On Fri, 25 May 2018, 8:30 am KUOKA Yusuke, notifications@github.com wrote:

@Stono https://github.com/Stono Hi. Thank you so much for the detailed
explanation!
Makes sense.

Btw, would this suggested feature #151 (comment)
https://github.com/roboll/helmfile/issues/151#issuecomment-391165364
help your use-case, too?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/roboll/helmfile/issues/137#issuecomment-391967309,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABaviRcqT5qDyVTJxY9m4HSUjtGLu8vQks5t17MWgaJpZM4T5faL
.

To throw in another usage case, we have Helm charts for Roles and RoleBindings. IIRC, the latter will fail if you try to bind a Role that doesn't exist yet.

We also Chart StorageClasses, which have to be the very first thing provisioned (our default storage class, in particular).

I have a WIP PR for #151 with lexical ordering at #160. Would you mind taking a look?

@gtaylor what's the logic for having roles and rolebindings in separate charts and not in the same chart?

You don't always need both.

I don't understand why you would have roles, but not bind them to anything. Seems like they go together to me and I would also enable/disable them through flags instead of having them in separate charts, but I don't have your full use-case.

We create roles on clusters for specific user types at the point of cluster bootstrapping, ClusterRoleBindings are added at a later date.

Roles and RoleBindings don't need to go in separate charts however, I believe you can do a rolebinding to a non-existent role and k8 just resolves them later when the role exists.

247 would allow more granular control over ordering.

@Stono Can we close this as resolved via #160 #266, and #339?

As answered in #591, I think sub-helmfiles can be used for ordering. It was known to be very repetitive, but after #587 the repetition is greatly reduced.

Closing this as resolved, but please feel free to reopen or create an another issue if you have any other request! Thanks.

@mumoshu looked at the docs but not 100% sure how ordering works.

Can I just do this and they will be installed in the order that they are specified?

releases:
- name: chart-that-installs-a-crd
  chart: stable/chart-that-installs-a-crd
- name: chart-that-uses-that-crd
  chart: chart-that-uses-that-crd

Nope. Releases are handled concurrently per --concurrency N where the default value for N is the number of releases in each helmfile.yaml :)

Thus basically you can achieve some ordering by setting concurrency to 1 :) But probably it's better to do something like this:

helmfiles:
- install-crd.yaml

releases:
- name: chart-that-uses-that-crd
   chart: chart-that-uses-that-crd

@andrewnazarov Thanks for the comment! Yeah I think that's correct.

Also see #715 that will give you concurrency AND ordering without splitting helmfile.yaml files.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

daaain picture daaain  Â·  3Comments

cilerler picture cilerler  Â·  4Comments

willejs picture willejs  Â·  4Comments

sstarcher picture sstarcher  Â·  3Comments

machine424 picture machine424  Â·  3Comments