1. 从“人肉运维”到“代码运维”为什么我们需要Ansible如果你和我一样在运维这条路上摸爬滚打了好些年一定经历过这样的场景半夜被电话叫醒因为线上某台服务器挂了你需要登录上去手动执行一连串的命令来重启服务、检查日志、修改配置。或者当业务需要扩容时你不得不对着几十上百台新服务器重复着安装软件、配置环境、部署应用这些枯燥且容易出错的操作。我们把这种模式戏称为“人肉运维”或“手工艺术”。“人肉运维”的痛点太明显了效率低下、一致性难以保证、操作可追溯性差更重要的是它严重依赖个人的经验和状态一旦人员变动整个运维体系就可能面临风险。而Ansible的出现正是为了解决这些问题。它不是什么高深莫测的黑科技其核心思想极其朴素用代码或者说用声明式的脚本来描述你的基础设施状态和运维操作。你可以把它理解为一个超级智能的、会自己干活儿的“运维助手”。这个助手有几个让我爱不释手的特质首先它无代理。这意味着你不需要在目标服务器上预先安装任何客户端代理程序只需要通过SSH或WinRM for Windows连接过去就行。这大大降低了初始部署和管理的复杂度尤其是在面对异构环境或严格的安全策略时。其次它简单易读。它的核心配置文件叫Playbook用的是YAML格式这种格式对人类非常友好即使是不太懂编程的运维同事看几眼也能明白个大概。最后它幂等性。这是一个非常重要的概念意思是无论你把同一个Playbook运行多少次最终系统的状态都是一样的。这避免了手动操作中常见的“重复执行导致错误”的问题。所以当有人问我“为什么要用Ansible”时我的回答很简单为了把我们从重复、繁琐、易错的手工劳动中解放出来让运维工作变得可重复、可审计、可协作最终实现基础设施即代码IaC的愿景。接下来我就结合自己多年的实战经验带你从零开始深入Ansible的部署与应用。2. 环境奠基Ansible控制节点的安装与基础配置万事开头难但Ansible的开头真的不难。它的架构是中心化的需要一个“控制节点”Control Node来发起所有任务。这个节点通常就是你的个人笔记本或者一台专门的跳板机/运维服务器。2.1 控制节点安装选对方法避开初坑控制节点必须是一个Linux或Unix系统macOS也可以。Windows本身不能作为控制节点但可以通过WSL2完美解决。安装Ansible主要有三种方式我强烈推荐第一种方式一使用系统包管理器最推荐这是最稳定、最省心的方式。以主流的CentOS/RHEL 7/8或Rocky Linux/AlmaLinux为例# 对于RHEL系CentOS 7/8, Rocky Linux 8需要先启用EPEL仓库 sudo yum install epel-release sudo yum install ansible # 对于Ubuntu/Debian系 sudo apt update sudo apt install ansible用包管理器安装会自动处理好依赖关系和系统服务集成后续升级也方便。方式二使用pip安装灵活性高如果你的系统版本较老或者需要安装特定版本pip是个好选择。但要注意用pip安装可能会和系统自带的Python包产生冲突。# 确保已安装pip和Python开发环境 sudo yum install python3-pip python3-devel # RHEL系 sudo apt install python3-pip python3-dev # Debian系 # 安装Ansible可以指定版本如 ansible2.9.27 pip3 install --user ansible # 或者全局安装需谨慎 sudo pip3 install ansible注意使用--user标志安装到用户目录可以避免污染系统Python环境。安装后需要将~/.local/bin添加到你的PATH环境变量中echo export PATH$PATH:~/.local/bin ~/.bashrc source ~/.bashrc。方式三通过源码安装仅用于开发或尝鲜除非你要贡献代码或测试最新特性否则不推荐。步骤繁琐且需要自行管理依赖。安装完成后验证一下ansible --version你会看到类似ansible 2.9.27的输出以及对应的Python版本和模块路径。看到这个第一步就成功了。2.2 核心配置文件ansible.cfg定下你的运维“规矩”Ansible的行为很大程度上由一个名为ansible.cfg的配置文件控制。它的查找顺序是环境变量ANSIBLE_CONFIG指定的文件./ansible.cfg当前目录~/.ansible.cfg用户家目录/etc/ansible/ansible.cfg系统全局我个人的最佳实践是在项目根目录下创建一个ansible.cfg文件。这样可以将配置和项目绑定便于版本管理和团队协作。一个最小化但功能强大的配置文件示例如下[defaults] # 清单文件路径默认是/etc/ansible/hosts我们改为当前目录下的inventory文件 inventory ./inventory # 禁用“收集事实”gather_facts在初期调试或对性能敏感时开启默认是True。如果遇到超时如热词中的gather_facts超时可以先设为False。 # gather_facts False # 设置远程用户如果所有机器都用同一个用户如ubuntu可以在这里统一指定 remote_user root # 启用主机密钥检查第一次连接新主机时会提示设为False可跳过安全环境内可用 host_key_checking False # 设置SSH超时和连接尝试次数应对网络不稳定 timeout 30 retries 3 [privilege_escalation] # 如果需要sudo/su提权在这里配置 become True become_method sudo become_user root become_ask_pass False # 如果sudo需要密码则设为True [ssh_connection] # SSH相关优化特别是连接复用能极大提升执行效率 control_path ~/.ssh/ansible-%%h-%%p-%%r control_master auto control_persist 10m pipelining True # 启用管道减少SSH连接次数提升性能这个配置文件定义了我们这个Ansible项目的“基本法”去哪里找要管理的机器inventory用什么用户登录remote_user是否需要提权become以及SSH连接的优化策略。特别是pipelining True和control_persist在管理大量主机时能带来显著的性能提升。2.3 清单Inventory定义告诉Ansible你的“军队”在哪Inventory清单文件就是你要管理的所有主机和分组的列表。它支持INI格式和YAML格式INI更常见。我们创建一个名为inventory的文件与ansible.cfg同级# 定义单个主机可以指定别名和连接变量 web1 ansible_host192.168.1.101 ansible_userubuntu web2 ansible_host192.168.1.102 ansible_userubuntu # 定义一个主机组 [group_name] [webservers] web1 web2 db1 ansible_host192.168.1.201 # 使用默认的remote_user # 组可以嵌套db1既属于[dbservers]也属于[datacenter_a] [dbservers] db1 [datacenter_a] web1 web2 db1 # 为组设置变量组内所有主机继承 [webservers:vars] ansible_python_interpreter/usr/bin/python3 http_port80 # 定义子组children[all:children]是一个特殊组包含所有子组 [all:children] webservers dbservers # 甚至可以定义主机范围不推荐在生产环境大量使用不利于管理 [web_range] web[01:50].example.com # 表示web01到web50有了清单你就可以用ansible命令进行初步测试了# 测试对所有主机执行ping模块测试连通性 ansible all -m ping # 测试对webservers组执行并收集事实 ansible webservers -m setup -a filteransible_distribution* # 在主机上执行一个原始shell命令 ansible web1 -a hostname如果看到绿色的SUCCESS和pong回复恭喜你Ansible已经可以和你的服务器“对话”了。这里经常遇到的第一个坑就是SSH密钥认证。确保控制节点上执行Ansible用户的SSH公钥已经分发到了所有目标主机的相应用户如ubuntu或root的~/.ssh/authorized_keys文件中。这是实现无密码登录的关键。3. Playbook实战从“执行命令”到“描述状态”Ad-hoc命令上面用的ansible -m -a适合做快速、一次性的任务但真正的力量在于Playbook。Playbook是一个YAML文件它描述了你希望目标主机达到的最终状态。3.1 Playbook结构解剖一出编排好的戏剧一个Playbook就像一出戏剧的剧本。它包含一个或多个“剧本”play每个剧本针对一组主机hosts执行一系列“任务”tasks。来看一个部署Nginx的简单例子文件名为deploy_nginx.yml--- # 这是一个Playbook文件 - name: 部署并配置Nginx Web服务器 # 第一个剧本play的名字 hosts: webservers # 这个剧本在哪些主机上执行 become: yes # 是否提权等价于ansible.cfg中的become vars: # 定义本剧本使用的变量 nginx_version: 1.18.0 web_root: /var/www/html tasks: # 任务列表按顺序执行 - name: 安装EPEL仓库针对RHEL系 yum: name: epel-release state: present when: ansible_os_family RedHat # 条件判断仅对RedHat系生效 - name: 安装Nginx package: # 使用通用的package模块自动选择yum或apt name: nginx state: present - name: 创建网站根目录 file: path: {{ web_root }} state: directory owner: nginx group: nginx mode: 0755 - name: 部署自定义首页 copy: src: files/index.html # 从控制节点的files/目录取文件 dest: {{ web_root }}/index.html owner: nginx group: nginx mode: 0644 - name: 启用并启动Nginx服务 systemd: name: nginx enabled: yes state: started - name: 开放防火墙端口 firewalld: # 使用firewalld模块 port: {{ http_port }}/tcp permanent: yes state: enabled immediate: yes when: ansible_os_family RedHat and ansible_facts[service_mgr] systemd # 剧本结束可以接着写下一个剧本比如针对数据库服务器执行这个Playbookansible-playbook deploy_nginx.ymlAnsible会以彩色输出显示执行过程黄色表示将要更改绿色表示OK无需更改或成功红色表示失败。幂等性在这里体现如果Nginx已经安装且版本一致安装Nginx任务会显示绿色ok而不会重复安装。3.2 变量Variables的魔法让Playbook灵活起来硬编码是Playbook的大忌。变量让你能轻松适配不同环境。变量来源的优先级从低到高清单变量在inventory文件中为主机或组设置。Playbook变量在Play的vars部分定义如上例。文件变量通过vars_files引入独立的YAML变量文件。命令行变量通过-e或--extra-vars传入优先级最高。一个常见的模式是创建group_vars/和host_vars/目录来组织变量项目根目录/ ├── ansible.cfg ├── inventory ├── deploy_nginx.yml ├── group_vars/ │ └── webservers.yml # 定义webservers组的变量 └── host_vars/ └── web1.yml # 定义web1主机的特定变量group_vars/webservers.yml内容--- nginx_version: 1.20.1 http_port: 8080 # 覆盖清单中定义的80端口 cluster_name: production_web_cluster这样变量管理清晰且能根据环境和主机灵活调整。3.3 模板Templates与文件管理动态配置的利器copy模块适合静态文件但对于需要根据变量动态生成的配置文件如Nginx虚拟主机配置、应用程序配置文件就需要template模块。它使用Jinja2模板引擎。假设我们有一个Nginx配置模板templates/nginx.conf.j2# Jinja2模板{{ }}内是变量 server { listen {{ http_port }} default_server; server_name {{ ansible_facts[fqdn] }}; root {{ web_root }}; index index.html index.htm; location / { try_files $uri $uri/ 404; } # 根据变量决定是否开启gzip {% if enable_gzip %} gzip on; gzip_types text/plain application/json; {% endif %} }在Playbook中使用template模块渲染并部署- name: 配置Nginx template: src: templates/nginx.conf.j2 dest: /etc/nginx/nginx.conf owner: root group: root mode: 0644 notify: restart nginx # 触发一个处理器handlernotify是关键。当模板任务因为文件内容变化而实际执行了更改状态为changed黄色时它会通知名为restart nginx的处理器。处理器是一种特殊的任务只在被通知时运行一次且在所有普通任务结束后执行常用于重启服务。定义处理器handlers: - name: restart nginx systemd: name: nginx state: restarted这种机制确保了配置变更后服务能自动重启同时避免了不必要的重复重启。4. 进阶技巧与实战避坑指南掌握了基础我们来看看如何让Ansible更高效、更稳健并避开那些常见的“坑”。4.1 角色RolesPlaybook的模块化与复用当Playbook越来越复杂把所有任务写在一个文件里会变得难以维护。Ansible角色Role是一种自动化的方式用于加载特定的变量、任务、处理器、模板和文件。你可以把角色想象成一个功能完整的“乐高积木”。一个标准的角色目录结构如下roles/ └── nginx/ # 角色名称 ├── defaults/ # 默认变量优先级最低 │ └── main.yml ├── files/ # 静态文件 ├── handlers/ # 处理器 │ └── main.yml ├── meta/ # 角色依赖信息 │ └── main.yml ├── tasks/ # 主任务列表 │ └── main.yml ├── templates/ # Jinja2模板 ├── tests/ # 测试相关 └── vars/ # 角色变量优先级高 └── main.yml创建角色可以使用命令ansible-galaxy init roles/nginx。然后在你的主Playbook中使用roles关键字来调用它变得极其简洁--- - name: 使用角色部署Web集群 hosts: webservers become: yes roles: - role: nginx vars: http_port: 8080 # 可以在这里覆盖角色的变量 - role: php-fpm # 可以按顺序应用多个角色 - role: deploy-app社区有大量的预置角色在Ansible Galaxy网站上可以直接拿来使用比如geerlingguy.nginx极大地提升了效率。4.2 故障排查与调试Debug让问题无处遁形再好的剧本也可能出问题。Ansible提供了强大的调试工具。1. 详细模式-v, -vvv运行Playbook时添加-vverbose标志可以输出更多信息。-vvv可以输出包括SSH连接细节在内的极度详细的信息是排查连接问题的利器。ansible-playbook deploy_nginx.yml -vvv2. 使用debug模块这是ansible debug的核心。你可以在任务中插入debug语句打印变量或信息。- name: 打印主机信息 debug: msg: 这台主机是 {{ ansible_facts[fqdn] }}, IP是 {{ ansible_default_ipv4.address }} - name: 打印整个ansible_facts字典信息量巨大慎用 debug: var: ansible_facts3. 使用--step和--start-at-task--step让你可以一步一步地确认每个任务的执行。--start-at-task可以从指定的任务开始运行非常适合在修复某个失败任务后跳过已经成功的部分重新测试。4. 处理“ansible gather_facts超时”这是热词中提到的一个常见问题。gather_facts是Playbook默认的第一个任务用于收集目标主机的各种信息IP、内存、磁盘等。如果网络慢或主机性能差可能超时。解决方法增加超时时间在ansible.cfg中设置gather_timeout 30默认10秒。禁用facts收集在Playbook或ansible.cfg中设置gather_facts: no。但后续任务如果需要用到ansible_facts变量就会出错。异步收集使用async和poll参数高级用法。4.3 性能优化管理成千上万台主机的秘诀当主机数量庞大时性能成为瓶颈。以下是我总结的优化点1. 启用SSH连接复用和管道化如前文ansible.cfg所示pipelining True和control_persist是必须的。它们能减少SSH握手开销。2. 使用forks增加并行度默认Ansible只同时操作5台主机。在ansible.cfg中增加forks 50或更高根据控制节点性能可以大幅提升并行执行速度。3. 使用strategy: free默认的线性策略strategy: linear会等待所有主机完成一个任务再开始下一个。而free策略允许每台主机尽快地、独立地执行所有任务对于任务执行时间差异大的场景非常有效。可以在Playbook中设置- hosts: large_cluster strategy: free tasks: - ...4. 关闭Fact收集或使用Fact缓存如果Playbook不依赖主机信息果断关闭gather_facts。如果依赖可以考虑使用Fact缓存如Redis、JSON文件将收集到的事实存储起来避免每次Playbook都重新收集。5. 使用async和poll处理长任务对于执行时间很长的任务如编译安装可以将其设置为异步让Ansible不必一直等待。- name: 执行一个长时间运行的脚本 shell: /usr/bin/long_running_operation.sh async: 1800 # 最大运行时间秒 poll: 0 # 设置为0表示“触发后不管”Ansible不会等待 register: long_task_result # 后续可以用async_status模块检查结果4.4 网络设备配置实战以华三交换机为例热词中提到了“ansible配置华三交换机”。Ansible确实可以管理网络设备但这和配置Linux服务器有些不同。网络设备通常使用CLI over SSH或API而不是在设备上运行Python。首先你需要安装针对网络设备的Ansible集合Collection。对于华三H3C设备社区可能有相关驱动但更通用的是使用ansible.netcommon集合它提供了cli_command等通用网络模块。# 安装网络通用集合 ansible-galaxy collection install ansible.netcommon然后你的清单文件需要为网络设备指定特殊的连接方式ansible_connection和网络操作系统类型ansible_network_os[h3c_switches] core_switch ansible_host10.10.1.1 [h3c_switches:vars] ansible_connectionansible.netcommon.network_cli # 使用network_cli连接插件 ansible_network_oscommunity.network.h3c_comware # 指定OS类型需确认有对应模块 ansible_useradmin ansible_ssh_passyour_password # 建议使用ansible-vault加密密码 ansible_becomeyes ansible_become_methodenable # 网络设备的特权模式 ansible_become_passwordenable_password一个简单的Playbook示例用于备份配置--- - name: 备份H3C交换机配置 hosts: h3c_switches gather_facts: no # 网络设备通常不收集facts tasks: - name: 执行display current-configuration命令 ansible.netcommon.cli_command: command: display current-configuration register: config_output - name: 将配置保存到本地文件 copy: content: {{ config_output.stdout[0] }} dest: ./backups/{{ inventory_hostname }}_config_{{ ansible_date_time.date }}.txt重要提示配置网络设备风险较高务必先在测试环境充分验证Playbook。对于ansible.cfg的写法和普通主机一样主要区别在于清单文件中为设备组设置的连接变量。核心就是正确指定ansible_connection和ansible_network_os。5. 融入CI/CD与日常运维让自动化成为习惯Ansible的价值不仅在于一次性部署更在于将运维工作流化、自动化。1. 与Git集成版本控制你的基础设施代码将你的Ansible项目Playbook、Roles、Inventory、Group_vars等放入Git仓库。每一次变更都有记录可以回滚可以Code Review。这是实现IaC的基础。2. 与Jenkins/GitLab CI集成持续部署在CI/CD流水线中可以在构建完应用包后触发一个Jenkins Job或GitLab CI Pipeline Stage执行Ansible Playbook将应用自动部署到测试或生产环境。# .gitlab-ci.yml 示例片段 deploy_to_staging: stage: deploy script: - ansible-playbook -i inventory/staging deploy_app.yml only: - main3. 使用Ansible Tower/AWX企业级控制平台对于团队协作和更复杂的调度、审计、可视化需求Red Hat Ansible Tower或其上游开源项目AWX是完美的选择。它提供了Web UI、RBAC基于角色的访问控制、工作流编排、作业模板和强大的审计日志。4. 日常运维场景示例批量执行命令ansible webservers -a systemctl restart nginx批量分发文件使用ansible.builtin.copy或synchronize模块。批量修改配置使用lineinfile或blockinfile模块确保某行文本存在于配置文件中。滚动更新使用serial关键字控制每次操作的主机数量实现灰度发布。- hosts: webservers serial: 2 # 每次只更新2台更新完一批再下一批 tasks: - name: 停止服务 systemd: namemyapp statestopped - name: 更新应用 copy: srcapp.tar.gz dest/opt/ - name: 启动服务 systemd: namemyapp statestarted走到这里Ansible已经从你手中的一个工具逐渐演变为团队乃至整个组织运维体系的基石。它带来的不仅是效率的提升更是工作模式的变革——从被动救火到主动规划从手工艺术到工程实践。回顾这段旅程最深的体会是自动化不是一蹴而就的可以从一个最简单的Playbook开始管理好一台服务器的Nginx然后逐步扩展到角色、变量管理、动态清单最终与你的CI/CD管道深度融合。每一次将手动操作转化为一行YAML代码都是向更稳定、更高效的运维环境迈进的一步。