Registry — Docker Hub pull-through cache
A read-only cache of Docker Hub in front of the carnaval k8s cluster, installed 2026-09-09 for the Kubernetes course block. Docker Hub caps anonymous pulls per public IP, and the three k8s servers share the school's; a class pulling the same images in the same quarter hour exhausts it. The mirror pulls each image once, serves every later request from the rack, and drops what nobody has used for a week.
| Guest | srv-registry — unprivileged LXC, CT 120 on rumba, 192.168.88.172, 2 cores / 2 GB, 8 GB root on local-lvm + a 200 GB local-lvm mount point on /var/lib/registry with backup=0 |
| URL | http://registry.isc3:5000 (also srv-registry.isc3) — LAN/VPN only, plain HTTP, not published through srv-web01. /v2/ answers 200 |
| Software | distribution 3.1.1, one static binary under systemd, proxy.remoteurl = registry-1.docker.io, proxy.ttl = 168h. A proxy registry accepts no pushes and mirrors one upstream: images from ghcr.io, quay.io or nvcr.io still come straight from their source |
| Consumers | the three k3s servers: /etc/rancher/k3s/registries.yaml points docker.io at the mirror, containerd falls back to Docker Hub itself when the mirror does not answer. The file is provisioning/k8s/registries.yaml, delivered by cloud-init at VM creation and by carnaval-k8s.sh mirror to a running fleet |
| Backups | root disk in both nightly jobs like every guest; the cache is not (backup=0) — it is public content, rebuilt on demand |
| Managed from | provisioning/registry/ — deploy-registry.sh (idempotent; REGISTRY_VERSION=… to upgrade), dns.sh for the CCR2004 records |
Nothing changes for whoever writes a manifest: image: python:3.12 stays image: python:3.12.
Verified 2026-09-09 with an uncached alpine:3.20 pulled on k8s2: the image arrived via the
mirror and its layers appeared under /var/lib/registry.
A Docker daemon elsewhere on the VPN can use the same cache with, in /etc/docker/daemon.json:
{ "registry-mirrors": ["http://registry.isc3:5000"], "insecure-registries": ["registry.isc3:5000"] }
Traffic from the 91 subnet to the mirror is software-routed by the CRS326 (the
~39 MB/s ceiling); the cache exists for the quota,
not for throughput. Should it matter, the container gets a second address in 192.168.91.0/24,
the same fix as the NAS.
Open items: ops todo → Carnaval.