mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 02:54:26 +00:00
A local deploy stopped four times in two days in "Ensure Docker apt key and sources are consistent" (#849). apt_repo.sh downloads the Docker GPG key on every run, and when download.docker.com refused the connection, curl's four attempts were over within about six seconds and the script returned 1, although the key from an earlier run was installed and is all the following apt operations need. install_key now fails only when no key is installed. With a key in place, a refused download prints a warning and keeps it. A downloaded key that differs still replaces the installed one, and the 0644 mode is enforced in every case. The keyring path became an argument: ensure-key-and-sanitize passes the keyring it already hands to sanitize_sources, so the role's call still resolves to /etc/apt/keyrings/docker.asc, and a test can point the script at a temporary keyring. Verified: tests/unit/python/roles/sys-svc-container/files/test_apt_repo.py stubs curl and sudo. A refused download keeps the installed key and ends with changed=0, a refused download without a key exits 1, and a new key replaces the installed one. A copy of the script whose keep branch always errors, the old behaviour, fails the first test. Two local deploys ran the new script with rc 0 and an empty stderr and left the installed key untouched. shellcheck is clean. Not verified live: the refused download itself, which needs download.docker.com to refuse a connection during a deploy. A host without a key still needs the download and still fails when it is refused. Closes #849 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
sys-svc-container – Files Overview
This directory contains helper scripts and binaries that are installed on the host to provide container-related runtime functionality for Infinito.Nexus.
The files here are not application-specific. They are infrastructure helpers used by other roles, health checks, CI jobs, and runtime scripts that interact with Docker containers in a controlled and reproducible way.
container.py
Purpose
container.py is a general-purpose Docker wrapper CLI installed as:
/usr/local/bin/container
It provides a stable, opinionated entry point for container execution within Infinito.Nexus.
Why it exists
- Centralizes container execution logic
- Injects CA trust only where it makes sense (
container run) - Avoids duplicating fragile
container runlogic across roles and scripts - Provides predictable behavior in CI and production
Key responsibilities
-
Implements
container runwith:- CA trust injection (
with-ca-trust.sh) - ENTRYPOINT detection and recovery
--pullpolicy handling
- CA trust injection (
-
Passes through commands where wrapping does not make sense:
container execcontainer logscontainer pscontainer inspectcontainer pull
-
Provides a raw escape hatch:
container docker <any docker args>
**Who uses it**
* Health-check scripts (e.g. CSP, DNS, HTTP checks)
* CI jobs running Docker-in-Docker
* Infrastructure roles that need reliable container execution
* Any script that would otherwise call `container run` directly
---
## test-dns.sh
**Purpose**
`test-dns.sh` is a **Docker-in-Docker DNS health check script**.
It validates that DNS resolution works correctly *inside containers*, which is
critical for:
* Node.js (`dns.lookup`, `getaddrinfo`)
* CSP checker containers
* Any service relying on outbound DNS
**What it tests**
1. Docker daemon availability (DinD readiness)
2. DNS resolution via BusyBox:
* A record resolution
* No `SERVFAIL` responses
3. DNS resolution via Node.js:
* `dns.lookup()` behavior
* Real-world behavior matching CSP checker usage
**Who uses it**
* CI pipelines
* System health checks
* Debugging DNS issues in containerized environments
---
## install-cli.sh
**Purpose**
`install-cli.sh` installs the **Docker CLI (client only)** in a
distribution-aware way.
It is intentionally limited to the CLI and does **not** start or manage the Docker
daemon.
**Supported distributions**
* Arch Linux
* Debian / Ubuntu
* Fedora
* CentOS / RHEL
**Who uses it**
* CI images
* Minimal container images
* Test environments where only `docker` client access is required
* Roles that need to interact with an external Docker daemon or DinD
---
## Design Principles
* **Separation "docker logic" from application logic**
* **One canonical container entry point** (`container`)
* **Minimal magic** – wrapping only where it is technically justified
* **CI-first design** (predictable behavior without a full system)
---
## Summary
| File | Used by | Purpose |
| ---------------- | ----------------------- | ---------------------------------- |
| `container.py` | Scripts, roles, CI | Safe, CA-aware container execution |
| `test-dns.sh` | CI, health checks | Validate container DNS behavior |
| `install-cli.sh` | CI images, test systems | Install Docker CLI only |
This directory forms the **container runtime foundation** of Infinito.Nexus.