用 Cloud-init 把 ECS 首次启动配置自动化：三个容易踩的坑

为什么用 cloud-init

手动登录服务器装软件的问题不是慢，是不可重复。换一台机器就要重来一遍，而且每次都可能漏掉某一步。cloud-init 把这段操作变成声明式配置，写一次就能复用。

坑一：apt 的交互式提示会卡死脚本

在 Ubuntu 上执行 apt-get install 时，某些包会弹出交互式配置界面等待输入。cloud-init 在非交互环境里跑，这个提示会让整个流程无限期挂起。解法是在脚本开头设置环境变量：DEBIAN_FRONTEND=noninteractive。这一行不是可选项，是必须项。

坑二：Nginx 的默认站点目录不是你想的那个

很多人把页面写到 /usr/share/nginx/html，然后发现访问是 404。原因是 Ubuntu 版 Nginx 的默认 server 块 root 指向 /var/www/html。要么把文件放到 /var/www/html，要么改配置文件，要么建一个软链接。三种做法都行，但必须先确认默认 root 到底在哪：grep -r "root " /etc/nginx/sites-enabled/。

坑三：服务启动顺序与文件写入顺序

如果先启动 Nginx 再写页面文件，理论上没问题，但如果你在 cloud-init 里用 systemctl start 之后立刻去 curl 验证，可能拿到 502 或 404。原因是 Nginx 的 worker 进程还没完全就绪。稳妥做法是写完文件后再 restart，并且用循环重试验证而不是单次 curl。

验证方法

不要只看 cloud-init 有没有执行完，要看实际结果。三层验证：第一层 curl -s -o /dev/null -w "%{http_code}" 看状态码；第二层 curl -s 拿字节数，和本地文件大小比对；第三层 grep 关键词计数，确认内容完整。三层都对上才算真的部署成功。

小结

cloud-init 的价值在于可重复，但它的调试成本高于手动操作，因为你看不到中间过程。把日志留在 /var/log/cloud-init-output.log 里，出问题第一件事就是去看它，比反复重试有效得多。