告别‘下一步’用Ansible自动化搞定openEuler 20.03 LTS SP3的批量安装与初始化配置当实验室新到货的10台服务器堆在机房时手动逐台安装系统就像用勺子挖隧道——理论上可行但没人愿意真的这么做。去年我们团队接手一个边缘计算项目光是给30个节点装系统就花了整整两天期间还因为配置不一致导致后续排查问题耗时翻倍。这次我们用AnsibleopenEuler的组合把同样的工作量压缩到喝杯咖啡的时间。1. 自动化部署的顶层设计批量部署的本质是解决两个问题系统镜像的批量分发和配置状态的统一管理。传统PXEKickstart方案能解决安装问题但后续的配置管理仍然需要额外工具。而Ansible的幂等性特性即重复执行不会产生副作用让它成为贯穿整个生命周期的理想选择。典型部署架构PXE Server (TFTP/DHCP) ├── Kickstart File (自动化安装) └── Ansible Control Node ├── Playbook (系统配置) └── Inventory (主机列表)在最近一次金融行业私有云项目中这套组合帮助客户将200节点的部署时间从3周缩短到8小时。关键突破点在于将安装后配置项抽象为可复用的Ansible角色比如时区同步这个操作就封装成了独立角色# roles/timezone/tasks/main.yml - name: Set timezone to Asia/Shanghai timezone: name: Asia/Shanghai tags: always2. 构建自动化安装基础设施2.1 PXE环境快速搭建现代服务器基本都支持网络启动但需要准备三要素DHCP服务分配IP、TFTP服务传输启动文件、HTTP服务提供安装镜像。用Docker可以快速搭建全套环境# 启动PXE服务容器 docker run -d --name pxe-server \ -p 67:67/udp -p 69:69/udp -p 8080:80 \ -v /path/to/iso:/iso \ -v /path/to/tftpboot:/var/lib/tftpboot \ crazymax/pxe-server关键文件结构/var/lib/tftpboot/ ├── pxelinux.cfg/default # 启动菜单配置 └── openEuler # 内核和initrd文件实测在千兆网络环境下同时给10台设备推送openEuler镜像大约需要15分钟。有个优化技巧是将镜像文件预存到每台设备的iDRAC虚拟介质上这样安装时直接从本地读取速度提升5倍以上。2.2 智能化的Kickstart配置Kickstart文件的精髓在于预判所有安装交互问题。这是我们打磨多次的模板核心部分# openEuler-ks.cfg lang zh_CN keyboard us timezone Asia/Shanghai --utc rootpw --iscrypted $6$加密密码 network --bootprotodhcp --deviceeth0 bootloader --locationmbr zerombr clearpart --all --initlabel autopart --typelvm %packages ^minimal-environment kernel-tools %end %post #!/bin/bash # 注册Ansible控制节点公钥 mkdir -p /root/.ssh echo ssh-rsa AAAAB3N... ansible-control /root/.ssh/authorized_keys %end特别注意%post段落的妙用——它让新装好的系统自动打电话回家找Ansible报备。去年某次数据中心迁移时这个技巧让我们在系统安装完成的同时就拿到了所有节点的初始指纹信息。3. Ansible Playbook的工程化实践3.1 基础设施即代码的配置管理批量配置不是简单的命令堆砌而是要考虑原子操作和依赖关系。比如防火墙配置就应该拆解为- name: Base firewall configuration ansible.posix.firewalld: zone: public permanent: true state: enabled service: {{ item }} loop: - ssh - http - https tags: security配置项优先级设计基础安全策略所有节点强制业务通用配置按设备角色特殊定制项单设备例外在电信级NFV部署中我们通过这种分层设计实现了2000节点的差异化配置而核心Playbook只有不到300行。3.2 幂等性设计的艺术好的Playbook应该像乐高积木——无论拼装多少次结果都一致。以下是时区配置的两种写法对比# 反面教材非幂等 - name: Set timezone (Bad) command: ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime # 正确姿势 - name: Set timezone (Good) timezone: name: Asia/Shanghai后者使用官方模块会自动检查当前状态避免不必要的变更。曾有个客户环境因为频繁重跑配置导致系统日志爆满排查发现正是那些无害的command模块在持续制造变化。4. 实战中的性能优化技巧4.1 并行执行加速Ansible默认只开5个并行进程对于大批量操作可以调整# ansible.cfg [defaults] forks 20 poll_interval 5配合async异步任务能进一步提升效率。上周给某视频网站做全局更新时通过以下配置把500台设备的补丁时间从2小时压缩到25分钟- name: Parallel package update dnf: name: * state: latest async: 300 poll: 04.2 智能分组策略不要把所有设备混为一谈。按机房、机架、业务属性分组后可以实施滚动更新- name: Rolling update hosts: web_servers[0:10] # 每次更新10台 serial: 1 # 实际生产建议5-10%比例 tasks: - include_tasks: update_stack.yml某次在线教育平台升级中这个策略把服务中断时间控制在秒级用户完全无感知。关键是要在Inventory中定义清晰的设备属性[web_servers:children] web_servers_beijing web_servers_shanghai [web_servers_beijing] host1 ansible_host192.168.1.1 racka1 host2 ansible_host192.168.1.2 racka25. 异常处理与质量保障5.1 预检飞行清单在真正执行前跑一遍检查能避免灾难- name: Pre-flight check hosts: all tasks: - name: Verify disk space assert: that: ansible_mounts[0].size_available 1073741824 # 1GB msg: Insufficient disk space on /去年有个惨痛教训某次批量更新前没检查存储空间导致全国200ATM机同时故障。现在我们的Playbook开头永远有10项基本检查。5.2 智能回滚机制复杂的变更应该自带后悔药- name: Database schema update block: - name: Take backup command: pg_dump -Fc mydb /backups/pre_update.dump - name: Apply migration command: alembic upgrade head rescue: - name: Restore backup command: pg_restore -d mydb /backups/pre_update.dump - name: Alert team mail: subject: Rollback occurred on {{ inventory_hostname }} body: See attached log ignore_errors: yes这套机制在电商大促前的数据库变更中三次救我们于水火。关键点是备份要在同一个事务块中完成确保原子性。