云服务器初始化配置自动化脚本分享附生产环境避坑要点

刚领到一批新开的云服务器，要是只有一两台，手动敲敲命令做初始化倒也没啥，可一旦碰上几十上百台的交付量，还靠纯手工去配，那真是又慢又容易出错。干运维的有时图省事，网上随便扒个自动化脚本就往上跑，结果环境不兼容，直接把业务搞出问题来，这种事我们见过太多次了。下面就把我们团队这几年反复磨出来的云服务器初始化配置经验摊开说说，希望能帮大家绕开生产环境里的那些坑。

工具选型看实际规模

挑自动化工具的时候，真别一上来就奔着功能堆成山的重型套件去，得先掂量掂量自己团队的人手和现有的技术底子。像我们这种中小规模的运维组，用 Ansible 就挺顺手，它那个无代理的架构再加上简单的 YAML 语法，新人花不了几天就能上手，学习压力小很多。要是公司原本就有成熟的 Puppet 或者 Chef 那一套运维体系在跑着，那直接复用现成框架就好，犯不着为了换工具再给自己加一堆维护负担。还有一种情况，碰到临时紧急交付、赶着上线的场景，这时候用 cloud-init 或者直接撸一套精简 Shell 脚本，反而比上重型工具更利索。这里得提一个高频翻车点：好多人在 CentOS 7 上直接用 pip 装 Ansible，经常撞上 Python 版本冲突的墙，导致模块加载直接挂掉，排查起来头都大。我们后来学乖了，优先用系统自带的源去装，或者提前在一台隔离的测试实例上把整套流程跑通，确认没问题了再往生产跳板机上搬，就这么个小习惯，能省掉好几天的排错时间。

写死逻辑不如做足幂等

别以为脚本跑完返回个成功码，云服务器就真的配到位了，这种想法挺危险的。我记得之前有个运维团队，自己写 Shell 脚本给 20 台新节点做批量初始化，因为脚本里没加用户是否存在的判断，重复执行的时候 useradd 命令直接报错卡死，最后逼得他们一台一台登上去手动救火，场面相当狼狈。所以写脚本时，一定要把条件判断逻辑加足，比如创建用户之前，顺手用 id 命令先瞅一眼用户是不是已经在了。校验环节也不能光盯着脚本的退出码，得实实在在去查一下关键端口有没有正常监听、核心配置文件内容是不是跟预期的一样。正式批量跑之前，务必找一台同系统版本的临时测试实例，把整个初始化流程从头到尾预演一遍，大部分环境适配的毛病，都是因为偷懒跳过这一步才惹出来的。

敏感信息脱敏与快照兜底

脚本里硬编码密码这种低级错误，真的是碰都不能碰，所有敏感字段都得通过环境变量或者 Ansible Vault 这类加密手段动态注入进去。执行脚本的账号权限也要收到最小，强制用 SSH 密钥对登录，把 root 账号的远程直连给禁掉，这能挡住绝大多数暴力破解的尝试。脚本文件本身也要做哈希校验，防止中途被人恶意篡改。还有一条血泪教训：在跑初始化脚本之前，一定一定先给新购的云服务器打个系统快照，万一脚本跑崩了，能秒级回滚回去，不至于把系统盘搞残了耽误交付进度，这个习惯能救命。