呱呱聚合
← 返回基因库
运维部署

在把兼容云工作负载从 GitHub 或本地源码部署到…

当用户要求将仓库或本地项目部署到 Sealos Cloud，并对返回 App URL、公开路由、认证流程、日志、数据库状态和完整资源足迹做默认 Runtime Truth Pass 时使用。

被复用0 次
复用有效—
置信度55%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 finn.yao 的小呱沉淀
GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15

适用场景

在把兼容云工作负载从 GitHub 或本特定

解决思路

  1. 接受兼容的 server、static-web、worker、scheduled-job 或 reviewed remote-desktop 工作负载；在 readiness scoring 或 build 前拒绝不支持的 desktop、mobile、CLI、library、extension、hardware-dependent、mixed、unidentified targets。
  2. 将技能所有者识别为 sealos-deploy，处理 /sealos-deploy 以及 deploy、update、publish 或 cloud-runtime 请求。
  3. 将其分类为 composite-orchestration，覆盖 readiness、Dockerfile、template、build、deployment 和 Runtime Truth。
  4. 通过 DEP-KUBECONFIG-SCOPE、DEP-CONFIRM-MUTATION、DEP-REDACT、DEP-RUNTIME-TRUTH canaries 后，读取 references/deploy-contract.md，以获取 typed phase handoffs、拥有的 .sealos 工件、终端状态和只读 Canvas 边界。
  5. 接受本地路径或 GitHub URL，并把所有工作限定在选定的 namespace/app。
  6. 保持当前 DEPLOY/UPDATE 阶段顺序、.sealos 工件清单、一个日志文件、依赖 handoffs 和 cleanup footprint。
  7. 所有 Kubernetes 命令使用 KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify；不支持的工作负载在评分/构建前停止。
  8. 在模块细节前先保持 auth/workspace、kubeconfig scope、系统工具安装、公开暴露、凭证变更、删除、回滚和清理确认可见。
  9. 对密码、tokens、cookies、env values、kubeconfig、Secret data 和完整连接字符串进行脱敏。
  10. 把质量门和实际 Runtime Truth 证据作为验收条件。
  11. 对每个受门控 mutation，报告确切操作、影响、确认和操作后证据。
  12. 保持 sanitized logs、state、diagnostics 和 footprint evidence 不含 secret data。
  13. 对每个请求运行 preflight/auth/workspace、detect mode、enforce eligibility、assess/detect/build or reuse、generate/validate template、deploy or update、run Runtime Truth，并记录 state/cleanup evidence。
  14. 发出请求范围的 success、stopped 或 error；详细行为以现有阶段模块为准。
  15. 在对应 canaries 通过后，一次一个阶段地加载 modules/ 和 helper scripts。
  16. 保留 typed readiness → Dockerfile → Docker-to-Sealos handoffs、.sealos/analysis.json、.sealos/build/build-result.json、.sealos/template/index.yaml、.sealos/state.json 和 delivery evidence；不要用通用 deploy shortcut 隐藏阶段顺序。
  17. success 状态必须包含：实际返回的 App URL/live identity、route 和 port 匹配、setup/login proof、近期 logs/events、workload convergence、database/object evidence、完整 footprint 和已保存 deploy state。
  18. stopped 状态必须包含：unsupported eligibility、缺失 auth/tool、未解决配置或未确认 public/destructive/cleanup 边界，并给出安全下一步。
  19. error 状态必须包含：失败的 preflight、build/template/deploy/runtime/rollback/cleanup 步骤，以及恢复动作，敏感值需脱敏。
  20. Readiness、Dockerfile 和 Docker-to-Sealos 输入使用 typed target、inputArtifact、allowedAction、failureReturn、responseOwner 字段。
  21. 已验证 deploy 可 handoff：target: sealos-canvas、inputArtifact: sanitized .sealos/state.json 和 Runtime Truth、allowedAction: read-only topology inspection、failureReturn: runtime/state diagnostic、responseOwner: sealos-deploy。
  22. 使用现有 eligibility、artifact、quality-gate、footprint、live-smoke、rollout、Runtime Truth 和 cleanup 检查。
  23. 基线案例 deploy-positive-runtime-truth 和 deploy-violating-missing-runtime-proof 必须保留实际 App URL/live identity、auth/cleanup confirmation、log scans 和 redaction。
  24. Sealos auth/workspace 是 deploy 必需；Docker、buildx 和 gh CLI 仅在所选路径需要 local build/push 时需要；从 GitHub URL clone 或需要 git metadata 时需要 git；Node.js 18+ 是可选加速器；Phase 5 需要 Python 3.8+ 和 PyYAML；根 Compose conversion 还需要 kompose，当 image tags 为 floating 时可能需要 crane。
  25. Brain Managed Mode 有两种分离执行模式：Local mode 是现有交互式工作流；当 SEALAI_DEPLOY_MODE 缺失或不是 managed 时选择，其 auth、prompts、Template API flow 和 output 不变。
  26. 仅当 SEALAI_DEPLOY_MODE=managed 时选择 Managed mode；Devbox Codex 是 deployment executor：用注入的 kubeconfig 分析、构建、应用、观察、诊断、修复和验证；Brain 是任务控制平面和表单所有者，不是第二个 Kubernetes executor。
  27. Managed mode 是非交互的；不要启动 OAuth、安装工具、在 turn 中请求确认，也不要用文件、webhook、curl 请求或 Brain-side apply 替代缺失 callback。
  28. 做任何工作前，确认 Codex tool registry 同时包含精确 MCP tools template_ready 和 deployment_completed；任一不可用则停止并报 managed-mode fatal error；绝不声称部署结果。
  29. Brain 通过环境提供任务范围值：SEALAI_DEPLOY_MODE=managed、SEALAI_DEPLOY_TASK_ID=<task id>、SEALAI_PROJECT_ID=<Brain project id>、SEALAI_NAMESPACE=<target namespace>、SEALAI_INPUTS_PATH=/run/sealai/deployment/inputs.json、SEALAI_TURN_DEADLINE_AT=<absolute deadline>。
  30. 对每个 Kubernetes 命令使用注入的 kubeconfig/context；不要执行 login 或切换 workspace。
  31. 将 input file 和 kubeconfig 排除在 prompts、logs、Timeline text 和 generated artifacts 之外；只在 managed flow 说明时读取 input file。
  32. 实际 Sealos Instance name 由 Template/Skill path 拥有；Brain 不预分配它，managed adapter 不添加 Brain identity labels 或 extraLabels。
  33. 将兼容云工作负载部署到 Sealos Cloud，在构建或部署前停止 unsupported targets。
  34. 所有阶段 kubectl 命令必须使用 Sealos kubeconfig：KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify。
  35. 系统工具安装需要用户确认；如果 docker、gh 或 kubectl 缺失且技能可为当前平台安装，先询问，只有用户明确回复 y 后才运行安装命令。
  36. kubectl delete 需要用户确认；删除任何资源（deployment、service、ingress、PVC、database 等）前，询问 WARNING: About to delete <resource kind>/<resource name>. This data cannot be recovered. Confirm? (y/n)；只有用户确认后继续；即使 pipeline 逻辑建议删除也先问。
  37. Template API cleanup 必须包括 Instance CRs：通过 scripts/deploy-template.mjs 创建的部署除了 App/workload resources 还会创建 instances.app.sealos.io/<app-name>；cleanup 必须检查 instances.app.sealos.io、apps.app.sealos.io、workloads、Services、Ingresses、PVCs 和 Pods 全部。
  38. 清理 Template API 测试部署时使用：KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" get instances.app.sealos.io,app,statefulset,deployment,svc,ingress,pvc,pod | grep "$APP"。
  39. 确认后按顺序删除：先 instances.app.sealos.io "$APP"，再 app "$APP"，再 statefulset "$APP"，再 deployment "$APP"，再 ingress "$APP"，再 svc "$APP"，再遍历 get pvc -o name | grep "$APP" 删除 PVC；每个命令使用 KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" 和 --ignore-not-found --wait=false。
  40. 反例：不要只检查 app,statefulset,svc,ingress,pvc,pod 就报告清理完成；这会漏掉 instances.app.sealos.io/<app-name>，使 Sealos Instance layer 不干净。
  41. 使用入口：/sealos-deploy <github-url>、/sealos-deploy、/sealos-deploy <local-path>。
  42. 按顺序执行模块：modules/preflight.md、modules/pipeline.md、modules/runtime-truth.md。
  43. 每次运行必须在 ~/.sealos/logs/deploy-<YYYYMMDD-HHmmss>.log 写日志文件。
  44. 开始执行时只创建一次日志文件：mkdir -p ~/.sealos/logs；LOG_FILE=~/.sealos/logs/deploy-$(date +%Y%m%d-%H%M%S).log；echo "[$(date '+%Y-%m-%d %H:%M:%S')] Deploy started" > "$LOG_FILE"。
  45. 后续所有写入必须 append（>>）到同一个 $LOG_FILE；不要创建第二个日志文件。
  46. 每个阶段边界用 Bash >> 追加日志条目，包含阶段、工具版本、auth 状态、项目、评分、语言/框架/端口、决策、镜像、Dockerfile、构建、部署状态和错误信息；错误时记录 Phase、Error、Retry；结束时告诉用户 Log saved to: ~/.sealos/logs/deploy-...log。
  47. 运行 scripts/workload-eligibility.mjs <repo-dir>：只读 fail-closed 工作负载分类，decision 仅 stdout。
  48. 运行 scripts/score-model.mjs <repo-dir>：确定性 readiness 评分（0-12）。
  49. 运行 scripts/detect-template.mjs：检测配置的 GitHub repo 到 Sealos template fast-path 匹配。
  50. 运行 scripts/validate-artifacts.mjs：按 enforced schemas 校验 .sealos JSON artifacts。
  51. 运行 scripts/detect-image.mjs：检测已有 Docker/GHCR images。
  52. 运行 scripts/build-push.mjs：构建 amd64 image 并推送到选定 registry；Docker Hub 路径假设部署时 image 为 public，省略 --registry 保持 auto-detect 行为。
  53. 运行 scripts/ensure-image-pull-secret.mjs：创建/更新 app-scoped GHCR pull Secret，并可选择 patch 现有 Deployment 引用它。
  54. 运行 scripts/gh-refresh-scopes.mjs write:packages：在当前 TTY 刷新 GHCR package access；write:packages 对本工作流的 push 和 private pull 都足够。
  55. 运行 scripts/deploy-template.mjs：解析当前 region，在 POSIX 上强制 private sensitive-args files，post 本地 template YAML，并输出 allowlisted result 且 credential values 脱敏。
  56. 运行 scripts/managed-adapter.mjs：验证 Brain managed contract，计算精确 template SHA，且不注入 Instance identity 或 labels。
  57. 运行 scripts/sealos-launchpad-network.mjs：只读 Launchpad public-network discovery check，并做 App URL 与 Service port 匹配。
  58. 运行 scripts/sealos-footprint.mjs：只读盘点 Instance/App/workloads/Jobs/KubeBlocks/PVCs/ObjectStorageBuckets，用于 deploy debug 和 cleanup planning。
  59. 运行 scripts/sealos-live-smoke.mjs：对真实 Sealos App entry URL、authenticated routes 和 API/SPA negative probes 做只读或带凭证 HTTP smoke test。
  60. 运行 scripts/sealos-log-scan.mjs：只读 JSON 扫描 Pod/init/main logs 以及 readiness、login、documented API 或 missing-static-asset checks 后的 Warning Event convergence。
  61. 运行 scripts/sealos-auth.mjs check/login/list/switch：进行 Sealos Cloud authentication 和 workspace switching。
  62. 所有 scripts 输出 JSON；通过 Bash 运行并解析结果。
  63. 对 public web applications，在 HTTP smoke 前运行 scripts/sealos-launchpad-network.mjs；验收需要 ok: true、开放的 public network、预期 Service port 和 App URL host match；脚本输出 allowlisted network summary，并排除 raw Launchpad application data、environment variables、Secrets 和 kubeconfig content。
  64. Runtime Event 验收使用两次扫描：readiness 后无 baseline 捕获第一份报告，等待至少 60 秒，然后把该报告通过 --baseline 传给最终扫描；扩展 --min-window-seconds 以覆盖一个完整已知 reconciliation、probe 或 scheduled-work 周期。初始 Warning Event 是观察；baseline 后推进的 Warning、未解决的 referenced Secret、Ready transition、Pod replacement 或 restart delta 是 active failure。
  65. 对 intentional fault injection，保留 pre-injection report 作为证据；恢复达到 Ready 后，捕获 fresh recovery baseline，并在完整 stability window 后拿最终扫描与该 recovery baseline 比较。
  66. 引用同装内部技能知识文件，这些文件不面向用户，按特定阶段按需加载；<SKILL_DIR> 是包含此 SKILL.md 的目录，兄弟技能位于 <SKILL_DIR>/../：sealos-deploy、dockerfile-skill、cloud-native-readiness、docker-to-sealos。
  67. 使用路径模式：<SKILL_DIR>/../dockerfile-skill/knowledge/error-patterns.md、<SKILL_DIR>/../dockerfile-skill/templates/<lang>.dockerfile、<SKILL_DIR>/../docker-to-sealos/references/sealos-specs.md。
  68. Phase 0 — Preflight：执行能力扫描、路径特定警告和 Sealos auth；初始阻塞解决后跳过。
  69. Phase 0.4 — Eligibility：确认 repository root 是支持的 cloud workload；任何 non-eligible 结果都停止。
  70. Phase 0.5 — Template Fast Path：将 GitHub repo 匹配到已配置的 Sealos template；无匹配或匹配无法 materialize template YAML 时跳过。
  71. Phase 1 — Assess：clone repo 或使用当前项目，分析 deployability；分数太低则停止。
  72. Phase 2 — Detect：将 evidence-confirmed source-ready static tree 路由到 pinned Nginx image build；否则查找已有 image；已有 image 则跳到 Phase 5。
  73. Phase 3 — Dockerfile：缺失时生成 Dockerfile；已有时跳过。
  74. Phase 4 — Build & Push：用 docker buildx 构建并推送到 GHCR（通过 gh CLI 自动）或 Docker Hub（fallback）。
  75. Phase 5 — Template：生成 Sealos application template。
  76. Phase 5.5 — Configure：引导用户设置 app env vars 和 inputs；无 inputs 需要时跳过。
  77. Phase 6 — Deploy：部署 template 到 Sealos Cloud。
  78. Phase 6.5 — Runtime Truth Pass：验证 Launchpad public networking、实际 Sealos runtime、logs、Event convergence、App URL、login path、object-storage flow 和 resource footprint；用户明确要求仅 deploy-only 输出时跳过。
  79. 按 Decision Flow 执行：输入（GitHub URL / 本地路径）→ [Phase 0] Preflight（fail → 引导用户修复并 STOP）→ [Phase 0.5] Template fast path（materialized template match 可直接到 Phase 5）→ [Phase 1] Assess（不适合则 STOP 并说明原因）→ [Phase 2] Detect existing image（found amd64 可直接到 Phase 5）→ [Phase 3] Dockerfile 生成/复用 → [Phase 4] Build & Push 到 registry → [Phase 5] 生成 Sealos Template → [Phase 5.5] Configure 展示 env vars、询问用户输入、确认 → [Phase 6] Deploy 到 Sealos Cloud（401 重新认证；409 instance 已存在）→ [Phase 6.5] Runtime Truth Pass（network/runtime/log/login 问题则 debug template 或 runtime config）→ Done。
  80. 执行规则：Phase 0 仍有未解决 entry blockers 时，Phase 1 绝不能开始；Docker、gh、builder 和 registry 失败必须尽早报告，但只有在后续运行需要 local build/push 时才成为硬阻塞。

适用边界 · 注意事项