介绍
在本实验中，你将系统学习如何使用 Ansible 在 Red Hat Enterprise Linux（RHEL）系统上部署、维护和管理文件。这是进行 Linux 自动化运维与配置管理的基础技能之一。你将亲自实践多个常用且功能强大的 Ansible 文件管理模块，内容涵盖从基础文件复制到更高级的内容编辑、状态校验与资源清理。
你将首先使用 ansible.builtin.copy 模块分发静态文件并设置文件属性。随后，你会借助 lineinfile 和 blockinfile 对文件内容进行精确修改，并通过 ansible.builtin.template 模块生成自定义 MOTD。实验还包括创建符号链接、使用 stat 检查文件状态、通过 fetch 拉取日志文件，以及清理已管理文件等操作，帮助你全面掌握 Ansible 在文件管理场景中的核心能力。
使用 ansible.builtin.copy 模块复制静态文件并设置属性
使用 ansible.builtin.copy 模块复制静态文件并设置属性
在本步骤中，你将学习如何使用最常见的 Ansible 模块之一：ansible.builtin.copy。该模块用于将文件从控制节点（LabEx VM）复制到受管主机上的指定路径。在本实验中，受管主机就是 localhost。本模块不仅可以完成文件复制，还能精确设置文件的所有者、所属组和权限模式，这对于 Linux 系统配置和安全管理非常重要。
首先，让我们准备实验环境。接下来的所有操作都将在 ~/project 目录中完成。
- 进入项目目录，并为源文件创建一个子目录。 这是整理 Ansible 项目结构的常见做法，有助于后续维护。
安装 ansible-core 包。
sudo dnf install -y ansible-core
然后，进入项目目录并创建用于存放源文件的子目录。
cd ~/project
mkdir files
2. 接着，创建一个简单的文本文件作为复制源文件。 我们将使用 cat 命令结合 here document，在 files 目录中创建 info.txt 文件。
cat << EOF > ~/project/files/info.txt
This file was deployed by Ansible.
It contains important system information.
EOF
3. 现在，创建一个 Ansible inventory 文件。 inventory 文件用于定义 Ansible 需要管理的主机列表。在本次实验中，我们只管理本机。创建一个名为 inventory.ini 的文件。
cat << EOF > ~/project/inventory.ini
localhost ansible_connection=local
EOF
在这个 inventory 中，localhost 是目标主机。变量 ansible_connection=local 表示 Ansible 直接在控制节点本地执行任务，而不是通过 SSH 远程连接。
4. 创建你的第一个 Ansible playbook。 该 playbook 将包含复制文件的任务。使用 nano 或 cat 创建一个名为 copy_file.yml 的文件。
nano ~/project/copy_file.yml
将以下内容写入文件。这个 playbook 定义了一个任务：将 info.txt 复制到 /tmp/ 目录，并设置对应的文件属性。
---
- name: Deploy a static file to localhost
hosts: localhost
tasks:
- name: Copy info.txt and set attributes
ansible.builtin.copy:
src: files/info.txt
dest: /tmp/info.txt
owner: labex
group: labex
mode: "0640"
下面是 copy 任务中各参数的含义：
- src: files/info.txt: 控制节点上的源文件路径，相对于 playbook 所在目录。
- dest: /tmp/info.txt: 文件在受管主机上的目标绝对路径。
- owner: labex: 将文件所有者设置为 labex 用户。
- group: labex: 将文件所属组设置为 labex 组。
- mode: '0640': 设置文件权限。0640 表示所有者可读可写、组用户可读、其他用户无权限。
5. 使用 ansible-playbook 命令运行 playbook。 其中 -i 参数用于指定 inventory 文件。
ansible-playbook -i inventory.ini copy_file.yml
你应该会看到类似如下的输出，表示 playbook 已成功执行：
PLAY [Deploy a static file to localhost] ***************************************
TASK [Gathering Facts] *********************************************************
ok: [localhost]
TASK [Copy info.txt and set attributes] ****************************************
changed: [localhost]
PLAY RECAP *********************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
6. 最后，验证文件是否已成功复制，并确认文件属性是否正确。使用 ls -l 命令查看权限、所有者和所属组。
ls -l /tmp/info.txt
输出应显示 labex 为文件所有者和所属组，权限为 -rw-r----。
-rw-r----- 1 labex labex 72 Jul 10 14:30 /tmp/info.txt
你还可以查看文件内容，确认文件已被完整复制。
cat /tmp/info.txt
This file was deployed by Ansible.
It contains important system information.
至此，你已经成功使用 ansible.builtin.copy 模块在本地系统中部署文件，并完成了文件属性配置。
使用 lineinfile 和 blockinfile 修改文件内容
使用 lineinfile 和 blockinfile 修改文件内容
在本步骤中，你将学习如何在不替换整个文件的前提下修改受管主机上的现有文件。Ansible 为此提供了两个非常实用的模块：ansible.builtin.lineinfile 用于管理单行内容，ansible.builtin.blockinfile 用于插入或维护多行文本块。这些模块特别适合用于编辑配置文件、插入注释信息或追加标准化内容。
我们将继续使用上一步创建的 /tmp/info.txt 文件。
1. 首先，确认你位于项目目录中。
cd ~/project
2. 创建一个名为 modify_file.yml 的新 playbook。该 playbook 将包含两个任务：一个用于添加单行文本，另一个用于向文件中插入多行文本块。
nano ~/project/modify_file.yml
3. 将以下内容添加到 modify_file.yml playbook 中。 该 playbook 以 localhost 为目标，并使用 lineinfile 与 blockinfile 向 /tmp/info.txt 追加内容。
---
- name: Modify an existing file
hosts: localhost
tasks:
- name: Add a single line of text to a file
ansible.builtin.lineinfile:
path: /tmp/info.txt
line: This line was added by the lineinfile module.
state: present
- name: 向现有文件中插入一段文本
ansible.builtin.blockinfile:
path: /tmp/info.txt
block: |
## BEGIN ANSIBLE MANAGED BLOCK
这里会写入一段包含两行内容的文本。
这两行内容由 blockinfile 模块追加到文件中。
## END ANSIBLE MANAGED BLOCK
state: present
下面来理解一下这里使用的模块：
- ansible.builtin.lineinfile: 该模块确保某一指定文本行存在于文件中。如果该行已经存在，Ansible 不会重复写入，因此具有良好的幂等性。
- path: 要修改的目标文件路径。
- line: 需要确保存在于文件中的那一行文本。
- state: present: 表示确保该行存在。若设置为 state: absent，则表示删除该行。
- ansible.builtin.blockinfile: 该模块用于管理由标记包围的多行文本块，非常适合维护配置片段或批量插入文本。
- path: 要编辑的文件路径。
- block: 要写入的多行内容。YAML 中的 | 表示字面量块写法，会保留原始换行格式。
- state: present: 确保该文本块存在于目标文件中。
4. 使用 ansible-playbook 命令结合 inventory.ini 文件执行 playbook。
ansible-playbook -i inventory.ini modify_file.yml
输出将显示两个任务都已对目标文件执行修改。
PLAY [Modify an existing file] *************************************************
TASK [Gathering Facts] *********************************************************
ok: [localhost]
TASK [Add a single line of text to a file] *************************************
changed: [localhost]
TASK [Add a block of text to an existing file] *********************************
changed: [localhost]
PLAY RECAP *********************************************************************
localhost : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
5. 最后，通过查看 /tmp/info.txt 的内容验证修改结果。
cat /tmp/info.txt
你应该能看到原始内容之后，新增了一行文本以及一段新的文本块。
This file was deployed by Ansible.
It contains important system information.
This line was added by the lineinfile module.
## BEGIN ANSIBLE MANAGED BLOCK
This block of text consists of two lines.
They ha ve been added by the blockinfile module.
## END ANSIBLE MANAGED BLOCK
如果你再次执行该 playbook，Ansible 会报告 ok=3 和 changed=0，因为目标内容已经存在，这正体现了这些模块的幂等性特性。
使用 ansible.builtin.template 模块生成自定义 MOTD
使用 ansible.builtin.template 模块生成自定义 MOTD
在本步骤中，你将从复制静态文件进一步提升到生成动态文件内容，使用的核心模块是 ansible.builtin.template。该模块基于 Jinja2 模板引擎，可结合 Ansible 从受管主机收集到的变量和系统 facts，动态生成定制化文件。我们将以每日消息（MOTD）为例，创建一个包含系统信息的动态欢迎文本。
1. 首先，确认你位于 ~/project 目录中，并创建一个专门存放模板文件的子目录。 在 Ansible 项目中，将 Jinja2 模板放入 templates 目录是一种推荐做法。
cd ~/project
mkdir templates
2. 接下来，创建 Jinja2 模板文件。 该文件名为 motd.j2，用于定义 MOTD 的输出结构，其中会包含动态变量占位符。.j2 扩展名是 Jinja2 模板的标准命名习惯。
nano ~/project/templates/motd.j2
将以下内容添加到文件中。请注意 {{ ... }} 语法，这表示变量或系统 fact 的占位位置。
#################################################################
## Welcome to {{ ansible_facts['fqdn'] }}
#
## This is a {{ ansible_facts['distribution'] }} system.
## System managed by Ansible.
#
## For support, contact: {{ admin_email }}
#################################################################
在此模板中：
- {{ ansible_facts['fqdn'] }} 会被替换为主机的完全限定域名（Fully Qualified Domain Name）。
- {{ ansible_facts['distribution'] }} 会被替换为当前 Linux 发行版名称，例如 RedHat。
- {{ admin_email }} 是一个自定义变量，我们将在 playbook 中进行定义。
3. 现在，创建一个名为 template_motd.yml 的新 playbook。该 playbook 将基于模板生成 /etc/motd 文件。
nano ~/project/template_motd.yml
添加以下内容。由于需要写入 /etc 目录，因此此 playbook 需要使用提权权限（become: true）。同时，它还定义了一个自定义变量 admin_email。
---
- name: Deploy a custom MOTD from a template
hosts: localhost
become: true
vars:
admin_email: admin@labex.io
tasks:
- name: Generate /etc/motd from template
ansible.builtin.template:
src: templates/motd.j2
dest: /etc/motd
owner: root
group: root
mode: "0644"
这个 playbook 中的关键点包括：
- become: true: 告诉 Ansible 使用 sudo 提权执行任务，这是写入 /etc/motd 所必需的。
- vars: 用于定义自定义变量，例如这里的 admin_email。
- ansible.builtin.template: 负责处理 Jinja2 模板的模块。src 指向模板文件，dest 指定生成后的目标文件路径。
4. 执行 playbook。
ansible-playbook -i inventory.ini template_motd.yml
输出应显示任务已经成功完成。
PLAY [Deploy a custom MOTD from a template] ************************************
TASK [Gathering Facts] *********************************************************
ok: [localhost]
TASK [Generate /etc/motd from template] ****************************************
changed: [localhost]
PLAY RECAP *********************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
5. 验证结果。 查看新生成的 /etc/motd 文件内容。
cat /etc/motd
你将看到模板渲染后的结果，其中 Jinja2 占位符已被实际系统 facts 和自定义变量值替换。fqdn 会与你当前实验环境中的主机名一致。
#################################################################
## Welcome to host.labex.io
#
## This is a RedHat system.
## System managed by Ansible.
#
## For support, contact: admin@labex.io
#################################################################
至此，你已经成功使用模板生成了一个定制化文件。这是 Ansible 自动化运维和基础设施即代码中的一项关键技能。
使用 copy 和 file 模块部署支持文件并创建符号链接
使用 copy 和 file 模块部署支持文件并创建符号链接
在本步骤中，你将结合 copy 模块和另一个功能强大的模块：ansible.builtin.file。copy 模块负责传输文件内容，而 file 模块则用于管理受管主机上的文件、目录及符号链接状态。你将使用它来管理系统文件、设置权限，并重点学习如何创建符号链接。
本节的场景是配置系统登录前提示信息。在很多 Linux 系统中，/etc/issue 用于向本地终端用户显示提示信息，而 /etc/issue.net 则常用于向远程连接用户（如 SSH 登录用户）显示内容。我们将先部署一个 issue 文件，再创建一个符号链接，让 /etc/issue.net 指向 /etc/issue，从而保证两者始终显示相同的消息内容。
1. 首先，确认你位于 ~/project 目录中，并创建 issue 消息源文件。 我们将把该文件存放到之前创建的 files 子目录中。
cd ~/project
cat << EOF > ~/project/files/issue
Authorized access only.
All connections are logged and monitored.
EOF
2. 创建一个名为 deploy_issue.yml 的新 playbook。该 playbook 将包含两个任务：一个用于复制 issue 文件，另一个用于创建符号链接。
nano ~/project/deploy_issue.yml
3. 将以下内容添加到 deploy_issue.yml playbook 中。 由于需要管理 /etc/ 目录下的系统文件，因此该 playbook 需要提权执行（become: true）。
---
- name: Configure system issue files
hosts: localhost
become: true
tasks:
- name: Copy custom /etc/issue file
ansible.builtin.copy:
src: files/issue
dest: /etc/issue
owner: root
group: root
mode: "0644"
这段配置的作用非常明确：确保 /etc/issue.net 始终以符号链接的形式指向 /etc/issue。对应的 Ansible 写法如下：
- name: Ensure /etc/issue.net is a symlink to /etc/issue
ansible.builtin.file:
src: /etc/issue
dest: /etc/issue.net
state: link
force: yes
下面来分析这个新的 ansible.builtin.file 任务：
- src: /etc/issue: 当 state 设置为 link 时，src 表示符号链接最终指向的源文件。
- dest: /etc/issue.net: 这是将要创建的符号链接路径。
- state: link: 该关键参数表示 file 模块要创建的是符号链接，而不是普通文件或目录。
- force: yes: 这是一个很实用的选项，可增强幂等性。如果 /etc/issue.net 已经以普通文件形式存在，Ansible 会先删除它，再创建正确的链接。如果不使用 force: yes，遇到这种情况时 playbook 可能会执行失败。
4. 执行 playbook。
ansible-playbook -i inventory.ini deploy_issue.yml
输出会显示两个任务都已成功完成变更。
PLAY [Configure system issue files] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [localhost]
TASK [Copy custom /etc/issue file] *********************************************
changed: [localhost]
TASK [Ensure /etc/issue.net is a symlink to /etc/issue] ************************
changed: [localhost]
PLAY RECAP *********************************************************************
localhost : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
5. 使用 ls -l 命令验证结果。 该命令可以通过详细列表直观显示符号链接状态。
ls -l /etc/issue /etc/issue.net
输出应显示 /etc/issue 是普通文件，而 /etc/issue.net 是一个指向它的符号链接。/etc/issue.net 权限字段开头的 l 表示这是一个链接文件。
-rw-r--r--. 1 root root 65 Jul 10 15:00 /etc/issue
lrwxrwxrwx. 1 root root 10 Jul 10 15:00 /etc/issue.net -> /etc/issue
到这里，你已经成功部署了一个系统配置文件，并通过 ansible.builtin.file 模块创建了符号链接。这是 Linux 系统配置自动化中非常常见且实用的管理模式。
使用 stat 验证文件状态并使用 fetch 检索日志
使用 stat 验证文件状态并使用 fetch 检索日志
在本步骤中，你将学习两个非常重要的 Ansible 数据收集模块：ansible.builtin.stat 和 ansible.builtin.fetch。stat 模块用于检查受管主机上某个文件或目录的状态，例如文件是否存在、权限是否正确、是否为普通文件以及最后修改时间等。它不会对目标做任何修改，因此非常适合用于前置检查和条件判断。fetch 模块则与 copy 模块作用相反：它会从受管主机拉取文件，并保存到控制节点本地，常用于备份配置文件或收集系统日志进行分析。
我们将创建一个 playbook，先检查你前面生成的 /etc/motd 文件是否存在，然后把 DNF 包管理器日志文件（/var/log/dnf.log）拉取到 LabEx VM 的本地目录中。
1. 首先，确认你位于 ~/project 目录中，并创建一个新的子目录用于保存拉取回来的文件。
cd ~/project
mkdir fetched_logs
2. 创建一个名为 check_and_fetch.yml 的新 playbook。该 playbook 将包含文件检查和日志拉取两个任务。
nano ~/project/check_and_fetch.yml
3. 将以下内容添加到 check_and_fetch.yml playbook 中。 该 playbook 使用 stat 获取文件信息，通过 register 保存结果，使用 debug 输出变量内容，并通过 fetch 拉取日志文件。
---
- name: Check file status and fetch logs
hosts: localhost
become: true
tasks:
- name: Check if /etc/motd exists
ansible.builtin.stat:
path: /etc/motd
register: motd_status
- name: Display stat results
ansible.builtin.debug:
var: motd_status.stat
- name: Fetch the dnf log file from managed host
ansible.builtin.fetch:
src: /var/log/dnf.log
dest: fetched_logs/
flat: yes
下面是几个关键概念的说明：
- register: motd_status: 这是 Ansible 中非常重要的机制，用于把任务的完整输出注册到一个变量中，这里变量名为 motd_status。
- ansible.builtin.debug: 该模块用于在 playbook 执行时输出变量内容。这里我们打印 motd_status.stat，以便查看 stat 返回的文件属性信息。
- ansible.builtin.fetch: 该模块用于从受管主机拉取文件到控制节点。
- src: 指定受管主机上要拉取的源文件路径。
- dest: 指定控制节点（LabEx VM）上保存文件的目录。
- flat: yes: 默认情况下，fetch 会根据主机名和源路径创建额外的目录层级。设置 flat: yes 后，文件将直接保存到 dest 目录中，目录结构更加简洁。
4. 执行 playbook。 由于需要读取系统日志文件，因此这里使用 become: true 获取必要权限。
ansible-playbook -i inventory.ini check_and_fetch.yml
输出会先展示 debug 任务打印的 stat 检查结果，随后执行 fetch 拉取日志文件。
PLAY [Check file status and fetch logs] ****************************************
TASK [Gathering Facts] *********************************************************
ok: [localhost]
TASK [Check if /etc/motd exists] ***********************************************
ok: [localhost]
TASK [Display stat results] ****************************************************
ok: [localhost] => {
"motd_status.stat": {
"exists": true,
"gid": 0,
"isreg": true,
"mode": "0644",
"path": "/etc/motd",
...
}
}
TASK [Fetch the dnf log file from managed host] ********************************
changed: [localhost]
PLAY RECAP *********************************************************************
localhost : ok=4 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
5. 验证日志文件是否已成功拉取。 查看 fetched_logs 目录中的内容。
ls -l ~/project/fetched_logs/
你应该会看到 dnf.log 文件，说明它已经从受管主机成功保存到控制节点本地。
total 4
-rw-r--r--. 1 labex labex 1234 Jul 10 15:30 dnf.log
现在，你已经掌握了如何在不修改目标文件的情况下检查文件属性，以及如何把受管系统中的关键文件或日志拉回到控制节点进行分析。
使用 file 模块清理已管理主机上的文件
使用 file 模块清理已管理主机上的文件
在最后这个步骤中，你将学习如何使用 ansible.builtin.file 模块确保文件和目录在系统中 *不存在*。在配置管理中，除了创建和修改资源之外，清理资源同样是非常关键的一部分。通过把 state 参数设置为 absent，你可以让 Ansible 删除文件、符号链接，甚至整个目录。
为了完成本次实验，我们将编写一个统一的“清理”playbook，用来删除前面步骤中创建的所有文件，包括：/tmp/info.txt、/etc/motd、/etc/issue 以及 /etc/issue.net 符号链接。
1. 首先，确认你位于 ~/project 目录中。
cd ~/project
2. 创建一个名为 cleanup.yml 的新 playbook。该 playbook 将包含撤销本实验更改所需的全部任务。
nano ~/project/cleanup.yml
3. 将以下内容添加到 cleanup.yml playbook 中。 该 playbook 使用任务列表依次删除我们创建的文件。请注意，become: true 是在 play 级别设置的，因此所有任务都将以提权方式执行。
---
- name: Clean up managed files from the system
hosts: localhost
become: true
tasks:
- name: Remove the temporary info file
ansible.builtin.file:
path: /tmp/info.txt
state: absent
- name: Remove the custom MOTD file
ansible.builtin.file:
path: /etc/motd
state: absent
- name: Remove the custom issue file
ansible.builtin.file:
path: /etc/issue
state: absent
- name: Remove the issue.net symbolic link
ansible.builtin.file:
path: /etc/issue.net
state: absent
这个 playbook 的关键就在于每个任务中的 state: absent 参数。它表示 file 模块要确保指定 path 对应的对象不存在。如果文件存在，Ansible 会将其删除；如果文件本来就不存在，则不会做任何更改，从而继续保持幂等性。
4. 执行清理 playbook。
ansible-playbook -i inventory.ini cleanup.yml
输出将显示每个任务都通过删除文件完成了变更。
PLAY [Clean up managed files from the system] **********************************
TASK [Gathering Facts] *********************************************************
ok: [localhost]
TASK [Remove the temporary info file] ******************************************
changed: [localhost]
TASK [Remove the custom MOTD file] *********************************************
changed: [localhost]
TASK [Remove the custom issue file] ********************************************
changed: [localhost]
TASK [Remove the issue.net symbolic link] **************************************
changed: [localhost]
PLAY RECAP *********************************************************************
localhost : ok=5 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
5. 验证文件是否已被成功删除。 你可以使用 ls 命令检查这些路径是否仍然存在。由于它们已被删除，命令会提示无法访问。
ls /tmp/info.txt /etc/motd /etc/issue /etc/issue.net
预期输出是一组错误信息，这恰好说明清理操作已经成功完成。
ls: cannot access '/tmp/info.txt': No such file or directory
ls: cannot access '/etc/motd': No such file or directory
ls: cannot access '/etc/issue': No such file or directory
ls: cannot access '/etc/issue.net': No such file or directory
至此，你已经成功使用 Ansible 删除文件并完成系统清理，掌握了从创建、修改到删除的完整文件管理生命周期。
总结
在本实验中，你系统学习了如何使用 Ansible 在 RHEL 系统上进行文件管理与自动化配置。你首先通过 ansible.builtin.copy 模块将静态文件部署到受管主机，并设置文件所有权和权限。随后，你使用 lineinfile 确保特定行存在，使用 blockinfile 管理多行文本块，从而掌握了对现有文件内容进行精细化修改的方法。你还学习了如何借助 ansible.builtin.template 模块和 Jinja2 语法生成动态文件内容，并据此创建包含系统 facts 的自定义 MOTD。
此外，你还实践了使用 ansible.builtin.file 模块部署支持文件和创建符号链接。为了验证部署结果，你使用 stat 模块检查文件状态和属性，并使用 fetch 模块将日志等文件从受管主机拉取到控制节点。最后，你通过为 file 模块设置 state: absent，完成了对实验中创建文件的清理操作，进一步掌握了 Ansible 文件管理从部署到回收的完整流程。这些内容也是学习 Ansible 自动化运维、Linux 配置管理和基础设施即代码的重要基础。
