Ansible01-入门

2026-09-06

2026-09-07

云原生中级

ansible

Ansible 入门

0. 为什么要学 Ansible

0.1 一个经典痛点：几十台机器怎么管

当服务器数量从几台增长到几十上百台，逐台 SSH 登录手动敲命令将变得不可持续：

重复劳动：每台机器都要装同样的软件、改同样的配置、启动同样的服务；
易出错：手敲命令容易漏、容易错，且每台机器可能被改成不一样的状态；
配置漂移（drift）：因为手工操作顺序不同、有人手动改过，机器之间的配置渐渐不一致，问题越来越难排查。

配置管理 / 自动化工具（Ansible、Puppet、Chef、SaltStack）正是为解决这一问题而生。它们的目标是：用一份「声明式」的配置，批量、可重复地把所有机器拉齐到期望状态。

0.2 Ansible 的答案：简单、无代理、基于 SSH

在众多工具里，Ansible 以「简单」著称，成为目前最流行的 IT 自动化平台之一：

简单：用 YAML 写配置（Playbook），人类可读，上手快；
无代理（agentless）：被管端不需要安装任何客户端，只要有 SSH 和 Python 即可；
基于 SSH：利用现有的 SSH 安全机制，不额外开放端口、不跑额外服务；
Push 模式：控制端主动把配置推送给被管端，即时生效。

它能做的事远超「批量敲命令」：配置管理、应用部署、任务编排、持续交付（CI/CD）、云资源管理，都能胜任。是运维工程师的必备技能，也是通往 DevOps、云原生的重要一步。

一、Ansible 是什么

1.1 起源与定位

Ansible 由 Michael DeHaan 于 2012 年创建，2015 年被 Red Hat（红帽） 收购，如今是 Red Hat Ansible Automation Platform 的核心。它最初定位是「像系统管理员手动操作那样，但自动化地做」。

本节只需建立整体印象。Ansible 本质上是一个自动化执行引擎：由使用者声明「哪些机器、做什么、怎么做」，引擎便通过 SSH 批量执行并将结果返回。

1.2 它能做什么

场景	例子
批量部署软件	一次给 50 台机器装 nginx / mysql / jdk
配置下发与模板替换	把 nginx.conf、环境变量模板渲染后推送到各机器
服务与用户管理	批量启动/重启服务、创建用户、开防火墙规则
编排跨主机任务	部署 Hadoop、K8s、Ceph 等多机协作的集群
云 / 容器 / 网络设备	调 AWS API、管 Docker、配 Cisco 设备

1.3 两个「安装包」：ansible-core 与 ansible

这是新手最容易懵的一点。现代 Ansible 被拆成了两样东西，安装前必须先分清：

包名	是什么	包含什么
`ansible-core`	核心引擎（精简运行时）	命令（ansible / ansible-playbook 等）+ 内置模块（`ansible.builtin.*`）
`ansible`（社区完整包）	核心 + 一堆常用集合	在 `ansible-core` 基础上，额外捆绑一批社区精选的集合（collections），开箱即用

理解要点：

ansible.builtin 是内置命名空间，核心模块（copy、service、user、yum、apt…）都在这里，装 ansible-core 就有；
现代 Ansible 的扩展模块都以**集合（collection）**形式组织，如 community.general、ansible.posix、community.docker；
完整版 ansible 包只是「预装了一堆集合」，本质还是那个 ansible-core + 集合，命令没有任何不同。

版本现状（截至写作时）：ansible-core 最新稳定版是 2.20.x，Ansible 社区完整包是 11.x（内含上百个集合）。不同发行版仓库里打包的版本可能偏旧，这点在安装章节会重点讲。

简单记忆：学习、开发推荐装完整版 ansible，开箱即用少踩坑；只想做基本批量操作、服务器资源紧张的可以只装 ansible-core。两者命令用法完全一样。

二、安装：先装通一种

2.1 只装在控制端

一个前提：Ansible 只安装在控制端（control node）——即负责发起管理的机器（可以是笔记本、跳板机或专门的运维机）。被管端（被管理的目标机器）无需安装任何 Ansible 组件，只需满足两点：能 SSH 连接 + 有 Python。

这就是「无代理」的含义：被管端无需安装/维护任何 Ansible 组件，SSH 连上即可管理。这也是 Ansible 比很多老牌配置管理工具简单的原因。

以下按「最常用 → 更灵活 → 更多方式」的顺序给出安装方法，可按实际系统场景选择其一。

2.2 最常用：RHEL / Rocky（dnf + EPEL）

RHEL 系的 Ansible 相关包在 EPEL（Extra Packages for Enterprise Linux） 仓库。关键差异在发行版版本：

发行版	EPEL 里有什么	说明
EL9 及以前（Rocky 9 / RHEL 9 / CentOS 9）	有 `ansible` 完整包	`dnf install ansible` 直接装完整版
EL10（Rocky 10 / RHEL 10）	只有 `ansible-core`，没有 `ansible` 包	官方已确认不打包完整版；需用 pip/galaxy 补集合

EL10 特别说明：Red Hat 官方（EPEL 维护者）已明确确认——EPEL10 不再提供 ansible 这个完整包名，它被拆成 ansible-core（dnf 提供）+ 各集合（用 pip 或 ansible-galaxy 安装）。你在 EL10 上执行 dnf install ansible 会报「没有任何匹配: ansible」。这是设计如此，不是你的错。

EL9 / Rocky 9 安装完整版（推荐入门）：

# 1. 启用 EPEL 和 CRB（EPEL 部分依赖需要）
sudo dnf install -y epel-release
sudo dnf config-manager --set-enabled crb   # RHEL9/Rocky9 需要 CRB；若已启用可跳过

# 2. 安装完整版 ansible（含常用集合）
sudo dnf install -y ansible sshpass
ansible --version

sshpass 用来让 Ansible 在被管端用密码登录时能工作（配合 ansible_ssh_pass）。如果只用密钥登录，可以不装。建议装上，少踩一个坑。

EL9 / Rocky 9 只想装精简核心版（够用就好）：

sudo dnf install -y epel-release
sudo dnf config-manager --set-enabled crb
sudo dnf install -y ansible-core sshpass
ansible --version

EL10 / Rocky 10 安装（只有 ansible-core）：

# 1. 启用 EPEL10 和 CRB
sudo dnf install -y epel-release
sudo dnf config-manager --set-enabled crb

# 2. 安装核心引擎
sudo dnf install -y ansible-core sshpass
ansible --version

# 3. （可选）后续要用哪些集合，用 ansible-galaxy 补装，例如：
ansible-galaxy collection install ansible.posix
ansible-galaxy collection install community.general

装了 ansible-core 后，命令仍是 ansible / ansible-playbook，只是模块只有内置的 ansible.builtin。要扩展就 ansible-galaxy collection install 集合名。

2.3 Debian / Ubuntu（apt）

Debian/Ubuntu 的官方源里有 ansible-core 包；较新 Ubuntu（如 24.04）在 universe 仓库里也有 ansible 完整包（但版本通常偏旧）。

# 更新索引
sudo apt update

# 方案 A：装完整版（Ubuntu 较新版本在 universe 里可用）
sudo apt install -y ansible sshpass
ansible --version

# 方案 B：只装核心（Debian 的 stable 源通常只有 ansible-core）
sudo apt install -y ansible-core sshpass
ansible --version

Ubuntu 官方源的 ansible 版本可能滞后很久（例如还是 2.14/2.16 时代）。想用最新版，常见做法是用 pip 装（见 2.4）。生产环境追版本用 pip 更可控。

2.4 想追新：pip 装进虚拟环境

无论哪个发行版，都可以用 pip 安装最新版 Ansible，这是跨发行版、版本最新的通用做法。因为现代系统 Python 受 PEP 668 限制（默认禁止 pip 写入系统 Python），强烈建议在虚拟环境（venv）里装：

# 1. 创建虚拟环境（一次性）
python3 -m venv ~/ansible-venv

# 2. 每次使用前先激活（或把 bin 加进 PATH）
source ~/ansible-venv/bin/activate

# 3. 在 venv 里安装完整版
pip install ansible
ansible --version

# 或只装核心：
# pip install ansible-core

要点：

完整版 pip install ansible 会自动带上依赖集合，pip install ansible-core 只装核心；

每次用之前先 source ~/ansible-venv/bin/activate，否则命令还是系统里的旧版；

若一定要装到系统 Python，可加 --user（用户级）或 --break-system-packages，但不推荐污染系统环境。

2.5 更多安装方式（附录）

以下方式第一遍学可以先略过，等需要时再回来看。

容器方式：docker / podman 里跑 Ansible

如果控制端不想污染系统，或想要一个「干净、固定版本」的 Ansible 环境，可以在容器里跑。前提是容器里能 SSH 到被管端（需要挂载密钥/网络互通）。

# 用官方社区开发工具镜像（自带较全的工具）
docker run --rm -it \
  -v ~/.ssh:/root/.ssh:ro \
  -v "$PWD":/work -w /work \
  ghcr.io/ansible/community-ansible-dev-tools:latest \
  ansible --version

想用专门为 Ansible 打造的容器化运行环境（execution environment，内置完整工具链），那是 ansible-navigator 的能力范围。这里只提一句：容器是跑 Ansible 的一种干净方式。

离线安装（内网/无外网环境）

内网机器没有外网时，不能在线 dnf install。离线方案有几种，按实际情况选。

方案 A：挂载系统安装光盘/DVD 作为本地源。若有 Rocky/RHEL 的安装 ISO，可挂载为本地 yum 源：

# 1. 挂载 ISO
sudo mkdir -p /mnt/iso
sudo mount -o loop /path/to/Rocky-9.x.iso /mnt/iso

# 2. 配置本地源
cat > /etc/yum.repos.d/local.repo <<'EOF'
[local-baseos]
name=Local BaseOS
baseurl=file:///mnt/iso/BaseOS
enabled=1
gpgcheck=0
[local-appstream]
name=Local AppStream
baseurl=file:///mnt/iso/AppStream
enabled=1
gpgcheck=0
EOF
sudo dnf clean all && sudo dnf makecache

注意：系统 ISO 里通常只有 BaseOS + AppStream，不一定有 ansible 完整包（在 Rocky 上 ansible 属于 EPEL）。所以纯靠系统盘可能只能装 ansible-core。要完整版，需要把 EPEL 的 RPM 包也离线下载下来。

方案 B：在能联网的机器上预下载 RPM，再拷到内网装。在一台有网的、同版本系统的机器上，用 dnf download 把包及其依赖下载下来，打包拷到内网：

# 有网机器上：仅下载不安装
sudo dnf install -y dnf-plugins-core
sudo dnf download --resolve --alldeps ansible-core sshpass
# 这会下载当前目录下的若干 .rpm 文件
# 把所有这些 .rpm 打包拷到内网
tar czf ansible-offline.tar.gz *.rpm

内网机器上：

tar xzf ansible-offline.tar.gz
sudo dnf localinstall -y *.rpm    # 从本地 rpm 批量安装

方案 C：pip 离线安装。

# 有网机器上：把包下载到本地目录
mkdir -p /tmp/wheels
pip download ansible -d /tmp/wheels
tar czf ansible-pip-offline.tar.gz /tmp/wheels

# 内网机器上（venv 内）
tar xzf ansible-pip-offline.tar.gz
pip install --no-index --find-links=/tmp/wheels ansible

离线安装最容易踩的坑是依赖缺失——装 ansible-core/ansible 时依赖可能很多（尤其完整版拉一堆集合）。务必用 --resolve --alldeps（rpm）或 pip download 把依赖一起拉齐。

装完先验证一下：

# 版本与关键信息
ansible --version
ansible-config --version

# 确认核心命令都在
which ansible ansible-playbook ansible-galaxy ansible-doc

# 列出已安装的集合（完整版这里会有一大堆）
ansible-galaxy collection list

ansible --version 会显示版本、配置文件路径、模块/集合搜索路径。看到 ansible [core 2.20.x] 就说明核心装好了。

三、连接机制与 SSH

Ansible 通过 SSH 连接被管端，因此安装完成后第一步是让控制端能连接到目标机器；连接不通，后续命令都无法执行。下面先配置连接。

3.1 连接插件：Ansible 怎么连

Ansible 通过连接插件决定「怎么连到被管端」。内置的连接插件：

插件	作用
`ansible.builtin.ssh`	默认，通过 SSH 客户端连（支持密钥、密码）
`ansible.builtin.local`	直接在控制端本机执行，不连远程
`ansible.builtin.paramiko_ssh`	用 Python 的 paramiko 库做 SSH（某些受限环境用）
`ansible.builtin.winrm`	管理 Windows 被管端
`ansible.builtin.psrp`	通过 PowerShell 远程协议管 Windows

日常 99% 的场景用默认的 ssh 即可，不需要手动切换。连接插件可以通过 ansible_connection 变量指定，也可以针对某台机器单独指定。

说明：Ansible 的管理节点（控制端）只能是 Linux。Windows 可以作为被管端（通过 WinRM），但不能作为控制端。

3.2 配置 SSH 免密

连接被管端有两种方式：密钥和密码。最省事、最安全的做法是密钥免密，一劳永逸：

# 控制端生成密钥（若还没有）
ssh-keygen -t ed25519

# 把公钥分发到被管端（会提示输入一次密码）
ssh-copy-id user@192.168.1.20

# 验证：这条命令能免密成功，说明连通了
ssh user@192.168.1.20 'echo ok'

也可用 ansible_ssh_pass 指定密码连接，但不推荐：密码明文存在清单里，且必须装 sshpass。生产优先用密钥。SSH 连接本身不是 Ansible 专属，任何 Linux 运维都离不开，这就是为什么「连上」这一步要先于「跑命令」——SSH 通了，Ansible 自然就能用。

3.3 特殊主机：localhost

localhost 是一个特殊主机，不需要在清单里声明就能用。未在清单声明时，Ansible 会用 local 方式连接（相当于在控制端本地执行）：

ansible localhost -m command -a 'id'

常见用途：在控制端本地生成备份文件名、调用本机脚本、记录时间戳等。local 连接会忽略 remote_user 选项——因为未连接远程，直接使用当前用户。在没有远程机器的环境中，localhost 是最方便的第一台被管端。

四、Inventory：告诉它管哪些机器

Inventory（主机清单） 它定义 Ansible 管理哪些主机、如何连接它们、按什么分组。

4.1 什么是 Inventory

Inventory（主机清单） 是一份记录被管主机及分组的列表，Ansible 靠它知道「要管哪些机器、怎么连」。推荐用项目内的自定义清单文件（如 inventory.ini），用 -i 指定或写在 ansible.cfg 里（第六章讲）。

4.2 一个最简单的清单

最简单的 INI 格式 inventory.ini：

192.168.1.20
web1.example.com

[webservers]
192.168.1.21
192.168.1.22

[dbservers]
db1.example.com

[all:vars]
ansible_user=centos
ansible_ssh_private_key_file=/home/ops/.ssh/id_ed25519

顶部的 192.168.1.20 等是未分组主机；
[webservers]、[dbservers] 是组；[组名:vars] 给该组定义变量，[all:vars] 给所有主机定义变量。

清单还可以写成 YAML 格式（更结构化）；入门阶段用 INI 就足够。

4.3 连接相关的主机变量

清单里常写这些连接相关的变量，它们决定 Ansible 怎么连到这台机器：

变量	作用
`ansible_host`	实际连接的主机名/IP（清单里的名字可作别名）
`ansible_user`	SSH 登录用户
`ansible_port`	SSH 端口（默认 22）
`ansible_ssh_private_key_file`	SSH 私钥路径
`ansible_ssh_pass`	SSH 密码（需装 sshpass；不推荐明文存，生产用密钥或 vault）
`ansible_connection`	连接方式（ssh/local/winrm 等）
`ansible_python_interpreter`	被管端 Python 路径

现在回过头看 5.2 清单里的 [all:vars] 就好懂了：它给所有主机统一指定登录用户 centos 和私钥路径。清单不止是「列机器」，也是「定义怎么连」。

4.4 选主机：Host Patterns

这是 Ansible 选主机最核心、也最实用的能力——ad-hoc 命令或 Playbook 里的 hosts: 都可以用模式精确挑选主机。

基础模式

目标	模式写法	说明
所有主机	`all` 或 `*`
单台主机	`host1`	用清单里的名字或别名
多台主机	`host1,host2`（或 `host1:host2`）	推荐用逗号，IPv6 场景更稳
一个组	`webservers`
多个组	`webservers:db`	两个组的所有主机
排除某组	`webservers:!atlanta`	webservers 里去掉 atlanta 组的主机
交集	`webservers:&staging`	既在 webservers 又在 staging 的主机

示例：webservers:db:&staging:!phoenix 表示「webservers 和 db 的所有主机中，与 staging 相交、且不在 phoenix 里的主机」。

通配符与正则

# 通配符：匹配以 node 开头的主机
ansible -i inventory.ini 'node*' --list-hosts

# 通配 IP 段
ansible -i inventory.ini '192.168.72.*' --list-hosts

# 正则（以 ~ 开头）：匹配 web 或 db 开头、.example.com 结尾的主机
ansible -i inventory.ini '~(web|db).*\.example\.com' --list-hosts

下标切片（按组内位置选）

[webservers]
cobweb
webbing
weber

webservers[0]    # == cobweb
webservers[-1]   # == weber
webservers[0:2]  # == cobweb,webbing
webservers[1:]   # == webbing,weber

--limit：运行时额外限定

即使 Playbook 里写了 hosts: all，命令行仍可用 --limit 精确收窄：

# 只跑清单里的 node1 和某 IP
ansible-playbook site.yml --limit node1,192.168.1.30

# 从一个文件里读主机列表（@ 前缀）
ansible-playbook site.yml --limit @/root/ansible/ip.txt

生产环境做灰度/定点操作最常用这一套：先 all 全量，发布时用 --limit 先放 1 台验证，再逐步放量。命令行 --limit 的优先级高于 Playbook 里 hosts: 的定义。

在 Playbook 中使用

- name: 重启 webservers
  hosts: webservers        # 这里就是模式
  become: true
  tasks:
    - name: 重启服务
      service:
        name: nginx
        state: restarted

4.5 验证主机选择

执行前可用 --list-hosts 确认模式匹配到的主机，避免误操作：

# 看某个模式会匹配哪些主机（不加 -m，只列清单）
ansible -i inventory.ini --list-hosts all
ansible -i inventory.ini --list-hosts webservers
ansible -i inventory.ini --list-hosts 'webservers:!node2'

强烈建议先 --list-hosts 确认模式匹配对了，再真正执行——尤其是带 !（排除）、&（交集）的复杂模式，手滑一次就可能管到不想管的主机。

五、跑通第一条命令：ad-hoc 与提权

SSH 连通后，Ansible 最直接的能力是 ad-hoc 命令——不写任何文件，用一条命令对一批机器执行单个操作。这是 Playbook 之前最基础的使用方式，也是理解其工作原理的起点。

5.1 ad-hoc 是什么

ad-hoc 指直接执行单条 Ansible 命令，不需要写 Playbook（剧本）。适合快速操作、测试连通性、临时改点东西。一条 ad-hoc 命令 = 选定主机 + 选一个模块 + 传参数。

5.2 语法与第一个 ping

语法骨架是：

ansible <主机模式> -i <清单> -m <模块> -a <模块参数>

最经典的测试命令是 ping（注意这不是网络 ICMP ping，而是「检测 Ansible 能不能连上被管端并执行」的连通性测试，返回 pong 即成功）：

# 对清单内所有机器执行 ping
ansible -i inventory.ini all -m ping

第一次先拿 localhost 试（不用清单就能用）：

ansible localhost -m ping

看到被管端返回 "pong" 就说明 Ansible 已经能在目标机器上执行了。到这一步，「装好 + 连上 + 能执行」这条链路就通了。

5.3 常用 ad-hoc 示例

以下为日常常用的 ad-hoc 操作（沿用上一章配置的 inventory.ini）：

# 执行任意命令
ansible -i inventory.ini all -m command -a 'uptime'
ansible -i inventory.ini all -m shell -a 'df -h | grep /$'

# 复制文件
ansible -i inventory.ini all -m copy -a 'src=/tmp/app.conf dest=/etc/app.conf'

# 管理服务（需提权）
ansible -i inventory.ini all -m service -a 'name=sshd state=restarted' -b

# 安装软件（需提权）
ansible -i inventory.ini all -m dnf -a 'name=httpd state=present' -b

几个模块的直觉理解：

command：执行一条命令（不支持管道、重定向等 shell 特性，最直接）；
shell：用被管端的 shell 执行，支持管道/重定向；
copy：把控制端本地的文件复制到被管端；
service / dnf / apt：管理服务、装软件。

5.4 提权：-b / --become

很多操作（装软件、改系统配置）需要 root。Ansible 默认以登录用户执行，用 -b（--become） 提权到 root（类似 sudo）：

ansible -i inventory.ini all -m dnf -a 'name=git state=present' -b
ansible -i inventory.ini all -m dnf -a 'name=git state=present' --become
ansible -i inventory.ini all -m dnf -a 'name=git state=present' -b -K   # -K 提示输入 sudo 密码

ad-hoc 适合临时、单步操作；多步、可复用、带逻辑的自动化应写成 Playbook。

六、ansible.cfg：让命令更省事

每次执行都要写 -i inventory.ini 较为繁琐。ansible.cfg 用于解决这一问题——它是 Ansible 的主配置文件，设定默认 inventory、并行数、提权方式、角色搜索路径等。不配置虽可使用，但会反复遇到「每次都要 -i 指定清单」「默认并行太少」等问题。

6.1 为什么需要它

把常用设置（默认清单、并行数、提权方式）写进配置文件后，命令就能写得更短、更不容易出错。它相当于 Ansible 的「环境偏好设置」。

6.2 查找优先级

Ansible 会按固定优先级从上到下查找 ansible.cfg（找到即停）：

环境变量 ANSIBLE_CONFIG（最高）；
当前目录下的 ansible.cfg；
用户家目录 ~/.ansible.cfg；
系统级 /etc/ansible/ansible.cfg（最低）。

实际运维中最常用的是**「当前目录下的 ansible.cfg」**——把配置文件与 inventory、Playbook 放在同一项目目录，随项目走、团队共享方便。

6.3 一个实用的入门配置

在项目目录下新建 ansible.cfg：

[defaults]
inventory = ./inventory.ini      # 默认清单，之后可省略 -i
forks = 10                       # 同时并行的主机数（默认 5）
host_key_checking = False        # 首次连接不校验 known_hosts（内网测试方便）
retry_files_enabled = False      # 不生成 .retry 重试文件
deprecation_warnings = False     # 关闭弃用告警

[privilege_escalation]
become = True                    # 默认提权
become_method = sudo             # 提权方式

关键项解释：

inventory：设了默认清单，之后 ansible-playbook playbook.yml 就不用再写 -i；
forks：同时并发管理的主机数，调大加速大批量部署，但更耗控制端资源；
host_key_checking = False：跳过 SSH 首次连接的指纹确认，内网测试方便；生产建议保留校验或用 known_hosts；
[privilege_escalation]：统一默认提权，但为了让 Playbook 自解释，正文示例仍会显式写 become。

用命令生成默认配置模板或验证当前生效配置：

# 生成一份"注释掉所有项"的默认配置模板
ansible-config init --disabled > ansible.cfg

# 查看最终生效的配置
ansible-config view
ansible-config dump | grep -E "INVENTORY|FORKS"

新版本可能不会自动生成 /etc/ansible 目录，需要时可自己 mkdir -p /etc/ansible 再 ansible-config init --disabled > /etc/ansible/ansible.cfg。

七、四大核心概念：全景认识

至此已完成安装、连接、Inventory 编写、ad-hoc 执行与 ansible.cfg 配置。

7.1 模块 / Inventory / Playbook / Roles

概念	是什么	类比	上文位置
模块（Module）	Ansible 执行的最小单元，封装了幂等的操作（copy 复制文件、service 管理服务…）	一个个「螺丝刀头」	第五章 ad-hoc 里的 `-m dnf`、`-m service`
Inventory（清单）	被管端主机与分组的列表，定义「管哪些机器」	花名册	第四章的 `inventory.ini`
Playbook（剧本）	用 YAML 写的一整套任务编排	工序流程图	第五章 ad-hoc 之外，多步任务编排的核心载体
Roles（角色）	把 Playbook 按功能拆成可复用的目录结构	预制模块化零件	将 Playbook 按功能模块化拆分

这四个概念贯穿整个系列。其关系为：Inventory 界定目标，模块定义操作，Playbook 串联多步，Roles 将 Playbook 拆为可复用的零件。

Ansible 是典型的 控制端 / 被管端 架构：控制端（安装 Ansible 的机器）保存 Inventory、Playbook，负责下发任务；被管端（被管理的目标机器）无需安装 Ansible，只需 SSH + Python。Ansible 通过 SSH 将模块推送到被管端，执行完即清理，并把结果返回控制端。被管端无需代理（agentless）是最关键的特性——省去在被管端安装、维护代理的负担；不开放额外端口、不跑额外服务，攻击面更小、更安全。

7.2 控制端如何执行一个任务

Ansible 在被管端执行任务的过程大致是：

通过 Inventory 确定要管哪些主机；
通过 Playbook / ad-hoc 确定要执行什么任务（用哪个模块）；
通过连接插件（默认 SSH）把「模块 + 参数」推送到被管端；
在被管端执行模块，执行完删除临时文件，把结果返回控制端。

Ansible 走的是 Push（推） 模式——控制端主动推送，即时生效；而 Puppet/Chef 走 Pull（被管端周期性拉取）并通常需要安装代理。Push 模式特别适合「现在、立刻、对所有机器做同一件事」——批量改配置、批量部署、批量重启，这也是日常运维里用得最多的场景。

八、总结

8.1 本篇要点回顾

为什么用：解决多机重复劳动、易错、配置漂移；Ansible 靠「简单（YAML）+ 无代理 + SSH + Push」成为最流行的自动化工具。
是什么：核心引擎 ansible-core + 完整包 ansible（预装一堆集合）；学习推荐装完整版。
安装：只装控制端；RHEL 系用 dnf+EPEL，Debian 系用 apt，追新用 pip(venv)；EL10 只有 ansible-core；容器/离线是备选方案。
连接：默认 SSH，配好密钥免密；localhost 用 local 连接。先「连上」再「跑命令」。
Inventory 与模式匹配：all/组/!排除/&交集/~正则/--limit——选主机的核心技能；先 --list-hosts 验证。
ad-hoc：ansible 模式 -m 模块 -a 参数 一条命令干一件事；-b 提权。
ansible.cfg：主配置，有固定查找优先级，配好 inventory/forks 少踩坑。
四大概念：模块（怎么做）、Inventory（去哪）、Playbook（串多步）、Roles（拆复用）。

8.2 下一步

至此可完成：安装 Ansible、连接机器、编写 Inventory、用 ad-hoc 批量执行单条操作、配置 ansible.cfg。但 ad-hoc 仅适合「单条命令」——复杂的多步自动化需要写成 Playbook。多步自动化与配置管理将在《Ansible Playbook 详解》中展开。

参考资料

Ansible 官方文档（Getting Started）：https://docs.ansible.com/ansible/latest/getting_started/index.html
Ansible 安装指引：https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html
Ansible Inventory 指南：https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html
Ansible Patterns（主机模式匹配）：https://docs.ansible.com/ansible/latest/inventory_guide/intro_patterns.html
Ansible Connection Plugins：https://docs.ansible.com/ansible/latest/collections/ansible/builtin/ssh_connection.html
Red Hat Bugzilla 2387001（EPEL10 无完整 ansible 包的官方确认）：https://bugzilla.redhat.com/show_bug.cgi?id=2387001
ansible-core 最新版本：https://github.com/ansible/ansible/releases

Hello,LinyuX!