tanshu
c3e0e4989c
The role created ~/podman-data/nextcloud/redis-session.ini and the unit bind-mounted it over the image path, purely because the entrypoint cannot write there itself. Removed: the task, the mount, and -- because it is the only thing that triggers the write -- REDIS_HOST from the environment file. The entrypoint now skips configure_redis_session entirely and starts. The Redis attach stays. The valkey role still puts nextcloud_net on the cache container with the alias `redis`, so an instance whose config.php names that host reaches it. Writing that configuration is config.php's business, and the readme gives the three `occ config:system:set` lines for anyone who wants it, including that this playbook will not do it for them. The only thing lost is PHP session storage, which falls back to the container's own filesystem -- a redeploy logs users out. That is the trade for not shipping a file whose sole purpose is to work around a directory the image owns as root. The env template and the valkey role comment both say why REDIS_HOST is absent, so that adding it back is recognisable as the regression it is.
29 lines
1.5 KiB
YAML
29 lines
1.5 KiB
YAML
---
|
|
# Attach this app's network to the shared Valkey unit.
|
|
#
|
|
# Valkey knows nothing about its clients, exactly like Caddy and Postgres: a
|
|
# service joins by dropping 50-nextcloud.conf and the shared
|
|
# 10-network-aliases.conf next to valkey.container. The canonical way to do that
|
|
# is the shared include below — it writes the same bytes every service writes,
|
|
# asserts that nextcloud.network already exists, and notifies the "Restart
|
|
# Valkey" handler defined in this role.
|
|
#
|
|
# `redis` is the alias the app connects to, not the container name: it is the host
|
|
# an instance configured for Redis has in config.php. This playbook does not write
|
|
# that configuration, it only makes the name resolvable.
|
|
|
|
- name: Attach Nextcloud to Valkey
|
|
ansible.builtin.include_tasks: "{{ playbook_dir }}/../valkey/roles/attach/tasks/main.yaml"
|
|
|
|
# On a first attach the drop-in is new, so Valkey has to be recreated to join
|
|
# nextcloud_net — and that restart is a *handler*, which by default runs at the
|
|
# end of the play, after the nextcloud role has already started the app. The app
|
|
# would then come up before `redis` resolves; with `memcache.locking` on Redis it
|
|
# would fail on the first write rather than at startup, which is a worse failure
|
|
# to debug.
|
|
#
|
|
# Flushing applies the new drop-in before the app starts. On later runs the
|
|
# drop-in is unchanged, nothing is pending, and this is a no-op.
|
|
- name: Apply the Valkey network change before starting Nextcloud
|
|
ansible.builtin.meta: flush_handlers
|