npx skills add https://github.com/incept5/eve-skillpacks --skill eve-deploy-debugging使用以下步骤快速部署和诊断应用问题。
从管理员处获取预发布环境 API URL。
创建并使用一个配置文件:
eve profile create staging --api-url https://api.eh1.incept5.dev eve profile use staging
切勿对共享基础设施运行 kubectl apply、helm install 或任何直接的 Kubernetes 资源创建操作。所有基础设施变更都通过 Terraform 进行。使用 Eve CLI(eve env、eve env deploy)来管理应用程序部署——平台会处理底层的 k8s 资源。
# 如果需要,创建环境
eve env create staging --project proj_xxx --type persistent
# 部署(需要 --ref 参数,值为 40 位字符的 SHA 或相对于 --repo-dir 解析的引用)
eve env deploy staging --ref main --repo-dir .
# 当环境配置了流水线时,上述命令会触发流水线。
# 使用 --direct 绕过流水线直接部署:
eve env deploy staging --ref main --repo-dir . --direct
# 向流水线传递输入:
eve env deploy staging --ref main --repo-dir . --inputs '{"key":"value"}'
Use these steps to deploy and diagnose app issues quickly.
Get the staging API URL from your admin.
Create and use a profile:
eve profile create staging --api-url https://api.eh1.incept5.dev eve profile use staging
Never run kubectl apply, helm install, or any direct Kubernetes resource creation against shared infrastructure. All infrastructure changes go through Terraform. Use the Eve CLI (eve env, eve env deploy) to manage application deployments — the platform handles the underlying k8s resources.
# Create env if needed
eve env create staging --project proj_xxx --type persistent
# Deploy (requires --ref with 40-char SHA or a ref resolved against --repo-dir)
eve env deploy staging --ref main --repo-dir .
# When environment has a pipeline configured, the above triggers the pipeline.
# Use --direct to bypass pipeline and deploy directly:
eve env deploy staging --ref main --repo-dir . --direct
# Pass inputs to pipeline:
eve env deploy staging --ref main --repo-dir . --inputs '{"key":"value"}'
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
当调用 eve env deploy 时:
deployment_status。轮询健康端点直到 ready === true。pipeline_run_id。轮询 GET /pipelines/{name}/runs/{id} 直到所有步骤完成,然后检查健康状态。部署完成的条件是:ready === true 且 active_pipeline_run === null。
eve job list --phase active
eve job follow <job-id> # 实时 SSE 流
eve job watch <job-id> # 基于轮询的状态更新
eve job diagnose <job-id> # 完整诊断
eve job result <job-id> # 最终结果
eve job runner-logs <job-id> # 原始工作进程日志
# 终端 1:流水线/作业进度
eve job follow <job-id>
# 终端 2:环境健康状态
eve env diagnose <project> <env>
# 终端 3:系统级日志
eve system logs
eve job dep list <job-id>eve job show <job-id> → 查看 blocked_byeve env show <project> <env>eve system orchestrator statuseve job diagnose <job-id>eve job follow <job-id> 或 eve job runner-logs <job-id>eve build diagnose <build-id>eve secrets list --project <project_id>eve job show <job-id> → effective_phaseeve thread messages <thread-id>eve system podseve system healtheve system orchestrator statuseve system events| 错误 | 原因 | 修复方法 |
|---|---|---|
401 Unauthorized | 令牌过期 | eve auth login |
git clone failed | 缺少凭据 | 设置 github_token 或 ssh_key 密钥 |
service not provisioned | 环境未创建 | eve env create <env> |
image pull backoff | 注册表认证失败 | 如果使用 BYO/自定义注册表,请验证 REGISTRY_USERNAME + REGISTRY_PASSWORD;对于托管应用,使用 registry: "eve" |
healthcheck timeout | 应用未启动 | 检查应用日志,验证清单中的端口 |
如果部署流水线在构建步骤失败:
eve build list --project <project_id>
eve build diagnose <build_id>
eve build logs <build_id>
eve secrets list --project <project_id> # BYO/自定义注册表所需:REGISTRY_USERNAME, REGISTRY_PASSWORD
常见的构建失败:
REGISTRY_USERNAME 和 REGISTRY_PASSWORD 密钥build.context 的路径eve build diagnoseEve 将工作进程镜像发布到配置的私有注册表,包含以下变体:
| 变体 | 内容 |
|---|---|
base | Node.js, git, 标准 CLI 工具 |
python | Base + Python 运行时 |
rust | Base + Rust 工具链 |
java | Base + JDK |
kotlin | Base + Kotlin 编译器 |
full | 所有运行时组合 |
版本固定:在生产环境中使用语义化版本标签(例如 v1.2.3)。在开发环境中使用 SHA 标签或 :latest。
Eve 自动将这些变量注入到每个已部署的服务容器中:
| 变量 | 用途 |
|---|---|
EVE_API_URL | 用于服务器间调用的内部集群 URL |
EVE_PUBLIC_API_URL | 面向浏览器应用的公共入口 URL(配置后) |
EVE_SSO_URL | 用于用户身份验证的 SSO 代理 URL(配置后) |
EVE_PROJECT_ID | 当前项目 ID |
EVE_ORG_ID | 当前组织 ID |
EVE_ENV_NAME | 当前环境名称 |
后端调用使用 EVE_API_URL。浏览器/客户端代码使用 EVE_PUBLIC_API_URL。服务可以通过在其清单的 environment 部分显式定义这些变量来覆盖它们。
{service}.{orgSlug}-{projectSlug}-{env}.{domain}lvh.me| 环境 | 如何调试 |
|---|---|
| 本地 (k3d) | 通过入口直接访问服务,eve system logs |
| Docker Compose | docker compose logs <service>,仅限开发(不用于生产) |
| Kubernetes | 基于入口的访问,最后手段使用 kubectl -n eve logs |
将私有网络上的服务(家庭实验室 GPU、内部 API、开发机器)连接到 Eve 集群。平台创建由 Tailscale 出口代理支持的 K8s ExternalName 服务。
# 注册私有端点
eve endpoint add \
--name lmstudio \
--provider tailscale \
--tailscale-hostname mac-mini.tail12345.ts.net \
--port 1234 \
--org org_xxx
# 列出并检查
eve endpoint list --org org_xxx
eve endpoint show lmstudio --org org_xxx
# 诊断连接性
eve endpoint diagnose lmstudio
# 移除
eve endpoint remove lmstudio --org org_xxx
每个端点都会获得一个稳定的集群内 DNS 名称:http://{orgSlug}-{name}.eve-tunnels.svc.cluster.local:{port}。通过密钥将其连接到应用/代理:
eve secrets set LLM_BASE_URL \
"http://myorg-lmstudio.eve-tunnels.svc.cluster.local:1234/v1" \
--scope project
诊断检查包括:操作员状态、K8s 服务是否存在、DNS 解析、TCP 连接性和 HTTP 健康状态。
默认的工作进程镜像是 base(约 800MB,包含 Node.js、git 和所有工具链)。工具链(Python、Rust、Java、Kotlin、媒体)通过初始化容器按需注入,而不是捆绑在一个臃肿的镜像中。
部署影响:如果代理作业需要工具链,运行器 Pod 会启动初始化容器,从小型预构建镜像中复制工具链二进制文件。首次拉取会增加约 5-10 秒;同一节点上的后续作业使用缓存的镜像。
调试工具链问题:
# 检查代理配置中是否声明了工具链
# agents.yaml: toolchains: [python]
# 如果运行时缺少工具链二进制文件:
# 1. 验证代理配置已声明该工具链
# 2. 检查运行器 Pod 上的初始化容器日志
# 3. 验证注册表中工具链镜像是否可用
要使用完整镜像(捆绑所有工具链):设置 EVE_WORKER_VARIANT=full 或在本地使用 --variant full。
移除环境并清理资源:
# 从环境中卸载服务(停止 Pod,保留环境记录)
eve env undeploy <project> <env>
# 完全删除环境(移除环境记录、托管数据库、密钥)
eve env delete <project> <env>
当附加了托管数据库时,eve env delete 会取消其配置。作用域为该环境的密钥会被清理。环境的流水线历史记录保留在审计日志中。
对于应用级清理,删除项目:
eve project delete <project-id>
这会级联删除:环境、密钥、流水线历史记录和构建产物都会被移除。
用于代理工作区的生产磁盘管理:
EVE_WORKSPACE_MAX_GB — 工作区总预算EVE_WORKSPACE_MIN_FREE_GB — 触发清理的阈值EVE_SESSION_TTL_HOURS — 自动驱逐过期会话eve-local-dev-loopeve-auth-and-secretseve-manifest-authoring每周安装数
149
代码仓库
首次出现
2026年2月8日
安全审计
安装于
gemini-cli149
codex149
claude-code146
pi52
opencode32
github-copilot32
When eve env deploy is called:
deployment_status directly. Poll health endpoint until ready === true.pipeline_run_id. Poll GET /pipelines/{name}/runs/{id} until all steps complete, then check health.Deploy is complete when: ready === true AND active_pipeline_run === null.
eve job list --phase active
eve job follow <job-id> # Real-time SSE streaming
eve job watch <job-id> # Poll-based status updates
eve job diagnose <job-id> # Full diagnostic
eve job result <job-id> # Final result
eve job runner-logs <job-id> # Raw worker logs
# Terminal 1: Pipeline/job progress
eve job follow <job-id>
# Terminal 2: Environment health
eve env diagnose <project> <env>
# Terminal 3: System-level logs
eve system logs
eve job dep list <job-id>eve job show <job-id> → look at blocked_byeve env show <project> <env>eve system orchestrator statuseve job diagnose <job-id>eve job follow <job-id> or eve job runner-logs <job-id>eve build diagnose <build-id>eve secrets list --project <project_id>eve job show <job-id> → effective_phaseeve thread messages <thread-id>eve system podseve system healtheve system orchestrator statuseve system events| Error | Cause | Fix |
|---|---|---|
401 Unauthorized | Token expired | eve auth login |
git clone failed | Missing credentials | Set github_token or ssh_key secret |
service not provisioned | Environment not created | eve env create <env> |
image pull backoff | Registry auth failed | If using BYO/custom registry, verify REGISTRY_USERNAME + REGISTRY_PASSWORD; for managed apps use registry: "eve" |
healthcheck timeout | App not starting | Check app logs, verify ports in manifest |
If a deploy pipeline fails at the build step:
eve build list --project <project_id>
eve build diagnose <build_id>
eve build logs <build_id>
eve secrets list --project <project_id> # Required for BYO/custom registry: REGISTRY_USERNAME, REGISTRY_PASSWORD
Common build failures:
REGISTRY_USERNAME and REGISTRY_PASSWORD secretsbuild.context path in manifesteve build diagnoseEve publishes worker images to the configured private registry with these variants:
| Variant | Contents |
|---|---|
base | Node.js, git, standard CLI tools |
python | Base + Python runtime |
rust | Base + Rust toolchain |
java | Base + JDK |
kotlin | Base + Kotlin compiler |
full | All runtimes combined |
Version pinning : Use semver tags (e.g., v1.2.3) in production. Use SHA tags or :latest in development.
Eve automatically injects these into every deployed service container:
| Variable | Purpose |
|---|---|
EVE_API_URL | Internal cluster URL for server-to-server calls |
EVE_PUBLIC_API_URL | Public ingress URL for browser-facing apps (when configured) |
EVE_SSO_URL | SSO broker URL for user authentication (when configured) |
EVE_PROJECT_ID | Current project ID |
EVE_ORG_ID | Current organization ID |
EVE_ENV_NAME | Current environment name |
Use EVE_API_URL for backend calls. Use EVE_PUBLIC_API_URL for browser/client-side code. Services can override any of these by defining them explicitly in their manifest environment section.
{service}.{orgSlug}-{projectSlug}-{env}.{domain}lvh.me| Environment | How to Debug |
|---|---|
| Local (k3d) | Direct service access via ingress, eve system logs |
| Docker Compose | docker compose logs <service>, dev-only (no production use) |
| Kubernetes | Ingress-based access, kubectl -n eve logs as last resort |
Connect services on private networks (home lab GPUs, internal APIs, dev machines) to the Eve cluster. The platform creates K8s ExternalName services backed by Tailscale egress proxies.
# Register a private endpoint
eve endpoint add \
--name lmstudio \
--provider tailscale \
--tailscale-hostname mac-mini.tail12345.ts.net \
--port 1234 \
--org org_xxx
# List and inspect
eve endpoint list --org org_xxx
eve endpoint show lmstudio --org org_xxx
# Diagnose connectivity
eve endpoint diagnose lmstudio
# Remove
eve endpoint remove lmstudio --org org_xxx
Each endpoint gets a stable in-cluster DNS name: http://{orgSlug}-{name}.eve-tunnels.svc.cluster.local:{port}. Wire it into apps/agents via secrets:
eve secrets set LLM_BASE_URL \
"http://myorg-lmstudio.eve-tunnels.svc.cluster.local:1234/v1" \
--scope project
Diagnostics check: operator status, K8s service existence, DNS resolution, TCP connectivity, and HTTP health.
The default worker image is base (~800MB with Node.js, git, and all harnesses). Toolchains (Python, Rust, Java, Kotlin, media) are injected on-demand via init containers rather than bundled in a fat image.
Deployment impact : If an agent job needs toolchains, the runner pod starts init containers that copy toolchain binaries from small pre-built images. First pull adds ~5-10s; subsequent jobs on the same node use cached images.
Debugging toolchain issues :
# Check if toolchains are declared in agent config
# agents.yaml: toolchains: [python]
# If a toolchain binary is missing at runtime:
# 1. Verify agent config has the toolchain declared
# 2. Check init container logs on the runner pod
# 3. Verify toolchain images are available in the registry
To use the full image (all toolchains bundled): set EVE_WORKER_VARIANT=full or use --variant full locally.
Remove environments and clean up resources:
# Undeploy services from an environment (stops pods, keeps env record)
eve env undeploy <project> <env>
# Delete the environment entirely (removes env record, managed DB, secrets)
eve env delete <project> <env>
When a managed DB is attached, eve env delete deprovisions it. Secrets scoped to the environment are cleaned up. The environment's pipeline history remains in the audit log.
For app-level cleanup, remove the project:
eve project delete <project-id>
This cascades: environments, secrets, pipeline history, and build artifacts are removed.
Production disk management for agent workspaces:
EVE_WORKSPACE_MAX_GB — total workspace budgetEVE_WORKSPACE_MIN_FREE_GB — trigger cleanup thresholdEVE_SESSION_TTL_HOURS — auto-evict stale sessionseve-local-dev-loopeve-auth-and-secretseve-manifest-authoringWeekly Installs
149
Repository
First Seen
Feb 8, 2026
Security Audits
Installed on
gemini-cli149
codex149
claude-code146
pi52
opencode32
github-copilot32
供应商主导的账户与联系人挖掘 | build-tam配方快捷方式 | AI代理技能
620 周安装
Spring Boot 测试模式指南:JUnit 5、Mockito、Testcontainers与切片测试
608 周安装
品牌声调强化插件 - 自动应用品牌指南生成营销内容,确保品牌一致性
629 周安装
工程团队技能集:23个生产级工程技能,涵盖核心工程、AI/ML/数据与专业工具
638 周安装
Swift HealthKit 开发指南:iOS 健康数据读写、授权与后台交付
626 周安装
HeyGen API 人脸替换教程:AI 换脸视频制作与 API 调用指南
630 周安装