initContainers not updated

[zenire]

I just started using Keel and it updates my containers fine. However, it seems like Keel doesn't watch/update my initContainers in the same deployment.

How can I get Keel to also watch/update the attached initContainers?

[rusenask]

It doesn't do that at the moment. Should init container update result in running it after the update?

[zenire]

Our initContainer uses the same image as the "main" container. In our case both should be updated.

I understand there can be situations for people where the initContainer uses a different image. I think there should be an option to influence this behaviour. Example:

keel.sh/initUpdate true = run if initContainer changed false = only update but dont run unless main container changed

[zenire]

I was wondering if you have had time to look into it @rusenask

[gaby]

I just ran into this same issue.

[zenire]

I believe the code at https://github.com/keel-hq/keel/blob/772fcdf2a9c44b20c7b69c76ea6c59f4301211ba/internal/k8s/converter.go#L32 needs to be adjusted to change initContainters as well.

Something like: d.Spec.Template.Spec.InitContainers[index].Image = image

[frankwiles]

Any chance this will get addressed in the near future?

We rolled out Keel with some clients of ours and after a couple of days of head scratching finally figured out this was our issue. I can however completely understand how it wasn't initially thought about.

If I took the time to write PR would it likely be accepted @rusenask ?

[rusenask]

PR would definitely be accepted and appreciated :) I managed to avoid init containers in my projects but I do understand that some frameworks and applications need them.

[frankwiles]

Awesome I'll get started on it. Yeah most of our deployments are Python apps, typically Django, so we use the same container with 2-4 different init container commands to do things like apply database migrations, put static media into place, ensure settings/environment are correct (and scream loudly to the right places if they are not), etc.

[arnediekmann]

@frankwiles may I ask if you managed to get this to work already? Just realized that init containers are not considered in Keel which is especially bad for us since we copy the main artifact into the application server on startup and thus can't get unattended upgrades for that application to work.

[frankwiles]

Yep we've got the same problem. I got a local dev environment setup, but then had to move house so haven't had a chance to get back to it yet. I'm hoping to find some time to devote to it over the next few days but if you can get to it quicker go for it!

[frankwiles]

Sadly my client has opted to use another method for deployment, so I won't be able to contribute a PR on this after all.

[arnediekmann]

Oops, totally forgot on the issue. Thank you for your updates. Haven't got the time to work on this yet, but I might take a stab at it once I do.

[lonk]

Hi ! Any updates on that ? We also use initContainers to launch our database migrations :)

[scottmando2000]

bump on this

[gaby]

I'm also still running into this issue.

[scottmando2000]

Bump since this issue is still relevant...

[TyrantWave]

Bump / plus one on this - not having initContainers updated is a big issue when it comes to Django projects which use them for migrations

[Startouf]

I have a more specific use case where I would require to have a different image tag on my container VS initContainer and have keel update their versions accordingly (same repo, different pre-release tag)

My use case : I am deploying a single page application on kubernetes that needs webpack compilation inside a node init container, and serving static files using a nginx container.

My deployment looks like

initContainers:
        - name: compile-application
          # Image resolves to something like 0.2.0-build-image-staging
          image: "{{ .Values.buildImage.repository }}:{{ .Values.buildImage.imageVersion }}-build-image-{{ .Values.appEnvironment }}"
          volumeMounts:
            - mountPath: {{ .Values.buildImage.mountPath }}
              name: dist
containers:
        - name: {{ .Chart.Name }}
          # Image resolves to something like 0.1.0-nginx-staging
          image: "{{ .Values.nginxImage.repository }}:{{ .Values.nginxImage.imageVersion }}-nginx-{{ .Values.appEnvironment }}"
          imagePullPolicy: {{ .Values.nginxImage.pullPolicy }}
          volumeMounts:
            - mountPath: {{ .Values.nginxImage.mountPath }}
              name: dist
              readOnly: true

The idea: when deploying review apps, I do not know in advance my service URLs, so I cannot build (webpack) my frontend application beforehand (I need env variables like API URL, etc that will be compiled by webpack). My init container builds an image and moves the dist files to a shared volume. Then, my app container starts, mounts this shared volume, and nginx serves these compiled files (I need nginx to add stuff like security headers, etc).

For simplicity, I have made a single docker repository that contains those different kinds of images. Not sure this is a really good pattern, but it makes sense.

Example:

suppose I have currently deployed

• 0.2.0-build-image-staging (on the init container)
• 0.1.0-nginx-staging (on the running container)

If I push a tag 0.2.1-build-image-staging the app should update itself to use

• 0.2.1-build-image-staging (on the init container)
• 0.1.0-nginx-staging (on the running container)

If I push a tag 0.1.1-nginx-staging the app should update itself to use

• 0.2.0-build-image-staging (on the init container)
• 0.1.1-nginx-staging (on the running container)

I am actually expecting my nginx image to change very rarely and it would be fine to handle its changes manually, but my build-image contains my app code which is supposed to change very often.

Final note

What behavior is expected when there are x containers in the same pod (not necessarily just 1 init container + 1 container) ?

[scottmando2000]

bump on this

[avaly]

I have an use case similar to the one described in this comment.

Ideally keel should be configurable via annotations which containers / init containers it should update and which it should not update.

[scottmando2000]

bump

since this issue is still relevant

[neverexists]

If someone is interested i found this fork for Keel that works also with initcontainers. https://github.com/Infinytum/keel

Here the Docker image: https://hub.docker.com/repository/docker/infinytum/keel

I added to the deployment the annotation: metadata: annotations: keel.sh/initContainers: true

and will be updated also the initcontainer's image.

[scalp42]

@neverexists any chance to see a Helm chart for your fork? 🙏

[neverexists]

I'm sorry but it is not a my fork.

[scalp42]

@neverexists my bad, meant to ping @nilathedragon 😅

[nilathedragon]

@scalp42

Would it suffice to change this portion of the values.yaml of the existing chart when installing?

image:
  pullPolicy: Always # Or whatever you prefer
  repository: infinytum/keel
  tag: main

There is nothing I need to change in the Helm chart as far as I'm aware :)

[jdinsel-xealth]

@nilathedragon: I discovered an unmerged change you made that seems to address this issue. Do you have plans to open a pull request?