Run Tandoor as a rootless Podman Quadlet
Replaces the docker_container role with a Quadlet systemd user unit, and moves state from /var/lib/tandoor to ~/podman-data/tandoor. Tandoor's entrypoint starts as root and drops privileges, but root is what ends up owning the data, so keep-id maps container root onto the connecting user and everything stays owned by tanshu rather than a subuid. The play does not run the rootless-Podman prerequisites: they are the shared task file at caddy/roles/podman, and a host that has run caddy/playbook.yml has them. Both integrations go through the shared includes rather than local copies -- caddy/roles/register for the network and the Caddy drop-in, postgres/roles/ attach for the database -- so this app writes the same drop-in bytes as every other service and a new service never means editing Caddy or Postgres. Three ordering details are load-bearing: - The register include runs in pre_tasks, before the unit is started. Quadlet fails unit *generation*, not merely startup, when a referenced .network file does not exist yet, so starting first reports "unit not found". - roles/postgres flushes handlers immediately after attaching. The restart that joins Postgres to this network is a handler, so by default it runs at the end of the play -- after the app has already started and failed to resolve `db`. - The role waits for a real HTTP response from inside the container instead of trusting systemctl is-active. The entrypoint runs Django migrations before gunicorn answers, and until it does the image's own nginx returns 502, which Caddy relays verbatim -- complete with `server: nginx`, which reads as a stray reverse proxy that is not actually there. Also drops the dead nginx.conf.j2 and the network role, both superseded by the shared includes, and moves .env into the role's templates/ as tandoor.env.j2, rendered at mode 0600 and read through EnvironmentFile=.
This commit is contained in:
1 parent
4297e5a71e
commit
4cd9308ae3
13 files changed
+654
-128
No files matched your search
@@ -0,0 +1,26 @@
|
||||
---
|
||||
# Attach this app's network to the shared Postgres unit.
|
||||
#
|
||||
# Postgres knows nothing about its clients, exactly like Caddy: a service joins
|
||||
# by dropping 50-tandoor.conf and the shared 10-network-aliases.conf next to
|
||||
# postgres.container. The canonical way to do that is the shared include below —
|
||||
# it writes the same bytes every service writes, asserts that tandoor.network
|
||||
# already exists, and notifies the "Restart Postgres" handler defined in this
|
||||
# role.
|
||||
#
|
||||
# This runs in the roles phase, which is after the register include in
|
||||
# playbook.yml's pre_tasks has created tandoor.network.
|
||||
|
||||
- name: Attach Tandoor to Postgres
|
||||
ansible.builtin.include_tasks: "{{ playbook_dir }}/../postgres/roles/attach/tasks/main.yaml"
|
||||
|
||||
# On a first attach both drop-ins are new, so Postgres has to be recreated to
|
||||
# join tandoor_net — and that restart is a *handler*, which by default runs at
|
||||
# the end of the play, after the tandoor role has already started the app. The
|
||||
# app would then come up before `db` resolves, fail its own is-active check, and
|
||||
# fail the play on a machine where nothing is actually wrong.
|
||||
#
|
||||
# Flushing applies the new drop-in before the app starts. On later runs the
|
||||
# drop-ins are unchanged, nothing is pending, and this is a no-op.
|
||||
- name: Apply the Postgres network change before starting Tandoor
|
||||
ansible.builtin.meta: flush_handlers
|
||||
Reference in new issue
Block a user