你现在看到的这个博客,部署在一台已经承载了二十多个服务的阿里云 ECS 上。本文是完整实录——包括每一处约束是怎么影响设计的。

现场约束

侦察(只读)得到的事实:

事实 影响
ECS:Ubuntu 24.04,2核8G,cn-beijing,nginx 1.24 直装在宿主机 博客应该复用这个 nginx,静态托管,零新增常驻进程
机器上已有 n8n、code-review-agent 等二十余个服务 不能动现有配置,新站点必须是独立的 server block
域名 jocab.xyz 已解析到该机,siyuan/openproject 两个子域名是既有模式 博客用 blog.jocab.xyz 子域名,与惯例一致
没有 SSH 密钥,但有阿里云 CLI(root) 用云助手 RunCommand 执行服务器端命令
80 端口已在跑 nginx 并对外服务,443 安全组已放行但未启用 直接加 server block + certbot 签证书

部署流水线

没有 CI/CD,没有 GitHub Actions,流水线只有三段:

本地 hugo build
   │  tar.gz
   ▼
阿里云 OSS(私有 bucket,中转)
   │  服务器从 OSS「内网 endpoint」拉取——不走公网、免流量费、秒级
   ▼
ECS:解压到 /var/www/blog + nginx server block + certbot HTTPS

为什么用 OSS 中转

云助手 RunCommand 的命令内容有 16KB 上限,塞不进几 MB 的静态站点;而服务器直接从 GitHub 拉取在境内网络不可靠。OSS 内网 endpoint 是唯一既快又稳的通道——这是典型的"用平台既有能力换工程复杂度"。

服务器端做了什么

# 1. 站点文件
mkdir -p /var/www/blog
tar -xzf site.tar.gz -C /var/www/blog

# 2. 独立 server block(不动既有配置)
cat > /etc/nginx/sites-available/blog.jocab.xyz <<'EOF'
server {
    listen 80;
    server_name blog.jocab.xyz;
    root /var/www/blog/public;
    index index.html;
}
EOF
ln -sf /etc/nginx/sites-available/blog.jocab.xyz /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

# 3. HTTPS
apt install -y certbot python3-certbot-nginx
certbot --nginx -d blog.jocab.xyz

certbot --nginx 会自动改写 server block 加上 443 监听和 80→443 跳转,续期由 systemd timer 自动完成。

安全与回滚设计

  • 最小侵入:只新增文件(sites-available/blog.jocab.xyz、/var/www/blog),不修改任何既有 server block;改前备份
  • 完全可回滚:回滚 = 删 symlink + 删目录 + 删 DNS 记录 + 删 OSS bucket,四个动作,机器上其他服务无感知
  • HTTPS 是标配:2026 年没有理由裸 HTTP

一条命令再发布

仓库里留了 deploy.sh:重新构建 → 上传 OSS → 云助手触发服务器拉取。写完 Markdown,一条命令,新文章上线。

下一篇,讲讲这条流水线背后更大的话题:如何把 AI Agent 当资深工程师用。