Converge kai-server docker insecure-registries for in-cluster registry push #341

New issue

Open

opened 2026-06-15 15:38:40 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-06-15 15:38:40 +00:00

Owner

Problem

The kai-server snap docker daemon cannot push to the in-cluster registry
(192.168.0.194:30500). The registry serves plain HTTP, but the docker daemon
defaults to HTTPS, so a docker push fails with:

Get "https://192.168.0.194:30500/v2/": http: server gave HTTP response to HTTPS client

k3s containerd already trusts this registry for pulls, but the snap docker
daemon (kai-server's build/CI daemon, which does the pushes) is a separate
config and was never told the registry is insecure. daemon.json held only
{"log-level": "error"} - no insecure-registries entry. This is why atlas
had never landed in the registry (eco-app images there were pushed by eco-app's
own CI from a different runner).

Manual fix already applied on kai-server

Added the entry to /var/snap/docker/current/config/daemon.json and restarted
the docker snap:

{
    "log-level":           "error",
    "insecure-registries": ["192.168.0.194:30500"]
}

Why this needs ansible

That path is per-snap-revision config under /var/snap/docker/current/. A snap
refresh is not guaranteed to carry it forward, and hand-applied host config has
no source of truth. Per the deploy repo's authoring/rollout split, host daemon
config belongs in this repo as an ansible task that converges kai-server's
docker insecure-registries to include 192.168.0.194:30500 (the NodePort
in-cluster registry), then handler-restarts the docker snap on change.

Acceptance

An ansible role/task declares insecure-registries: ["192.168.0.194:30500"]
in the kai-server docker daemon.json, idempotently.
A handler restarts the docker snap only when the file changes.
Re-running the play on a host already converged is a no-op.

Refs

Surfaced while verifying the atlas deploy push (coilyco-bridge/deploy).
Registry is the same NodePort registry eco-app uses.

## Problem The kai-server snap docker daemon cannot push to the in-cluster registry (`192.168.0.194:30500`). The registry serves plain HTTP, but the docker daemon defaults to HTTPS, so a `docker push` fails with: ``` Get "https://192.168.0.194:30500/v2/": http: server gave HTTP response to HTTPS client ``` k3s containerd already trusts this registry for **pulls**, but the snap docker daemon (kai-server's build/CI daemon, which does the **pushes**) is a separate config and was never told the registry is insecure. `daemon.json` held only `{"log-level": "error"}` - no `insecure-registries` entry. This is why atlas had never landed in the registry (eco-app images there were pushed by eco-app's own CI from a different runner). ## Manual fix already applied on kai-server Added the entry to `/var/snap/docker/current/config/daemon.json` and restarted the docker snap: ```json { "log-level": "error", "insecure-registries": ["192.168.0.194:30500"] } ``` ## Why this needs ansible That path is per-snap-revision config under `/var/snap/docker/current/`. A snap refresh is not guaranteed to carry it forward, and hand-applied host config has no source of truth. Per the deploy repo's authoring/rollout split, host daemon config belongs in this repo as an ansible task that converges kai-server's docker `insecure-registries` to include `192.168.0.194:30500` (the NodePort in-cluster registry), then handler-restarts the docker snap on change. ## Acceptance - An ansible role/task declares `insecure-registries: ["192.168.0.194:30500"]` in the kai-server docker `daemon.json`, idempotently. - A handler restarts the docker snap only when the file changes. - Re-running the play on a host already converged is a no-op. ## Refs - Surfaced while verifying the atlas deploy push (coilyco-bridge/deploy). - Registry is the same NodePort registry eco-app uses.

coilysiren added the

label

2026-06-17 09:23:37 +00:00

coilysiren added the

consult

label

2026-06-18 06:28:15 +00:00