mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 02:54:26 +00:00
Introduces a `registry-cache` service (rpardini/docker-registry-proxy) in the `ci` profile that MITM-caches every outbound docker registry pull made by `infinito`'s inner dockerd, drastically cutting bandwidth on re-deploys, parallel CI shards, and local fresh-purges. Wiring (all bind-mounted via compose.yml, no Dockerfile or entry.sh staging, so edits hot-reload on next container start): - CA bundle at /opt/registry-cache-ca (read-only), - systemd drop-in at /etc/systemd/system/docker.service.d/registry-cache-proxy.conf, - registry-cache-ca.sh at /usr/local/bin/registry-cache-ca.sh. The drop-in registers registry-cache-ca.sh as ExecStartPre. Compose gates `infinito` on `registry-cache` `service_healthy` so the CA is on disk before dockerd boots; the install script supports both Debian (`update-ca-certificates`) and Arch/Fedora (`update-ca-trust extract`) trust stores, detected by command availability. Also reorganizes compose/ into per-service subdirectories (compose/coredns/, compose/registry-cache/) with README.md per directory following the documentation guidelines, adds scripts/docker/README.md, and nests the registry-cache host paths under /tmp/infinito/core/ (mirror/ for blobs, ca/ for the MITM CA bundle). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
37 lines
1.7 KiB
Markdown
37 lines
1.7 KiB
Markdown
# Docker Runner Scripts 🐳
|
|
|
|
Shell helpers that run inside the `infinito` runner container defined by
|
|
the top-level [compose.yml](../../compose.yml). They cover container
|
|
lifecycle (entry, healthcheck) and integration with peer compose
|
|
services (e.g. the `registry-cache` pull-through proxy).
|
|
|
|
## Scope 📋
|
|
|
|
- This directory MUST contain only scripts that execute inside the
|
|
`infinito` container, either as the container entrypoint, as a
|
|
Docker `HEALTHCHECK`, or as a `systemd` unit hook.
|
|
- This directory MUST NOT host host-side tooling. Scripts that run on
|
|
the developer or CI host belong under their workflow-specific path
|
|
(for example `scripts/tests/`, `scripts/image/`, `scripts/meta/`).
|
|
- This directory MUST NOT host application logic that belongs to an
|
|
Ansible role.
|
|
|
|
## Bind-mounted scripts 🔗
|
|
|
|
A script that is bind-mounted from this directory into a fixed in-container
|
|
path (see [compose.yml](../../compose.yml)) MUST keep its git executable
|
|
bit, because Docker bind-mounts preserve host file permissions and the
|
|
in-container caller (systemd, dockerd, the entrypoint) cannot recover from
|
|
a non-executable mount.
|
|
|
|
When a new script is added with a bind-mount target, its purpose and
|
|
in-container target path SHOULD be documented at the call site (the
|
|
matching `compose/<service>/` README, or [compose.yml.md](../../docs/contributing/artefact/files/compose.yml.md)).
|
|
|
|
## Distro portability 🌐
|
|
|
|
A script in this directory MUST work across every distro variant that
|
|
the runner image is built for (currently Debian, Ubuntu, Arch, Fedora,
|
|
CentOS). Tool availability differs across these variants, so a script
|
|
SHOULD branch on `command -v <tool>` rather than on distro IDs.
|