Ansible

概述 凌晨两点，告警群炸了。一台刚上线两小时的 Web 服务器 CPU 飙到 100%，SSH 进去一看，Nginx 没装，但端口被一个旧版本 Apache 占着。翻部署日志发现：Terraform 10 分钟前做了一次 terraform apply，把这台机器重建了（因为有人改了 instance_type），但 Ansible 的配置脚本没有跟着跑——机器是新机器，上面的软件配置全丢了。 这不是个例。用 Terraform 建云主机、用 Ansible 做配置管理，这个组合在 2026 年已经是运维团队的标配。但"标配"不等于"配好了"——大量团队把这两个工具简单堆在一起，没有清晰的协同设计，结果就是基础设施"管了两遍"：Terraform 建了一遍资源，Ansible 又配了一遍，两边都不知道对方在干什么，配置漂移、状态不一致、流水线断裂，全来了。 这篇文章拆解 Terraform + Ansible 协同的 5 个核心决策。每个决策都来自实际生产环境的踩坑经验，不是理论推演。如果你的团队正在用或准备用这个组合，这些决策点会帮你少走至少半年的弯路。 一、职责边界：Terraform 管什么，Ansible 管什么 先说清楚一个最基本但最容易被忽视的问题：这两个工具的职责边界到底画在哪里。 Terraform 的强项是基础设施编排——创建云主机、虚拟机、网络、存储、负载均衡、安全组、数据库实例、K8s 集群。它是声明式的，你告诉它"我要 3 台 4C8G 的云主机在这个可用区"，它就去创建。它管理资源的整个生命周期：创建、修改、销毁。 Ansible 的强项是系统配置和应用交付——操作系统初始化、账号权限、内核参数、防火墙规则、软件包安装、中间件部署、配置文件渲染、服务启停、定时任务。它是过程式的（虽然也有幂等性设计），你告诉它"先装 Nginx，再拷配置，然后启动服务"，它按顺序执行。 两个工具各管一摊，看起来很清楚。但实际生产中，边界经常模糊。举几个常见的"灰色地带"： 配置项 Terraform 能做 Ansible 能做 应该谁管 创建云主机 ✅ 原生支持 ❌ 不适合 Terraform 安装 Nginx ✅ remote-exec ✅ 原生支持 Ansible 配置安全组规则 ✅ 原生支持 ⚠️ 能做但不推荐 Terraform 渲染 Nginx 配置文件 ⚠️ local-exec 拼接 ✅ Jinja2 模板 Ansible 磁盘挂载和格式化 ⚠️ 能做但粗糙 ✅ 精细控制 Ansible 创建 DNS 记录 ✅ 原生支持 ⚠️ 能做但不推荐 Terraform 用户和 SSH 密钥 ✅ 能做 ✅ 原生支持 Ansible 决策 1：不要用 Terraform provisioner 做复杂配置 Terraform 提供了 remote-exec 和 local-exec 两个 provisioner，可以在资源创建后执行命令或脚本。很多团队一上来就在 Terraform 里写一长串 remote-exec 块，用 shell 脚本装软件、配防火墙、改内核参数。...

paramiko：SSH 批量管理基础 paramiko 是 Python 实现的 SSHv2 协议库，是运维自动化的底层基石。当需要精细控制 SSH 连接、处理非标准场景时，paramiko 提供了最大灵活性。 基础连接与命令执行 import paramiko import time def ssh_exec(host, port, username, password, command): """基础 SSH 命令执行""" client = paramiko.SSHClient() # 自动添加主机密钥（生产环境建议使用 known_hosts） client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) try: client.connect(host, port=port, username=username, password=password, timeout=10) stdin, stdout, stderr = client.exec_command(command) # 获取退出码 exit_code = stdout.channel.recv_exit_status() output = stdout.read().decode().strip() error = stderr.read().decode().strip() return { 'host': host, 'exit_code': exit_code, 'output': output, 'error': error } finally: client.close() # 使用示例 result = ssh_exec('10....

概述 在自动化运维中，Ansible Playbook 经常需要处理数据库密码、API 密钥、SSH 私钥等敏感信息。如果这些数据以明文形式存储在代码仓库中，一旦仓库泄露，所有凭据都将暴露。Ansible Vault 作为 Ansible 内置的加密工具，通过 AES-256 对称加密算法保护敏感数据，确保只有授权用户才能访问。 我将从基础概念到生产实践，详细梳理 Ansible Vault 的使用方法、密码管理策略，以及在 CI/CD 流水线中的集成方案。 为什么需要 Ansible Vault 明文存储的风险 在实际运维中，敏感信息散落在多个位置： 位置 常见敏感数据 风险等级 group_vars/all.yml 数据库密码、Redis 密码 高 host_vars/web01.yml SSH 连接密码、BECOME 密码 高 Inventory 文件 ansible_password、ansible_ssh_pass 高 Playbook 变量 API Token、第三方密钥 中 Jinja2 模板 证书私钥、JWT Secret 高 明文存储的风险包括： 代码仓库泄露：Git 历史记录中永远保留明文密码，即使后续删除也能从历史中恢复 合规审计失败：PCI-DSS、ISO 27001 等安全标准要求敏感数据加密存储 团队协作风险：任何有仓库访问权限的人都能看到所有密码 日志泄露：Ansible 执行日志可能输出变量值，导致密码出现在日志文件中 Ansible Vault 的定位 Ansible Vault 不是唯一的密钥管理方案，但它是 Ansible 生态中最直接的选择： 方案 优点 缺点 适用场景 Ansible Vault 内置、零依赖、YAML 原生 单密码加密、无细粒度权限 中小规模团队、快速上手 HashiCorp Vault 动态密钥、租约管理、审计日志 需要额外部署和维护 大型企业、高安全要求 AWS Secrets Manager 云原生、自动轮转 厂商锁定、按量计费 AWS 云环境 SOPS + age 支持多密钥加密、Git 友好 需要额外工具 多人协作、GitOps 场景 参考 Ansible Vault 官方文档 了解完整功能列表。...

概述 Ansible 的上手门槛很低——一个 YAML 文件、几行 yum install 就能跑通。但当你面对几百台服务器、多套环境、复杂的依赖关系和严格的变更审计要求时，“能跑"和"能上线"之间隔着一整个工程体系。本文把生产级 Playbook 的核心实践浓缩成一份可操作的指南，涵盖从结构组织到性能优化的全链路。 参考来源：Ansible 官方好的实践 一、Playbook 结构优化 1.1 目录布局 生产级 Ansible 项目应该遵循标准目录结构。这不是 Ansible 的强制要求，而是大量团队踩坑后形成的共识： production-project/ ├── ansible.cfg # 项目级配置 ├── inventory/ │ ├── production/ │ │ ├── hosts.ini # 生产环境主机清单 │ │ └── group_vars/ │ │ ├── all.yml # 所有环境共享变量 │ │ ├── web.yml # web 组专用变量 │ │ └── db.yml # db 组专用变量 │ └── staging/ │ ├── hosts.ini │ └── group_vars/ │ └── all....