Bastian de BylandClaude Opus 5
2a6390c0ad
podman_prune_users listed only the podman and git users, so the two stores that turn over fastest were never touched. gitea-runner had reached 1205 images / 113.1 GB with 100% of it reclaimable, and actions-runner had 137 exited job containers. That layer count is what makes overlayfs lookups -- and so CI itself -- slow; the disk was the lesser problem. Split into two policies, because the stores are not the same kind of thing: service users keep the 30-day rollback window, and their containers are deliberately NOT pruned. They are the live services, and reaping one that merely happens to be stopped would turn a transient crash into a unit that cannot start again until the next deploy. CI users get 48h and their exited job containers reaped too. Build layers carry no rollback value. Containers are reaped BEFORE images on purpose: an exited container pins the image it ran from, so pruning images first would leave those layers behind for another day. Timer moved weekly -> daily; a week of CI turnover is what let the store reach 113 GB between runs. Persistent=true is kept so a missed run catches up. First run reclaimed 134 GB: gitea-runner 113.1 -> 4.2 GB, actions-runner 7.6 GB -> 0, podman 25.7 -> 15.1 GB. Disk 449G -> 315G, all 26 containers up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deploy Home
There's no place like home!
Just as Dorothy managed the simple task of clicking her heels together, the desire for an equally simple one-button push deployment was in my heart. Thus, this repository was made.
Ansible
Ansible, along with double encrypted secrets, deploys the necessary configurations to make the home fit for certain needs and desires. Namely, having access to my home from anywhere, securely, and a self-hosted CI server that easily ties into existing workflows.
Makefile
The makefile is primarily used as a wrapper script to ensure that necessary
files, such as the secret vault password file, are provisioned as part of this.
One such addition to the task is utilizing dependency pinning through the
utilization of Python's virtualenv to lock down the specific dependency
versions within the requirements.txt file. This, ideally, prevents any
deployment issues with dependency version woes (e.g. version conflicts, major
updates in newest versions, etc.)
| Target Name | Description |
|---|---|
lint |
(default) Runs yamllint and ansible-lint on all YAML files in ansible/ |
deploy |
Deploys everything, or only tasks specified in TAGS= environment variable |
check |
Runs deploy in a "dry-run", showing diff-style outputs on tasks indicating changes |
vault |
Opens the Ansible vault file for editing |