ansible和playbook和role运维实战教程 1.5万 80 2023-04-16 16:39:41

转载自博客：https://www.bilibili.com/video/BV1oX4y1z7Kr/?spm_id_from=333.788.recommend_more_video.2&trackid=web_related_0.router-related-2479604-5tzfh.1779106313047.143&vd_source=98f3349ab95218044e2c42b526a191ca

 

 

这张图展示了 Ansible 的安装与入门测试，这是开始自动化运维的第一步。这里详细列出了两种安装方式，并给出了验证命令。

我将图中的核心内容提炼为三个关键步骤，帮你理清思路：

1. 安装方式的选择与避坑

图中列出了两种安装方法，强烈建议遵循图中的建议：

• 首选方案：YUM 安装（推荐）

  • 原因：简单、快捷，且能自动处理大部分系统依赖。

  • 关键步骤：

    1. 先安装 EPEL 源：yum install epel-release（这是必须的，因为 Ansible 本身在默认源里可能没有）。

    2. 再安装 Ansible：yum -y install ansible。

  • 避坑指南：图中有个被遮挡的命令 # yum install epel-re...，请务必输入完整的 epel-release，漏掉 e会导致找不到包。

• 备选方案：PIP 安装

  • 适用场景：当你需要特定版本的 Ansible，或者你的系统比较老旧时。

  • 缺点：正如图片中作者吐槽的“比较麻烦”。因为它涉及 Python 环境的管理，容易遇到各种路径或依赖冲突的问题。除非你是 Python 专家，否则不建议新手首选这条路。

2. 如何确认安装成功？

安装完成后，不要盲目往下走，先验证一下环境是否就绪：

• 查看版本号

  • 命令：ansible --version

  • 作用：不仅能看到版本号（如图中的 2.9.27），还能看到 Ansible 的配置文件路径、Python 解释器位置等关键信息。这是排查环境问题的第一道关卡。

3. 经典的 "Hello World"：Ping 模块

这是运维界最著名的测试命令，用来验证 Ansible 是否能成功连接并管理目标主机：

• 命令：ansible localhost -m ping

• 原理解析：

  • localhost：目标主机是本机。

  • -m ping：调用 ping模块。

• 成功标志：

  看到返回的 JSON 数据中有一个 "pong"，就代表一切正常！

  • "changed": false表示这次运行没有改变系统状态（只是测试连通性），这是正常的。

  • "ping": "pong"是 Ansible 给你的“成功响应”。

---

💡 实战小贴士

如果你在运行 ansible localhost -m ping时报错 Permission denied或 Failed to connect，通常是因为：

1. SSH 服务未开启：即使连接本机，Ansible 默认也走 SSH 协议。需要确保本机的 SSH 服务正在运行（systemctl status sshd）。

2. 未配置免密登录：如果是连接远程服务器，记得提前配置好 SSH Key 免密登录，否则会一直提示输入密码。

 

 

这张图展示了 Ansible 的核心配置文件和主机清单管理，这是从“能运行”进阶到“能管理大规模服务器”的关键一步。

这里的核心逻辑是：Ansible 要知道“管理谁”以及“怎么管理”。

1. 核心概念：Inventory（主机清单）

图中重点演示了修改 /etc/ansible/hosts文件，这个文件就是 Ansible 的“通讯录”。

• 为什么要改？

  默认情况下，Ansible 不知道你要操作哪些服务器。你需要在这个文件里列出它们的 IP 或域名。

• 怎么写？（分组管理）

  • [test]：这是一个组名。把具有相同属性的服务器归到一个组里，方便批量操作。

  • 192.168.171.129：这是被管理服务器的实际 IP。

  • 实战意义：假设你有 100 台 Web 服务器，你不需要写 100 行命令，只需要把它们都归入 [webservers]组，然后执行命令时指定 ansible webservers -m ...，就能一次性搞定所有机器。

2. 配置文件：ansible.cfg

图中提到了编辑 /etc/ansible/ansible.cfg。

• 它的作用：这是 Ansible 的“总控开关”。它里面定义了连接超时时间、并发线程数、默认用户（比如是否默认使用 root）、日志路径等。

• 什么时候改？

  • 默认配置通常能满足大部分需求。

  • 只有当你的服务器 SSH 端口不是默认的 22，或者你需要指定特定的 SSH 密钥路径时，才需要来这个文件里修改。

3. 实战演练建议

如果你想跟着图片里的步骤动手试一试，可以按照以下流程：

1. 配置主机：

   vim /etc/ansible/hosts

   在文件末尾添加：

   [my_servers]
   192.168.1.100  # 替换成你实际的服务器IP
   192.168.1.101

2. 配置免密登录（非常重要！）：

   在真正执行命令前，确保你的控制机能免密 SSH 登录到上面添加的 IP。否则 Ansible 会一直卡在输入密码的环节。

   ssh-copy-id root@192.168.1.100

3. 测试连通性：

   配置好 hosts 和免密登录后，就可以测试了：

   ansible my_servers -m ping

   如果返回 SUCCESS和 pong，说明你的“通讯录”配置正确，Ansible 已经准备好接管这些服务器了。

 

这张图展示了 Ansible 的两个核心进阶配置：Inventory 主机清单和ansible.cfg 全局配置。理解了这两个部分，你就掌握了 Ansible 管理多台服务器的“基础语法”和“快捷键”。

我将图中的知识点拆解为三个实战要点，帮你理清思路：

1. 核心实战：配置你的“服务器通讯录” (Inventory)

图中重点演示了编辑 /etc/ansible/hosts文件。这是 Ansible 能够管理服务器的第一步，它相当于你的“通讯录”。

• 为什么要分组？

  假设你有 100 台服务器，不可能每次都挨个 IP 敲命令。通过分组，你可以实现“批量化操作”。

  • 比如把所有 Web 服务器放进 [webservers]组。

  • 把所有数据库服务器放进 [dbservers]组。

• 图中的写法解析：

  ini

  [test] # 定义一个组名叫 test

  192.168.171.129 # 组里的第一个成员

  192.168.171.130 # 组里的第二个成员

• 怎么用？

  配置好后，你不需要写 IP，直接用组名操作：

  bash

  ansible test -m ping # 一次性测试 test 组里所有机器的连通性

2. 避坑指南：SSH 首次连接确认 (host_key_checking)

图中高亮了 host_key_checking = False，这是新手最容易卡住的地方。

• 痛点场景：当你第一次用 Ansible 连接一台新服务器时，SSH 会弹出一个安全警告：“Are you sure you want to continue connecting (yes/no)?” 并要求你输入密码。

• 后果：Ansible 是自动化工具，遇到这种交互式弹窗就会卡死，因为它不知道该怎么按“Yes”。

• 解决方案：

  将 host_key_checking = False取消注释（设为 False）。这相当于告诉 Ansible：“以后遇到没连过的服务器，别问了，直接信任并建立连接。” 这在测试环境和自动化脚本中是必须的。

3. 运维增效：日志记录与性能监控

图中还提到了两个非常实用的配置，建议在生产环境中开启：

• log_path = /var/log/ansible.log

  • 作用：开启“黑匣子”。默认情况下 Ansible 是不记录日志的，一旦执行出错，很难排查。开启后，所有的操作记录、报错信息都会保存在这个文件里，是你的“排错神器”。

• accelerate(加速模式)

  • 原理：普通的 Ansible 是基于 SSH 的，每次执行命令都要经过 SSH 握手，连接多台机器时会有延迟。开启 accelerate后，Ansible 会在目标机器上启动一个守护进程，后续的连接会复用这个通道，速度会快很多。

  • 注意：这需要目标机器额外开放一个端口（默认 5099），通常用于大规模集群（几百上千台机器）的性能优化。

💡 动手实操建议

如果你想立刻验证图中的配置是否生效，可以按以下步骤操作：

1. 配置 Inventory：

   bash

   echo -e "[my_test_group]\n192.168.1.100" >> /etc/ansible/hosts

2. 开启免密 SSH：

   确保你的控制机能免密登录到 192.168.1.100。

3. 测试连通性：

   bash

   ansible my_test_group -m ping

   如果返回 SUCCESS和 pong，恭喜你，Ansible 已经完全接管了这台机器！

这张图展示了 Ansible 的两个核心进阶配置：Inventory 主机清单和ansible.cfg 全局配置。理解了这两个部分，你就掌握了 Ansible 管理多台服务器的“基础语法”和“快捷键”。

我将图中的知识点拆解为三个实战要点，帮你理清思路：

1. 核心实战：配置你的“服务器通讯录” (Inventory)

图中重点演示了编辑 /etc/ansible/hosts文件。这是 Ansible 能够管理服务器的第一步，它相当于你的“通讯录”。

• 为什么要分组？

  假设你有 100 台服务器，不可能每次都挨个 IP 敲命令。通过分组，你可以实现“批量化操作”。

  • 比如把所有 Web 服务器放进 [webservers]组。

  • 把所有数据库服务器放进 [dbservers]组。

• 图中的写法解析：

  ini

  [test] # 定义一个组名叫 test

  192.168.171.129 # 组里的第一个成员

  192.168.171.130 # 组里的第二个成员

• 怎么用？

  配置好后，你不需要写 IP，直接用组名操作：

  bash

  ansible test -m ping # 一次性测试 test 组里所有机器的连通性

2. 避坑指南：SSH 首次连接确认 (host_key_checking)

图中高亮了 host_key_checking = False，这是新手最容易卡住的地方。

• 痛点场景：当你第一次用 Ansible 连接一台新服务器时，SSH 会弹出一个安全警告：“Are you sure you want to continue connecting (yes/no)?” 并要求你输入密码。

• 后果：Ansible 是自动化工具，遇到这种交互式弹窗就会卡死，因为它不知道该怎么按“Yes”。

• 解决方案：

  将 host_key_checking = False取消注释（设为 False）。这相当于告诉 Ansible：“以后遇到没连过的服务器，别问了，直接信任并建立连接。” 这在测试环境和自动化脚本中是必须的。

3. 运维增效：日志记录与性能监控

图中还提到了两个非常实用的配置，建议在生产环境中开启：

• log_path = /var/log/ansible.log

  • 作用：开启“黑匣子”。默认情况下 Ansible 是不记录日志的，一旦执行出错，很难排查。开启后，所有的操作记录、报错信息都会保存在这个文件里，是你的“排错神器”。

• accelerate(加速模式)

  • 原理：普通的 Ansible 是基于 SSH 的，每次执行命令都要经过 SSH 握手，连接多台机器时会有延迟。开启 accelerate后，Ansible 会在目标机器上启动一个守护进程，后续的连接会复用这个通道，速度会快很多。

  • 注意：这需要目标机器额外开放一个端口（默认 5099），通常用于大规模集群（几百上千台机器）的性能优化。

💡 动手实操建议

如果你想立刻验证图中的配置是否生效，可以按以下步骤操作：

1. 配置 Inventory：

   bash

   echo -e "[my_test_group]\n192.168.1.100" >> /etc/ansible/hosts

2. 开启免密 SSH：

   确保你的控制机能免密登录到 192.168.1.100。

3. 测试连通性：

   bash

   ansible my_test_group -m ping

   如果返回 SUCCESS和 pong，恭喜你，Ansible 已经完全接管了这台机器！

 

这张图展示了 SSH 免密登录的配置过程，这是 Ansible 能够自动化管理的基石。

简单来说，这一步是在解决“如何不用输密码就能控制其他服务器”的问题。我将图中的步骤拆解为三个关键阶段，帮你理解其中的逻辑：

1. 生成“身份证”：SSH 密钥对

• 命令：ssh-keygen

• 图中现象：上半部分的乱码图形是 SSH 密钥的指纹，下方显示生成了两个文件：

  • id_rsa：私钥（自己留着，千万不能泄露）。

  • id_rsa.pub：公钥（用来发给别的机器）。

• 作用：这相当于你生成了一把“家门钥匙”（公钥）和一把“保险柜钥匙”（私钥）。

2. 分发“通行证”：SSH 免密登录设置

这是图中最核心的操作，目的是把你的公钥复制到目标服务器上，让目标服务器认识你。

• 命令：ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.171.129

• 参数解析：

  • -i：指定要发送的公钥文件。

  • root@IP：指定目标机器的用户名和 IP。

• 关键点（避坑指南）：

  • 第一次连接需要密码：图中注释明确写了“第一次需要输入对方用户密码”。这是因为目标服务器还不认识你，需要验证身份才能把公钥存进去。

  • 结果：执行成功后，目标服务器的 ~/.ssh/authorized_keys文件里就会多出你的公钥。以后再连，对方一看是你，直接开门，不用再输密码了。

3. 验货：测试连接

• 命令：ssh root@192.168.171.129 ifconfig | head -3

• 双重目的：

  1. 测试免密是否成功：如果能直接进去执行命令，说明免密配置生效。

  2. 验证 Root 权限：Ansible 通常需要 root 权限来安装软件或修改配置。ifconfig命令一般只有 root 能用，如果这里能执行成功，说明 Ansible 后续操作也不会因为权限不足而报错。

---

💡 实战补充：如果 ssh-copy-id命令不存在怎么办？

虽然图中演示的是用 ssh-copy-id，但在某些极简系统（如最小化安装的 CentOS）中可能没有这个命令。你可以直接用 Linux 的管道大法手动复制：

# 1. 先把本地的公钥内容打印出来
cat /root/.ssh/id_rsa.pub

# 2. 登录到目标服务器，把内容追加到 authorized_keys 文件里
# (需要先手动输入一次密码登录目标机)
ssh root@192.168.171.129
echo "刚才复制的公钥内容" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys  # 别忘了改权限，否则SSH会拒绝读取

完成这些步骤后，你的 Ansible 就可以畅通无阻地管理这两台 192.168.x.x的机器了！

 

这张图讲解了 Ansible 中最核心的执行命令模块：command和 shell。这是你从“配置工具”转向“实际操作服务器”的第一步。

我将图中的知识点拆解为两者的区别和实战用法，帮你快速上手：

1. 核心区别：什么时候用 command？什么时候用 shell？

这是新手最容易混淆的地方，图中也给出了明确的指引：

• command模块（简单命令）

  • 特点：它只负责“傻傻地”执行命令，不支持管道（|）、重定向（>）或逻辑运算符（&&、||）。

  • 适用场景：执行一些简单的查询或单步操作，比如 free -m、uptime、date。

  • 优势：更安全，执行效率高，因为它是 Ansible 的原生模块，不需要调用系统的 Shell 解释器。

• shell模块（复杂命令）

  • 特点：它会调用目标机器上的 /bin/sh来解释命令，支持管道、重定向、通配符等所有 Shell 语法。

  • 适用场景：当你需要组合命令时。如图中所示，ifconfig|grep ens33，如果不加引号或者用 command模块，Ansible 会报错或无法解析管道。

  • 注意：因为赋予了更大的权限，使用时需确保命令的安全性。

2. 命令结构解析

图中的命令模板非常经典，记住这个公式：

ansible [目标主机/组] -m [模块名] -a "[具体的命令内容]"

• -m command/shell：指定你要使用的模块。

• -a "..."：-a代表 argument（参数），引号里就是你要在远程服务器上跑的具体命令。

3. 实战例子解析

• 例子 1：查看内存

  bash

  ansible test -m command -a "free -m"

  • 解析：直接调用 free -m查看内存。test是在 /etc/ansible/hosts里定义的主机组名。

• 例子 2：过滤网卡信息（展示 Shell 的必要性）

  • Command 尝试（可能受限）：

    bash

    ansible test -m command -a "ifconfig|grep ens33"

    如果目标系统是 CentOS 7+（默认没有 ifconfig），或者严格限制了 command 模块，这行命令可能会失败。

  • Shell 执行（推荐）：

    bash

    ansible test -m shell -a "ifconfig|grep ens33"

    通过 shell模块，管道符生效，成功过滤出 ens33网卡的信息。

4. 实战小贴士

图中有一条命令带了 -f 50：

ansible test -m shell -a "ifconfig|grep ens33" -f 50

• -f 50是什么意思？

  • 它是 --forks（分叉）的缩写，代表并发数。

  • 默认情况下，Ansible 是串行执行的（一台跑完跑下一台）。如果你的 test组里有 100 台机器，不加这个参数要等很久。

  • 加上 -f 50后，Ansible 会同时向 50 台机器​ 发送命令并等待结果，大大加快了执行速度。一般建议设置为 50 或 100。

总结建议：日常简单查状态用 command，需要做文本处理或多命令组合时用 shell，如果要操作大量机器记得加上 -f 50提升速度。

 

 

这张图讲解了 Ansible 中非常实用的 copy模块，它是实现“批量分发文件”的核心工具。

简单来说，这就是 Ansible 版的“批量复制粘贴”功能。我将图中的知识点拆解为参数解析、实战操作和避坑指南，帮你彻底掌握它。

1. 核心功能：不仅是“发文件”，还能“写内容”

copy模块主要有两个用途，图中都有体现：

• 用途一：本地文件 -> 远程服务器

  把你管理机（控制端）上的文件，原封不动地推送到远程被管理机上。

• 用途二：直接写入字符串

  不需要先在本地建文件，直接把一段文字（Content）推送到远程服务器的某个文件里。这在实际工作中非常方便，比如批量修改配置文件中的某一行。

2. 关键参数速查表（建议收藏）

图中列出了最常用的几个参数，这是写 copy模块命令的基础：

 

参数	作用	类比
src​	源文件。本地文件的路径。	我要复制哪个文件？
dest​	目标路径。远程服务器存放文件的路径。	我要把它放到哪？
backup​	备份。推送前先备份远程的旧文件（默认为 no）。	怕改坏了？先做个备份。
content​	内容。直接写入的文本内容，不需要本地文件。	不想建文件？直接写文字。
owner/group/mode​	权限。设定远程文件的属主、属组和权限（如 0644）。	到了那边是什么身份？

3. 实战案例解析：图中在做什么？

图中的操作步骤非常经典，模拟了一次标准的“批量下发文件”流程：

第一步：准备本地文件

bash

[root@localhost ~]# cat /tmp/a.txt

111

• 解读：在管理机上准备了一个叫 a.txt的文件，里面只有一行 111。

第二步：执行 Copy 命令

bash

ansible test -m copy -a "src=/tmp/a.txt dest=/tmp/"

• 解读：

  • test：目标主机组（之前在 hosts 文件里定义好的）。

  • -m copy：调用 copy 模块。

  • -a "..."：参数部分。

    • src=/tmp/a.txt：告诉 Ansible 去哪找源文件。

    • dest=/tmp/：告诉 Ansible 把文件推送到远程的哪个目录。

第三步：查看执行结果 (Return JSON)

图中展示了返回的 JSON 数据，重点关注这几个字段：

• "changed": true：最重要标志。表示文件确实被传输了（如果文件没变，这里会是 false）。

• "dest": "/tmp/a.txt"：确认文件最终到达的位置。

• "checksum"：文件的 MD5 校验值，确保文件传输过程中没有损坏或被篡改。

4. ⚠️ 避坑指南：那个黄色的警告

图中特别用黄色高亮了一行字：

copy模块注意：所有被管理端需要安装：libselinux-python

• 为什么要注意这个？

  如果你的远程服务器开启了 SELinux（CentOS 默认开启），并且你要传输的文件涉及系统服务（比如配置文件、脚本等），Ansible 的 copy模块在推送完成后，可能需要修改文件的 SELinux 上下文标签。如果没有这个 Python 库，模块就会报错。

• 怎么解决？

  非常简单，在远程主机上执行安装：

  bash

  yum install libselinux-python -y

  (注：CentOS 7 通常默认已安装，但最小化安装的系统可能需要手动装一下。)

💡 进阶玩法：不传文件，直接写内容

虽然图中没演示，但根据图里的参数，你可以玩个更高级的：直接把一串配置写入远程文件，不需要先在本地建文件。

示例：在所有 test组的机器上，往 /tmp/test.conf里写入一行 "Hello Ansible"。

bash

ansible test -m copy -a "content='Hello Ansible' dest=/tmp/test.conf"

 

这张图讲解了 Ansible 中三个非常核心的模块：copy（进阶用法）、yum（包管理）和 service（服务管理）。这三个模块组合起来，就是一套完整的“部署软件并启动服务”的标准流程。

我将图中的知识点拆解为这三个模块的核心用法，并补充了一些实战避坑指南：

1. copy模块的进阶用法：直接写入文本 (content)

图中上半部分展示了 copy模块除了发文件外的另一个强大功能——直接写入字符串。

• 场景：有时候你不需要在本地建一个文件再传过去，而是想直接把一段配置（比如密码文件、单行配置）推送到远程服务器。

• 命令解析：

  bash

  ansible test -m copy -a "content='123' dest=/etc/rsync.pass owner=root group=root mode=600"

  • content='123'：直接把 123这个字符串写入目标文件。注意这里用了单引号，防止变量扩展。

  • dest=/etc/rsync.pass：目标文件路径。

  • mode=600：非常关键！​ 这设置了文件权限为 rw-------。对于密码文件或密钥文件，必须严格限制权限，否则服务（如 rsync）可能会因为权限太开放而拒绝读取。

2. yum模块：批量装软件

这是运维中最常用的模块之一，相当于在每台机器上执行 yum install。

• 命令结构：

  bash

  ansible test -m yum -a "name=httpd state=installed"

• 参数详解：

  • name=：要安装的软件包名（如 httpd, vim, wget）。

  • state=：状态控制（这是重点）：

    • installed/ present：确保安装（如果没装就装，如果已装就不动）。最常用。

    • removed/ absent：确保卸载（如果装了就卸，没装就算了）。

    • latest：确保是最新版（如果系统里有旧版，会自动升级）。

3. service模块：批量启停服务

装好软件后，通常需要启动服务并设置开机自启。

• 命令结构：

  bash

  ansible test -m service -a "name=httpd state=stopped enabled=yes"

• 实战映射：

  这个命令其实就是在远程执行：

  systemctl stop httpd(停止服务)

  systemctl enable httpd(设置开机自启)

• 参数详解：

  • state=：服务的最终状态。

    • started：启动

    • stopped：停止

    • restarted：重启（配置文件变了通常用这个）

    • reloaded：重载配置（平滑重启，不中断连接）

  • enabled=：是否开机自启 (yes或 no)。

💡 实战串联：部署一个 Web 服务器

图中的操作流程其实就是一套标准的 LAMP/LNMP 环境部署的前半段。我们可以把它串联起来：

假设我们要在所有 test组的机器上安装并启动 Nginx：

1. 安装：

   bash

   ansible test -m yum -a "name=nginx state=installed"

2. 推配置文件（假设本地有个 nginx.conf）：

   bash

   ansible test -m copy -a "src=/root/nginx.conf dest=/etc/nginx/nginx.conf"

3. 启动服务：

   bash

   ansible test -m service -a "name=nginx state=started enabled=yes"

⚠️ 避坑小贴士

1. 权限问题：图中的 mode=600是个很好的习惯。在使用 copy推送敏感文件（如 .pem密钥、.pass密码文件）时，务必检查权限，否则服务启动会报错。

2. yum模块依赖：yum模块底层依赖 Python 的 yum库。如果在某些极简系统上执行报错，可能需要先安装 python3-libsemanage或相关的 yum 依赖包。

3. 状态幂等性：Ansible 的强大在于“幂等性”。也就是说，如果你连续执行两次 yum install httpd，第二次执行时 Ansible 会发现 httpd已经安装了，于是返回 OK而不做任何实际操作，不会报错。这也是为什么推荐使用 state=installed而不是简单地执行 shell 命令 yum -y install。

 

这张图继续深入讲解了 Ansible 的三个高级模块：script、service和 file。它们分别解决了“运行本地脚本”、“管理后台服务”和“操控文件系统”的问题。

我将图中的知识点拆解为这三个模块的核心用法和避坑指南，帮你完善运维工具箱：

1. script模块：本地脚本，远程执行

这是图中非常高效的一个模块，它的核心逻辑是“本地写好，远程运行”。

• 痛点场景：如果你有一段很复杂的配置逻辑（比如循环安装 10 个软件包），写在命令行里会非常长且难以维护。通常你会写成一个 .sh脚本。

• 传统做法的麻烦：先用 copy模块把脚本传到远程，再用 shell模块执行，执行完可能还要删掉脚本。

• script模块的优雅：不需要传文件。你只需在管理端写好脚本，直接让 Ansible 读取并执行它，Ansible 会在后台自动处理临时传输和执行的过程。

• 实战解析：

  bash

  1. 在本地编写脚本

  cat /root/yum_wget.sh

  !/bin/bash

  yum -y install wget

  2. 赋予执行权限（本地必须有 x 权限，否则 Ansible 会报错）

  chmod +x /root/yum_wget.sh

  3. 一键远程执行

  ansible test -m script -a "/root/yum_wget.sh"

  • 结果验证：图中最后用 wget -V验证了软件确实被安装，说明脚本在远程成功运行。

2. service模块：服务的生命周期管理

图中展示了 systemctl status httpd的结果，这是一个典型的“部署后验证”环节。

• 状态解读：

  • Active: inactive (dead)：说明服务当前是停止状态。

  • since ... 1min 5s ago：说明服务是在 1 分 5 秒前停止的。

• 为什么要用 Ansible 管理服务？

  手动登录每台机器敲 systemctl start httpd效率极低。service模块可以实现：

  • 批量启动：state=started

  • 批量停止：state=stopped

  • 批量重启：state=restarted（修改配置文件后必用）

  • 开机自启：enabled=yes（防止服务器重启后服务挂掉）

3. file模块：文件系统操控大师

这是专门用来处理文件和目录状态的模块，比 copy模块更底层，专注于“节点”的创建和属性管理。

图中展示了两个最核心的功能：

• 创建目录 (state=directory)

  • 命令：ansible test -m file -a "path=/tmp/shi state=directory"

  • 作用：在远程所有机器上创建 /tmp/shi目录。

  • 隐含效果：如果该目录已存在，Ansible 不会报错（幂等性），这正是自动化工具的优势。

• 创建文件 (state=touch)

  • 命令：ansible test -m file -a "path=/tmp/shi.txt state=touch mode=555 owner=root group=root"

  • 作用：创建一个名为 shi.txt的空文件。

  • 参数解析：

    • state=touch：类似于 Linux 底层的 touch命令，文件不存在则创建，存在则更新时间戳。

    • mode=555：设置权限。555代表 r-xr-xr-x，即所有人都可以读和执行，但不能写。这在发布只读配置文件时非常有用。

---

💡 实战串联：从零搭建一个 Web 节点

结合这几张图的知识点，我们可以串起一条标准的自动化部署流水线：

1. 准备阶段：确保免密登录 (ssh-copy-id) 和 Ansible 配置 (hosts, ansible.cfg) 已搞定。

2. 传输脚本：如果需要复杂配置，用 copy模块下发脚本，或者用 script模块直接运行本地脚本。

3. 安装软件：用 yum模块批量安装 httpd。

4. 下发配置：用 copy模块把本地的 httpd.conf推送到远程 /etc/httpd/conf/。

5. 管理目录：用 file模块创建日志目录 /var/log/httpd_custom并设置好权限。

6. 启动服务：用 service模块执行 state=restarted和 enabled=yes。

通过这一套组合拳，你就可以用一条命令完成过去需要登录几十台机器才能完成的繁琐工作！

 

 

这张图继续深入讲解了 file模块的高级用法​ 以及 group和 user模块，这是进行用户管理和文件系统维护的核心工具。

我将图中的知识点拆解为三个部分：文件的高级操作、用户组管理、以及用户管理，帮你构建完整的系统配置能力。

1. file模块进阶：不仅是创建，更是“链接”与“递归”

图中展示了 file模块在处理复杂文件属性时的强大功能，特别是链接和递归操作：

• 创建软链接 (state=link)

  • 命令：ansible test -m file -a "src=/tmp/shi.txt path=/tmp/shi.txt_link state=link"

  • 作用：在远端创建一个指向源文件的快捷方式。

  • 类比：就像 Windows 的桌面快捷方式。当源文件被修改或删除时，快捷方式的状态也会相应变化。

• 递归修改权限 (recurse=yes)

  • 命令：ansible test -m file -a "path=/tmp/shi state=directory owner=root group=root mode=600 recurse=yes"

  • 作用：非常重要！​ 如果不加 recurse=yes，file模块只会修改 /tmp/shi这个目录本身的权限。加上它之后，Ansible 会深入到目录内部，递归修改所有文件和子目录的权限。

  • 实战场景：当你批量修复服务器上某个目录（如 /var/www/html）因误操作导致的混乱权限时，这个参数是救星。

2. group模块：批量建“部门”（用户组）

系统管理中，我们通常不直接给用户 root 权限，而是把用户分到不同的组里。

• 核心参数：

  • name：组名（如 shi_group）。

  • gid：组 ID。指定 GID 可以保证不同服务器上的组 ID 一致，避免权限错乱。

  • state：present（创建/保持）或 absent（删除）。

• 实战解析：

  bash

  ansible test -m group -a "name=shi_group gid=888 state=present"

  执行后，去远程机器的 /etc/group文件尾部，就能看到新增的一行：shi_group:x:888:，证明组创建成功。

3. user模块：批量建“员工”（用户账号）

这是创建系统用户的终极武器。虽然图中底部截断了，但前面的语法已经足够说明问题。

• 基本命令结构：

  bash

  ansible test -m user -a "name=用户名 uid=xxx group=组名 shell=/bin/bash home=/home/xxx state=present"

• 关键参数解析：

  • name：用户名。

  • uid：用户 ID（User ID）。同样是为了保证多台服务器 UID 一致。

  • group：主组。通常填入上面创建的组名（如 shi_group）。

  • shell：指定登录后使用的命令解释器，通常设为 /bin/bash以便拥有完整的交互式 Shell。

  • home：指定家目录路径（默认通常是 /home/用户名）。

  • state=present：表示“如果不存在就创建，如果存在就保持不变”。

💡 实战串联：如何批量创建一个“受限的开发人员”账号？

假设公司新来了一个开发，叫 dev01，需要给他创建一个账号，并把他放入我们刚才创建的 shi_group组里。

Step 1：创建用户并指定主组

bash

ansible test -m user -a "name=dev01 group=shi_group shell=/bin/bash home=/home/dev01 state=present"

Step 2：设置密码（进阶）

user模块本身不能直接设明文密码，通常需要先在管理端生成加密后的密码字符串：

bash

在管理机生成密码哈希

openssl passwd -1 "YourPassword123"

然后在命令中加入 password=刚才生成的哈希值。

总结：配合 file（环境准备）、group（组织架构）和 user（人员账号），你已经具备了自动化搭建基础 Linux 环境的能力！

这张图讲解了 Ansible 中用于管理定时任务的 cron模块。这是运维自动化中实现“无人值守”和“定期维护”的关键模块。

我将图中的知识点拆解为核心参数和实战场景，帮你掌握如何批量设置定时任务。

1. 核心参数速查表

cron模块的本质是操作 Linux 的 /var/spool/cron/目录下的 crontab 文件，它的参数与系统的 crontab -e一一对应：

 

参数	作用	类比 crontab -e
minute/hour/day/month/weekday​	时间规则	前面的 * * * * *
job​	要执行的命令	后面的 command
name​	任务注释/标识​	写在命令上面的 # comment
state​	状态	present(存在/创建) / absent(删除)
disabled​	禁用/注释	在行首加 #

2. 实战场景解析

场景 A：批量添加一个每天凌晨 1 点执行的备份脚本

这是最常见的用法。

• 命令：

  bash

  ansible test -m cron -a "minute=00 hour=01 day=* month=* weekday=* job='/bin/sh /root/a.sh' state=present"

• 解析：

  • 00 01 * * *：标准的 Linux 时间格式，代表每天 1:00。

  • job='...'：这里必须用单引号把整个命令包起来，防止 shell 解析特殊字符。

  • 注意：如果不加 name参数，Ansible 会给这个任务一个默认的注释 #Ansible: None（如图中第一次执行的结果所示）。

场景 B：防止任务重复（最佳实践）

痛点：如果你在 Playbook 里或者 ad-hoc 命令里写错了，重复执行两次，远程机器上就会有两个一模一样的定时任务，导致脚本跑两遍。

解决方案：使用 name参数。

• 命令：

  bash

  ansible test -m cron -a "minute=00 hour=01 day=* month=* weekday=* job='/bin/sh /root/a.sh' name='daily_backup' state=present"

• 原理：Ansible 在执行前会先读取远程的 crontab。如果它发现已经有一个叫 daily_backup的任务了，它就会认为“任务已存在”，不会再创建一份。这保证了幂等性。

场景 C：临时禁用某个任务

比如线上出问题了，你想暂停某个定时任务，但不想删掉（怕以后忘了）。

• 命令：

  bash

  ansible test -m cron -a "name='cron1' job='/bin/sh /root/a.sh' disabled=yes"

• 效果：Ansible 会在远程机器的 crontab 文件里，在这个任务前面加一个 #，把它注释掉。

3. 结果验证：图中的输出说明了什么？

图中最后展示了执行后的验证步骤：

bash

ansible test -m command -a "crontab -l"

• 输出内容：

  text

  00 01 * * * /bin/sh /root/a.sh

• 含义：这说明定时任务已经成功写入了远程机器的当前用户的 crontab 列表中。

💡 避坑指南：权限问题

1. 用户上下文：cron模块默认操作的是当前执行 Ansible 的用户（通常是 root）的 crontab。

2. 脚本路径：如果 job里调用的脚本（如 /root/a.sh）没有执行权限（chmod +x），定时任务是不会执行的。通常建议在脚本里写全路径，或者在 job 里用 /bin/sh /path/to/script.sh的方式调用。

 

 

 

这张图讲解了 Ansible 中专门用于管理 Systemd 服务​ 的模块（即 systemd模块）。

它与传统的 service模块功能类似，但更加现代化，直接对接系统的 systemctl命令，是管理 CentOS 7/8 等现代 Linux 系统服务的首选。

1. 核心功能：服务生命周期与开机自启

图中通过 httpd(Apache) 服务，演示了 systemd模块最经典的两个应用场景：

• 场景一：启动服务并设为开机自启

  • 命令：

    bash

    ansible test -m systemd -a "name=httpd state=started enabled=yes"

  • 参数解析：

    • state=started：确保服务处于运行状态（如果没启动就拉起它）。

    • enabled=yes：确保服务开机自启（会执行 systemctl enable的操作）。

• 场景二：停止服务并关闭开机自启

  • 命令：

    bash

    ansible test -m systemd -a "name=httpd state=stopped enabled=no"

  • 参数解析：

    • state=stopped：确保服务处于停止状态。

    • enabled=no：确保服务不开机自启（会执行 systemctl disable的操作）。

2. 结果深度解析：为什么第一次失败，第二次成功？

观察图中的执行过程，非常有教学意义：

第一阶段：安装后的状态

• 现象：执行 systemctl status httpd显示 Active: inactive (dead)，且 Loaded行显示 disabled。

• 原因：刚用 yum装完软件，默认是不会自动启动的，也不会默认加入开机自启。

第二阶段：执行启动命令

• 现象：返回 CHANGED，且再次查询状态变为 Active: active (running)，Loaded变为 enabled。

• 结论：说明 systemd模块成功执行了“启动 + 设置开机自启”的组合操作。

第三阶段：执行停止命令

• 现象：返回 FAILED | rc=3。

• 注意：虽然显示失败，但下方的服务状态已经变成了 inactive (dead)和 disabled。

• 原因分析：这里的“失败”不是真的报错，而是 Ansible 的“严格模式”导致的。因为 state=stopped指令要求服务是停止的，而远程机器上的服务当前可能已经是停止的了（或者处于某种无法再次停止的特殊状态），Ansible 发现状态已经是 stopped，但命令执行返回了一个非零退出码（rc=3），为了安全起见，它会判定任务失败。在实际生产中，这通常可以忽略，或者可以通过增加 force=yes参数来强制处理。

3. systemd模块 vs service模块

既然有了 service模块，为什么还要学 systemd？

 

特性	service模块	systemd模块
适用系统​	通用（兼容 SysVinit 和 Systemd）	仅限 Systemd 系统（CentOS 7+）
功能​	基础启动/停止/重启	全面，支持 enabled、daemon_reload等高级功能
推荐度​	旧系统维护用	现代系统首选，更纯粹、更强大

💡 进阶用法：配置文件更新后怎么办？

如果你用 Ansible 推送了新的 httpd.conf配置文件，仅仅重启服务可能不够，有时需要让 Systemd 重新加载守护进程配置。

你可以使用 daemon_reload=yes参数：

bash

先推送新配置

ansible test -m copy -a "src=new.conf dest=/etc/httpd/conf/httpd.conf"

让 systemd 重新加载配置，并重启服务

ansible test -m systemd -a "name=httpd daemon_reload=yes state=restarted"

 

的核心逻辑。

我将图中的知识点拆解为 Playbook 核心概念、YAML 语法规范​ 以及 实战案例解析，帮你建立从 Ad-hoc 命令到剧本编排的思维跨越。

1. Playbook 核心概念：从“单兵作战”到“集团军作战”

图中提到 Playbook 由 play和 task两部分组成，这是理解其架构的关键：

• Play（场次/剧本）：

  • 定义：一个 Play 定义了要对哪些主机（hosts）执行哪些任务。

  • 类比：就像一出戏的“第一幕”，规定了谁上台、在什么场景下表演。

  • 作用：映射主机清单（Inventory），确定操作的目标范围。

• Task（任务）：

  • 定义：Task 是 Play 内部的具体动作，调用具体的模块（如 yum, copy, service）来完成具体操作。

  • 类比：戏里的具体“动作”或“台词”。

  • 作用：描述“做什么”，例如安装软件、拷贝配置文件、启动服务。

总结：Play 找人，Task 做事。

2. YAML 语法“三板斧”

Playbook 使用 YAML 格式编写，图中强调的这三条规则是写好 YAML 的生死线，违反任何一条都会导致语法错误：

1. 缩进（Indentation）：

   • 规则：必须使用两个空格进行缩进，绝对不能使用 Tab 键。

   • 原因：YAML 依靠缩进来区分层级关系。如果用 Tab，不同的编辑器显示宽度可能不同，会导致 Ansible 解析错位。

   • 记忆口诀：空格是友军，Tab 是叛徒。

2. 冒号（Colon）：

   • 规则：冒号后面必须跟一个空格（除非是行末的无引号字符串结尾）。

   • 示例：name: httpd（正确），name:httpd（错误）。

3. 短横线（Dash）：

   • 规则：短横线加空格表示一个列表项。

   • 作用：一个 Play 里的多个 Task 就是通过 -符号列出来的。

3. 实战案例深度解析：部署 Apache (httpd)

图中展示了一个经典的案例：如何用 Playbook 实现“安装 -> 配置 -> 启动”的完整闭环。这比之前学的 Ad-hoc 命令更适合生产环境，因为它可以被保存、复用和版本控制。

场景痛点

图中特别提到：“若修改完配置，重新推送后，配置改了但没重载服务，不生效”。

这正是 Playbook 的优势所在——它可以把“推送配置后重启服务”这个逻辑固化在代码里。每次运行 Playbook，它都会检查配置是否变更，如果变了，就会自动触发服务重启。

代码结构映射

图中的 httpd_install.yaml包含了以下核心字段：

yaml

这是一个注释

• hosts: test # 【第一步：找谁】定义在 test 主机组上执行

  remote_user: root # 【身份】使用 root 用户连接远程主机

  gather_facts: no # 【性能优化】不收集远程主机的系统信息（如主机名、IP等），加快执行速度

  tasks: # 【第二步：做什么】任务列表开始

  • name: 描述信息 # 【可读性】任务的说明，打印在屏幕上，方便人看

    yum: # 【第三步：具体怎么做】调用 yum 模块

    name: httpd

    state: installed

  • name:

    copy:

    src: /path/to/httpd.conf

    dest: /etc/httpd/conf/

    notify: restart httpd # 【高级联动】如果 copy 改变了文件，就触发名为 restart httpd 的 handler

  • name:

    service:

    name: httpd

    state: started

    enabled: yes

💡 学习建议：下一步是什么？

这张图展示了 Playbook 的骨架。接下来你可以尝试编写一个简单的 test.yml文件：

1. 定义一个 hosts: localhost（本地执行，不需要配置 SSH 免密）。

2. 写一个 Task，使用 shell模块执行 echo "Hello Ansible"。

3. 在命令行运行 ansible-playbook test.yml。

当你成功看到输出结果时，就正式跨入了 Ansible 自动化编排的大门！

 

这是一个非常标准的 Ansible Playbook 部署 Apache (httpd) 的实战案例。它完美地呼应了上一张图讲的“Playbook 三部曲”：找谁、做什么、怎么做。

我把这段代码的实战逻辑拆解给你：

1. 代码结构逐行解析

这段 YAML 代码实现了“安装 -> 配置 -> 启动”的全自动化流程：

yaml

• hosts: test # 【找谁】：目标主机是 inventory 文件中定义的 [test] 组

  remote_user: root # 【身份】：以 root 用户连接远程机器执行操作

  gather_facts: no # 【优化】：关闭“收集主机信息”功能。如果不需要用到远程主机的 IP、主机名等变量，关闭它可以大幅提升执行速度。

  tasks: # 【任务列表】：下面列出了具体的执行步骤

  • name: install httpd fuwu # 【步骤1：安装】

    yum: name=httpd,httpd-tools state=installed

    解析：使用 yum 模块，安装 httpd 主程序和 httpd-tools 工具包。state=installed 表示“如果没有就安装，有就保持原样”。

  • name: configure httpd fuwu # 【步骤2：配置】

    copy: src=/root/httpd.conf dest=/etc/httpd/conf/httpd.conf

    解析：使用 copy 模块，把管理端（本机）的 /root/httpd.conf 文件推送到远程机器的指定目录，覆盖原配置。

  • name: qidong httpd fuwu # 【步骤3：启动并自启】

    service: name=httpd state=started enabled=yes

    解析：使用 service 模块。state=started 确保服务正在运行；enabled=yes 确保开机自动启动。

2. 实战运行与验证

写完这个文件（假设命名为 httpd_install.yaml），在命令行执行以下命令即可：

bash

ansible-playbook httpd_install.yaml

预期效果：

1. 连接 test组的所有机器。

2. 如果没装 httpd，就装上；装好了就跳过。

3. 不管有没有改动，都把本地的配置文件覆盖过去。

4. 确保 httpd 服务处于“正在运行”且“开机自启”的状态。

3. 关键避坑指南

• 配置文件路径：src=/root/httpd.conf必须是管理端（执行 Ansible 命令的那台机器）上真实存在的路径。

• 语法检查：在运行前，强烈建议先执行 ansible-playbook --syntax-check httpd_install.yaml来检查 YAML 格式是否有误（比如冒号后面忘了加空格）。

这段代码是一个非常经典且实用的入门模板，你可以把它保存下来，以后部署 Nginx 或其他服务时，只需要把 yum的包名、copy的源文件路径、service的服务名改一下，就能直接复用！

 

 

这张图的核心内容是引入了 Handlers（处理器）​ 的概念，并展示了 Ansible Playbook 中至关重要的“通知机制”（Notify）。

简单来说，Handlers 就是用来“被动重启服务”的。只有在配置文件真的发生改变时，才去重启服务；如果配置文件没变，就什么都不做。这避免了每次运行 Playbook 都无条件重启服务造成的资源浪费或服务中断。

以下是图中代码逻辑的详细拆解：

1. 核心机制：Notify + Handlers

图中展示了一个经典的“配置变更触发重启”的逻辑闭环：

• Step 1: 定义通知任务（Task 中的 notify）

  在 configure httpd fuwu这个任务中，当 copy模块将本地配置文件推送到远程机器时，Ansible 会对比文件内容。

  • 如果文件不一样（发生了变更），copy模块会返回一个“changed”状态。

  • 此时，notify: Restart httpd fuwu就会被触发。这就像给系统下了一道“命令”，告诉它：“注意了，配置变了，一会儿去执行名为 Restart httpd fuwu的动作。”

• Step 2: 定义处理器（Handlers 部分）

  在文件底部的 handlers:区块，定义了具体要执行什么动作。

  • - name: Restart httpd fuwu

  • service: name=httpd state=restarted

  • 注意：Handlers 里的 name必须和 Task 里的 notify完全一致（包括大小写和空格），系统才能把它们关联起来。

2. 执行逻辑（什么时候会重启？）

Handlers 有一个特殊的执行规则：它只在 Playbook 中所有 Tasks 全部执行完毕后，才会被触发执行，而且每个 Handler 只执行一次。

• 场景 A：配置文件被修改了

  1. copy模块发现文件不同，执行推送。

  2. copy模块状态变为 changed。

  3. notify触发 Handlers。

  4. Playbook 所有任务跑完后，执行 Restart httpd fuwu，httpd 服务重启。

• 场景 B：配置文件一模一样（没有变更）

  1. copy模块发现文件相同，跳过推送。

  2. copy模块状态为 ok。

  3. notify不会触发任何东西。

  4. Playbook 跑完后，Handlers 也不会执行。服务保持原样运行，完全不受影响。

3. 底部的常用运维命令

图底部展示了三个非常实用的调试和运行命令：

1. 语法检查：

   bash

   ansible-playbook --syntax-check httpd_install.yaml

   作用：在正式运行前，先检查 YAML 格式有没有写错（比如冒号后面忘加空格、缩进不对），如果有错会直接报错，不消耗资源。

2. 模拟运行（干跑模式）：

   bash

   ansible-playbook -C httpd_install.yaml

   作用：加上 -C(check mode)，Ansible 会告诉你哪些文件会被修改、哪些服务会被重启，但实际上什么都不会改变。这是上线前最安全的验证手段。

3. 正式运行：

   bash

   ansible-playbook httpd_install.yaml

   作用：真正去远程机器上执行安装、配置和重启操作。

💡 总结

这张图教你的不仅是写代码，更是一种“优雅的运维思维”：不要盲目操作，而是“感知变化，按需响应”。这是编写高质量、生产级 Ansible Playbook 的必备技巧。

 

这张图展示了一个非常经典的 Ansible Playbook 实战场景：卸载与清理。

如果说之前的代码是在“搭积木”，那么这段代码就是在“拆积木”。它演示了如何批量、干净地将上一节安装的 Apache (httpd) 服务从远程服务器上彻底移除。

我把这段代码的逻辑拆解为你梳理一下：

1. 代码结构逐行解析

这段 YAML 代码定义了一个名为 remove httpd的 Play，主要包含三个清理步骤：

yaml

• hosts: test # 【找谁】：依然针对 [test] 主机组进行操作

  remote_user: root # 【身份】：以 root 权限执行删除操作

  gather_facts: no # 【优化】：关闭主机信息收集

  tasks: # 【任务列表】：开始清理

  • name: remove httpd fufu # 【步骤1：卸载软件】

    yum: name=httpd,httpd-tools state=absent

    解析：关键参数是 state=absent。它表示“确保软件不存在”。如果机器上有 httpd，就卸载它；如果没有，就什么都不做。

  • name: remove apache user # 【步骤2：删除用户】

    user: name=apache state=absent

    解析：httpd 服务通常会创建一个专用的 apache用户来运行。这里使用 user 模块将其删除，消除安全隐患。

  • name: remove data file # 【步骤3：清理目录】

    file: name=/etc/httpd state=absent

    解析：使用 file 模块。当 state=absent 时，它可以用来删除文件或目录。这里强制删除了 httpd 的配置目录。

2. 核心知识点：幂等性（Idempotency）

你可能注意到，无论是安装（state=installed）还是卸载（state=absent），都在强调“如果...就...”的逻辑。

这就是 Ansible 最核心的特性——幂等性。

• 安装时：如果装好了，再次运行就不会重复安装。

• 卸载时：如果已经删了，再次运行就不会报错说“找不到”。

这意味着，你可以把这段卸载代码拿去反复执行，无论服务器当前处于什么状态，最终的结果都是“干干净净，什么都没有”。

3. 实战意义与扩展

这个“卸载脚本”在实际工作中非常有用，特别是在测试环境中：

1. 快速重置环境：当你测试完一套复杂的服务部署后，不需要一台台机器手动去敲 yum remove、rm -rf，只需要运行这个 Playbook，几秒钟就能把环境恢复到初始状态，方便进行下一轮测试。

2. 灰度下线：在正式环境中，如果需要下线某个服务，这个脚本可以确保服务、用户、残留文件被彻底清理，不给系统留垃圾。

💡 扩展思考：

如果你想做得更严谨，可以在卸载软件（yum）那个任务后面加上 notify，触发一个 Handler 来清理开机自启项，确保服务彻底停止运行。不过对于简单的卸载任务，这样写已经完全够用了。

 

这张图的核心内容是 Ansible 实现 NFS（网络文件系统）的自动化挂载。

这是一个非常经典的“配置管理 + 存储挂载”的实战案例。它演示了如何将管理端的本地目录共享出去，并让被管理的多台机器自动挂载到本地，从而实现文件的跨机器共享。

我把图中的步骤拆解为“服务端配置”和“客户端自动化挂载”两部分来解析：

第一部分：管理端配置 NFS 服务端（手动步骤）

在管理端（192.168.171.128）上，需要完成以下准备工作：

1. 定义主机清单：

   • 在 /etc/ansible/hosts文件中定义了 [test]组，包含了两个被管理端的 IP（129 和 130）。这是 Ansible 能够批量操作这两台机器的前提。

2. 安装与配置 NFS 服务：

   • yum -y install nfs-utils：安装 NFS 服务端软件。

   • vim /etc/exports：编辑配置文件。

     • 写入 /data *(rw,no_root_squash)。

     • 含义：将本地的 /data目录共享给所有人（*），赋予读写权限（rw），并且允许客户端以 root 身份访问（no_root_squash）。

   • ls /data/a.txt：检查共享目录中是否有测试文件。

   • systemctl start nfs：启动 NFS 服务。

第二部分：被管理端自动化挂载（Playbook 核心）

图中下方的 web_mount.yaml是核心，它实现了批量挂载：

yaml

• hosts: test # 目标：test 组的两台机器

  remote_user: root # 权限：root

  gather_facts: no

  tasks:

  • name: Mount nfs server share data

    mount: # 核心模块：mount

    src=192.168.171.128:/data # 源：管理端的共享路径

    path=/data # 目标：挂载到被管端的 /data 目录

    fstype=nfs # 类型：指定为 nfs

    opts=defaults # 选项：默认挂载参数

    state=mounted # 状态：关键参数

核心知识点：mount模块的 state参数

图中底部特别标注了 state参数的两种用法，这是运维中的高频考点：

1. state=mounted（图中使用的）：

   • 效果：“立即挂载 + 永久生效”。

   • 它不仅会在执行 Playbook 时立刻执行挂载命令，还会自动修改被控端的 /etc/fstab文件。这意味着即使服务器重启，挂载关系依然存在。

2. state=absent（图中提到的对比项）：

   • 效果：“立即卸载 + 清除配置”。

   • 它会立刻卸载掉挂载点，并且把 /etc/fstab中关于这个挂载的记录删掉，彻底断开联系。

总结

这个案例展示了 Ansible 在基础设施运维中的强大之处：你只需要维护好管理端的 NFS 服务和 Ansible 的 Playbook，无论被管理端有多少台机器，都可以一键完成存储挂载，无需人工逐一登录服务器执行 mount命令。