Install requires a lot of space

[lognaturel]

Related to getodk/docs#1668, for now we'll document this, but it would be great to improve.

Some drivers I can think of:

• the postgres migration still being in play. We should make a plan to remove it. Maybe in mid-2024?
• Enketo and Central using different node base images. Hopefully that will be addressed soon and won't need to happen again
• frontend needing to be rebuilt for several config changes. Would be great if we could ship a built artifact instead.

[matthew-white]

frontend needing to be rebuilt for several config changes.

A config change specific to Frontend should be pretty rare, right? Currently that's just for SSO I believe. I think docker image prune will also recapture that space.

[matthew-white]

Ah I see, even if you change a config to Backend, Frontend will get rebuilt if you run docker compose build. But as long as docker image prune is run, won't the user be OK?

[lognaturel]

as long as docker image prune is run, won't the user be OK?

I think so "at rest"? But they'll need more space than maybe expected at some point in time. I'm not entirely sure how big the impact is.

[spwoodcock]

For FMTM at HOT I bundle ODKCentral into our stack.

To do that I have a customised backend Dockerfile based on the one in this repo (service.dockerfile), to optimise the build.
Building the image from this repo --> 1.2GB
Building the optimised image --> 372MB

Base Image

A good starting point is using the slim images provided by node.
The node:18.17 image is 352MB, while 18.7-slim is 75.37MB currently.
It just requires three additional packages to be installed (not bundled in slim):

• gpg
• procps
• netcat-traditional

Efficient Layering

Dockerfile directives should be bundled together where possible for more efficient layer caching, for two reasons:

• Each new directive generates a new layer. There is overhead associated with very layer, and inefficiencies when stacking multiple layers. Also if a previous layer generates temp files that are not cleaned up, then they are carried forward to the next layer.
• Each layer is generated as an intermediate image during build. These bloat the filesystem (stored in the Docker image cache) & will increase the space required to actually do the build.

Frontend

I also bundle a central-frontend. It's only 74.9MB.

Contribution

Would it be useful for me to make a PR, is someone already working on this?

Also, as a separate but related issue, it would be great to have the images built and published to something like Github container registry. Is this something you would consider?

The only reason I had to generate my custom Dockerfiles is because there is no official distribution of ODK Container Images.
I build when ODK Central is updated & tag within the container registry of FMTM.
It would simplify our stack if we just used official images & contributed to updates here 😄

[spwoodcock]

I just saw #546 so that answers my questions around providing pre-built images.

As for optimising the current dockerfiles to use multi-stage, efficient layer caching, and slim images, the offer is still there!

[lognaturel]

Ah yes, I forgot we weren’t on slim images! I don’t remember the details of why not but it’s great to see they may not apply anymore anyway.

Please do submit a PR with your ideal setup and let’s take a look at it together.

[lognaturel]

Going to close this for now. Using the slim images will help and then the next thing will probably be to use pre-built images.