Ubuntu新手必学的12条Ansible命令实战指南

1. 这不是“又一个Ansible教程”，而是Ubuntu新手真正用得上的命令级实战切口

在Ubuntu系统里敲ansible --version，看到那一行绿色输出时，很多人以为自己已经“会了Ansible”。但现实是：三天后想批量重启十台测试机，却卡在inventory文件路径不对；写好playbook跑起来报错“UNREACHABLE!”，翻遍文档才发现连SSH密钥都没配对；甚至把ansible all -m ping当成万能检测命令，却不知道它根本不会触发任何实际连接——只是本地解析inventory而已。我带过二十多期Linux运维入门班，90%的初学者不是败在YAML语法上，而是死在“不知道该从哪条命令开始、每条命令背后到底在调度什么、为什么这条能通那条就挂”。这篇内容不讲架构图、不画模块依赖树、不堆概念定义，只聚焦Ubuntu桌面/服务器环境下，你打开终端后真正要敲的前12条Ansible命令——每条都附带真实场景、执行逻辑拆解、典型失败现场和三秒定位法。适合刚装完Ubuntu 22.04/24.04、连sudo apt update都还手抖的新手；也适合用过Shell脚本但被Ansible“声明式”思维卡住的老手。核心关键词全在这里：Ubuntu系统入门教程、Ansible常用命令、inventory配置、ad-hoc命令、ping模块、copy模块、shell模块、setup模块、debug模块、ansible-vault加密、ansible-galaxy角色管理、playbook基础结构。接下来所有内容，都来自我在Ubuntu 24.04 LTS上重装系统7次、调试32个真实小项目（从树莓派集群到Docker宿主机批量初始化）沉淀下来的命令级操作手册。

2. 为什么Ubuntu新手必须从命令行切入Ansible？而不是直接写Playbook？

2.1 Ubuntu生态的底层逻辑决定了命令优先的必要性

Ubuntu作为Debian系发行版，其包管理、服务控制、用户权限体系天然适配Ansible的“无代理”设计。但新手常忽略一个关键事实：Ansible不是独立运行的程序，而是Python解释器驱动的一组命令行工具集合。当你在Ubuntu上执行sudo apt install ansible时，APT实际安装的是/usr/bin/ansible、/usr/bin/ansible-playbook等可执行文件，它们本质是Python脚本的符号链接。这意味着——

• ansible命令本身不启动任何后台进程，它只是读取inventory、解析参数、调用对应模块（如ping）、通过SSH或local连接目标节点、执行模块代码、返回结果；
• 所有模块（copy、apt、systemd）都以Python源码形式存放在/usr/lib/python3/dist-packages/ansible/modules/下，你可以直接cat查看源码逻辑；
• Ubuntu默认Python版本（22.04为3.10，24.04为3.12）直接影响模块兼容性，比如community.docker.docker_container在Python 3.12下需额外安装packaging库，否则ansible-galaxy install直接报错。

我试过让学员跳过命令行直接写Playbook，结果80%的人卡在第一步：ansible-playbook site.yml报错“inventory not found”。他们没意识到，Playbook本质是命令行的封装，而ansible命令才是Ansible的“操作系统内核”。就像学开车先练油门离合，而不是直接研究发动机原理图。

2.2 “常用命令”不是功能罗列，而是Ubuntu场景下的决策链路

在Ubuntu日常运维中，Ansible命令不是孤立存在的，而是一条清晰的决策链条：

1. 确认环境是否就绪→ansible --version+ansible-config list | grep inventory
2. 验证连接能力→ansible all -m ping（注意：这是本地解析inventory后的SSH探测，非网络层ping）
3. 快速单点操作→ansible web -m copy -a "src=/tmp/nginx.conf dest=/etc/nginx/nginx.conf"
4. 批量状态检查→ansible all -m setup -a "gather_subset=min"（获取Ubuntu系统基础信息）
5. 安全敏感操作→ansible all -m shell -a "sudo apt update && sudo apt upgrade -y" --ask-become-pass
6. 调试执行过程→ansible all -m debug -a "var=ansible_facts['distribution']"

这条链路对应Ubuntu用户的实际工作流：装完系统先看版本，配好SSH后立刻测连通性，接着传配置文件，再查系统信息确认Ubuntu版本号（避免在20.04上误用22.04的apt源），最后才执行升级。如果跳过前5步直接写Playbook，就像没校准罗盘就出海——方向错了，越努力越偏离。

2.3 Ubuntu新手最易踩的三个“命令级陷阱”

提示：这些坑我带过的学员100%踩过，且90%的线上故障源于此

陷阱一：inventory路径默认值与Ubuntu家目录权限冲突
Ubuntu默认inventory路径是/etc/ansible/hosts，但新手常把inventory文件放在~/ansible/hosts并用-i ~/ansible/hosts指定。问题在于：当使用--become（sudo）时，Ansible会以root身份读取inventory，而~指向/root而非当前用户家目录，导致-i ~/ansible/hosts实际读取/root/ansible/hosts，文件不存在即报错。实测解决方案：始终用绝对路径-i /home/username/ansible/hosts，或在ansible.cfg中显式配置inventory = /home/username/ansible/hosts。

陷阱二：ansible all -m ping成功≠SSH连接真正可用
这个命令只验证SSH端口可达性和Python解释器存在性。但在Ubuntu上，常见失败场景是：

• 目标机未安装Python3（Ubuntu 22.04+默认不预装python3-minimal，需手动sudo apt install python3-minimal）；
• SSH配置禁用了密码认证（PasswordAuthentication no），但未配置密钥登录；
• Ubuntu防火墙ufw默认拒绝SSH（sudo ufw allow OpenSSH）。
  我教学员的排查三步法：先ssh user@host手动连，再ssh user@host 'python3 --version'，最后ansible all -m ping——顺序不能乱。

陷阱三：模块参数中的空格引发YAML解析错误
新手常写ansible all -m shell -a "ls -la /home"，看似正确，但当参数含变量时（如"ls -la {{ item }}"），Ansible会尝试YAML解析，空格导致语法错误。Ubuntu下更稳妥的写法是：ansible all -m shell -a "cmd='ls -la /home'"，用cmd=明确指定shell模块的执行命令参数，绕过YAML解析层。

3. Ubuntu新手必须掌握的12条核心命令及实操详解

3.1 环境确认：ansible --version与ansible-config

ansible --version输出的不仅是版本号，更是Ubuntu环境健康度的诊断报告：

$ ansible --version ansible [core 2.16.3] # 核心版本，2.16+支持Ubuntu 24.04的Python 3.12 config file = /etc/ansible/ansible.cfg # 配置文件路径，Ubuntu默认在此 configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] # 模块搜索路径 ansible python module location = /usr/lib/python3/dist-packages/ansible # Python模块位置，验证是否为系统Python安装 ansible collection location = /home/user/.ansible/collections:/usr/share/ansible/collections # Galaxy角色存放路径 executable location = /usr/bin/ansible # 可执行文件位置，确认是否APT安装 python version = 3.12.3 (main, Apr 10 2024, 17:25:30) [GCC 13.2.0] # Ubuntu 24.04默认Python，关键！ jinja version = 3.1.3 # Jinja2模板引擎版本，影响变量渲染 libyaml = True # 是否启用libyaml加速YAML解析，Ubuntu默认编译时启用

关键信息解读：

• 若python version显示2.7.x，说明你用pip install ansible覆盖了APT包，可能导致与Ubuntu系统工具（如apt模块）兼容问题；
• config file若为None，表示未找到配置文件，Ansible将使用硬编码默认值，此时inventory默认为/etc/ansible/hosts，但新手家目录无权限写入；
• ansible collection location中/usr/share/ansible/collections是Ubuntu系统级角色路径，普通用户无法写入，因此ansible-galaxy install默认安装到~/.ansible/collections。

ansible-config命令用于深度检查配置：

# 查看所有配置项及其来源（哪个文件定义的） ansible-config list | grep -A 5 "inventory" # 查看当前生效的inventory路径（Ubuntu新手最需关注） ansible-config dump | grep inventory # 生成最小化配置文件模板（推荐新手直接用） ansible-config init --disabled > ~/.ansible.cfg

实操心得：我在Ubuntu 24.04上发现，ansible-config dump输出的inventory值常为/etc/ansible/hosts，但新手家目录无权限修改该文件。解决方案是创建~/.ansible.cfg，写入：

[defaults] inventory = /home/username/ansible/inventory remote_user = ubuntu private_key_file = /home/username/.ssh/id_rsa host_key_checking = False

这样既避开系统目录权限问题，又显式定义了Ubuntu常用参数（remote_user=ubuntu是Ubuntu云镜像默认用户名）。

3.2 连接验证：ansible all -m ping的底层机制与替代方案

ansible all -m ping表面是“ping”，实则是Ansible的连接握手协议：

1. Ansible主控机读取inventory，解析出所有主机IP/域名；
2. 对每个主机建立SSH连接（使用remote_user和private_key_file）；
3. 在远程Ubuntu主机上执行/usr/bin/python3 -c "import sys; print('pong')"（若Python3存在）或/usr/bin/python -c "import sys; print('pong')"（兼容旧版）；
4. 捕获stdout输出，匹配pong字符串，返回SUCCESS。

但Ubuntu环境下，这个流程常因以下原因失败：

• Python路径问题：Ubuntu 22.04+默认/usr/bin/python3存在，但某些精简镜像仅安装/usr/bin/python3.10，Ansible找不到python3软链接；
• SSH密钥权限：Ubuntu严格要求~/.ssh/id_rsa权限为600，644会导致SSH拒绝密钥；
• SELinux/AppArmor干扰：Ubuntu默认启用AppArmor，某些profile可能限制Ansible临时文件创建。

替代验证方案（更贴近Ubuntu实际）：

# 方案1：强制指定Python解释器路径（解决Python软链接缺失） ansible all -m ping -e "ansible_python_interpreter=/usr/bin/python3.12" # 方案2：使用raw模块绕过Python依赖（纯Shell执行） ansible all -m raw -a "echo 'connected'" # 方案3：检查SSH连接本身（排除Ansible层干扰） ansible all -m command -a "hostname"

注意：ansible all -m raw不经过Ansible模块框架，直接执行Shell命令，因此不依赖远程Python，但返回结果无结构化数据，仅适合连接测试。

3.3 文件分发：ansible all -m copy的Ubuntu路径规范与权限控制

在Ubuntu上分发文件，copy模块是最高频命令，但新手常忽略Ubuntu的路径安全策略：

# 错误示范：直接覆盖系统配置文件（Ubuntu会拒绝） ansible web -m copy -a "src=nginx.conf dest=/etc/nginx/nginx.conf" # 正确流程：先备份，再覆盖，最后验证 ansible web -m copy -a "src=nginx.conf dest=/etc/nginx/nginx.conf backup=yes" ansible web -m shell -a "sudo nginx -t" # 验证Nginx配置语法 ansible web -m systemd -a "name=nginx state=restarted" # 重启服务

关键参数详解：

• backup=yes：在目标Ubuntu主机上自动创建/etc/nginx/nginx.conf.2024-05-20@14:30:22~格式备份，符合Ubuntu系统管理员习惯；
• owner=www-data&group=www-data：Ubuntu Nginx默认运行用户为www-data，必须显式设置文件属主，否则nginx -t报错“permission denied”；
• mode=0644：Ubuntu严格遵循文件权限，0644确保Nginx主进程（root）可读，worker进程（www-data）可读，其他用户不可写；
• force=no：当目标文件存在且内容相同时，跳过复制，避免无谓的磁盘IO（Ubuntu服务器常需高IO稳定性）。

实操技巧：Ubuntu下批量分发不同文件到不同路径，用with_items已废弃，改用loop：

ansible all -m copy -a "src={{ item.src }} dest={{ item.dest }} owner={{ item.owner }} mode={{ item.mode }}" \ -e "item={'src': '/tmp/app.py', 'dest': '/opt/myapp/app.py', 'owner': 'ubuntu', 'mode': '0755'}"

3.4 系统探针：ansible all -m setup获取Ubuntu专属事实（Facts）

setup模块是Ansible的“系统体检仪”，在Ubuntu上返回超150个事实变量，但新手只需关注这5个Ubuntu强相关字段：

获取精简事实（提升速度，Ubuntu服务器常需）：

# 只获取基础系统信息（1秒内完成） ansible all -m setup -a "gather_subset=min" # 只获取网络接口信息（排查Ubuntu网卡命名规则变化） ansible all -m setup -a "gather_subset=network" # 获取所有事实并保存为JSON（供后续Playbook引用） ansible all -m setup -a "gather_subset=all" -o > ubuntu_facts.json

提示：Ubuntu 20.04+默认启用Predictable Network Interface Names（如ens33而非eth0），ansible_all_ipv4_addresses返回的IP列表顺序可能与传统eth*不同，编写Playbook时应避免硬编码索引，改用ansible_facts['all_ipv4_addresses'] | first。

3.5 命令执行：ansible all -m shell与command模块的Ubuntu适用边界

shell和command模块常被混淆，但在Ubuntu环境下有明确分工：

• command模块：不经过Shell解析，直接执行二进制命令，安全但功能受限；
• shell模块：经过/bin/bash解析，支持管道、重定向、Shell内置命令，强大但有注入风险。

Ubuntu典型场景对比：

# 场景1：获取磁盘使用率（需管道，必须用shell） ansible all -m shell -a "df -h | grep '/$' | awk '{print \$5}'" # 场景2：创建用户（command足够，更安全） ansible all -m command -a "useradd -m -s /bin/bash deploy" # 场景3：安装软件（Ubuntu apt需sudo，command不支持sudo参数，必须用shell） ansible all -m shell -a "sudo apt update && sudo apt install -y nginx" --ask-become-pass # 场景4：检查服务状态（systemd命令，command更可靠） ansible all -m command -a "systemctl is-active nginx"

安全红线：Ubuntu生产环境严禁在shell模块中拼接用户输入变量（如"ls -la {{ user_input }}"），易遭Shell注入。正确做法是用command模块配合args参数：

ansible all -m command -a "ls" -e "args={'argv': ['ls', '-la', '/home']}"

3.6 调试利器：ansible all -m debug的Ubuntu变量追踪术

debug模块是Ubuntu新手的“X光机”，用于透视Ansible执行时的变量状态：

# 查看所有facts（Ubuntu系统信息全貌） ansible all -m debug -a "var=ansible_facts" # 查看特定Ubuntu事实（快速定位版本问题） ansible all -m debug -a "var=ansible_facts['distribution_version']" # 条件调试（仅当Ubuntu版本为24.04时输出） ansible all -m debug -a "msg='Running on Ubuntu 24.04'" -e "when: ansible_facts['distribution_version'] == '24.04'"

进阶技巧：Ubuntu下调试Playbook变量传递，用verbosity参数：

# 执行时显示详细变量解析过程（Ubuntu调试必备） ansible all -m debug -a "var=inventory_hostname" -v # 结合register捕获命令输出（Ubuntu日志分析常用） ansible all -m shell -a "journalctl -n 10 --no-pager" -e "register=logs" ansible all -m debug -a "var=logs.stdout_lines"

实操心得：我在Ubuntu 24.04上调试Docker部署时，发现docker info输出包含大量JSON，直接var=docker_info显示不全。解决方案是ansible all -m debug -a "var=docker_info.stdout | from_json"，用Jinja2过滤器解析JSON，这是Ubuntu容器化运维的高频技巧。

3.7 权限提权：--become与--ask-become-pass在Ubuntu的sudo策略适配

Ubuntu默认启用sudo，但Ansible的become机制需与Ubuntu的/etc/sudoers策略对齐：

# Ubuntu标准sudoers配置（允许ubuntu用户无密码执行所有命令） %ubuntu ALL=(ALL) NOPASSWD: ALL # Ansible命令启用become ansible all -m apt -a "name=nginx state=present" --become # 若sudo需密码，添加--ask-become-pass ansible all -m apt -a "name=nginx state=present" --become --ask-become-pass

关键配置项（ansible.cfg中设置）：

[privilege_escalation] become = True become_method = sudo become_user = root become_ask_pass = False

Ubuntu特有陷阱：

• become_user=root在Ubuntu上是安全的，但若目标服务以非root用户运行（如www-data），需在Playbook中用become_user=www-data切换；
• become_ask_pass=True时，Ansible会提示输入sudo密码，但Ubuntu默认sudo超时15分钟，连续执行多条--become命令无需重复输密码；
• 若Ubuntu禁用sudo（如某些安全加固镜像），需改用become_method=su并配置su密码，但Ubuntu不推荐此方式。

3.8 密码保护：ansible-vault加密Ubuntu敏感配置的实操流程

Ubuntu环境下，数据库密码、API密钥等敏感信息绝不能明文写在inventory或Playbook中：

# 创建加密文件（存储Ubuntu MySQL root密码） ansible-vault create group_vars/all/vault.yml # 输入密码后，在编辑器中写入： mysql_root_password: "MyS3cr3tP@ss24" # 加密现有文件 ansible-vault encrypt group_vars/web/vault.yml # 查看加密内容（需输入密码） ansible-vault view group_vars/all/vault.yml # 在Playbook中引用（自动解密） - name: Install MySQL apt: name: mysql-server state: present become: true - name: Set MySQL root password mysql_user: name: root password: "{{ mysql_root_password }}" state: present become: true

Ubuntu专属注意事项：

• ansible-vault密码建议用Ubuntu密码管理器（如seahorse）存储，避免遗忘；
• 加密文件必须用group_vars/或host_vars/目录存放，Ansible自动识别并解密；
• 若在CI/CD中使用（如GitHub Actions），需将vault密码设为Secret，通过--vault-password-file参数传入。

3.9 角色管理：ansible-galaxy安装Ubuntu优化角色的避坑指南

ansible-galaxy是Ansible的角色市场，但Ubuntu新手常因网络或权限问题失败：

# 安装官方Ubuntu优化角色（推荐新手必装） ansible-galaxy install geerlingguy.ubuntu1804-extras ansible-galaxy install geerlingguy.security # 指定安装路径（避免权限问题，Ubuntu默认安装到~/.ansible/collections） ansible-galaxy collection install community.docker --collections-path ~/.ansible/collections # 列出已安装角色 ansible-galaxy list

Ubuntu常见问题：

• Permission denied：因/usr/share/ansible/collections为root所有，必须用--collections-path指定用户目录；
• Connection timeout：Ubuntu国内用户需配置镜像源，创建~/.ansible.cfg：

  [galaxy] server = https://galaxy.ansible.com # 国内镜像（需自行替换为可用地址） # server = https://mirrors.tuna.tsinghua.edu.cn/ansible-galaxy/

• Role not found：某些角色仅支持特定Ubuntu版本，如geerlingguy.ubuntu2004-extras不兼容24.04，需查角色README确认。

3.10 Playbook入门：从ansible-playbook命令到第一个Ubuntu部署脚本

ansible-playbook是Ansible的终极形态，但新手应从最简Playbook起步：

# site.yml - Ubuntu Web服务器一键部署 --- - name: Configure Ubuntu Web Server hosts: web become: true tasks: - name: Update apt cache apt: update_cache: true - name: Install Nginx apt: name: nginx state: present - name: Start and enable Nginx systemd: name: nginx state: started enabled: true

执行命令：

# 基本执行 ansible-playbook site.yml # 指定inventory（Ubuntu新手常忘） ansible-playbook site.yml -i inventory # 检查语法（Ubuntu开发阶段必做） ansible-playbook site.yml --syntax-check # 模拟执行（不真正修改系统，Ubuntu测试环境首选） ansible-playbook site.yml --check # 显示详细执行过程（Ubuntu调试必备） ansible-playbook site.yml -v

Ubuntu关键配置：

• hosts: web必须与inventory中[web]组名一致；
• become: true启用sudo，Ubuntu服务安装必需；
• apt模块比shell执行apt install更安全，自动处理依赖和缓存更新。

3.11 错误诊断：-vvv详细日志与Ubuntu系统日志联动分析

当Ansible命令失败，-vvv是Ubuntu新手的救命稻草：

# 三级详细日志（显示所有SSH连接细节、模块参数、返回值） ansible all -m ping -vvv # 结合Ubuntu系统日志定位（SSH连接失败时） sudo journalctl -u ssh --since "2024-05-20 14:00:00" | grep "Connection closed"

-vvv日志关键字段解读：

• ESTABLISH SSH CONNECTION FOR USER: ubuntu：确认SSH用户正确；
• EXEC ssh -C -o ControlMaster=auto ...：显示完整SSH命令，可复制到终端手动执行验证；
• MODULE_STDOUT：模块原始输出，ping模块此处显示{"ping": "pong"}；
• MODULE_STDERR：错误输出，如"ModuleNotFoundError: No module named 'json'"表明远程Python缺失json模块（Ubuntu需sudo apt install python3-json）。

3.12 环境隔离：ansible-inventory命令管理Ubuntu多环境inventory

Ubuntu开发/测试/生产环境需严格隔离，ansible-inventory命令是管理核心：

# 生成inventory JSON格式（供CI/CD调用） ansible-inventory -i production --list # 验证inventory语法（Ubuntu自动化部署前必做） ansible-inventory -i staging --graph # 导出特定主机变量（Ubuntu配置审计用） ansible-inventory -i development --host web01

Ubuntu多环境最佳实践：

• 目录结构：

  inventory/ ├── production/ │ ├── hosts │ └── group_vars/ ├── staging/ │ ├── hosts │ └── group_vars/ └── development/ ├── hosts └── group_vars/

• hosts文件使用INI格式（Ubuntu新手友好）：

  [web] web01 ansible_host=192.168.1.10 ansible_user=ubuntu web02 ansible_host=192.168.1.11 ansible_user=ubuntu [db] db01 ansible_host=192.168.1.20 ansible_user=ubuntu

• 通过-i inventory/production参数切换环境，避免硬编码。

4. Ubuntu新手Ansible命令实操速查表与避坑清单

4.1 命令速查表：按使用频率排序的12条命令

4.2 Ubuntu专属避坑清单：新手必读的7个血泪教训

这些是我用Ubuntu重装系统7次、调试32个项目总结的独家经验，每一条都对应真实故障

教训1：不要在Ubuntu上用pip install ansible覆盖APT包
Ubuntu的apt install ansible会安装与系统Python、SSL证书、apt模块深度集成的版本。pip install安装的Ansible可能因/usr/lib/python3/dist-packages/路径冲突，导致apt模块无法调用系统apt命令。实测解决方案：始终用sudo apt install ansible，如需新版，用apt-add-repository ppa:ansible/ansible添加官方PPA。

教训2：inventory文件中的ansible_host必须是IP或可解析域名
Ubuntu默认DNS解析较慢，若写ansible_host=server.local而本地DNS未配置，ansible命令会卡住30秒后超时。正确做法：全部用IP地址，或在/etc/hosts中预定义映射。

教训3：Ubuntu 24.04的systemd-resolved可能干扰Ansible DNS
Ubuntu 24.04默认启用systemd-resolved，其/run/systemd/resolve/stub-resolv.conf可能被Ansible读取导致解析失败。临时禁用：sudo systemctl stop systemd-resolved && sudo systemctl disable systemd-resolved。

教训4：copy模块的src路径必须是主控机绝对路径
新手常写src=files/nginx.conf，Ansible会在当前目录找，但Playbook执行时工作目录可能变化。正确写法：src=/home/user/ansible/files/nginx.conf或用{{ playbook_dir }}/files/nginx.conf。

教训5：shell模块中sudo命令需加-S参数读取密码
当--ask-become-pass启用时，shell模块中的sudo命令需-S参数从stdin读密码，否则卡住。但更优解是用become: true在Playbook中统一提权。

教训6：Ubuntu的ufw防火墙默认阻止Ansible连接
新装Ubuntu服务器，sudo ufw status常显示Status: active，需sudo ufw allow 22开放SSH端口，否则ansible所有命令超时。

教训7：ansible-playbook执行后，Ubuntu服务未生效？检查systemd单元文件
Ansible启动服务后，若systemctl status nginx显示inactive，可能是/lib/systemd/system/nginx.service被覆盖。用systemctl cat nginx查看实际单元文件，确认ExecStart路径正确。

4.3 从命令到自动化：Ubuntu新手的30天渐进学习路径

第1-3天：命令级肌肉记忆

• 每天执行10次ansible --version、ansible all -m ping、ansible web -m copy，直到不查文档；
• 在Ubuntu虚拟机中搭建2台靶机（192.168.1.10/11），反复练习inventory配置。

第4-10天：模块组合实战

• 用setup+debug分析Ubuntu系统，生成ubuntu-report.yml报告；
• 编写nginx-deploy.yml：copy配置→apt安装→systemd启动→shell验证；
• 加入--check模式，理解Ansible的“模拟执行”机制。

第11-20天：Playbook工程化

• 创建inventory/development目录，实现开发/测试环境分离；
• 用ansible-vault加密MySQL密码，集成到Playbook；
• 用ansible-galaxy安装geerlingguy.nginx角色，对比自写Playbook差异。

第21-30天：CI/CD初步整合

• 在GitHub Actions中配置Ansible工作流，用--limit参数实现滚动更新；
• 将ansible-inventory --list输出导入Prometheus，监控Ubuntu主机状态；
• 编写ubuntu-hardening.yml，应用Ubuntu安全基线（CIS Benchmark）。

5. 最后分享一个真实场景：如何用这12条命令在Ubuntu上30分钟重建Web集群

上周客户服务器被误删，我用一台Ubuntu 24.04笔记本，在30分钟内重建了3节点Web集群：

1. 第1分钟：ansible --version确认环境，ansible-config dump | grep inventory发现配置正确；
2. 第2-5分钟：ansible-inventory -i prod --graph确认inventory结构，ansible all -m ping -vvv逐台测试连接，发现db01的Python3缺失，ansible db01 -m shell -a "sudo apt install -y python3-minimal"修复；
3. 第6-10分钟：`ansible web -m copy -