tanshu
3587bc9001
Replaces the docker_container playbook, which published 127.0.0.1:6379 and kept its /data in an anonymous Docker volume -- the one the audit flagged because no backup script can see it (docs/podman-compat-audit.md 3.1). Valkey becomes the base Quadlet unit, the same shape as Postgres: it knows nothing about its clients, and a service attaches itself by dropping a file into valkey.container.d/ via valkey/roles/attach. Nothing on the host needs 6379, so there is no PublishPort at all rather than a narrower one. The name stays `valkey` for the directory, container, unit and Podman network, and only the alias clients connect on is `redis`: Nextcloud's config.php (written by the image from REDIS_HOST=redis), outline and overleaf reach it as `redis`, while paperless-ngx and yamtrack use the container name. Renaming would touch every REDIS_HOST for no gain. The uid/gid mapping is the detail worth spelling out, because the audit only records the uid. The Alpine image's `valkey` account is 999:1000, not 999:999 -- Alpine already has a gid 999, and the Dockerfile says so before creating the group with the next id. 999 is the uid the anonymous volume was owned by, so the uid matches what was already on disk, but mapping only the uid would leave every file valkey-server writes, dump.rdb included, group-owned by a subgid. Both ids map onto the connection user, so ~/podman-data/valkey stays tanshu:tanshu. Persistence stays on deliberately, and the mount with it. The contents are disposable -- nothing is copied off monoco, and a cold start is survivable -- but this is not purely a cache: Nextcloud keeps its PHP sessions and memcache.locking in it, and Yamtrack uses it as its Celery broker. With RDB on, a rebuild is a graceful stop that writes a final snapshot on SIGTERM that the next container loads, so a redeploy does not log every Nextcloud user out or discard queued tasks. Tmpfs=/data with `save ""` would remove the mount and the whole keep-id mapping with it, and is the right shape for a pure cache, but it would make every redeploy exactly that. The rootless-Podman prerequisites are not applied here: they are the shared task file at caddy/roles/podman, and a host that has run caddy/playbook.yml has them. Two ordering details are load-bearing: - The attach include asserts that <name>.network exists before writing a drop-in that names it. Quadlet rejects the whole valkey unit, with an error that never mentions the drop-in, when a referenced .network file is missing. - A service that attaches flushes handlers before starting the app. The restart that joins Valkey to the new network is a handler, so by default it runs at the end of the play, after the app has already come up and failed to resolve `redis`. nextcloud/roles/valkey is the working example. The play waits on `valkey-cli ping` inside the container rather than trusting systemctl is-active. Restart=always reports active even while the container crash-loops, which is exactly what a wrong keep-id looks like.
Ansible Playbooks
A collection of minimalist Ansible playbooks for automating server setups, based on DigitalOcean's Community guides.
- Initial Server Setup for Ubuntu 18.04 *
- Apache on Ubuntu 18.04
- Postgres on Ubuntu 19.10
- Redis on Ubuntu 19.10
- Bitwarden Ubuntu 19.10
- Gitea on Ubuntu 19.10
*the Initial Server Setup should be your starting point for fresh servers.
Playbook Structure
The playbooks contained in this repository were created for educational purposes, and should serve as a base for you to create your own playbooks and roles.
Although we opt to not use roles, our playbooks follow a distinctive structure to facilitate reuse while keeping them mostly self-contained and straightforward.
For instance, this is how the lemp playbook is structured:
lemp_ubuntu1804
├── files
│ ├── info.php.j2
│ └── nginx.conf.j2
├── vars
│ └── default.yml
├── playbook.yml
└── readme.md
files/: directory containing templates and other files required by the playbook.vars/: directory to save variable files. Adefault.ymlvar file is included by default.playbook.yml: the playbook file.readme.md: instructions and links related to this playbook.
Getting Started
To set up your Ansible environment, please follow our guide on How to Install and Configure Ansible on Ubuntu 18.04.
Connection Test
From your local machine or Ansible control node, run:
ansible all -m ping -u remote_user
If you're able to get a "pong" reply back from your node(s), your setup works as expected and you'll be able to run both ad-hoc commands and playbooks on your nodes, using Ansible.
Guides
The following guides cover how to use the playbooks you'll find in this repository.
Initial Server Setup
Once you have executed the initial server setup, you can choose from any of the available server setup playbooks:
Web Servers
- Apache on Ubuntu 18.04
- LEMP (Linux, Nginx, MySQL, PHP) on Ubuntu 18.04
- LAMP (Linux, Apache, MySQL, PHP) on Ubuntu 18.04