mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
837f44f8a37b467444aab38081cfc61db4123328
pikasTech-unidesk/docs/reference/g14.md
T
Codex 837f44f8a3 docs: pin G14 HWLAB workspace
2026-05-25 07:01:41 +00:00

7.0 KiB
Raw Blame History

G14 Provider Node

G14 is a UniDesk provider node for staging infrastructure workloads. Its UniDesk provider id is G14; the local UniDesk worktree is /root/unidesk, and the native k3s kubeconfig is /etc/rancher/k3s/k3s.yaml.

G14's long-lived k3s control bridge is k3sctl-adapter-g14, a UniDesk direct service outside the k3s fault domain. It listens on the G14 host loopback port 127.0.0.1:4266 and is registered separately from the D601 k3sctl-adapter, so G14 infrastructure services can be built and tested without taking over user services that still run on D601.

For Code Queue and CI/CD migration preparation, G14 uses native k3s labels unidesk.ai/node-id=G14 and unidesk.ai/provider-id=G14. The G14 Code Queue manifests src/components/microservices/k3sctl-adapter/k3s/code-queue.g14.k8s.yaml and src/components/microservices/k3sctl-adapter/k3s/code-queue.g14.k3s.json are candidate staging artifacts only until an explicit production cutover is approved. Production Code Queue, CI/CD and user-service execution must remain on D601 while D601 is carrying production.

HWLAB DEV Staging

G14 can host a parallel HWLAB DEV staging cluster in the native k3s namespace hwlab-dev. The canonical G14 HWLAB source workspace is /root/hwlab on branch G14, with origin set to git@github.com:pikasTech/HWLAB.git; G14 source edits, CI/CD script changes, render work and manual polling must be done from that workspace through UniDesk SSH passthrough. Do not use /root/HWLAB, /home/ubuntu/hwlab, /workspace/hwlab or a master-server checkout as persistent G14 source truth. G14-local details are mirrored on the node in /root/docs/hwlab-g14-workspace.md.

The standard entry forms are:

bun scripts/cli.ts ssh G14 script <<'SCRIPT'
set -eu
cd /root/hwlab
git status --short --branch
SCRIPT

bun scripts/cli.ts ssh G14 apply-patch < patch.diff
bun scripts/cli.ts ssh G14:k3s kubectl get pods -n hwlab-ci

G14:k3s is the only supported k3s route form. Do not use ssh G14 k3s ...; the first token must locate the distributed target, and the following tokens must be the operation.

The G14 HWLAB DEV boundary is:

  • Do not switch public traffic, DNS, FRP, UniDesk microservice routing or Code Queue/CI/CD control from D601 to G14 during staging.
  • Keep hwlab-tunnel-client scaled to 0 replicas unless a separate cutover approval explicitly enables a public tunnel.
  • Keep G14 HWLAB Services as ClusterIP; use kubectl port-forward --address 127.0.0.1 or in-cluster probes for smoke tests.
  • Use a G14-local PostgreSQL instance such as hwlab-g14-postgres and a G14-local hwlab-cloud-api-dev-db Secret for cloud-api durable runtime tests. Do not copy D601 database credentials.
  • Use only G14-local placeholder Codex auth for mount/readiness tests unless real Code Agent execution on G14 has been separately authorized; do not copy D601 or production auth material.
  • Set HWLAB_CLOUD_API_PORT=6667 explicitly in the G14 cloud-api Deployment. Kubernetes otherwise injects a HWLAB_CLOUD_API_PORT=tcp://... Service environment variable that breaks the Node port parser.
  • Override HWLAB_PUBLIC_ENDPOINT to a cluster-local G14 endpoint while no public tunnel is active, so staging services do not advertise the D601 production endpoint.
  • Do not run HWLAB repository check, Playwright/browser smoke, image builds or other heavy validation on the master server. Run those through G14 /root/hwlab, G14 k3s/Tekton, or another explicitly approved external execution plane.

After the G14-local database is provisioned, run the HWLAB migration CLI only against the G14 DEV database with explicit non-production confirmations:

kubectl -n hwlab-dev exec deploy/hwlab-cloud-api -- \
  node /app/cmd/hwlab-cloud-api/migrate.mjs \
  --apply --confirm-dev --confirmed-non-production

Healthy G14 HWLAB staging means the main Deployments and StatefulSets are Ready, cloud-api and edge-proxy return /health/live with status=ok, and hwlab-tunnel-client still has replicas=0 and no Pods. hwlab-agent-mgr can report degraded while no skills manifest commit/version is wired; treat that as an agent-runtime metadata gap, not as a traffic switch signal.

Node-Local VPN Proxy

G14 has a node-local VPN/proxy stack for infrastructure bootstrap and recovery downloads:

  • Primary mixed HTTP/SOCKS proxy: 127.0.0.1:10808.
  • Backup Hysteria2 HTTP proxy: 127.0.0.1:11809.
  • Backup Hysteria2 SOCKS5 proxy: 127.0.0.1:11808.
  • Operator-only local details remain on G14 under /root/docs/vpn-proxy-ops.md; subscription URLs, node credentials and GUI database contents must not be copied into the UniDesk repository.

The G14 host persists this proxy configuration in these local files:

  • /etc/profile.d/unidesk-g14-proxy.sh exports HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, lowercase aliases and NO_PROXY for new login shells. Set UNIDESK_G14_DISABLE_PROXY=1 before shell startup to opt out.
  • /root/.npmrc pins npm proxy, https-proxy, noproxy and retry settings for root-side bootstrap commands.
  • /root/.gitconfig pins root Git HTTP/HTTPS proxy settings.
  • /root/.docker/config.json pins Docker client proxy settings for commands and build contexts that honor Docker client proxy configuration.
  • /etc/systemd/system/docker.service.d/proxy.conf pins Docker daemon pull proxy settings. Updating this drop-in requires systemctl daemon-reload and a Docker restart before the active daemon sees the new NO_PROXY; do not restart Docker while G14 provider-gateway, k3s bootstrap or image builds are in flight unless that interruption is intentional.

The NO_PROXY list must include localhost, the main server, private LAN ranges, k3s pod/service CIDRs, Kubernetes service domains and the loopback registry so that k3s, 127.0.0.1:5000, Kubernetes API access and UniDesk control paths do not route through the VPN proxy.

The primary proxy can be used for G14 target-side image bootstrap when Docker Hub, npm, GitHub or Playwright downloads are unreliable through direct network or provider-gateway WS egress. For Docker build steps that use 127.0.0.1, build with host networking so the build container reaches the host proxy:

docker build --network host \
  --build-arg HTTP_PROXY=http://127.0.0.1:10808 \
  --build-arg HTTPS_PROXY=http://127.0.0.1:10808 \
  --build-arg ALL_PROXY=socks5h://127.0.0.1:10808 \
  --build-arg http_proxy=http://127.0.0.1:10808 \
  --build-arg https_proxy=http://127.0.0.1:10808 \
  --build-arg all_proxy=socks5h://127.0.0.1:10808 \
  ...

The backup proxy uses HTTP_PROXY=http://127.0.0.1:11809, HTTPS_PROXY=http://127.0.0.1:11809 and ALL_PROXY=socks5h://127.0.0.1:11808.

This proxy is not a replacement for UniDesk runtime egress. k3s workloads such as Code Queue must still use the cataloged g14-provider-egress-proxy Kubernetes Service and g14-tcp-egress-gateway for normal runtime access to PostgreSQL, OA Event Flow and external APIs. The node-local VPN proxy is allowed only for G14 host-side bootstrap, image build, cache prewarm or recovery steps, and those steps should record the proxy choice in issue or deployment evidence.

Reference in New Issue View Git Blame Copy Permalink