Volumes instead of bind mounts (+ DKIM-key generation)

[chrisblech]

Volumes instead of bind mounts (+ DKIM-key generation)

Motivation

The current setup relies on bind mounts (./db, ./pgp, ./upload,
./dkim.key, ./unbound/conf.d/) for anything that needs to persist or be
pre-provisioned. That works fine when you deploy from a shell on the host,
but it quietly assumes host filesystem access: someone needs to mkdir
the right directories and drop a dkim.key file in the right place before
docker compose up will actually work correctly.

That assumption breaks down for Portainer's Web editor / Git deployment
without SSH access to the host - a fairly common setup (managed Portainer,
restricted hosts, teammates who only get Portainer access). Named Docker
volumes are created and populated entirely by the Docker daemon itself, so
switching to them means the whole stack - including first-time DKIM key
generation - can be deployed and managed purely through the Portainer UI,
no host shell required.

This PR switches every bind mount to a named volume, adds a migration path
for existing deployments, and folds in a small related improvement
(DKIM key generation on first start) that enables to bring up the whole setup
without fiddling anything on the host.

What changed

1. Named volumes replace bind mounts

  x-sl-defaults: &sl-defaults
    image: simplelogin/$SL_IMAGE:$SL_VERSION
    env_file: .env
    volumes:
-     - ./pgp:/sl/pgp
-     - ./upload:/code/static/upload
-     - ./dkim.key:/dkim.key
+     - sldata:/sl
+     - upload:/code/static/upload

sldata is mounted once at /sl, with pgp/, dkim/, tmp/ and
unsent/ as subdirectories, rather than one volume per bind mount.
postgres gets a db volume the same way.

DKIM_PRIVATE_KEY_PATH, GNUPGHOME, TEMP_DIR and SAVE_UNSENT_DIR are
now fixed in the sl-defaults anchor's environment: instead of being
.env-configurable - these are container-internal implementation
details of the volume layout, not something a deployer needs (or should
want) to change. Setting them as literal environment: values means they
take precedence over anything env_file: provides, so an existing .env
that still has the old DKIM_PRIVATE_KEY_PATH=/dkim.key is automatically
overridden rather than breaking anything.

2. Migration path for existing deployments

New migrate-volumes-compose.yaml, included by default from
docker-compose.yaml, adds a one-shot volume-migrate service:

services:
  volume-migrate:
    image: alpine:3.22
    volumes:
      - .:/legacy:ro
      - db:/new/db
      - sldata:/new/sldata
      - upload:/new/upload
    entrypoint: [...]  # copies ./db, ./pgp, ./upload, ./dkim.key into the
                        # new volumes, but only if the volume is still empty

  postgres:
    depends_on:
      volume-migrate:
        condition: service_completed_successfully

The whole project directory is bind-mounted read-only as a single mount
(.:/legacy:ro) rather than mounting each legacy path individually -
mounting a nonexistent single file/directory path directly would make
Docker silently create an empty directory there instead of leaving it
absent, which matters most for ./dkim.key (commonly absent on a fresh
install) but is avoided for all four legacy paths this way.

It's safe to leave this file included even on a fresh install with none
of the legacy paths present - it just creates the sldata directory
structure and otherwise does nothing. Comment out its include: line in
docker-compose.yaml once you've confirmed an existing deployment
migrated successfully.

3. DKIM key generation, key echoed on app startup

A entrypoint override in the init container ensures presence of all
paths (regardless of whether migrate-volumes-compose.yaml
was used), and generates a DKIM-key if there is none present.

init:
  <<: *sl-defaults
  entrypoint:
    - /bin/sh
    - -c
    - |
      set -eu
      umask 077
      mkdir -p /sl/pgp /sl/dkim /sl/tmp /sl/unsent
      if [ ! -s "$$DKIM_PRIVATE_KEY_PATH" ]; then
        echo "[dkim-init] No key at $$DKIM_PRIVATE_KEY_PATH — generating 1024-bit RSA key..."
        openssl genrsa -out "$$DKIM_PRIVATE_KEY_PATH" 1024
      fi
      chmod 600 "$$DKIM_PRIVATE_KEY_PATH" 2>/dev/null || true
      exec python init_app.py

app now also prints the DKIM public key on every start, as a
convenience for setting up the DNS TXT record:

[dkim-init] DKIM public key (p=) — add this to your DNS TXT record:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB...

4. DNS resolver config written at container start instead of bind-mounted

As we cannot rely on bind-mounts from the host any more, there is another
approach to inject unbound configuration into dns container: an entrypoint
override writes our config file on startup.

    dns:
      image: crazymax/unbound:latest
-     volumes:
-       - ./unbound/conf.d/:/config/:ro
      entrypoint:
        - /bin/sh
        - -ec
        - |
+         cat > /config/00-listen-port.conf <<'EOF'
+         server:
+           interface: 0.0.0.0@53
+           log-queries: yes
+           verbosity: 2
+           module-config: "validator iterator"
+           identity: "DNS"
+           root-hints: "/usr/share/dns-root-hints/named.root"
+         EOF
          unbound-anchor -a /var/run/unbound/root.key || true
          exec su -s /bin/sh unbound -c "sh /entrypoint.sh"

Testing

Everything below was checked with real containers, not just docker compose config:

• init's entrypoint against a real sl-app image and a fresh volume:
  creates /sl/{pgp,dkim,tmp,unsent} with correct permissions
  (700/600), generates a working RSA key; a second run correctly skips
  regeneration
• app's entrypoint against the generated key produces a valid DKIM
  public key in the expected DNS TXT format
• volume-migrate against fake legacy ./db, ./pgp, ./upload,
  ./dkim.key content: copies all four correctly on first run; a second
  run skips all four (idempotent, never overwrites)
• the resolver: still resolves and DNSSEC-validates (a signed test zone
  returns the ad flag); unbound-checkconf -o confirms
  module-config/identity/root-hints now match the old config
  exactly; the image's built-in healthcheck (port 5053) is unaffected by
  the new port-53 listener, since both are registered additively via the
  image's own include: /config/*.conf
• docker compose config renders cleanly end-to-end with no
  variable-interpolation warnings (had to escape the new shell variables
  as $$, same convention used elsewhere in this file - Compose
  interpolates the whole file's string values, including inside
  multi-line shell script blocks, before service definitions are parsed)

No changes to the SimpleLogin app image itself - this is purely compose
orchestration.

[springcomp]

That looks awesome.
Thanks for taking the time to document migration.

Note to @springcomp (self): consider documenting upgrade path:
https://github.com/springcomp/self-hosted-simplelogin/wiki/Upgrading
Maybe README ?