nested-podman-socket
Recipe card from the charly-distros plugin (Images — the deployable catalog).
nested-podman-socket — the nested podman’s API socket
Section titled “nested-podman-socket — the nested podman’s API socket”Composes container-nesting (/charly-distros:container-nesting) and serves that
nested rootless podman as an API socket at
unix:///run/user/1000/podman/podman.sock.
Why it is separate from container-nesting
Section titled “Why it is separate from container-nesting”container-nesting supplies nested podman; this candy supplies its SOCKET. A
nesting box that only builds and runs containers itself needs no API endpoint,
and starting a podman service in every such box would be scope it did not ask
for. Anything driven from OUTSIDE the container needs exactly that endpoint —
charly box load (/charly-build:load) delivering images in, or an in-pod
controller spawning its own containers.
The socket’s store IS the container’s rootless store, which is the whole point: containers spawned through it stay inside the candybox instead of landing in the host store beside everything else.
The runtime-dir named volume is load-bearing
Section titled “The runtime-dir named volume is load-bearing”/run is a fresh ROOT-OWNED tmpfs at container start. A build-time
mkdir /run/user/1000 therefore does not survive into the running container, and
the uid-1000 service cannot create its own runtime dir under a root-owned
/run/user. The candy declares a NAMED VOLUME at /run/user/1000: podman
copy-up populates an empty named volume from the image’s content at that path,
ownership preserved, so the container starts with the uid-1000-owned directory
seeded at build time.
A tmpfs is NOT an alternative, and this is measured rather than argued: podman’s
--tmpfs rejects uid=/gid= (unknown mount option "uid=1000"), so a tmpfs
at this path can only ever be root-owned.
The seed chowns the WHOLE directory, not just its podman/ subdirectory — the
nested podman writes its libpod runtime dir alongside, and seeding only the
subdirectory leaves the service unable to start. The candy’s build-context check
asserts the PARENT’s owner for exactly that reason.
Verification
Section titled “Verification”The candy’s own plan asserts the socket exists, answers, and reports a graph root
inside the container’s rootless store — the last of which is what would fail if
the socket were ever wired to a store outside the candybox. check-boxload-pod
exercises the whole arrangement end to end.