tanshu
e68f8ab00d
The fleet on emily is rootless Podman with Quadlet units under ~/.config/containers/systemd and state in ~/podman-data, all behind one shared Caddy unit. This brings the menus in line instead of leaving them the last Docker deployment. The build moves with them: podman reads a Containerfile as readily as a Dockerfile, so the name now says which toolchain is real. The app is one .container and one .network file. Two details carry it. UserNS=keep-id maps the image's own node account onto the user that owns the units, so data/ and site.env stay owned by tanshu: plain tar backups, no subuids. provision-site-env.sh writes site.env with the same mapping rather than --user, which under rootless Podman would have produced a subuid-owned file the app could not read. And the Site registers its own network with Caddy by writing a drop-in beside caddy.container, so Caddy never lists its upstreams and never changes when a Site is added. The unit keeps the Docker-era container name for the scripts and muscle memory that look it up, while the Caddyfile proxies to a dotless NetworkAlias, because a container name with dots in it is a liability in DNS. The unit keeps podman's Pull=missing, so a restart or a reboot never depends on the registry being reachable, while the play pulls explicitly at deploy time. That is also where a missing `podman login` for the private registry now fails, with the instruction, rather than as a unit that will not start. copy-site-data.sh moves a Site's data across, and is not a plain rsync: /var/lib/menu.* on monoco belongs to uid 1000 while the ssh user there is 1001, so the read needs sudo; monoco cannot ssh to emily, so the workstation relays the tar; and the extraction runs as tanshu on emily, which is what makes the files land owned by the user keep-id maps the app onto. It proves the copy by comparing a SHA-256 of the whole tree against the source and checking every file's owner. Not yet done: the copies themselves and the DNS move, which need a human.
32 lines
1.3 KiB
YAML
32 lines
1.3 KiB
YAML
---
|
|
# Caddy is its own playbook (ansible-playbooks/caddy/playbook.yml) and a rootless
|
|
# Quadlet unit there. These handlers run as the connection user, so
|
|
# `systemctl --user` and `podman exec` work without any XDG_RUNTIME_DIR juggling.
|
|
|
|
# Notified by this role when the Caddyfile changes. A reload keeps existing
|
|
# connections; a restart would briefly drop every hosted site.
|
|
#
|
|
# Note the config path: /etc/caddy/Caddyfile is the mount inside the container,
|
|
# not {{ caddyfile_path }}, which is the host side of it.
|
|
- name: Reload Caddy configuration
|
|
ansible.builtin.command: >-
|
|
podman exec {{ caddy_name }} caddy reload --config /etc/caddy/Caddyfile
|
|
changed_when: true
|
|
listen: 'Reload Caddy'
|
|
|
|
# Notified by roles/register when this Site's network unit, or the drop-in that
|
|
# attaches Caddy to it, is written. Quadlet has no live equivalent of
|
|
# `docker network connect`, so the container has to be recreated — a brief
|
|
# restart of every hosted site, not just this one. See the Caddy playbook's
|
|
# readme, "Trade-off worth knowing".
|
|
#
|
|
# Defined after the reload above so that when both are notified the cheap config
|
|
# reload happens first.
|
|
- name: Restart Caddy
|
|
ansible.builtin.systemd_service:
|
|
name: '{{ caddy_name }}.service'
|
|
scope: user
|
|
state: restarted
|
|
daemon_reload: true
|
|
listen: Restart Caddy
|