开始使用
Orbit 账户的组织方式、控制台各处的功能,以及从登录到让我们的网络开始应答一个域名的最短路径。
Pages(静态站点)
上传一个目录。
Pages 站点由我们所有节点分发,跑在你自己拥有的主机名上。我们不提供子域名 —— 第一节说明为什么这是一个决定而非缺口。
01
始终是你的域名
Pages 站点只在你自己拥有的主机名上提供服务。我们不提供可发布的子域名,今后也不会提供。
把任意用户内容挂在我们自己的名字下,会让我们运营的每一项服务处于同一条浏览器黑名单条目之后 —— 控制台、身份服务、状态页,以及其他人设备所依赖的公共解析器。你的域名承载你自己的声誉,那才是它该在的位置。
02
选哪一档
两者的区别不是大小,而是「别的东西坏了会怎样」。
| Store | Edge | |
|---|---|---|
| 文件在哪 | 集中存储,各节点首次访问后缓存 | 复制到每一个节点 |
| 回源 | 每个节点每个文件一次 | 从不 —— 没有源站 |
| 容量 | 50 MB,5000 文件 | 5 MB,200 文件 |
| 适合 | 有实际内容的站点 | 落地页、文档、跳转 |
一般用 store,除非站点很小而你希望它在任何情况下都可用。edge 档的限额之所以小,正是因为每个节点都存了一份副本。
03
部署
- 在控制台打开 CDN → Pages 并创建项目,选择一档。
- 点 Upload,选择站点的构建输出目录。目录本身的名字不是站点的一部分 ——
index.html必须在它的顶层。 - 把某个主机名指过去:在对应的 Shield 站点上,选择这个项目作为内容来源。
若用脚本,一次部署是三步:开始、逐个 PUT 文件、结束。具体形状见 API 文档。
curl -X POST -H "Authorization: Bearer orb_…" \
https://dash.yunzheng.space/api/v1/pages/projects/7/deploys
curl -X PUT -H "Authorization: Bearer orb_…" --data-binary @dist/index.html \
https://dash.yunzheng.space/api/v1/pages/projects/7/deploys/12/files/index.html
curl -X POST -H "Authorization: Bearer orb_…" -d '{"activate":true}' \
https://dash.yunzheng.space/api/v1/pages/projects/7/deploys/12/finish04
回退
每次上传都是一个部署,完成后不再改变。让较早的部署重新生效是瞬时的:不复制、不重建,因为部署本身就是文件存储位置的一部分 —— 移动的只是一个指针。边缘缓存在同一刻被清除,所以变化立即可见,而不是等最后一个缓存文件过期。
05
文件约定
| 请求的路径 | 实际应答 |
|---|---|
/ | index.html |
/docs | 先 docs,再 docs.html,再重定向到 /docs/ |
/docs/ | docs/index.html |
| 不存在的路径 | 404.html,状态码为 404 |
缺少末尾斜杠的目录请求会被重定向,而不是直接应答。在那里直接应答会让页面上所有相对链接都解析到上一层 —— 这类问题往往要到第二个页面才暴露。
_redirects 每行一条规则:/from /to 301。末尾 /* 匹配前缀,:splat 携带其余部分。状态 200 表示不改变 URL 的重写,单页应用用它来处理自己的路由。
/old-page /new-page 301
/blog/* /articles/:splat 301
/app/* /index.html 200_headers 设置你自己的响应头:一行路径模式,随后是缩进的头部行。会覆盖边缘决定的头部(长度、连接、cookie)会被忽略。
/*
X-Frame-Options: DENY
Referrer-Policy: no-referrer
/assets/*
Cache-Control: public, max-age=31536000, immutable06
常见问题
有构建步骤吗?
没有。你上传的是构建产物,在你原本构建的地方构建即可 —— 我们分发的就是它的输出。
旧的部署会怎样?
会保留,所以回退是一个动作的事。移动的只是指向当前生效版本的指针。
一个项目能服务多个主机名吗?
可以。你可以把任意多个自己的主机名指过去,它们服务同一个当前部署。