Stateless Docker Container

[icrc-fdeniger]

At startup, the container modifies some files in /service/api/build/static/webapp.
On Kubernetes/OpenShift these folder are in read only mode ( stateless container approach).

A quick and dirty solution is to add this command in the image:

RUN chmod -R a+rwX /service/api/build/static/webapp

Describe the solution you'd like
The image should be fully operational at startup without requiring a build phase.

This issue might be related to #9141 and could potentially be resolved using a multi-stage build process.

[mrjones-plip]

@Hareet or @dianabarsan - thoughts on @icrc-fdeniger question?

It was my understanding that our images either bind mount key points they need to write to or are otherwise immutable and ok to reboot with 100% data loss of the non persistent data.

[icrc-fdeniger]

it "seems" that some build process is completed at container startup. If it's the case it should done at build image phase.

[mrjones-plip]

Ah - I see what you mean now about a true read only container in k8s or OpenShift vs an ephemerally writable docker container.

Do you have an audit of all the instances you've had to change? Taking a look around, I see for example this entry point creates a directory.

I can also see how #9141 could relate to possibly fix this if we do some updates - thanks for making the comparison and searching for other tickets!

[icrc-fdeniger]

thanks @mrjones-plip for your feedbacks.
The issue is that the content of the folder /service/api/build/static/webapp is modified at startup ( some js files). Normally these content should be changed and be all computed at docker build stage.

[dianabarsan]

Hi @icrc-fdeniger

The reason why /service/api/build/static/webapp is modified at startup is because we generate the service-worker document, which is served statically from this folder. The service-worker depends on configuration that exists in the instance database, such as enabled languages, custom translations, logos and so on. This document cannot be generated at the docker build stage.

One potential change I see is that we should still generate the service-worker at runtime, but not serve it statically, and instead store it in memory (??) and have a custom API route to serve it.

[mrjones-plip]

@dianabarsan - I think one of the other work-arounds we had thought of might be to bind mount all the directories in the container that get written to? For sure a work around, but this should unblock any users like @icrc-fdeniger that want fully read only containers that can't write to anywhere except to bind mounted or named volumes.

(Apologies if i'm using too Docker-centric terms and not K8S-centric terms!)

[icrc-fdeniger]

thanks @dianabarsan and @mrjones-plip
as @mrjones-plip a solution could be to write these info in a dedicated folder so that we can bind a volume on it and this volume can deleted at each restart ( or not :))