kevinveenbirkenbachandClaude Opus 5
4986e80dd4
The Production block never set one. inventory provision writes only
ansible_connection for a local host, so DOMAIN_PRIMARY stayed at the
group_vars default of infinito.localhost and the deployment served a zone its
own resolver knows nothing about. CoreDNS templates answers for
INFINITO_DOMAIN_RE and nothing else, so every lookup of the deployment's own
name came back NXDOMAIN.
Mastodon is where that surfaced. tootctl accounts create validates the address
through EmailMxValidator, which resolves MX and then, for the domain itself,
A and AAAA. All six queries returned NXDOMAIN in run 33574056480, the
validator recorded email :unreachable, and the admin account was never created.
Only the guide rows were affected: the matrix rows write
DOMAIN_PRIMARY: "{{ lookup('env', 'INFINITO_DOMAIN') }}" into their host_vars
and resolve fine.
The template now carries DOMAIN=<your-domain> in both the host and the
container form and threads it into --vars, with the container form passing it
through the docker run boundary as well. The two guide runners substitute it
the way they already substitute the SSH key, so the replay deploys under
INFINITO_DOMAIN like every other CI deploy. compose_deploy.sh moves its env
load ahead of the substitutions to have the value; host_deploy.sh had no env
load at all.
A production reader is asked for a domain now instead of silently inheriting
infinito.localhost, which no real deployment wants either. The shipped default
keeps its value: sys-svc-nss documents that *.localhost resolves through the
myhostname NSS module without any zone, and host-side tasks lean on it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
4.5 KiB
Kata & gVisor
Description
Kata Containers is an OCI container runtime that starts each container inside a lightweight virtual machine with its own kernel instead of sharing the host kernel. gVisor is a second isolating runtime, shipped as the single runsc binary, that intercepts container syscalls in a userspace kernel and runs without hardware virtualization.
Overview
This role provisions the isolating runtime layer of a container host. It installs the pinned gVisor binary, then re-runs the daemon configuration of the container role so the freshly installed runtime is registered and the daemon is restarted onto it. In swarm mode it additionally labels the node as sandbox-isolating, which is the placement constraint that keeps sandboxed workloads off nodes that still default to the shared kernel.
Cosmos
The diagram places Kata & gVisor in the Infinito.Nexus cosmos: the components it deploys (capabilities), the central services it consumes (dependencies), and its outward reach (federation and bridged external networks).
flowchart LR
subgraph role [svc-virt-kata 💻]
svc_kata["kata"]
end
subgraph dependents [Dependents]
dpt_web_app_hermes["web-app-hermes 🐳🐝"]
dpt_web_app_openclaw["web-app-openclaw 🐳🐝"]
end
svc_kata -- "1:1" --> dpt_web_app_hermes
svc_kata -- "1:1" --> dpt_web_app_openclaw
Solid 1:1 edges are fixed relationships; dashed 0..1 edges are conditional (enabled only in matching deployments); red 0..0 edges are turned off in this role. Node markers show the role's deploy modes (💻 host, 🐳 compose, 🐝 swarm); ❌ marks a service that is explicitly turned off, and ⚙️ an Ansible role dependency declared in meta/main.yml.
Features
- gVisor runtime: The pinned
runscrelease is fetched to/usr/local/bin/runscand verified against its published SHA-512 checksum. The Kata shim is taken from the host as it is; the role does not install it. - Runtime probing: The container role checks every host for
/dev/kvm, for the Kata shim binary and for docker-in-docker, and publishes the resulting choice betweenkataandrunscasSANDBOX_RUNTIME. - Daemon registration: Only runtimes whose binary is present are written to the daemon configuration, on a bare host and inside docker-in-docker alike. A daemon pointed at an absent runtime path refuses to start, so this role installs first and re-renders the configuration afterwards.
- Swarm default runtime:
docker stack deploydrops the per-serviceruntime:key, so a swarm worker carries the sandbox as its daemon-widedefault-runtimeinstead. The stack host keeps the shared kernel for the platform's own services. - Node labelling: In swarm mode the node is labelled
kata-capable=true, and sandboxed services are constrained to that label. A deploy without a single such node is refused rather than left pending. - Runtime pinning: In compose mode Hermes Agent and OpenClaw pin
SANDBOX_RUNTIMEon their service directly.
Quick Setup
Development
Clone, set up the workstation, and deploy Kata & gVisor onto the local stack:
git clone https://github.com/infinito-nexus/core.git
cd core
make onboard
make compose-deploy mode=reinstall apps=svc-virt-kata full_cycle=false
Production
Install Kata & gVisor directly onto the target machine: clone the repository, install the OS prerequisites and the repository toolchain, then deploy against localhost over a local connection (no SSH, no container):
git clone https://github.com/infinito-nexus/core.git
cd core
bash scripts/install/package.sh
make install
source scripts/meta/env/load.sh
APP=svc-virt-kata
DOMAIN=<your-domain>
TLS_MODE=self_signed
SSH_PUBLIC_KEY="<your-ssh-public-key>"
INVENTORY=inventories/production
infinito administration inventory provision "$INVENTORY" \
--inventory-file "$INVENTORY/devices.yml" \
--host localhost \
--include "$APP" \
--vars "{\"TLS_MODE\": \"$TLS_MODE\", \"DOMAIN_PRIMARY\": \"$DOMAIN\", \"users\": {\"administrator\": {\"authorized_keys\": [\"$SSH_PUBLIC_KEY\"]}}}"
infinito administration deploy dedicated "$INVENTORY/devices.yml" \
--password-file "$INVENTORY/.password" \
--diff -vv
Credits
Implemented by Kevin Veen-Birkenbach. Part of the Infinito.Nexus Project and maintained by Kevin Veen-Birkenbach. Licensed under the Infinito.Nexus Community License (Non-Commercial).