This PR presents the result of 16 hrs of work to reshape it into a more "production-ready" form. This is achieved by dropping the support for local source builds.

• Local container builds for developing Pretalx should be implemented with development containers in the upstream repository.

Additionally, following the 12factor.net approach of designing web applications, it is useful to consider the parts of the application self-contained and independent from external systems. Why the reliance on a cron scheduler may be defeating the purpose of separating concerns in containers.

A convention designed for running jobs in distributed systems is to use a worker queue and have it be triggered with timers. Fortunately Celery is already used for dispatching asynchronous tasks. Its Celery Beat feature can also be used to regularly schedule jobs, removing the need for a separate cron container.

• Handling Periodic Tasks in Django with Celery and Docker | TestDriven.io
• Periodic Tasks — Celery 5.4.0 documentation

I'm especially invested in this, since the cron implementation took a quarter of the time from the overall procedure and is prone to fail in a container.

• Celery Beat is to be implemented upstream as well.

To complete the move towards "cloud-native", distributed application design, it is also advisable to implement the database URL pattern, which had been introduced by Heroku and is of good ease, convenience and use to DevOps people.

• jazzband/dj-database-url is to be implemented in Pretalx.

Further on, now that the application setup is more decoupled, images are more lightweight and deterministic, due to switching to pinned release versions of Pretalx, it becomes possible to imagine to further

• automate the image build pipeline, e.g. by reacting to upstream releases and to offer versioned, tagged releases here, too.

I'm thinking of the way how these two repositories react to their upstream, adapted from Node to Python:

• federated-wiki/wiki-oci-base
• federated-wiki/wiki-oci-distribution

In case you agree with the follow ups as outlined above, I'd step ahead and open respective issues.

More inspiration could be taken from allmende/docker-fiduswriter.

This looks generally good to me.

While in a Kubernetes environment I'm used to having CronTab jobs running periodic stuff in containers, I don't see too much harm in having crontab running within the application container. That is, unless someone wants to create replicas of the application container and run the worker things isolated on their own, but I doubt that this would be possible with Pretalx, so this is likely a non issue.

For static file serving I think that nginx as a separate container (or any other simple file server like halverneus/static-file-server) is a good choice, instead of the main container doing the serving.

👍 Overall, I'm happy with these changes.

Could we maybe consider having a GitHub workflow which automates new releases to DockerHub (or GitHub Packages)? This would avoid having bug-fixes merged into main but then not released for several months.

The last two days have brought new image variants, local build scripts, a build pipeline and the proposed migration hints to the README.

For now, the pipeline can be triggered manually and by releases.

• Release 2024-05-23 · allmende/pretalx-docker
• 2024-05-23 · allmende/pretalx-docker@8bea177

The other push and PR triggers have been removed, until this has been settled a little.

The image variants reintroduce the standalone image for easing the migration in existing setups.

The extended and cron variants from the "stock" image have also been applied to the standalone one for sake of completeness. This means people can potentially remove the external dependency to cron from their existing containerised application setup.

There are also new example contexts to build the application from source, of which one mimics the current state of affairs, namely context/source/standalone/Dockerfile.debian.local, which is included in the overlay compose/build/source/standalone.local.yml.

The one interesting for me to be able to run from main, including the fix for pretalx/pretalx#1773, is compose/build/source/extended.cron.remote.yml.

The README tries to be complete and concise at the same time. Due to the multiple ways to approach the repository, its images, the Compose manifests and also the CI pipeline(s) we cannot be exhaustive here. Maybe the setup is complex enough to consider adding separate documentation to docs/.

This is now ready for merge with approaching the 50th hour. I would leave the click to another maintainer, as I wouldn't want to misuse the gained write-permission to the repository with my own and first contribution.

What's left for future cycles is roughly:

• Optimisation of the build pipeline, esp. with regards to code deduplication
• Automation of the build triggers, esp. with regards to upstream releases
• Reintroduction of PR and push triggers for selected scenarios
• Individual pipelines per image?
• Testing and fixing of the functionalities of the containers, esp. for the supervisor and cron variants. Experience tells there might be regressions somewhere.
• Testing and refinement of the instructions in the readme
• Testing and documenting a successful migration path from the original standalone image to one of its new variants
• Testing and documenting a successful migration path from the original source build to one of the new examples

Also new usages for the repository appear within reach:

• Running containerised end-to-end integration tests for the containers, but also possibly for pretalx itself
• Examples for using these images with other container schedulers, such as Nomad or Kubernetes

Ultimately, I will also raise conversations upstream about implementing Celery Beat, which would allow to get rid of the cron dependency entirely, and about a containerised development environment and why one might like that.

Thank you for taking the time to look into this. The two points you mention reflect very well the course this has taken:

• I came here to find a pretalx setup for a live instance.
• It wasn't existing, so I built on what was there: a source build and a coupled standalone container.
• I was adding the option to build from versioned releases and then parametrised it, removing prior art.
• Then I needed support for a custom source build (from a remote git repository) and used the earlier implementation as inspiration, also readding the standalone build and a build from local source.
• Due to me trying to document these Container development use cases, the readme got out of band.

I agree that the primary use case of this repository should be to show how to run pretalx in a real-world environment, in opposition to its earlier use for building an opinionated standalone image from a tightly coupled git submodule source. The effort of trying to answer to all possible use cases makes the individual choices harder to stand out.

If there would be support by upstream, we would maybe do good in considering to move the Container image + CI manifests for base/ and default/ into the main pretalx repository, in order to build local development containers and the release artifacts where development and releases happen. This repository could then focus on the Compose setup and the image variants.

I agree to decouple the image development instructions into separate docs/ and to render the readme much more accessible for casual visitors.

Allow me to respond to the suggestions in the next two weeks. We are not in a rush here and can take the time to introduce these breaking changes in a well-documented and -tested fashion.

@almereyda Just a ping: are you still planning to work on this?

Yes, I got sick back then. I'm currently refactoring and documenting a few Django Compose repositories, from which I plan to backport some of their patterns here, including more simple documentation, as suggested.

I'd say at least another two months, given life circumstances.

Thanks a lot for the PR. IMO it's over complicated for docker compose repo. It took me quite a while to understand what goes where.

I made it work: extended version with configured traefik TriplEight#3
Can create a PR here after this one is merged.

Great suggestions and ideas in that branch, esp. around the auxiliary services cron, Traefik. I'm also considering using more of Compose's newer include: and extends: statements to organise and layer these setups more clearly. Recent work on Funkwhale ¹ has shown these might come in handy for a Django application with many varying dependencies.

¹ fix(DX): Docker mac compatibility, dynamic DNS + Debian image (!2799) · Merge requests · funkwhale / funkwhale · GitLab

I especially like how you shoretend the healthcheck: commands, the added x-pretalx-depends-on anchor for further deduplication and how you include multiple YAML anchors with <<:

As a style note to TriplEight#3, I would like to suggest to refrain from using the env_file: pattern, where you map the whole environment into each service's container, including all variables present in .env. With calling the variables in the environment: key individually, we only provide the selected needed blend to each service, which are pulled from the .env file. ¹ With avoiding custom configuration and resorting to conventional defaults, we also keep the command to run everything shorter.

Also defining loggin: settings for short-lived development environments appears redundant.

The FQDN for docker.io images were intentionally provided for compatibility with Podman.

I'll be able to return work on this from mid November on, with aiming for a merge in the first two weeks of December.