当服务器数量从 1 台变成 10 台、100 台甚至更多时，依靠 SSH 登录服务器逐台执行命令会越来越低效，也容易产生环境差异。

Ansible 通过 Inventory 管理目标主机，通过 Playbook 描述目标状态，再利用 Modules、Variables、Templates、Handlers 和 Roles 将运维操作自动化。

Ansible 的核心不是“远程执行命令”，而是把基础设施的配置和运维操作变成可以重复执行的代码。

一、Ansible 概述#

1.1 什么是 Ansible#

Ansible 是一种 IT 自动化工具，可以用于：

1
配置管理
2
应用部署
3
批量执行任务
4
服务器初始化
5
服务管理
6
系统维护
7
网络设备自动化

例如现在有：

1
web01
2
web02
3
web03
4
web04

手工执行：

1
ssh web01
2
ssh web02
3
ssh web03
4
ssh web04

然后重复：

1
apt update
2
apt install nginx
3
systemctl enable nginx
4
systemctl start nginx

机器越多，重复劳动越严重。

Ansible 的目标则是：

1
Inventory
2
    │
3
    ▼
4
Ansible
5
    │
6
    ├── web01
7
    ├── web02
8
    ├── web03
9
    └── web04

执行一次：

1
ansible-playbook deploy.yml

就可以批量完成任务。

Ansible 官方： Ansible Introduction

1.2 Ansible 的核心特点#

Ansible 的几个核心特点：

1
Agentless
2
YAML
3
Idempotent
4
Declarative

Agentless#

Ansible 通常不要求在被管理主机上额外安装 Ansible Agent。

典型 Linux 环境：

1
Control Node
2
    │
3
    │ SSH
4
    ├────────► Managed Node 1
5
    ├────────► Managed Node 2
6
    └────────► Managed Node 3

Ansible 官方文档明确说明，Managed Node 一般不需要安装 Ansible 本身，而 Control Node 运行 Ansible 并通过 SSH 等方式管理远程节点。

YAML#

Playbook 使用 YAML 编写：

1
- hosts: web
2
  tasks:
3
    - name: Install nginx
4
      ansible.builtin.apt:
5
        name: nginx
6
        state: present

相比：

1
Shell Script

Playbook 更强调：

1
我要系统达到什么状态

Idempotent#

幂等性是 Ansible 非常重要的设计思想。

例如：

1
state: present

意味着：

1
“确保 nginx 存在”

如果已经安装：

1
不需要重复安装

如果没有安装：

1
执行安装

所以：

1
第一次执行
2
→ Changed
3

4
第二次执行
5
→ 通常不会再产生变化

Ansible 官方也将 idempotence 和 predictability 作为核心设计原则。

二、Ansible 架构#

2.1 Control Node#

Control Node 是运行 Ansible 的机器。

例如：

1
管理服务器
2
      │
3
      └── Ansible

安装：

1
ansible --version

可以查看版本。

2.2 Managed Node#

Managed Node 是被管理的目标机器。

例如：

1
web01
2
web02
3
db01
4
redis01

Linux Managed Node 通常至少需要：

1
SSH
2
Python
3
用户权限

具体 Module 的要求可能有所不同。

2.3 Inventory#

Inventory 是 Ansible 的主机清单。

例如：

1
web01
2
web02
3
web03
4
db01
5
redis01

可以按角色组织：

1
web
2
├── web01
3
├── web02
4
└── web03
5

6
db
7
├── db01
8
└── db02
9

10
redis
11
└── redis01

Ansible 官方将 Inventory 定义为组织 Managed Nodes 的主机清单。

因此：

1
Control Node
2
      │
3
      ▼
4
  Inventory
5
      │
6
      ├── web
7
      ├── db
8
      └── redis

三、安装 Ansible#

3.1 使用 pip 安装#

在 Control Node 中，可以使用：

1
python3 -m pip install ansible

或者使用官方推荐的 Python 包管理方式之一，例如：

1
pipx install ansible

Ansible 官方当前提供 ansible 和 ansible-core 两种主要包形态：

1
ansible
2
→ 更完整的社区内容集合
3

4
ansible-core
5
→ 核心运行时和内置功能

具体安装方式和版本支持应以官方 Installation Guide 为准。

检查：

1
ansible --version

3.2 创建项目目录#

例如：

1
mkdir -p ~/ansible-demo
2
cd ~/ansible-demo

创建：

1
inventory
2
ansible.cfg
3
playbook.yml

最终：

1
ansible-demo/
2
├── ansible.cfg
3
├── inventory
4
└── playbook.yml

四、Inventory#

4.1 INI Inventory#

最简单：

1
[web]
2
web01 ansible_host=192.168.1.101
3
web02 ansible_host=192.168.1.102
4

5
[db]
6
db01 ansible_host=192.168.1.103

指定 SSH 用户：

1
[web]
2
web01 ansible_host=192.168.1.101 ansible_user=ubuntu
3
web02 ansible_host=192.168.1.102 ansible_user=ubuntu

4.2 YAML Inventory#

也可以使用 YAML：

1
all:
2
  children:
3

4
    web:
5
      hosts:
6
        web01:
7
          ansible_host: 192.168.1.101
8
        web02:
9
          ansible_host: 192.168.1.102
10

11
    db:
12
      hosts:
13
        db01:
14
          ansible_host: 192.168.1.103

Ansible 官方支持多种 Inventory 形式，并可以为 Host 或 Group 设置变量。

4.3 Group#

例如：

1
[web]
2
web01
3
web02
4
web03
5

6
[db]
7
db01
8
db02

可以：

1
ansible web -m ping

只对：

1
web

组执行。

4.4 Group of Groups#

还可以：

1
[frontend]
2
web01
3
web02
4

5
[backend]
6
app01
7
app02
8

9
[production:children]
10
frontend
11
backend

于是：

1
production
2
├── frontend
3
└── backend

执行：

1
ansible production -m ping

就可以管理整个生产环境。

五、ansible.cfg#

Ansible 可以通过配置文件统一管理默认行为。

例如：

1
[defaults]
2
inventory = ./inventory
3
host_key_checking = False
4
interpreter_python = auto_silent

这样就不需要每次都：

1
ansible -i inventory ...

查看当前配置：

1
ansible-config dump

也可以：

1
ansible-config list

需要注意：

1
host_key_checking = False

在学习环境中比较方便，但生产环境不应该无条件关闭 SSH 主机密钥验证。

六、Ansible Ad-hoc 命令#

6.1 什么是 Ad-hoc#

Ad-hoc Command 用于临时执行任务。

例如：

1
ansible all -m ping

意思是：

1
对 Inventory 中的所有主机执行 ping Module

官方文档将 ansible 命令和 Ad-hoc Commands 作为 Ansible 日常命令行操作的一部分。

6.2 ping Module#

：

1
ansible all -m ansible.builtin.ping

成功可能返回：

1
web01 | SUCCESS => {
2
    "changed": false,
3
    "ping": "pong"
4
}

这里：

1
SUCCESS
2
→ Ansible 能够正常管理目标主机
3

4
changed: false
5
→ 没有修改目标系统

注意：

1
Ansible ping

不是普通 ICMP：

1
ping 192.168.1.101

它主要用于验证 Ansible 与目标节点之间的管理通信和模块执行环境。

七、常见 Ad-hoc 操作#

7.1 查看主机#

1
ansible all -m ansible.builtin.command -a "hostname"

7.2 查看内存#

1
ansible all \
2
  -m ansible.builtin.command \
3
  -a "free -h"

7.3 查看磁盘#

1
ansible all \
2
  -m ansible.builtin.command \
3
  -a "df -h"

7.4 查看服务#

1
ansible web \
2
  -m ansible.builtin.command \
3
  -a "systemctl status nginx"

不过实际修改系统时，更推荐使用：

1
专用 Module

而不是到处执行：

1
Shell Command

因为 Module 通常能够更好地表达目标状态，并提供幂等行为。

八、Module#

8.1 什么是 Module#

Module 是 Ansible 用来执行具体工作的功能单元。

例如：

1
apt
2
dnf
3
service
4
systemd
5
file
6
copy
7
template
8
user
9
group
10
command
11
shell
12
package

可以理解为：

1
Playbook
2
   │
3
   ▼
4
 Module
5
   │
6
   ▼
7
Managed Node

例如：

1
- name: Install nginx
2
  ansible.builtin.apt:
3
    name: nginx
4
    state: present

这里：

1
apt
2
→ Module
3

4
name
5
state
6
→ Module 参数

8.2 ansible-doc#

查看 Module 文档：

1
ansible-doc ansible.builtin.apt

例如：

1
ansible-doc ansible.builtin.copy

这是非常实用的命令。

不要记住所有参数，更推荐：

1
ansible-doc <module>

需要什么就查什么。

九、Playbook#

9.1 什么是 Playbook#

Playbook 是 Ansible 自动化任务的主要描述形式。

典型结构：

1
Playbook
2
   │
3
   └── Play
4
        │
5
        └── Tasks
6
              │
7
              ├── Task 1
8
              ├── Task 2
9
              └── Task 3

Ansible 官方将 Play 定义为将目标主机映射到任务的执行上下文，Playbook 则由一个或多个 Play 组成。

9.2 第一个 Playbook#

1
---
2
- name: Install nginx
3
  hosts: web
4
  become: true
5

6
  tasks:
7
    - name: Install nginx
8
      ansible.builtin.apt:
9
        name: nginx
10
        state: present
11

12
    - name: Start nginx
13
      ansible.builtin.systemd:
14
        name: nginx
15
        state: started
16
        enabled: true

运行：

1
ansible-playbook playbook.yml

指定 Inventory：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml

9.3 Play 的主要组成#

一个 Play 常见：

1
- name: Web server
2
  hosts: web
3
  become: true
4

5
  vars:
6
    http_port: 80
7

8
  tasks:
9
    ...

核心部分：

1
name
2
hosts
3
vars
4
tasks
5
handlers
6
roles

十、Task#

Task 是一个具体操作。

例如：

1
tasks:
2

3
  - name: Install nginx
4
    ansible.builtin.apt:
5
      name: nginx
6
      state: present

每个 Task 通常具有：

1
name
2
module
3
module arguments

例如：

1
Task
2
 │
3
 └── apt
4
      ├── name
5
      └── state

10.1 Task 顺序#

默认情况下，Playbook 中的 Task 按照定义顺序执行：

1
Task 1
2
 ↓
3
Task 2
4
 ↓
5
Task 3
6
 ↓
7
Task 4

因此可以建立：

1
安装
2
 ↓
3
配置
4
 ↓
5
启动

这样的执行流程。

十一、变量 Variables#

11.1 为什么需要变量#

假设开发环境：

1
port = 8080

生产环境：

1
port = 80

如果把数字直接写死：

1
port: 8080

不同环境就需要修改 Playbook。

更好的方式：

1
http_port: 8080

然后：

1
port: "{{ http_port }}"

Ansible 官方支持在 Inventory、Playbook、Role、命令行等多处定义变量，并按照变量优先级规则处理。

11.2 Playbook 变量#

1
vars:
2
  app_name: myapp
3
  app_port: 8080

引用：

1
- name: Show app port
2
  ansible.builtin.debug:
3
    msg: "Application port is {{ app_port }}"

11.3 Inventory 变量#

例如：

1
[web]
2
web01 ansible_host=192.168.1.101
3
web02 ansible_host=192.168.1.102

也可以进一步设置：

1
group_vars/
2
host_vars/

组织变量。

11.4 Extra Vars#

运行时传入：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml \
4
  -e "app_port=8080"

Extra Vars 具有很高的变量优先级。

十二、Facts#

12.1 什么是 Facts#

Ansible 可以自动收集远程主机的信息。

例如：

1
操作系统
2
IP 地址
3
CPU
4
内存
5
磁盘
6
文件系统
7
主机名

这些数据称为：

1
Facts

Ansible 官方文档将远程系统信息称为 Facts，并通过 setup Module 收集。

查看：

1
ansible web \
2
  -m ansible.builtin.setup

12.2 使用 Facts#

例如根据操作系统执行不同任务：

1
- name: Install package
2
  ansible.builtin.package:
3
    name: nginx
4
    state: present

也可以访问：

1
ansible_facts

例如：

1
- name: Show OS
2
  ansible.builtin.debug:
3
    var: ansible_facts.distribution

这让 Playbook 能够根据目标机器的实际环境动态执行。

十三、Conditionals#

13.1 when#

有时任务只应该在特定条件下执行。

例如：

1
- name: Install nginx on Debian
2
  ansible.builtin.apt:
3
    name: nginx
4
    state: present
5
  when: ansible_facts.distribution in ["Ubuntu", "Debian"]

Red Hat 系：

1
- name: Install nginx on RedHat
2
  ansible.builtin.dnf:
3
    name: nginx
4
    state: present
5
  when: ansible_facts.os_family == "RedHat"

于是：

1
Ubuntu
2
 → apt
3

4
RHEL / Fedora
5
 → dnf

13.2 Condition 的意义#

这使一个 Playbook 能适应：

1
多个发行版
2
多个环境
3
多个节点类型

而不是：

1
一台机器一个脚本

十四、Loops#

14.1 基本循环#

例如安装多个软件包：

1
- name: Install packages
2
  ansible.builtin.apt:
3
    name: "{{ item }}"
4
    state: present
5
  loop:
6
    - curl
7
    - vim
8
    - git

逻辑：

1
item = curl
2
item = vim
3
item = git

14.2 为什么需要循环#

如果没有 loop：

1
- apt:
2
    name: curl
3

4
- apt:
5
    name: vim
6

7
- apt:
8
    name: git

重复内容很多。

使用：

1
loop:

更简洁。

十五、常用 Module#

15.1 package / apt / dnf#

跨发行版时：

1
ansible.builtin.package:
2
  name: nginx
3
  state: present

Debian / Ubuntu：

1
ansible.builtin.apt:

RHEL / Fedora：

1
ansible.builtin.dnf:

15.2 service / systemd#

例如：

1
- name: Start nginx
2
  ansible.builtin.systemd:
3
    name: nginx
4
    state: started
5
    enabled: true

对应：

1
systemctl start nginx
2
systemctl enable nginx

15.3 file#

创建目录：

1
- name: Create application directory
2
  ansible.builtin.file:
3
    path: /opt/myapp
4
    state: directory
5
    owner: root
6
    group: root
7
    mode: "0755"

15.4 copy#

复制文件：

1
- name: Copy config
2
  ansible.builtin.copy:
3
    src: files/app.conf
4
    dest: /etc/myapp/app.conf
5
    mode: "0644"

15.5 user#

创建用户：

1
- name: Create deploy user
2
  ansible.builtin.user:
3
    name: deploy
4
    shell: /bin/bash
5
    create_home: true

十六、Template 与 Jinja2#

16.1 为什么需要 Template#

如果配置文件中存在：

1
端口
2
域名
3
IP
4
路径
5
环境

直接复制固定文件并不灵活。

例如：

1
dev
2
→ port=8080
3

4
prod
5
→ port=80

可以使用：

1
Jinja2 Template

16.2 模板#

例如：

1
templates/nginx.conf.j2

内容：

1
server {
2
    listen {{ http_port }};
3

4
    server_name {{ server_name }};
5

6
    location / {
7
        proxy_pass http://{{ backend_host }}:{{ backend_port }};
8
    }
9
}

Playbook：

1
- name: Deploy nginx config
2
  ansible.builtin.template:
3
    src: nginx.conf.j2
4
    dest: /etc/nginx/conf.d/app.conf
5
    mode: "0644"

最终不同机器可能生成：

1
server01
2
listen 80;
3

4
server02
5
listen 8080;

因为变量不同。

16.3 Template 的核心#

可以理解成：

1
Template
2
   +
3
Variables
4
   │
5
   ▼
6
Rendered Config

Ansible 官方也支持在模板中使用 Jinja2 语法处理变量、循环和条件。

十七、Handlers#

17.1 为什么需要 Handler#

假设修改了：

1
nginx.conf

修改后才需要：

1
systemctl reload nginx

如果配置没有发生变化：

1
不需要 reload

这就是 Handler 的用途。

1
tasks:
2

3
  - name: Deploy nginx config
4
    ansible.builtin.template:
5
      src: nginx.conf.j2
6
      dest: /etc/nginx/conf.d/app.conf
7
    notify:
8
      - Reload nginx
9

10
handlers:
11

12
  - name: Reload nginx
13
    ansible.builtin.systemd:
14
      name: nginx
15
      state: reloaded

逻辑：

1
Template changed
2
      │
3
      ▼
4
notify
5
      │
6
      ▼
7
Handler
8
      │
9
      ▼
10
Reload nginx

如果文件：

1
没有变化

则：

1
Handler 不执行

这也是幂等性的重要体现。

十八、Become 与权限提升#

很多运维操作需要 root：

1
安装软件
2
修改 /etc
3
管理 systemd
4
创建系统用户

Ansible 常用：

1
become: true

例如：

1
- hosts: web
2
  become: true
3

4
  tasks:
5
    - name: Install nginx
6
      ansible.builtin.apt:
7
        name: nginx
8
        state: present

运行时也可以：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml \
4
  -b

这里：

1
-b
2
→ become

通常最终通过：

1
sudo

等方式获得目标权限。

因此：

1
SSH User
2
   │
3
   ▼
4
Become / sudo
5
   │
6
   ▼
7
Root-level Task

十九、Command 与 Shell#

19.1 command#

执行命令：

1
- name: Check hostname
2
  ansible.builtin.command:
3
    cmd: hostname

19.2 shell#

需要 Shell 特性时：

1
- name: Check logs
2
  ansible.builtin.shell:
3
    cmd: "journalctl -u nginx | tail -n 20"

但应该注意：

能使用专用 Module 时，优先使用 Module，而不是把所有操作都写成 Shell。

例如：

不要：

1
ansible.builtin.shell:
2
  cmd: "systemctl start nginx"

更推荐：

1
ansible.builtin.systemd:
2
  name: nginx
3
  state: started

因为：

1
systemd Module
2
→ 表达目标状态
3

4
shell systemctl
5
→ 只是执行命令

后者更难保证幂等性。

二十、Check Mode 与 Diff#

20.1 Check Mode#

运行：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml \
4
  --check

可以在尽可能不修改目标系统的情况下，预览哪些任务可能产生变化。

这对于生产环境非常有价值：

1
修改之前
2
 ↓
3
--check
4
 ↓
5
确认变化
6
 ↓
7
正式执行

20.2 Diff#

对于部分文件修改操作，可以：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml \
4
  --diff

查看配置变化。

例如：

1
old config
2
     ↓
3
new config

这样比直接修改生产配置更安全。

二十一、Ansible Playbook 的幂等性#

考虑：

1
- name: Ensure nginx installed
2
  ansible.builtin.apt:
3
    name: nginx
4
    state: present

第一次：

1
changed = true

第二次：

1
changed = false

因为：

1
目标状态已经满足

这就是：

1
Idempotency

21.1 为什么幂等性重要#

假设：

1
100 台服务器

需要反复执行：

1
安装
2
配置
3
更新

如果脚本每次都会：

1
重复修改
2
重复创建
3
重复启动

就很危险。

而幂等自动化强调：

1
Desired State
2
      │
3
      ▼
4
当前状态检查
5
      │
6
      ├── 已满足 → 不修改
7
      │
8
      └── 未满足 → 修改

因此 Playbook 可以安全地反复执行。

二十二、Roles#

22.1 为什么需要 Role#

一个大型 Playbook 很容易越来越长：

1
install
2
configure
3
deploy
4
firewall
5
monitor
6
backup
7
...

全部写在：

1
playbook.yml

会越来越难维护。

于是可以拆成：

1
Role

22.2 Role 目录#

典型结构：

1
roles/
2
└── nginx/
3
    ├── tasks/
4
    │   └── main.yml
5
    ├── handlers/
6
    │   └── main.yml
7
    ├── templates/
8
    ├── files/
9
    ├── vars/
10
    ├── defaults/
11
    ├── meta/
12
    └── README.md

Ansible 官方将 Role 定义为用于复用 Tasks、Handlers、Variables、Templates、Files 等自动化内容的一种组织方式。

22.3 使用 Role#

Playbook：

1
- name: Deploy web server
2
  hosts: web
3
  become: true
4

5
  roles:
6
    - nginx

于是：

1
Playbook
2
   │
3
   ▼
4
 nginx Role
5
   │
6
   ├── Tasks
7
   ├── Handlers
8
   ├── Templates
9
   └── Variables

22.4 Role 的价值#

Role 的本质是：

1
复用
2
组织
3
抽象

例如：

1
nginx-role
2
mysql-role
3
redis-role
4
docker-role
5
node-exporter-role

以后换一批服务器：

1
重新执行 Role

就可以快速完成环境部署。

二十三、Ansible Vault#

自动化配置中经常需要：

1
密码
2
Token
3
SSH Key
4
数据库凭证

不应该直接写在 Git 仓库的普通 YAML 中：

1
db_password: "123456"

Ansible 提供：

1
ansible-vault

用于加密敏感数据。

创建：

1
ansible-vault create secrets.yml

编辑：

1
ansible-vault edit secrets.yml

运行 Playbook：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml \
4
  --ask-vault-pass

这样：

1
Git
2
 ↓
3
加密文件
4
 ↓
5
Ansible Vault

而不是：

1
Git
2
 ↓
3
明文密码

二十四、Ansible Galaxy 与 Collections#

Ansible 自动化内容不一定全部自己编写。

还可以使用：

1
Collections
2
Roles

通过：

1
ansible-galaxy

管理。

例如：

1
ansible-galaxy collection install community.general

查看：

1
ansible-galaxy collection list

当前 Ansible 生态大量功能已经通过 Collections 组织。

因此：

1
ansible-core
2
      │
3
      ├── Built-in Modules
4
      │
5
      └── Collections
6
             │
7
             ├── community.general
8
             ├── vendor collections
9
             └── ...

二十五、一个完整的 Web 服务 Playbook#

现在把前面的知识组合起来。

1
ansible-demo/
2
├── inventory
3
├── playbook.yml
4
└── templates/
5
    └── nginx.conf.j2

Inventory：

1
[web]
2
web01 ansible_host=192.168.1.101
3
web02 ansible_host=192.168.1.102

Playbook：

1
---
2
- name: Deploy web server
3
  hosts: web
4
  become: true
5

6
  vars:
7
    http_port: 8080
8
    server_name: example.local
9

10
  tasks:
11

12
    - name: Install nginx
13
      ansible.builtin.package:
14
        name: nginx
15
        state: present
16

17
    - name: Deploy nginx config
18
      ansible.builtin.template:
19
        src: nginx.conf.j2
20
        dest: /etc/nginx/conf.d/app.conf
21
        mode: "0644"
22
      notify:
23
        - Reload nginx
24

25
    - name: Ensure nginx is running
26
      ansible.builtin.systemd:
27
        name: nginx
28
        state: started
29
        enabled: true
30

31
  handlers:
32

33
    - name: Reload nginx
34
      ansible.builtin.systemd:
35
        name: nginx
36
        state: reloaded

模板：

1
server {
2
    listen {{ http_port }};
3

4
    server_name {{ server_name }};
5

6
    location / {
7
        return 200 "Hello from {{ inventory_hostname }}\n";
8
    }
9
}

执行：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml

最终：

1
Control Node
2
     │
3
     ▼
4
Inventory
5
     │
6
     ▼
7
Playbook
8
     │
9
     ├── Install nginx
10
     ├── Render Template
11
     ├── Start nginx
12
     └── Handler
13
           │
14
           ▼
15
       Managed Nodes

二十六、Ansible 执行过程#

理解 Ansible 时，可以把一次 Playbook 执行抽象为：

1
ansible-playbook
2
        │
3
        ▼
4
    Inventory
5
        │
6
        ▼
7
      Hosts
8
        │
9
        ▼
10
      Facts
11
        │
12
        ▼
13
       Tasks
14
        │
15
        ▼
16
      Modules
17
        │
18
        ▼
19
   Managed Nodes
20
        │
21
        ▼
22
Desired State

例如：

1
“nginx 必须安装并运行”

Ansible 会检查：

1
当前状态

再决定：

1
需要修改
2
还是
3
已经满足

因此它不是简单的：

1
SSH
2
+
3
Shell Script

而是：

1
Desired State
2
+
3
State Reconciliation

二十七、Ansible 常见故障排查#

自动化工具本身也会出问题。

排查时建议按照：

1
Inventory
2
 ↓
3
Network
4
 ↓
5
SSH
6
 ↓
7
Privilege
8
 ↓
9
Module
10
 ↓
11
Variable
12
 ↓
13
Task
14
 ↓
15
Managed Service

逐层定位。

二十八、Inventory 故障#

例如：

1
ansible web -m ping

1
No hosts matched

先检查：

1
ansible-inventory \
2
  -i inventory \
3
  --graph

查看：

1
web
2
├── web01
3
└── web02

再：

1
ansible-inventory \
2
  -i inventory \
3
  --list

确认 Inventory 是否被正确解析。

二十九、SSH 故障#

如果：

1
UNREACHABLE

首先从 SSH 入手：

1
ssh user@192.168.1.101

检查：

1
IP
2
端口
3
用户名
4
SSH Key
5
密码
6
Known Hosts
7
防火墙

如果手工 SSH 都连接不上：

1
Ansible 通常也不可能正常工作

因此：

1
Ansible 问题

有时候根本不是 Ansible 本身的问题，而是：

1
基础网络 / SSH

29.1 指定 SSH Key#

Inventory：

1
[web]
2
web01 ansible_host=192.168.1.101 \
3
      ansible_user=ubuntu \
4
      ansible_ssh_private_key_file=~/.ssh/id_ed25519

也可以命令行：

1
ansible web \
2
  -m ping \
3
  --private-key ~/.ssh/id_ed25519

三十、权限问题#

如果出现：

1
Permission denied

检查：

1
SSH User
2
sudo
3
become

例如：

1
become: true

还要确认：

1
用户是否可以 sudo
2
是否需要密码
3
sudo 配置是否允许

运行：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml \
4
  -K

可以提示输入 Become 密码。

三十一、Module 故障#

如果：

1
Module failed

可以：

1
ansible-doc <module>

检查参数。

也可以增加详细输出：

1
ansible-playbook \
2
  -i inventory \
3
  playbook.yml \
4
  -vvv

-vvv 会输出更详细的执行信息。

对于进一步排查：

1
Module 参数
2
Python
3
权限
4
目标系统
5
模块兼容性

都需要考虑。

三十二、变量问题#

如果出现：

1
'xxx' is undefined

检查：

1
变量名称
2
变量作用域
3
Inventory
4
group_vars
5
host_vars
6
Role
7
Extra Vars

可以使用：

1
- name: Debug variable
2
  ansible.builtin.debug:
3
    var: app_port

帮助确认变量实际值。

32.1 变量优先级#

Ansible 存在复杂的变量优先级体系。

初学阶段不需要背完整优先级表，但应该知道：

1
同一个变量
2
在不同位置重复定义

最终只会有一个值真正生效。

因此大型项目中最好：

1
明确变量来源
2
避免重复定义

官方变量文档提供了完整的变量优先级规则。

三十三、Playbook 调试#

33.1 Verbosity#

1
ansible-playbook -v playbook.yml

更详细：

1
ansible-playbook -vvv playbook.yml

可以看到：

1
连接
2
模块
3
参数
4
执行结果

33.2 Debug Module#

例如：

1
- name: Debug hostname
2
  ansible.builtin.debug:
3
    var: inventory_hostname

或者：

1
- name: Debug message
2
  ansible.builtin.debug:
3
    msg: "Port is {{ http_port }}"

这在排查：

1
变量
2
条件
3
Facts

时非常有用。

三十四、Ansible 运维自动化的典型应用#

Ansible 可以覆盖大量运维任务：

1
服务器初始化
2
软件安装
3
用户管理
4
SSH 配置
5
Nginx 部署
6
数据库部署
7
Docker 部署
8
Kubernetes 节点初始化
9
日志配置
10
监控 Agent 部署
11
防火墙配置
12
定时任务
13
应用发布

例如：

1
新服务器上线
2
      │
3
      ▼
4
Ansible
5
      │
6
      ├── 创建用户
7
      ├── 配置 SSH
8
      ├── 配置时区
9
      ├── 安装 Docker
10
      ├── 安装 node_exporter
11
      ├── 配置 Nginx
12
      └── 加入监控

原本可能需要：

1
30 分钟

自动化之后可以变成：

1
ansible-playbook bootstrap.yml

三十五、Ansible 与 Docker / Kubernetes#

前面已经学习：

1
Docker
2
Kubernetes

Ansible 则可以站在更高层做自动化。

例如：

1
Ansible
2
    │
3
    ├── 安装 Docker
4
    ├── 配置 Docker
5
    ├── 部署 Compose
6
    │
7
    └── 准备 Kubernetes Node
8
              │
9
              ├── containerd
10
              ├── kubeadm
11
              ├── kubelet
12
              └── 网络配置

因此：

1
Docker
2
→ 容器运行
3

4
Kubernetes
5
→ 容器编排
6

7
Ansible
8
→ 自动化配置和部署

三者解决的问题不同。

三十六、Ansible 与 CI/CD#

Ansible 还可以被 CI/CD 调用：

1
Git Push
2
   │
3
   ▼
4
CI Pipeline
5
   │
6
   ▼
7
Build
8
   │
9
   ▼
10
Docker Image
11
   │
12
   ▼
13
Ansible
14
   │
15
   ▼
16
Server

例如：

1
GitHub Actions
2
      │
3
      ▼
4
ansible-playbook deploy.yml
5
      │
6
      ▼
7
Production Server

这样就可以形成：

1
代码提交
2
 ↓
3
自动测试
4
 ↓
5
构建镜像
6
 ↓
7
自动部署

Ansible 可以作为发布流程中的一个执行步骤，具体编排取决于现有流水线。

三十七、Ansible 项目推荐目录#

小型项目：

1
ansible/
2
├── ansible.cfg
3
├── inventory
4
└── site.yml

稍大的项目：

1
ansible/
2
├── ansible.cfg
3
├── inventory/
4
│   ├── production
5
│   └── development
6
├── group_vars/
7
├── host_vars/
8
├── playbooks/
9
│   ├── site.yml
10
│   ├── web.yml
11
│   └── db.yml
12
├── roles/
13
│   ├── nginx/
14
│   ├── docker/
15
│   └── node_exporter/
16
└── requirements.yml

这样能够把：

1
主机
2
变量
3
Playbook
4
Role
5
依赖

分别组织起来。

Ansible 官方也提供了按功能组织 Inventory、Playbook、Roles、Variables、Files 等内容的示例项目结构。

三十八、从手工运维到自动化运维#

传统方式：

1
服务器 1
2
   ↓
3
SSH
4
   ↓
5
手工操作
6

7
服务器 2
8
   ↓
9
SSH
10
   ↓
11
手工操作
12

13
服务器 3
14
   ↓
15
SSH
16
   ↓
17
手工操作

容易出现：

1
人为失误
2
环境不一致
3
配置漂移
4
重复劳动
5
难以审计

Ansible：

1
              Playbook
2
                  │
3
                  ▼
4
              Inventory
5
                  │
6
      ┌───────────┼───────────┐
7
      ▼           ▼           ▼
8
    Server 1    Server 2    Server 3
9
      │           │           │
10
      └───────────┼───────────┘
11
                  ▼
12
           Desired State

于是：

1
同一份配置
2
→ 多台机器
3
→ 重复执行
4
→ 保持一致

三十九、Ansible 核心模型#

学习到这里，可以把 Ansible 浓缩成：

1
                    Ansible
2
                       │
3
              ┌────────┴────────┐
4
              ▼                 ▼
5
          Control Node       Inventory
6
              │                 │
7
              └────────┬────────┘
8
                       ▼
9
                    Playbook
10
                       │
11
            ┌──────────┼──────────┐
12
            ▼          ▼          ▼
13
          Tasks      Variables   Templates
14
            │                     │
15
            ▼                     ▼
16
         Modules                Config
17
            │
18
            ▼
19
       Managed Nodes
20
            │
21
            ▼
22
      Desired State

Role 再提供：

1
复用与组织

Vault 提供：

1
敏感变量保护

Check Mode 提供：

1
执行前验证

Handlers 提供：

1
变更后的条件化操作

四十、Ansible 故障排查总模型#

最终可以形成一套固定排查顺序：

1
                Playbook 执行失败
2
                        │
3
                        ▼
4
                  Inventory 正确吗？
5
                        │
6
                        ▼
7
                   Host 能解析吗？
8
                        │
9
                        ▼
10
                    SSH 能连接吗？
11
                        │
12
                        ▼
13
                   权限是否足够？
14
                        │
15
                        ▼
16
                    Module 正确吗？
17
                        │
18
                        ▼
19
                   Variables 正确吗？
20
                        │
21
                        ▼
22
                    Task 失败原因
23
                        │
24
                        ▼
25
                   服务本身正常吗？

常用命令：

1
# 查看版本
2
ansible --version
3

4
# 检查 Inventory
5
ansible-inventory -i inventory --graph
6

7
# 测试连接
8
ansible all -m ansible.builtin.ping
9

10
# 查看 Module
11
ansible-doc ansible.builtin.apt
12

13
# 执行 Playbook
14
ansible-playbook -i inventory playbook.yml
15

16
# 检查模式
17
ansible-playbook -i inventory playbook.yml --check
18

19
# 查看配置变化
20
ansible-playbook -i inventory playbook.yml --diff
21

22
# 更详细日志
23
ansible-playbook -i inventory playbook.yml -vvv

四十一、总结#

Ansible 的核心知识可以整理成：

1
Inventory
2
→ 管理哪些机器
3

4
Playbook
5
→ 要做什么
6

7
Task
8
→ 一个具体步骤
9

10
Module
11
→ 用什么方式完成
12

13
Variable
14
→ 不同机器有什么差异
15

16
Facts
17
→ 机器当前是什么状态
18

19
Template
20
→ 根据变量生成配置
21

22
Handler
23
→ 配置变化后执行什么
24

25
Role
26
→ 如何复用和组织自动化内容
27

28
Vault
29
→ 如何保存敏感数据
30

31
Become
32
→ 如何执行需要高权限的操作
33

34
Check Mode
35
→ 执行之前如何检查

完整执行链：

1
Inventory
2
    │
3
    ▼
4
Playbook
5
    │
6
    ▼
7
Tasks
8
    │
9
    ├── Variables
10
    ├── Facts
11
    ├── Conditions
12
    ├── Loops
13
    ├── Templates
14
    └── Handlers
15
    │
16
    ▼
17
Modules
18
    │
19
    ▼
20
Managed Nodes
21
    │
22
    ▼
23
Desired State

最终可以用一句话理解 Ansible：

Ansible 把原本需要运维人员逐台 SSH 登录执行的重复操作，转换成可以批量执行、重复运行和版本管理的自动化配置。

而从运维视角看，它真正重要的价值是：

1
少手工
2
少错误
3
保持一致
4
可重复
5
可审计
6
可扩展

当服务器只有一台时：

1
Ansible

看起来可能有些“重”。

但当环境变成：

甚至需要：

1
Docker
2
Kubernetes
3
监控
4
日志
5
应用发布

一起维护时，自动化就会逐渐从：

1
“方便的工具”

变成：

1
“基础设施管理的一部分”