企业官网建设流程全解析

• 文档
• 教程

本篇技术指南以 command/ansible.md 为核心，系统讲解 Ansible 的安装方式、核心命令家族、Inventory 主机清单、配置文件与 Vault 加密机制，并结合 linux-command 仓库中 systemctl、service、firewall-cmd 等命令文档，展开 Ad-Hoc 批量操作与 Playbook 编排的完整实战。

Ansible 是什么：无代理的自动化运维框架

ansible命令是一款强大的自动化运维工具，基于 Python 开发，采用 SSH 协议进行远程管理，无需在被管理节点安装代理。Ansible 可以实现自动化部署、配置管理、应用部署、任务编排等多种 IT 自动化需求。

Ansible 的核心特点是：无代理架构（Agentless）、幂等性（Idempotent）、使用 YAML 格式的 Playbook 描述自动化任务、基于 SSH 通信、模块化设计等。它使用简单直观，适合中小规模的自动化运维场景。

从架构层面看，Ansible 的控制端（Control Node）负责解析命令或 Playbook，通过 SSH 将模块推送到被管理主机上执行，执行完毕后模块随即退出，不留驻任何常驻进程。这种设计带来了两个直接收益：

• 无需在被管理节点安装 Agent，只要目标主机开放 SSH 且具备 Python 运行环境即可（文档明确指出需要 Python 2.7 或 Python 3.5+）；
• 管理端与被管理端是纯客户端-服务器之外的"推送式"关系，控制端既可以是物理机、虚拟机，也可以是容器或 CI 流水线中的临时环境。

由于 Ansible 与 SSH 深度绑定，本仓库中配套的 ssh.md、ssh-copy-id.md、ssh-keygen.md 等命令文档可作为你打通免密登录链路时的直接参考。

安装 Ansible：按发行版选择最合适的方式

# Ubuntu/Debian apt-get update apt-get install ansible # CentOS/RHEL yum install epel-release yum install ansible # 使用pip安装（推荐，获取最新版本） pip install ansible # macOS (Homebrew) brew install ansible # 验证安装 ansible --version

安装完成后，可通过ansible --version验证安装结果，输出中会同时显示核心模块版本、Python 版本与被管理端兼容性信息。安装方式的选择建议：

• Debian/Ubuntu 系：apt-get install ansible会从发行版软件源安装，版本相对保守但稳定；
• CentOS/RHEL 系：需先启用 EPEL（Extra Packages for Enterprise Linux）仓库，即先执行yum install epel-release，再安装 ansible；
• pip 方式：适合需要快速跟进新版本特性的场景，也便于在虚拟环境中隔离依赖；
• macOS（Homebrew）：适合本地开发机，可与仓库中的 brew 相关命令 配合管理。

需要说明的是，不同发行版软件源中 ansible 的版本与可用模块集合可能有差异，生产环境建议以官方文档对应版本为准。

命令语法与命令家族

基本语法

ansible [options] <host-pattern> ansible-playbook [options] <playbook-file>

ansible用于执行临时命令（Ad-Hoc），ansible-playbook用于执行 Playbook 文件。两者共用一个 Inventory（主机清单）作为主机来源。

常用命令

ansible 执行临时命令 ansible-playbook 执行Playbook ansible-galaxy 管理角色和集合 ansible-console 交互式控制台 ansible-doc 查看模块文档 ansible-inventory 显示库存信息 ansible-pull 从远程拉取配置 ansible-vault 加密/解密文件 ansible-config 显示配置 ansible-test 运行测试

各命令的分工如下：

• ansible：Ad-Hoc 模式，一条命令完成"对某组主机执行某个模块操作"；
• ansible-playbook：把多步任务以 YAML 文件形式编排执行，是正式自动化运维的主力；
• ansible-galaxy：从 Ansible Galaxy 社区下载、安装角色（Roles）和集合（Collections），也可初始化本地角色骨架；
• ansible-console：交互式 Shell，可逐条输入命令并自动带上前缀主机模式；
• ansible-doc：离线查看模块文档与参数说明，是编写 Playbook 时最常用的"活字典"；
• ansible-inventory：以 JSON 或 graph 格式展示 Inventory 解析结果，用于调试主机分组；
• ansible-pull：反向模式，由被管理节点主动从 Git 仓库拉取配置并执行，适合大规模节点或离线场景；
• ansible-vault：对敏感文件（密码、私钥、证书）进行 AES 加密存储；
• ansible-config：查看当前生效配置与默认值，帮助定位配置覆盖关系；
• ansible-test：面向模块与集合开发者的测试框架入口。

Ad-Hoc 实战：零剧本的批量操作

Ad-Hoc 模式适合"查状态、装软件、启服务"这类一次性或探索性操作，语法为ansible <host-pattern> -m <module> -a "<参数>"。

连通性测试与信息采集

# 基本用法：ping所有主机 ansible all -m ping # ping指定组的主机 ansible webservers -m ping # 执行简单命令 ansible all -a "/usr/bin/uptime" # 查看主机信息 ansible all -m setup # 查看特定fact ansible all -m setup -a "filter=ansible_os_family"

ping模块并非 ICMP 探测，而是测试 SSH 通道与 Python 解释器是否可用；setup模块会采集目标主机的 Facts（系统信息），filter参数支持使用通配符过滤，例如filter=ansible_*。这一机制与仓库中 hostname.md、uname.md 等单机信息查看命令互补——前者是"一键采集所有主机"，后者是"单机手工查看"。

软件安装与服务管理

# 安装软件包 ansible webservers -m apt -a "name=nginx state=present" # 管理服务 ansible webservers -m service -a "name=nginx state=started enabled=yes"

apt模块面向 Debian/Ubuntu 系，yum模块面向 CentOS/RHEL 系（可参考 yum.md）；service模块兼容 SysV init 脚本，若目标主机使用 systemd 则建议改用systemd模块，详见仓库中的 service.md 与 systemctl.md——两者分别对应传统 init 脚本管理与现代 systemd 单元管理。state=present表示"若未安装则安装"，enabled=yes表示"开机自启"，这正是幂等性的体现：重复执行不会产生多余副作用。

文件与目录管理

# 创建目录 ansible all -m file -a "path=/opt/myapp state=directory owner=root group=root mode=0755" # 创建文件 ansible all -m copy -a "src=/local/file.txt dest=/remote/file.txt owner=root mode=0644" # 从模板部署文件 ansible all -m template -a "src=template.j2 dest=/etc/myapp/config.yaml" # 执行脚本 ansible all -m script -a "/scripts/deploy.sh" # 下载文件 ansible all -m get_url -a "url=https://example.com/file.tar.gz dest=/tmp/" # 压缩文件 ansible all -m unarchive -a "src=/tmp/file.tar.gz dest=/opt/ remote_src=yes" # 删除文件或目录 ansible all -m file -a "path=/tmp/oldfile state=absent"

各模块要点：

• file：管理文件/目录/软链接的存在性与属性，state=directory、state=absent、state=touch等取值决定操作类型；
• copy：从控制端拷贝文件到远端，可同时设定属主与权限；
• template：基于 Jinja2 模板（.j2）渲染后部署，是"一套模板、多主机差异化配置"的关键模块；
• script：把控制端本地脚本复制到远端执行，适合复用已有 Shell 脚本（如本仓库中大量 shell 类命令）；
• get_url：在远端直接下载 URL 资源；
• unarchive：解压归档文件，remote_src=yes表示归档文件已在远端而非控制端。

批量运维场景

# 查看日志 ansible all -m shell -a "tail -n 50 /var/log/syslog" # 批量重启服务 ansible webservers -m shell -a "systemctl restart nginx" # 批量更新系统 ansible all -m shell -a "yum update -y" --limit centos_servers # 批量检查磁盘空间 ansible all -m shell -a "df -h" -o # 批量收集系统信息 ansible all -m setup -a "filter=ansible_*" -o > system_info.json # 使用shell模块执行复杂命令 ansible all -m shell -a "ps aux | grep nginx | grep -v grep | wc -l" # 使用lineinfile修改配置文件 ansible webservers -m lineinfile -a "path=/etc/nginx/nginx.conf line=\"worker_processes auto;\" insertafter=\"#worker_processes\""

shell模块支持管道、重定向等 Shell 特性（command模块则不支持），适合一次性批量巡检；lineinfile可在不覆盖整个文件的前提下"按行"插入/替换/删除配置项，是精细化配置管理的利器；-o（one-line）参数将输出压缩为单行，方便大量主机的日志收集与管道处理。

连接与执行控制

# 使用become提权 ansible all -m ping -b --become-user=root # 指定SSH端口 ansible all -m ping -c ssh --connection-options "port=2222" # 并发执行 ansible all -m ping -f 10 # 限制输出 ansible all -m ping -o

• -b/--become：以提权方式执行（默认 sudo），配合--become-user=root指定提权目标用户，对应配置文件中的[privilege_escalation]段；
• -c ssh：显式指定 SSH 连接插件，--connection-options可透传port=2222等 SSH 参数；
• -f 10：设置并发 forks 数量，控制执行速度与资源占用；
• -o：单行输出，便于脚本化处理。

Playbook 编排：从临时命令到可复用自动化

当操作步骤超过一条时，应使用 Playbook 把任务、变量、条件、循环、Handler 组织成 YAML 文件。

一个完整的 nginx 部署 Playbook

--- # site.yml hosts: webservers become: yes tasks: - name: Install nginx apt: name: nginx state: present - name: Start nginx service: name: nginx state: started enabled: yes - name: Deploy config template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf notify: Restart nginx handlers: - name: Restart nginx service: name: nginx state: restarted

# 执行Playbook ansible-playbook site.yml # 执行Playbook并指定变量 ansible-playbook site.yml -e "nginx_port=8080" # 执行Playbook并指定inventory文件 ansible-playbook site.yml -i inventory.ini

要点解析：

• hosts指定目标主机组，become: yes声明全程提权；
• notify + handlers：notify在任务状态发生变化（changed）时触发同名 handler，handlers中的任务只在被通知时执行——如上例中仅当模板内容变化时才重启 nginx，避免无谓重启，这正是幂等设计的落地点；
• -e可在命令行注入变量，优先级高于 Playbook 内定义；
• -i指定自定义 Inventory 文件路径。

任务执行控制

# 测试playbook语法 ansible-playbook site.yml --syntax-check # 模拟执行（dry-run） ansible-playbook site.yml --check # 只运行指定的任务 ansible-playbook site.yml --tags "install" # 跳过指定的任务 ansible-playbook site.yml --skip-tags "restart" # 限制执行的主机 ansible-playbook site.yml --limit "web1,web2"

• --syntax-check：仅校验 YAML 语法与模块参数格式，不连接主机；
• --check：模拟执行（dry-run），报告"将要发生的变化"但不对目标主机做实际修改，是上线前验证的关键手段；
• --tags/--skip-tags：配合任务上的tags标记实现"只跑/不跑某类任务"的精细化控制；
• --limit：把执行范围收敛到指定主机或子集，配合分组使用可避免误操作扩散到全量节点。

条件、循环与结果注册

# 使用when条件执行 --- tasks: - name: Install nginx on Debian apt: name: nginx when: ansible_os_family == "Debian" - name: Install nginx on RedHat yum: name: nginx when: ansible_os_family == "RedHat" # 使用loop循环 --- tasks: - name: Create users user: name: "{{ item }}" state: present loop: - alice - bob - charlie # 使用register保存结果 --- tasks: - name: Check if file exists stat: path: /etc/myapp/config.yaml register: config_file - name: Deploy config if not exists copy: src: config.yaml dest: /etc/myapp/config.yaml when: not config_file.stat.exists

• when：基于 Facts（如ansible_os_family）或变量做条件判断，让同一 Playbook 兼容多发行版；
• loop：迭代列表批量执行，配合{{ item }}引用当前元素，替代冗长的重复任务；
• register：把前序任务的返回结果存入变量，供后续任务的when判断使用——上例先stat探测文件是否存在，存在与否再决定是否部署，这是"幂等 + 条件化"的典型组合。

notify 与 handlers 联动

# 使用notify和handlers --- tasks: - name: Update nginx config template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf notify: Reload nginx handlers: - name: Reload nginx service: name: nginx state: reloaded

reloaded与restarted的区别在于：reload 平滑重载配置（不中断连接），restart 完全重启进程。仅当模板内容发生变更时 handler 才会被触发，多次执行 Playbook 不会反复重启服务。

block、rescue 与 always：任务级异常处理

--- tasks: - block: - name: Task 1 apt: name: pkg1 - name: Task 2 apt: name: pkg2 rescue: - name: Recovery task debug: msg: "Rescue executed" always: - name: Always run debug: msg: "Always executed"

block将多个任务聚合成一个逻辑单元；当其中任一任务失败时执行rescue中的恢复任务；always无论成功失败都会执行，适合做清理、告警、状态回写等收尾操作——语义与编程语言中的 try / except / finally 对应。

tags 标记与选择性执行

--- tasks: - name: Install packages apt: name: "{{ item }}" loop: [pkg1, pkg2] tags: [install, packages] - name: Configure service template: src: service.conf.j2 dest: /etc/service.conf tags: [configure] - name: Restart service service: name: service state: restarted tags: [restart] # 执行指定tag的任务 ansible-playbook site.yml --tags "install,configure" # 跳过指定tag的任务 ansible-playbook site.yml --skip-tags "restart"

Role 角色：把 Playbook 组件化复用

使用 ansible-galaxy 管理角色与集合

# 使用角色 ansible-galaxy install geerlingguy.nginx # 列出已安装的角色 ansible-galaxy list # 从requirements文件安装角色 ansible-galaxy install -r requirements.yml # 创建新角色 ansible-galaxy init myrole # 创建集合 ansible-galaxy collection init mynamespace.mycollection # 发布集合到Galaxy ansible-galaxy collection publish mycollection-1.0.0.tar.gz # 搜索集合 ansible-galaxy collection search nginx

requirements.yml可声明多个角色及其版本，便于团队通过一条命令复现相同依赖；collection是 Ansible 2.9+ 的模块分发单位，支持命名空间隔离与独立发布。

Role 目录结构

myrole/ ├── tasks/ │ └── main.yml ├── handlers/ │ └── main.yml ├── templates/ │ └── config.j2 ├── files/ │ └── app.tar.gz ├── vars/ │ └── main.yml ├── defaults/ │ └── main.yml └── meta/ └── main.yml

• tasks/：角色主逻辑入口，Playbook 引用角色时自动执行；
• handlers/：角色内的 handler 定义；
• templates/：Jinja2 模板文件（如config.j2）；
• files/：无需渲染的静态文件（供copy模块直接使用）；
• vars/：高优先级变量，不可被 Inventory 覆盖；
• defaults/：默认变量，优先级最低，可被任意层覆盖——这是角色"开箱即用、按需覆盖"的关键；
• meta/：角色元信息（依赖、作者等）。

在 Playbook 中使用角色

--- hosts: webservers roles: - common - nginx - myapp

角色按声明顺序依次执行，适合把"初始化（common）→ 装应用（nginx）→ 部署业务（myapp）"的完整流程拆解为独立可复用的组件。

Inventory：主机清单与分组

# 主机分组 [webservers] web1.example.com ansible_host=192.168.1.10 web2.example.com ansible_host=192.168.1.11 [databases] db1.example.com ansible_host=192.168.1.20 [production:children] webservers databases # 变量定义 [webservers:vars] http_port=80 max_clients=200 # 指定SSH参数 web3.example.com ansible_port=2222 ansible_user=admin

要点说明：

• ansible_host：实际连接地址（覆盖主机名），适合"别名 + 内网 IP"的映射；
• [组名:children]：定义组的父子关系，production组的成员即其子组所有主机，实现环境级（production/staging）聚合管理；
• [组名:vars]：为该组所有主机定义统一变量（如http_port、max_clients）；
• ansible_port、ansible_user：按主机覆盖 SSH 端口与登录用户，配合 ssh.md 中相关参数理解更佳。

# 显示库存 ansible-inventory --list ansible-inventory --graph

ansible-inventory --list以 JSON 输出完整清单与变量，--graph以树状图展示分组层级，两者都是排查"主机该归哪组、变量是否生效"的常用调试手段。

配置文件：ansible.cfg 核心项解读

# 主配置文件 /etc/ansible/ansible.cfg # 默认inventory /etc/ansible/hosts # 用户配置 ~/.ansible.cfg # 常用配置项 [defaults] inventory = /etc/ansible/hosts remote_user = root log_path = /var/log/ansible.log host_key_checking = False retry_files_enabled = False forks = 50 [privilege_escalation] become = True become_method = sudo become_user = root become_ask_pass = False

配置文件优先级为：命令行参数 > 环境变量 >ansible.cfg（当前目录 > 用户~/.ansible.cfg> 全局/etc/ansible/ansible.cfg）。核心项含义：

• inventory：默认主机清单路径；
• remote_user：默认 SSH 登录用户；
• log_path：开启并指定日志文件，便于审计所有执行动作；
• host_key_checking：设为False可避免首次连接时的 host key 确认交互（自动化场景常用，生产环境建议按安全策略权衡）；
• retry_files_enabled：失败重试文件开关，False可避免在本地残留.retry文件；
• forks：默认并发进程数，值越大批量执行越快，需结合控制端资源设置；
• [privilege_escalation]：默认提权策略，become_method = sudo与become_user = root定义了提权方式和目标用户。

可以用ansible-config命令查看当前生效配置与默认值，辅助定位覆盖关系。

Ansible Vault：敏感信息加密

# 创建新的vault文件 ansible-vault create secret.yml # 使用vault加密 ansible-vault encrypt secret.yml ansible-vault decrypt secret.yml ansible-vault view secret.yml ansible-vault edit secret.yml # 使用vault运行playbook ansible-playbook site.yml --ask-vault-pass

• create：新建一个自动加密的文件，会提示输入密码；
• encrypt/decrypt：对已有明文文件进行加密/解密；
• view/edit：不解密落盘的前提下查看/编辑加密内容；
• 运行含加密变量的 Playbook 时通过--ask-vault-pass交互输入密码，也可配合--vault-password-file指定密码文件实现流水线自动化。

Vault 是 Ansible 处理密码、私钥、证书等敏感信息的标准手段。需要特别提醒：涉及密钥与凭据的配置务必使用 Vault 加密存储，切勿以明文形式提交到版本库。

实战注意要点

1. Ansible 默认使用 SSH 连接，需要确保目标主机开放 SSH 端口且 SSH 密钥配置正确——免密登录可用ssh-keygen+ssh-copy-id完成（参见 ssh-keygen.md、ssh-copy-id.md）；
2. 被管理节点不需要安装 Agent，只需要 Python 2.7 或 Python 3.5+；
3. 使用--check模式可以模拟执行，不会实际修改目标主机；
4. 敏感信息（如密码）应该使用 Ansible Vault 加密存储；
5. Playbook 具有幂等性，多次执行不会产生副作用；
6. 建议使用 roles 组织复杂的自动化任务，提高代码复用性；
7. 使用--limit参数可以限制执行范围，避免误操作；
8. 生产环境建议先在测试环境验证 Playbook，再应用到生产环境。

相关命令速览

• ansible-playbook— 执行 Playbook
• ansible-vault— 加密解密文件
• ansible-galaxy— 管理角色和集合
• ansible-doc— 查看模块文档

与 Ansible 日常运维紧密相关的命令文档，可在本仓库对应文件中继续查阅：

• systemctl.md：systemd 服务管理（现代发行版默认）；
• service.md：SysV init 服务管理；
• yum.md、apt-get.md：RPM/DEB 软件包管理；
• firewall-cmd.md：firewalld 防火墙管理，配合服务端口放行；
• ssh.md、ssh-copy-id.md、ssh-keygen.md：SSH 连接与免密配置；
• crontab.md：定时任务，可与ansible-pull结合实现节点侧定时拉取配置；
• nohup.md：后台运行控制端长任务。

此外，Ansible 官方提供了完整的 文档、入门指南 与 最佳实践，可作为进一步学习的权威参考资料。

• 文档
• 教程