跳到主要内容

启动模式

启动模式决定容器启动时实际运行什么、哪些端口会被发布,以及你的启动脚本会不会被执行。它是模板上影响最大的一个字段。

四种模式

argssshjupytervm
启动什么镜像自身的入口点基础镜像入口点:22 端口上的 sshdsshd 加上通过 HTTPS 提供的 JupyterLab一台完整的 KVM 虚拟机
派生自基础镜像的镜像不需要必需必需不需要
隐式端口前置 22,标签为 ssh前置 22ssh)和 8080jupyter前置 22,标签为 ssh
你声明的端口按原样发布追加在 22 之后,标签为 app追加在 228080 之后,标签为 app追加在 22 之后,标签为 app
args_str拆分为容器命令忽略忽略忽略
onstart不执行首次启动时运行一次首次启动时运行一次随启动一起下发
报价要求支持 VM 的报价
连接方式你自己发布的端口SSH打开 JupyterLab 按钮,或 SSHSSH

args

默认模式。Superheat 完全按照镜像作者的意图运行你的镜像:使用镜像自带的入口点,并把 args_str 按 shell 分词规则拆分成命令。--model llama-3 --port 8000 会变成四个参数。

启动路径上不会注入任何东西,这就是 onstart 在这里不起作用的原因——没有 Superheat 入口点来运行它。如果你在 args 模式下需要做准备工作,就把它构建进镜像,或者让它成为你的命令做的第一件事。

推理服务、训练任务,以及任何不是你自己构建的上游镜像,都用 args

ssh

启动 Superheat 基础镜像入口点:它把你的公钥装进 /root/.ssh/authorized_keys,在容器 22 端口上启动 sshd,把你的启动脚本运行一次,然后移交给镜像的 CMD(或者进入空闲状态让容器保持运行)。

容器 22 端口会自动前置到端口列表里;你不需要声明它。主机侧端口从机器已发布的端口范围中分配,绝不会是 22——实例页面会为你生成完整的连接字符串。

当你想要的是一台可以在上面干活的机器,而不是一个可调用的服务时,用 ssh

jupyter

ssh 做的一切,外加 JupyterLab。容器端口 22 和 8080 都会被前置。Jupyter 使用自签名证书通过 HTTPS 绑定在 0.0.0.0:8080,根目录是你的 Jupyter 工作目录(默认 /workspace)。关掉 JupyterLab 开关则改为提供经典 notebook。

访问令牌由平台生成,下发到容器,任何 API 响应都不会返回它。控制台会拼出已经带上令牌的打开 JupyterLab 链接,这是拿到令牌的唯一途径。

浏览器会就证书发出警告

Jupyter 通过 HTTPS 配自签名证书提供服务,以便令牌和你的 notebook 流量在直连路径上是加密的。出现警告属于预期行为。

vm

一台完整的 KVM 虚拟机,而不是容器。VM 模板只能启动到主机支持 VM 的报价上。在部署页面,把 VM 模板配到不支持 VM 的报价上时该报价不可选,原因写着“该机器不支持 VM。”,并且部署按钮保持禁用;API 执行同样的规则,返回 422 OFFER_NOT_VM_CAPABLE。启动时会编译进 SSH 访问,所以连接方式和 ssh 模式一样。

不需要派生自基础镜像的镜像,因为虚拟机并不运行容器入口点。

为什么 ssh 和 jupyter 需要派生自基础镜像的镜像

pytorch/pytorch 这样的普通上游镜像既不带 sshd 也不带 JupyterLab,所以这两种模式没有任何东西可启动。Superheat 通过 com.superheat.base 标签识别可用的镜像,这个标签由已发布的基础镜像设置,并被任何 FROM 它构建的镜像继承。

如果你让 sshjupyter 模板指向一个不带该标签的镜像,启动时就无从下手。要么基于基础镜像构建你的镜像——参见基础镜像——要么把模板改成 args

端口优先级

前置隐式端口之后,列表会按容器端口和协议去重,优先级更高的条目胜出:

ssh / jupyter > open_button > app

这个顺序让你既能在端口列表里声明某个端口,又能把打开按钮指向它:该条目返回时标签是 open_button 而不是 app。它同时也意味着,在 sshjupyter 模式下你自己声明 22 或 8080 不会改变任何东西——隐式条目保留它的角色。

标签和打开按钮见端口

之后更改模式

启动模式是启动配方的一部分,所以编辑它会重新生成模板的 hash_id,任何固定分享链接都会失效。运行中的实例不受影响——它们保留启动时使用的配方。