4、Inventory详解：静态Inventory的编写（主机组、变量、嵌套组）、动态Inventory的获取方式与使用场景

Inventory（主机清单）是Ansible的“通讯录”，它定义了Ansible管理哪些主机、如何连接这些主机、以及这些主机归属于哪些逻辑分组。无论是执行一条临时命令（ad-hoc）还是运行一个Playbook，Ansible都必须先读取Inventory来确定目标节点。理解Inventory的静态编写与动态获取机制，是掌握Ansible批量管理的基础，也是从“单机操作”走向“基础设施即代码”的关键一步。本章将深入剖析静态Inventory的语法细节、变量组织方式，并探讨动态Inventory的适用场景与实现思路。

Ansible Inventory 核心架构与数据流 静态 Inventory（INI / YAML） [web_servers] [db_servers] [all_servers:children] 主机变量 ansible_host= 组变量 http_port=8080 嵌套组 :children 关键字 动态 Inventory（脚本 / 插件） 云平台 API AWS / 阿里云 / 腾讯云 CMDB / 数据库 Zabbix / 自研系统 容器平台 K8s / Docker JSON 格式 {"_meta": {"hostvars":{}}} --list --host 或 Ansible 执行引擎 主机组 变量 动态源

上图清晰地展示了Ansible Inventory的两大来源：左侧为静态Inventory，通过INI或YAML文件直接定义主机、组及变量；右侧为动态Inventory，通过脚本或插件从外部系统（云平台、CMDB、容器平台）拉取主机信息并转换为JSON格式。两者最终都汇入Ansible执行引擎，作为任务执行的目标清单。下面我们逐一展开。

4.1 静态Inventory的编写：从基础语法到嵌套组

4.1.1 核心原理：INI格式的默认约定

Ansible默认的Inventory文件是一个INI格式的文本文件（通常命名为hosts或inventory.ini）。其核心语法非常直观：[组名]下方列出该组包含的主机，每行一个主机。主机可以是IP地址、域名或别名。默认情况下，Ansible通过SSH连接主机，使用当前执行用户的用户名，SSH端口为22。

# 最简单的Inventory示例
[web_servers]
192.168.1.10
192.168.1.11
web.example.com

[db_servers]
db1.example.com
db2.example.com ansible_port=2222

在上述示例中，web_servers组包含两台IP主机和一个域名主机；db_servers组包含两台数据库主机，其中db2.example.com通过ansible_port=2222覆盖了默认SSH端口。这种“主机后跟键值对”的写法，就是主机变量的雏形。

4.1.2 操作流程：定义主机组与嵌套组

实际生产环境中，主机往往需要多维度分组。例如，按业务（Web、DB）、按环境（生产、测试）、按地域（北京、上海）。Ansible提供了:children后缀来创建嵌套组，从而构建灵活的层级关系。

# 定义子组
[web_beijing]
web-bj-01.example.com
web-bj-02.example.com

[web_shanghai]
web-sh-01.example.com

[db_beijing]
db-bj-01.example.com

# 定义父组，包含上述子组
[web_servers:children]
web_beijing
web_shanghai

[production:children]
web_servers
db_beijing

# 也可以直接给父组定义变量
[production:vars]
ansible_user=deploy
ansible_ssh_private_key_file=/home/deploy/.ssh/id_rsa

这里的关键点在于：[production:children]下方的缩进列表是组名，而不是主机名。通过这种方式，production组就自动包含了web_servers和db_beijing下的所有主机。同时，[production:vars]可以为整个生产环境统一设置连接参数，避免了重复定义。

4.1.3 案例拆解：多环境多角色的Inventory设计

假设我们管理一个典型的电商应用，分为开发（dev）、测试（staging）、生产（prod）三个环境，每个环境都有Web和DB角色。一个结构清晰的静态Inventory如下：

# inventory.ini
[dev_web]
dev-web-01 ansible_host=10.0.1.11

[dev_db]
dev-db-01 ansible_host=10.0.1.12

[staging_web]
staging-web-01 ansible_host=10.0.2.11

[staging_db]
staging-db-01 ansible_host=10.0.2.12

[prod_web]
prod-web-01 ansible_host=10.0.3.11
prod-web-02 ansible_host=10.0.3.12

[prod_db]
prod-db-01 ansible_host=10.0.3.13

# 环境父组
[dev:children]
dev_web
dev_db

[staging:children]
staging_web
staging_db

[prod:children]
prod_web
prod_db

# 角色父组
[web:children]
dev_web
staging_web
prod_web

[db:children]
dev_db
staging_db
prod_db

# 全局变量
[all:vars]
ansible_user=ops
ansible_become=yes
ansible_become_method=sudo

这个设计带来了极大的灵活性：

  • 要对所有Web服务器执行操作，直接指定web组。
  • 要只对生产环境操作，指定prod组。
  • 要对生产环境的数据库进行维护，指定prod_db组。

通过ansible-inventory --list命令，可以直观地看到这个层级关系被解析后的JSON结构，验证分组是否正确。

4.1.4 常见误区与总结复盘

误区一：在:children组中误写主机名。系统会报错“Host pattern not found”，因为Ansible期望的是组名。

误区二：忽略ansible_host与主机别名的区别。如果Inventory中写的是web-01，而实际DNS无法解析该名称，必须使用ansible_host=IP来指定真实连接地址。否则会报“unreachable”错误。

误区三：变量覆盖顺序混乱。Ansible的变量优先级从高到低为：extra vars（命令行） > playbook vars > 主机变量 > 组变量 > 全局变量。理解这个顺序，才能避免“为什么我设置了变量不生效”的困惑。

静态Inventory适合主机数量相对固定、变更不频繁的场景。它的优点是简单、直观、可读性强，且可以直接纳入Git版本控制，实现配置的审计与回滚。

4.2 静态Inventory的变量组织：主机变量与组变量

4.2.1 核心原理：变量的作用域与优先级

变量是Inventory的灵魂。通过变量，我们可以让同一个Playbook在不同主机上表现出不同的行为。Inventory中的变量主要分为两类：主机变量（仅对特定主机生效）和组变量（对组内所有主机生效）。当主机同时属于多个组时，如果不同组定义了同名变量，Ansible会按照一定的优先级规则进行合并，通常更具体的组（子组）优先级高于父组。

4.2.2 操作流程：在Inventory中定义变量的三种方式

  1. 内联方式：直接在主机行后追加key=value。适合少量、仅针对单台主机的特殊配置。
  2. 组变量段：使用[组名:vars]段落。适合该组所有主机通用的配置。
  3. 独立变量文件：在group_vars/和host_vars/目录下创建与组名或主机名同名的YAML文件。这是大型项目推荐的方式，便于维护。
# 方式一：内联
[webservers]
web1 ansible_host=192.168.1.1 http_port=8080
web2 ansible_host=192.168.1.2 http_port=8081

# 方式二：组变量段
[webservers:vars]
ntp_server=ntp.example.com
http_port=80

# 方式三：独立文件（推荐）
# 创建 group_vars/webservers.yml 内容如下：
# ---
# ntp_server: ntp.example.com
# http_port: 80

4.2.3 案例拆解：利用组变量简化Playbook

假设我们需要部署Nginx，不同环境的监听端口不同。我们可以在group_vars/下为不同环境定义变量：

# group_vars/dev_web.yml
http_port: 8080
server_name: dev.example.com

# group_vars/prod_web.yml
http_port: 80
server_name: www.example.com

Playbook中只需要引用变量，无需关心具体环境：

- name: Configure Nginx
  hosts: web
  tasks:
    - name: Write nginx config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/conf.d/{{ server_name }}.conf
      vars:
        listen_port: "{{ http_port }}"

当Playbook针对dev_web组运行时，http_port自动为8080；针对prod_web组运行时，自动为80。这大大提升了代码复用性。

4.2.4 常见误区与总结复盘

经验提醒：变量名建议使用小写字母和下划线，避免使用连字符（-），因为YAML中连字符会被解析为列表，导致变量引用失败。

合理组织变量，是Ansible项目从“脚本集合”走向“产品化”的关键一步。建议将敏感信息（如密码）使用Ansible Vault加密，而不是明文写在Inventory中。

4.3 动态Inventory：获取方式与使用场景

4.3.1 核心原理：从静态到动态的跃迁

在云计算和容器化时代，主机是弹性伸缩的，可能随时创建和销毁。静态Inventory无法满足这种动态性。动态Inventory通过执行一个外部脚本或使用Ansible官方插件，在每次运行Playbook时实时从外部系统（如AWS EC2、阿里云ECS、Kubernetes集群、CMDB）查询主机列表，并输出为JSON格式。Ansible会缓存这个结果，避免频繁调用API。

4.3.2 操作流程：动态Inventory的工作机制

一个动态Inventory脚本必须支持两个命令行参数：

  • --list：返回所有主机和组的JSON结构。
  • --host <hostname>：返回指定主机的变量信息。

使用方式非常简单，只需在ansible-playbook -i参数后指定脚本路径（需赋予执行权限）或插件名称。

# 使用AWS EC2官方动态Inventory插件
ansible-playbook -i aws_ec2.yml deploy.yml

# 使用自定义Python脚本
ansible-playbook -i inventory.py deploy.yml

对于云平台，Ansible提供了丰富的内置插件（如amazon.aws.aws_ec2、azure.azcollection.azure_rm），只需在YAML配置文件中指定插件名称、区域、标签过滤条件等，即可自动获取主机。

4.3.3 案例拆解：基于标签的AWS EC2动态Inventory

假设我们在AWS上有多个EC2实例，通过标签Environment: production和Role: web来标识。我们可以创建一个aws_ec2.yml文件：

# aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - ap-southeast-1
filters:
  tag:Environment: production
keyed_groups:
  - key: tags.Role
    prefix: ""
    separator: ""
hostnames:
  - tag:Name
  - private-ip-address
compose:
  ansible_host: private_ip_address

执行ansible-inventory -i aws_ec2.yml --graph，可以看到Ansible自动生成了production组和web组（基于Role标签）。这样，当新实例上线并打上标签后，无需修改Inventory，Playbook即可自动管理新主机。

4.3.4 常见误区与总结复盘

风险提示：动态Inventory脚本如果执行失败（如过期、网络不通），Ansible会直接报错并终止。建议在脚本中做好异常处理，并利用Ansible的cache功能（如Redis、JSON文件）缓存Inventory数据，避免因API抖动导致任务中断。

动态Inventory特别适合以下场景：

场景推荐方案优势
云主机（AWS/阿里云）官方云插件无需额外开发，支持标签过滤
自建CMDB自定义Python脚本可对接内部系统，数据准确
Kubernetes集群kubernetes.core.k8s插件自动发现Pod/Node，支持命名空间过滤
混合云环境脚本聚合多个云API统一入口，屏蔽底层差异

选择动态Inventory的核心原则是：主机生命周期是否频繁变化？如果答案是肯定的，那么动态Inventory是必然选择；如果主机相对固定，静态Inventory的简单性反而更具优势。

4.4 本章总结与最佳实践

Inventory是Ansible的基石，无论是静态还是动态，其核心目标都是准确、高效地描述“我要管理什么”。静态Inventory适合小型、稳定的环境，通过嵌套组和变量组织，可以构建出清晰的管理视图。动态Inventory则面向云原生和弹性伸缩场景，将主机发现过程自动化，让Ansible真正融入CI/CD流水线。

最佳实践建议：

  • 始终将Inventory文件纳入Git版本控制，记录每一次变更。
  • 使用ansible-inventory --list验证Inventory解析结果，确保分组和变量符合预期。
  • 敏感变量使用ansible-vault encrypt_string加密，避免明文泄露。
  • 对于动态Inventory，务必配置缓存策略，并设置合理的缓存过期时间（如300秒）。
  • 在Playbook中尽量使用hosts: all配合--limit参数，而不是硬编码组名，提高Playbook的通用性。

掌握Inventory的编写与选择，意味着你已经迈出了Ansible自动化管理的第一步。接下来，我们将深入Playbook的核心语法，看看如何利用这些主机清单编写出强大且可维护的自动化任务。

← 上一章 📖 返回目录 下一章 →