部署与版本

应用用 POST /v1/apps 创建，或用 glac deploy 创建：项目中没有同名应用时，它会创建一个。给出 image 时，同时部署它的第一个版本。之后的每次部署都是 POST /v1/apps/{app}/versions，或用同一个 --name 再次运行 glac deploy。

glac deploy ghcr.io/acme/api:1.4 --name api --port 8080 --ready-http /healthz
glac deploy ghcr.io/acme/api:1.5 --name api        # the next version of the same app

什么是版本

版本由改变应用运行方式的内容构成：

• 镜像，部署时固定到它的摘要 (digest)（之后指向别处的标签不会改变版本）；
• 启动命令或其参数、端口和就绪检查；
• 环境变量、机密，以及拉取私有镜像所用的机密；
• 规格、存储卷和云盘、启动前写入的文件、用户、工作目录、停止方式；
• 它的类型（service，存在多久就运行多久；或 job，运行到结束为止）和它的主机名；
• 它的运行时设置（runtime，见下文）。

修改其中任何一项都会部署一个新版本。版本创建后永不改变。再次部署同一个标签也会产生新版本，因为那时标签可能已经指向另一个镜像。

版本的 resolved 说明部署时对镜像的发现，只确定一次：按摘要标识的镜像、询问实例时所用的端口，以及 unmounted_volumes，即镜像声明为卷 (VOLUME) 而版本没有在那里挂载存储卷或云盘的路径。Docker 会在那里挂载一个它自己的卷；在这里，这样的路径是每个实例自己磁盘上的一个目录，新版本不会保留它，glac deploy 会对此发出警告。

其他设置立即生效，不产生新版本：扩缩容、区域、键、网络规则、标签、日志设置、是否公开，以及名称。

运行时设置

版本的 runtime 设置 Compose 文件中的 ulimits、sysctls、tmpfs、dns 和 shm_size 所要求的内容。实例的机器在启动时、保存模板之前应用这些设置，这些限制对启动命令和在实例中运行的每条命令都有效：

• ulimits：按 Docker 的名称设置的限制（nofile、nproc、memlock、stack 等），一个数字同时作为软限制和硬限制，或者 {soft, hard}；-1 表示不限制。打开文件数为 1 到 1,048,576。不设置时，打开文件数为 1,024，最多可提高到 524,288，与 Docker 下相同。
• sysctls：Docker 允许容器设置的内核参数：net.*、kernel.shm*、kernel.msg*、kernel.sem、fs.mqueue.*。其他参数都会被拒绝（返回 400，并指明是哪个），机器内核中没有的参数会让版本构建失败。
• tmpfs：实例内存中最多 16 个文件系统，每个为 {path, size_bytes, mode}（默认为内存的一半，权限 1777）；不能覆盖机器自己的路径（/proc、/sys、/dev、/run）、平台的路径或存储卷的路径。
• dns：它的 /etc/resolv.conf，即 {servers, search, options}，替代镜像中的设置。在项目的私有网络上，由平台代替这些服务器回答它的查询，先解析项目内的名称。
• shm_size_bytes：/dev/shm 的大小；默认为内存的一半。

glac deploy postgres:16 --name db --ulimit nofile=65535 --sysctl net.core.somaxconn=1024 --shm-size 1g
glac cube update db --reset runtime        # none again

--ulimit、--sysctl、--tmpfs /scratch:size=64m,mode=1770、--dns、--dns-search、--dns-option 和 --shm-size 中的任何一个都会替换版本的全部运行时设置；SDK 接受 runtime，MCP 服务器的 cube_deploy 也接受。沙箱在创建时接受同样的 runtime（创建沙箱）。

glac cube update api -e KEY=value 只设置一个变量，保留其他变量。使用 API 和 SDK 时，部署时给出的 env 和 secrets 就是版本拥有的全部。

部署的过程

平台拉取镜像，在应用所在的每个区域的机器上启动它，等待就绪检查通过，然后把正在运行的服务保存为模板。实例都是这个模板的副本，所以服务在每个实例中都已经在运行。

版本先是 building，然后是 ready 或 failed。就绪后它承接应用的流量：旧版本上正在处理的请求会得到响应，新请求进入新版本，不会丢失任何请求。没能起来的版本为 failed，它的 error 中有镜像最后的输出，流量保持不变。磁盘没有空间容纳这个版本的机器会被跳过，换成同区域中有空间的另一台；都没有时，版本立即失败（drive_full，并说明机器磁盘的占用情况）。版本绝不会停留在一台什么都不接收的机器上的 building 状态：两分钟后它会失败 (deploy_stalled)，并附上机器的信息。glac deploy 会等待版本，失败时以 1 退出；--no-wait 立即返回。

glac cube versions api       # newest first: building, ready or failed, and which has the traffic

回滚

POST /v1/apps/{app}/rollback 带上 {"version": …}（编号或 id），或者 glac cube rollback api 3，把流量切到另一个处于 ready 的版本，更旧或更新都可以。不指定版本时，命令行选择当前版本之前最新的就绪版本。

机器会保留承接流量的版本、正在构建的版本，以及最新三个就绪版本的模板（这是平台的数字，对所有应用都一样），所以回滚到其中之一时，流量会立即切换。模板已被清除的更旧版本会先重新构建，就绪后再切换流量；这个过程和部署一样需要等待。每个版本都一直留在 glac cube versions 中，任何曾经就绪的版本都可以回滚到。

删除应用

glac cube rm api (DELETE /v1/apps/{app}) 释放它的名称。正在处理的请求在最多 30 秒内仍会得到响应，WebSocket 会被关闭，然后它的实例被删除。在套餐保留日志的期限内，仍可以通过它的 id 读取它的日志。

限制

一个账户在它的所有项目中，应用总数有上限（超过时返回 403 app_limit_reached），一个应用的环境变量和机密合计有上限 (403 env_limit_reached)，一个账户每小时创建的应用和版本数也有上限（403 plan_cap_reached，带 Retry-After）：

其余限制见限制。