fix: keep dev code queue deploy target side
This commit is contained in:
@@ -75,7 +75,7 @@ Phase 5 introduces the dev Code Queue execution manifest at `src/components/micr
|
||||
|
||||
All dev Code Queue components must use `unidesk-dev-runtime-config` and `unidesk-dev-runtime-secrets`, connect to `postgres-dev.../unidesk_dev`, write logs and state under `/home/ubuntu/unidesk-dev-code-queue-deploy/state`, and expose HTTP on 4222 only as ClusterIP services. The scheduler uses `CODE_QUEUE_MAIN_PROVIDER_ID=D601-dev`, `CODE_QUEUE_WORKDIR=/workspace-dev`, `CODE_QUEUE_REMOTE_WORKDIR=/home/ubuntu/unidesk-dev-workspace`, disables ClaudeQQ notifications by default, and does not use the production `d601-tcp-egress-gateway` or production PostgreSQL route.
|
||||
|
||||
`deploy apply --env dev --service code-queue` fetches `origin/deploy/dev:deploy.json`, materializes the requested source commit on D601, copies the dev Code Queue control manifest, narrows it to Code Queue dev objects, replaces placeholders with the requested commit and `unidesk-code-queue:dev`, builds on D601, imports the image into native k3s containerd, applies only `unidesk-dev` objects and stamps the dev Deployments. Because Code Queue carries the agent toolchain and browser/runtime dependencies, dev builds may reuse an existing D601 `unidesk-code-queue:d601-build-base` or `unidesk-code-queue:d601` image when the dev build-base tag is absent, and the deploy executor allows a longer Code Queue build window than lightweight services. This first dev execution slice proves deployability, health and dev database isolation; wiring the dev frontend stable `code-queue` route through a dev `code-queue-mgr` is a separate later phase.
|
||||
`deploy apply --env dev --service code-queue` fetches `origin/deploy/dev:deploy.json`, materializes the requested source commit on D601, uses the dev Code Queue control manifest from that D601 materialized commit, narrows it to Code Queue dev objects, replaces placeholders with the requested commit and `unidesk-code-queue:dev`, builds on D601, imports the image into native k3s containerd, applies only `unidesk-dev` objects and stamps the dev Deployments. Because Code Queue carries the agent toolchain and browser/runtime dependencies, dev builds may reuse an existing D601 `unidesk-code-queue:d601-build-base` or `unidesk-code-queue:d601` image when the dev build-base tag is absent, and the deploy executor allows a longer Code Queue build window than lightweight services. The scheduler has an explicit 5Gi memory limit, and all dev Code Queue containers must set CPU limits so the namespace `LimitRange` does not inject a quota-breaking default CPU limit. This first dev execution slice proves deployability, health and dev database isolation; wiring the dev frontend stable `code-queue` route through a dev `code-queue-mgr` is a separate later phase.
|
||||
|
||||
## CLI
|
||||
|
||||
@@ -100,7 +100,7 @@ Target-side build is the only standard deployment mode. The controller may run o
|
||||
|
||||
The reconciler distributes only repository URL, commit ID, Dockerfile path, build context and the existing deployment manifest/compose declaration. It must not distribute large Docker images between hosts as the default path, and it must not accept `docker commit` images, dirty worktrees or hand-mutated runtime containers as deployment truth.
|
||||
|
||||
Each target fetches the remote repository, resolves the requested commit to a full 40 character SHA and exports tracked files with `git archive`. Build contexts are created from that archive, not from the operator's current working tree.
|
||||
Each target fetches the remote repository, resolves the requested commit to a full 40 character SHA and exports tracked files with `git archive`. Build contexts are created from that archive, not from the operator's current working tree. Environment applies such as `deploy apply --env dev` must not upload Kubernetes manifests or source files from the master server worktree; the target-side materialized commit is the source for Dockerfile, build context and k3s control manifests. The master server side may only do lightweight CLI orchestration, environment ref reading and remote command dispatch.
|
||||
|
||||
## One-Shot Build Proxy
|
||||
|
||||
|
||||
@@ -1070,16 +1070,13 @@ function claudeqqDeployAssetOverlayCommands(): string[] {
|
||||
function syncK8sControlManifestsScript(service: UniDeskMicroserviceConfig): string {
|
||||
if (isDevK3sDeployService(service)) {
|
||||
const manifest = k8sManifestPath(service);
|
||||
if (!existsSync(rootPath(manifest))) throw new Error(`${service.id} dev k3s control manifest missing: ${manifest}`);
|
||||
const encoded = Buffer.from(readFileSync(rootPath(manifest), "utf8"), "utf8").toString("base64");
|
||||
return [
|
||||
"set -euo pipefail",
|
||||
`target_root=${shellQuote(targetWorkDir(service))}`,
|
||||
`relative_path=${shellQuote(manifest)}`,
|
||||
"target_file=\"$target_root/$relative_path\"",
|
||||
"mkdir -p \"$(dirname \"$target_file\")\"",
|
||||
`printf %s ${shellQuote(encoded)} | base64 -d > "$target_file"`,
|
||||
"printf 'synced_k3s_control_manifest=%s\\n' \"$target_file\"",
|
||||
"test -f \"$target_file\"",
|
||||
"printf 'target_k3s_control_manifest=%s\\n' \"$target_file\"",
|
||||
].join("\n");
|
||||
}
|
||||
if (service.deployment.mode !== "k3sctl-managed" || isUnideskRepo(service.repository.url)) return "";
|
||||
@@ -2110,7 +2107,8 @@ async function applyOneService(config: UniDeskConfig, service: UniDeskMicroservi
|
||||
|
||||
const controlManifestSyncScript = syncK8sControlManifestsScript(service);
|
||||
if (controlManifestSyncScript.length > 0) {
|
||||
const controlManifestSync = await step(config, service, "sync-k3s-control-manifests", controlManifestSyncScript, targetIsMain(service) ? repoRoot : "/home/ubuntu", 90_000, !targetIsMain(service));
|
||||
const controlManifestStep = isDevK3sDeployService(service) ? "verify-target-k3s-manifest" : "sync-k3s-control-manifests";
|
||||
const controlManifestSync = await step(config, service, controlManifestStep, controlManifestSyncScript, targetIsMain(service) ? repoRoot : "/home/ubuntu", 90_000, !targetIsMain(service));
|
||||
if (!pushStep(steps, controlManifestSync)) return { ok: false, serviceId: service.id, startedAt, finishedAt: nowIso(), resolvedCommit, before, steps };
|
||||
}
|
||||
|
||||
@@ -2296,9 +2294,8 @@ export async function runDeployCommand(config: UniDeskConfig | null, args: strin
|
||||
throw new Error(`deploy apply --env dev currently supports only ${[...devApplySupportedServiceIds].join(", ")}; unsupported selected services: ${unsupported.join(", ")}`);
|
||||
}
|
||||
if (config === null) throw new Error("deploy apply --env dev requires config.json");
|
||||
const resolved = resolveManifestCommits(manifest, options.serviceId);
|
||||
if (!options.runNow) return applyJob(config, args, options);
|
||||
return await runApplyNow(config, resolved, options);
|
||||
return await runApplyNow(config, manifest, options);
|
||||
}
|
||||
if (config === null) throw new Error("deploy local manifest mode requires config.json");
|
||||
const manifest = resolveManifestCommits(await readDeployManifest(options.file), options.serviceId);
|
||||
|
||||
+11
-1
@@ -224,6 +224,13 @@ spec:
|
||||
periodSeconds: 10
|
||||
timeoutSeconds: 3
|
||||
failureThreshold: 6
|
||||
resources:
|
||||
requests:
|
||||
cpu: 25m
|
||||
memory: 64Mi
|
||||
limits:
|
||||
cpu: 100m
|
||||
memory: 128Mi
|
||||
volumes:
|
||||
- name: script
|
||||
configMap:
|
||||
@@ -406,7 +413,8 @@ spec:
|
||||
cpu: 150m
|
||||
memory: 384Mi
|
||||
limits:
|
||||
memory: 3Gi
|
||||
cpu: 800m
|
||||
memory: 5Gi
|
||||
volumes:
|
||||
- name: docker-sock
|
||||
hostPath:
|
||||
@@ -568,6 +576,7 @@ spec:
|
||||
cpu: 80m
|
||||
memory: 192Mi
|
||||
limits:
|
||||
cpu: 250m
|
||||
memory: 768Mi
|
||||
volumes:
|
||||
- name: repo
|
||||
@@ -710,6 +719,7 @@ spec:
|
||||
cpu: 80m
|
||||
memory: 192Mi
|
||||
limits:
|
||||
cpu: 250m
|
||||
memory: 768Mi
|
||||
volumes:
|
||||
- name: repo
|
||||
|
||||
@@ -40,10 +40,11 @@ spec:
|
||||
cpu: 50m
|
||||
memory: 96Mi
|
||||
default:
|
||||
cpu: 250m
|
||||
memory: 512Mi
|
||||
max:
|
||||
cpu: "2"
|
||||
memory: 2Gi
|
||||
memory: 5Gi
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
|
||||
Reference in New Issue
Block a user