Files
kevinveenbirkenbachandClaude Opus 5.5 ba8f4b5f3a fix(sys-svc-container): keep the installed Docker apt key when its refresh is refused
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>
2026-10-13 21:31:47 +02:00
..
…

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 run logic across roles and scripts
  • Provides predictable behavior in CI and production

Key responsibilities

  • Implements container run with:

    • CA trust injection (with-ca-trust.sh)
    • ENTRYPOINT detection and recovery
    • --pull policy handling
  • Passes through commands where wrapping does not make sense:

    • container exec
    • container logs
    • container ps
    • container inspect
    • container 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.