feat(docker): add basic docker support

[desaintmartin]

Here is a first try of #1350 as a simpler alternative / first step than #1170

Here are some notes:

• Scope is much smaller than Docker #1170: only having a production container image
• It's a two-stages image, instead of the separated "composer" stage of Docker #1170. If you think this could easily be done, feel free to point me to the right direction, but I was not able to properly separate build from serve (due to always needing to build extensions...) edit: https://hub.docker.com/_/composer/ recommends doing what is done in this pr, so everything seems ok, and I now delete development packages.
• cron in included within the container, which seems to be a very good compromise but may not be ideal in some rare situations
• I'm assuming that SQLite is used and a data volume is mounted and config can be customized (mounted as volume). I haven't tried with external database.
• It's not using fpm but ol' good apache. I'm assuming this is ok for now.

What do you think?

Potential next steps if this gets merged:

• image building & hosting automation to GitHub Container Registry using Github Actions (I can do)
• Kubernetes compatibility through Helm Chart with dedicated database (I can do)
• dev-container
• profit and glory

[netlify]

✅ Deploy Preview for selfoss canceled.

Name	Link
🔨 Latest commit	2910891
🔍 Latest deploy log	https://app.netlify.com/sites/selfoss/deploys/65441d7039c136000849f091

[jtojnar]

Thanks for the contribution.

Still the main obstacle is that I do not understand how users that want Docker expect to use the image so I have no way of evaluating whether the PR fits that.

Do people just run docker commands manually? Or use something like docker-compose? How do they handle updates? What are security considerations? How do people configure software? How do they manage data backups?

[jtojnar]

I do not really like these huge blacklists with patterns that are not relevant. Maybe just copy what we need. Or better copy the result on npm run dist, which also prunes the vendor/ directory.

[desaintmartin]

I've reduced the blacklist. Usually we want to "copy everything relevant" (COPY . .) without having to bother for new / changed directories, although the opposite is also valid.

[jtojnar]

IIUC, each RUN creates a new layer which is suboptimal https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#minimize-the-number-of-layers

[desaintmartin]

Indeed, but having more separate, atomic layers with fine-grained COPY is far better than a few non-atomic layers. Each layer actually add a few bytes (technically speaking, a layer is a tar file, and all layers of an image are mounted on top of the previous ones)

[jtojnar]

Does cron run multiple instances or wait for the old one to finish? If the former, that sounds like a recipe for #967. Either way running every minute is probably too frequent.

[desaintmartin]

cron here is the good old Vixie / ISC cron, so it is quite dumb and launches the command even if the old one have not finished. We could use some locking here, let me add it.

[jtojnar]

This looks too messy for my taste. At minimum we should use a service manager like https://gitlab.com/radek-sprta/docker-selfoss does.

Ideally, the whole thing would be fully declarative like #1271 but I still need to figure out how to use s6-rc service manager.

[desaintmartin]

Actually, the more I think about it, the more I think maybe we should NOT try to deal with it from inside of the container. A container is supposed to be simple and run one thing, and put cron AND apache on the same container is more of a hack. At worse, one still have to configure its own cron, at best we can automate further through another container in the future.

What's your opinion?

[dxlr8r]

could have another container doing that job. For Kubernetes, you could simply use a CronSet.

[desaintmartin]

A few months later, let me try to answer.

Still the main obstacle is that I do not understand how users that want Docker expect to use the image so I have no way of evaluating whether the PR fits that.

I understand this issue. Maybe I can just say that I'm a Kubernetes contributor (see my profile) and my production clusters manage ~15000 running containers right now, if that helps. Of course I don't want to pretend to be someone here! ;)

Do people just run docker commands manually? Or use something like docker-compose? How do they handle updates? What are security considerations? How do people configure software? How do they manage data backups?

It really depend, some use docker-compose, some use raw docker/containerd commands, some use Kubernetes either directly or through Helm, some use home NAS like synology to manage containers for them, but all of them use container image definition.

I'm going to update a bit the PR to be more up-to-date and take into account your suggestions!

[desaintmartin]

Notes:

• I haven't included a docker healthcheck. I am not sure it is always wanted. On kubernetes, healthcheck are a completely different system anyway
• I disabled cron, so we still have to do it like today. Much more atomic / simpler like a container is supposed to be, much less surprise / bugs.
• php:8.2-apache image, built on top of debian:12-slim, is 710MB (!!), final image is 770MB so 60MB more than upstream image, which is not bad, relatively speaking (absolutely speaking, this is huge, but this seems to be how it works today).
• I now drop root, according to production good practices
• We need minimalistic documentation, just tell me where you want it to be.
• To build it: docker build --tag selfoss:docker-beta .
• To run it: docker run --rm --name my-selfoss -p 80:80 -v data:/var/www/html/data selfoss:docker-beta

[desaintmartin]

Hello @jtojnar, would you have any time to review this PR?