部署工作负载

以下是使用 cornus deploy 应用 deploy spec、访问 workload，以及在五种部署后端间驱动 workload 的操作方法。Local backend 由环境变量 CORNUS_DEPLOY_BACKEND 选择；没有 CLI flag。

在 Docker host 本地部署 Compose project(默认 dockerhost backend)

将 spec 应用至 local Docker daemon，即默认 dockerhost backend。

cornus deploy -f app.yaml

name: web
image: localhost:5000/app:v1
replicas: 1
restart: unless-stopped
ports:
  - { host: 8080, container: 80 }

• dockerhost 需要 Docker socket(/var/run/docker.sock)。它功能最完整，可映射最多 spec field。

**另请参阅: **cornus deploy、Deploy spec、部署后端

部署到 bare containerd host(CORNUS_DEPLOY_BACKEND=containerd)

在无 dockerd 的 containerd host 上原生运行 workload。

sudo CORNUS_DEPLOY_BACKEND=containerd cornus deploy -f app.yaml

• 仅 Linux；需要 root(创建 netns、运行 CNI)、containerd socket(CORNUS_CONTAINERD_ADDRESS，默认 /run/containerd/containerd.sock)以及 /opt/cni/bin 下的标准 CNI plugin。
• 相对 dockerhost 的已知缺口: attach 仅输出，healthcheck 被忽略。

**另请参阅: **部署后端、cornus deploy

部署到 Incus host(CORNUS_DEPLOY_BACKEND=incus)

把同一个 OCI 镜像作为 Incus 应用容器运行，由 incusd 监督。

CORNUS_DEPLOY_BACKEND=incus cornus deploy -f app.yaml

• 仅 Linux；需要 Incus 6.3+(更早的版本没有 OCI 支持)以及对 daemon socket(CORNUS_INCUS_SOCKET，默认 /var/lib/incus/unix.socket)的访问权限。用 CORNUS_INCUS_PROJECT 选择 project。
• skopeo 和 umoci 必须安装在 incusd 运行的主机上——展平 OCI 镜像的是 daemon，而不是 cornus。若 incusd 需要从明文 HTTP 的注册表(例如 cornus 自身的注册表)拉取，请把它列入 CORNUS_INCUS_INSECURE_REGISTRIES，并且在 daemon 主机的 /etc/containers/registries.conf.d/ 中标记为 insecure，否则 skopeo 会拒绝。
• Instance 命名为 cornus-<app>-<replica>；已发布端口成为 replica 0 上的 Incus proxy device。
• 与 dockerhost 相比的已知差距: 不支持 mount、volume、user network、healthcheck 以及 command/entrypoint 覆盖；cornus attach 不受支持(请改用 cornus exec)；日志来自 instance 控制台，因此 --follow/--since/--tail 不适用；cornus stats 的 CPU 百分比偏低。每个未映射的字段都会按名称告警。

另请参阅: 部署后端、服务器环境变量

部署到 Kubernetes cluster(通过 server / connection profile)

kubernetes backend 仅 server / in-cluster 支持，因此应针对 cluster 中运行的 cornus server 部署。

cornus deploy -f app.yaml --server https://cornus.example.com

• 设置 CORNUS_DEPLOY_BACKEND=kubernetes 的 local cornus deploy 会 warning 后回退到 dockerhost；cluster backend 在 server(cornus serve)上运行。
• 一次将 server 存为 connection profile，后续 command 无需 --server。

**另请参阅: **远程集群、部署后端

应用 raw deploy spec file(cornus deploy -f spec.yaml)

直接部署 native schema，即 Compose 和 devcontainer 转换出的同一形状。

cornus deploy -f spec.yaml

• Spec 以命令式方式应用: 输入一个 spec，backend 将 workload 收敛到该状态。port、mount、volume、resource 和 healthcheck 的完整字段见参考。

**另请参阅: **Deploy spec、cornus deploy

删除 deployment(cornus deploy --delete / cornus compose down)

在本地或针对 server 按名称拆除 deployment。

cornus deploy -f app.yaml --delete
cornus deploy -f app.yaml --server https://cornus.example.com --delete

• Compose project 请使用 cornus compose down(添加 --volumes 也移除 project-scoped named volume)。

**另请参阅: **cornus deploy、cornus compose

在后台运行 deploy(-d/--detach)

将 spec 向 server POST 一次并退出，workload 无 client session 地保持运行。

cornus deploy -f app.yaml --server https://cornus.example.com --detach
# later, tear it down:
cornus deploy -f app.yaml --server https://cornus.example.com --delete

• Detached deploy 拒绝 client-local bind mount 与 client-sourced credential，published port bind 在 server host 而不是自动 forward。
• --detach 对 local deploy 无作用。

**另请参阅: **cornus deploy、使用远程集群

扩缩 replica 并配置 rolling update(deploy spec replicas + updateConfig)

设置 desired instance count，以及 Kubernetes rolling update 的进行方式。

name: web
image: localhost:5000/app:v1
replicas: 3
updateConfig:
  parallelism: 1
  order: start-first

cornus deploy -f app.yaml --server https://cornus.example.com

• 每个 backend 都遵循 replicas；host backend 的 published host port 仅指向 replica 0。
• updateConfig 只映射到 Kubernetes Deployment strategy.rollingUpdate；host backend recreate 单一 instance 并忽略它。

**另请参阅: **Deploy spec、部署后端

在运行中 workload 内运行 command(cornus exec)

类似 docker exec，经 server exec 进入 deployment 的第一个 instance。

cornus exec --server https://cornus.example.com -it web -- sh

• Deployment name 之后的所有内容原样传给 command。-i 转发 stdin；-t 请求 PTY(stdin 不是 terminal 时降级为 plain stream)。
• Remote command exit code 会作为 cornus 自身 exit code 传播。

**另请参阅: **cornus exec、cornus config

将 client-local directory mount 到 remote workload(--local-mount，经 9P stream)

cornus deploy --server 会在远程服务器上运行部署，同时通过 --local-mount (或 Compose volumes:) 使用经由 9P 流式传输的、位于本机的目录进行绑定挂载。部署会在命令保持连接期间持续存在，这正是它适用于内循环的原因: 你在本地编辑文件，工作负载便能看到更新。

cornus deploy -f app.yaml --server https://cornus.example.com \
  --local-mount ./config:/etc/app:ro \
  --local-mount ./data:/data

• --local-mount SRC:DST[:ro] 可重复，在 session 存续期间经 9P 提供该路径。工作负载就地读取您的文件，无需预先复制。
• 客户端本地挂载由服务器自身的 <DataDir>/mounts 区域提供，且始终允许使用，因此无需放宽主机权限策略。
• 需要 foreground session；--detach 拒绝 client-local mount。

素朴地 tunnel 9P 意味着每次读取都跨越网络，这对大型或写密集的挂载会造成困扰。两个后缀可启用服务器端文件缓存:

cornus deploy -f app.yaml --server https://cornus.example.com \
  --local-mount ./models:/models:ro,cache \
  --local-mount ./db:/var/lib/app:async

• 添加 ,cache 可将源声明为不变的只读源，即面向数据集、模型权重等输入的 read-through 缓存。它使用 server 按文件缓存，并隐含 :ro。
• 添加 ,async 可获得由 block protocol 支持的可写、缓存一致挂载。它适用于开发数据库等写密集型单一 writer 工作负载，需要 replicas: 1，且不能与 ro 或 cache 组合。
• 两者都需要启用服务器的文件缓存。对数据库形态的 async 挂载，可先在 server 和 deploy caller 环境中设置 CORNUS_BLOCK_COHERENCE=subhash,subfill，再设置 CORNUS_BLOCK_READAHEAD=64k 或更大的 cap。参见服务器环境变量，缓存机制参阅客户端本地绑定挂载。

**另请参阅: **cornus deploy、网络与 conduit

访问 published 和 unpublished port(自动 client-side forward + cornus port-forward)

--server session 中，published port(spec ports:)自动 forward 至 127.0.0.1:<host>；其他任意 container port 可按需用 cornus port-forward 访问。

# Published ports auto-forward for the session's lifetime:
cornus deploy -f app.yaml --server https://cornus.example.com
# (prints forwarding 127.0.0.1:8080 -> :80)

# Reach an unpublished container port separately:
cornus port-forward web 5432:5432

• Deploy 使用 --no-forward-ports 禁用 auto-forward。cornus port-forward 为每个 LOCAL:REMOTE(或 bare PORT)mapping bind 一个 local listener，并在 foreground 运行至 Ctrl-C。
• Cluster profile 中，两条路径都用 kubeconfig 直达 workload pod，必要时回退到经 server 的 tunnel；/udp mapping 在 dockerhost、containerd 和 bare backend 工作，但在 Kubernetes 上跳过。

**另请参阅: **cornus port-forward、网络、使用远程集群