mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: codify JD01 k3s registry bootstrap

Browse Source
This commit is contained in:
Codex
2026-06-29 12:44:46 +00:00
parent 9afff816f8
commit e4fed24e43
4 changed files with 23 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/yaml-first-ops.md
+8
View File
@@ -92,6 +92,14 @@ For fresh VPS bring-up, do not use provider-gateway WebSocket egress as the bulk
Host proxy use has a privacy boundary. A plain `http_proxy=http://...` proxy can observe destination hosts, request metadata and any proxy credential embedded in the URL or process environment; TLS protects encrypted request bodies from the proxy but does not hide the destination metadata from the proxy operator. Do not place private API keys in proxy URLs, logs or CLI output. `NO_PROXY`/`no_proxy` must preserve local, cluster, metadata and explicitly declared direct domains, including `hyueapi.com` and `.hyueapi.com` for Codex direct API access.
## K3s-First Local Registry
Fresh node bootstrap must not require an already-populated host Docker registry in order to deploy the node-local registry itself. The durable path for a new k3s node is to render the registry from YAML as a k3s workload with declared namespace, Deployment, Service, PVC, endpoint and image source. Host-Docker registry containers are legacy or migration sources only; they must not be the source of truth for a new node's ability to come up from zero.
When migrating from a host-Docker registry to a k3s registry, the control path must make the data provenance explicit. If the goal is to prove from-zero deployment, stop the old host registry first and do not seed from it. The status output should say whether the new registry was seeded from an old registry or zero-seeded, whether the PVC is bound, whether the endpoint is ready, and which workload owns the registry. After a zero-seeded migration, required runtime images, BuildKit images and tools images must be re-created or preloaded through YAML-first control commands before claiming the lane can build or roll out.
The registry is not a general reason to keep host Docker as a long-running dependency. Host Docker may still appear as a temporary build or image-transfer tool while a lane is being migrated, but the owning issue should classify it as a remaining Docker dependency and move durable builds toward k3s/Tekton/BuildKit or an equivalent rootless builder. Runtime status should distinguish long-running host Docker services from one-shot controlled build/preload operations.
## Cross-Repository Operational Truth
When UniDesk prepares or supervises runtime data for another repository, the owning YAML still belongs in UniDesk if the data is part of node/lane operations rather than that repository's application source. Examples include HWLAB test/admin account inventories, operator-only API key source references, runtime DB sync inputs, public exposure targets and cross-node workbench preparation. The service repository may contain application code and app-native migrations, but it must not become a second desired-state truth for UniDesk-operated accounts, credentials, nodes, lanes, namespaces or sourceRef bindings.