Configure a containerd mirror for the in-cluster registry #508

New issue

Closed

opened 2026-07-09 21:45:51 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 21:45:51 +00:00

Member

Configure kai-server/k3s containerd to use a logical registry name for the in-cluster OCI registry instead of requiring manifests to hardcode 192.168.0.194:30500.

Current state:

The homelab in-cluster registry is registry:2 exposed as NodePort 30500.
Docs identify the current pull/push endpoint as 192.168.0.194:30500.
Deploy manifests currently use image refs like 192.168.0.194:30500/factory-game-v3:<sha>, 192.168.0.194:30500/atlas:<sha>, etc.
That works, but it bakes a LAN IP and port into every deploy surface.

Requested target:

Add a k3s/containerd registry mirror so Kubernetes image refs can use a stable logical registry authority, for example kai-registry.local/<image>:<tag> or another clear name chosen by existing infra conventions.
The mirror should point to the existing plain HTTP endpoint http://192.168.0.194:30500.
Image pulls from k3s should work without DNS resolution for the logical name if containerd mirror config supports that directly.
Keep the existing registry service and NodePort unless there is a strong reason to change it.

Important distinction:

This is for containerd/k3s pulls. Docker build/push jobs may continue pushing to 192.168.0.194:30500 unless/until Docker daemon config gets a matching alias. Pulls through the logical name should still resolve to the same registry repository paths.

Acceptance criteria:

Infrastructure config converges kai-server with a k3s/containerd mirror for the chosen logical registry authority.
Documentation updates explain the new image reference scheme and the difference between push endpoint and pull alias.
A verification path is documented, for example pulling a known image through the logical authority with crictl or k3s/containerd.
The existing 192.168.0.194:30500 path remains functional during migration.
The issue outcome states the exact registry authority downstream deploy manifests should use.

Follow-up expected after this lands:

coilyco-bridge/deploy should migrate image repository values and docs from 192.168.0.194:30500/... to the chosen logical registry authority.

Out of scope:

Replacing the registry deployment.
Moving to public Forgejo packages.
Changing app build pipelines unless needed for verification.

Configure kai-server/k3s containerd to use a logical registry name for the in-cluster OCI registry instead of requiring manifests to hardcode `192.168.0.194:30500`. Current state: * The homelab in-cluster registry is `registry:2` exposed as NodePort `30500`. * Docs identify the current pull/push endpoint as `192.168.0.194:30500`. * Deploy manifests currently use image refs like `192.168.0.194:30500/factory-game-v3:<sha>`, `192.168.0.194:30500/atlas:<sha>`, etc. * That works, but it bakes a LAN IP and port into every deploy surface. Requested target: * Add a k3s/containerd registry mirror so Kubernetes image refs can use a stable logical registry authority, for example `kai-registry.local/<image>:<tag>` or another clear name chosen by existing infra conventions. * The mirror should point to the existing plain HTTP endpoint `http://192.168.0.194:30500`. * Image pulls from k3s should work without DNS resolution for the logical name if containerd mirror config supports that directly. * Keep the existing registry service and NodePort unless there is a strong reason to change it. Important distinction: * This is for **containerd/k3s pulls**. Docker build/push jobs may continue pushing to `192.168.0.194:30500` unless/until Docker daemon config gets a matching alias. Pulls through the logical name should still resolve to the same registry repository paths. Acceptance criteria: * Infrastructure config converges kai-server with a k3s/containerd mirror for the chosen logical registry authority. * Documentation updates explain the new image reference scheme and the difference between push endpoint and pull alias. * A verification path is documented, for example pulling a known image through the logical authority with `crictl` or k3s/containerd. * The existing `192.168.0.194:30500` path remains functional during migration. * The issue outcome states the exact registry authority downstream deploy manifests should use. Follow-up expected after this lands: * `coilyco-bridge/deploy` should migrate image repository values and docs from `192.168.0.194:30500/...` to the chosen logical registry authority. Out of scope: * Replacing the registry deployment. * Moving to public Forgejo packages. * Changing app build pipelines unless needed for verification.

coilyco-ops commented

2026-07-09 21:46:19 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-infrastructure-508 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T21:46:17Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/infrastructure#508 · branch issue-508 · harness codex · workflow direct-to-main
Run: engineer-codex-infrastructure-508 · ward v0.493.0 · dispatched 2026-07-09T21:46:17Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-infrastructure-508` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T21:46:17Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/infrastructure#508` · branch `issue-508` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-infrastructure-508` · ward `v0.493.0` · dispatched `2026-07-09T21:46:17Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

headless

labels

2026-07-09 21:47:16 +00:00

coilyco-ops commented

2026-07-09 21:59:10 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)
felt: straightforward once the registry alias and ansible role were pinned down
confidence: high
surprises: the container hit disk-full during validation, and Ansible's temp path needed a writable override
follow-ups: coilyco-bridge/deploy should migrate image refs to kai-registry.local/...

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) felt: straightforward once the registry alias and ansible role were pinned down confidence: high surprises: the container hit disk-full during validation, and Ansible's temp path needed a writable override follow-ups: coilyco-bridge/deploy should migrate image refs to `kai-registry.local/...` </details>

coilyco-ops referenced this issue from a commit

2026-07-09 22:04:22 +00:00

feat: add k3s registry mirror alias

coilyco-ops closed this issue

2026-07-09 22:04:22 +00:00