尧图网站建设 
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90DaysOfDevOps 开源学习路线图中「配置管理Configuration Management」专题的实践开篇对应仓库 2022/vi/Days/day64.md越南语版本及其英文原版 2022/Days/day64.md。文章围绕 Ansible 的三大核心特性无代理、SSH 驱动、跨平台、在 Ubuntu 控制节点上的完整安装流程、/etc/ansible/hosts主机清单的编写方法以及 ad-hoc 命令的声明式与幂等执行模型展开。读完本文你将能够独立完成 Ansible 控制节点的搭建并在本地与远端节点上运行ping、service等模块化命令为后续编写 Playbook 打好基础。从昨天的大图到今天的动手Ansible 在配置管理中的定位在正式动手之前值得回顾一下 Ansible 在整套 DevOps 工具链中的位置。仓库中的前序文档 2022/Days/day63.md 已经给出了配置管理Configuration Management的大图IaC 负责让基础设施处于期望状态而配置管理工具则进一步保证操作系统设置与应用软件始终处于期望状态。在那个对比表格中Ansible 被归纳为类型配置管理工具与 Terraform 这类编排工具相对基础设施支持可变基础设施mutable infrastructure语言遵循过程式procedural描述方式供应能力提供部分供应能力VM、网络、存储打包对打包与模板化提供完整支持生命周期管理不依赖状态文件不像 Terraform 那样重度依赖 state 管理。也就是说Ansible 擅长的是把事情快速跑起来并保持系统与应用的期望状态这也是本文后续所有命令与清单设计的出发点。Ansible 是什么RedHat 出品、无代理、SSH 驱动2022/vi/Days/day64.md 在开头用三条结论概括了 Ansible 的本质Ansible 是 RedHat 的产品背后有成熟的企业支持同时存在付费的企业级选项核心本身是开源免费的。它是无代理agentless的不需要在被管理节点上安装任何 Ansible 客户端控制节点通过 SSH 连接到目标机器并下发命令。它是跨平台的支持 Linux、macOS 以及 WSL2并且是开源项目。这三条结论决定了 Ansible 的整个工作模型——控制节点Control Node→ SSH → 托管节点的推式架构。所有自动化逻辑集中在控制节点上目标机器只需要能通过 SSH 被访问即可。文档同时强调了一个重要的平台限制Windows 操作系统不能作为控制节点运行 Ansible官方安装文档中有明确说明。但 Windows 完全可以作为被管理的目标节点存在——本文后面就会看到作者把一个 Windows 主机加进了清单。安装 Ansible在 Ubuntu 控制节点上从零开始文档采用的演示环境是 Linux 虚拟机该虚拟机最早在 2022/Days/day20.md 的 Linux 章节中创建系统为 Ubuntu。安装命令如下它通过 Ansible 官方 PPAPersonal Package Archive获取软件包sudo apt update sudo apt install software-properties-common sudo add-apt-repository --yes --update ppa:ansible/ansible sudo apt install ansible逐条拆解这四条命令的作用sudo apt update刷新本地软件包索引确保能拿到最新可用的软件包信息sudo apt install software-properties-common安装add-apt-repository所需的软件包管理工具该命令在部分精简版 Ubuntu 中默认不包含sudo add-apt-repository --yes --update ppa:ansible/ansible添加 Ansible 官方 PPA 源。--yes跳过交互确认--update在添加源的同时立即刷新索引sudo apt install ansible正式安装 Ansible 本体及其依赖。安装完成后通过ansible --version验证安装结果。仓库中保存了当时的真实运行截图从截图中可以看到ansible --version输出的关键信息包括Ansible 核心版本号、ansible 可执行文件路径、配置文件位置/etc/ansible/ansible.cfg、模块搜索路径、使用的 Python 解释器版本以及依赖的 Jinja2 版本。这意味着安装成功控制节点已经就绪。控制节点的前置条件小结控制节点是唯一需要安装 Ansible 的系统控制节点不能是 Windows本文环境为 Ubuntu控制节点需要能通过 SSH 访问所有目标节点网络可达、SSH 服务开启、凭据可用。第一个模块命令对 localhost 运行 ping安装完成后的第一件事是验证 Ansible 本身的功能链路。文档给出的命令是ansible localhost -m ping这里使用了 Ansible 的模块Module机制——模块是 Ansible 执行任务的最小单元ping模块会测试控制节点与目标节点之间的 SSH 连接与 Python 可用性与 ICMP 的网络 ping 不同Ansible 的ping模块返回pong即表示 Ansible 自身通信链路正常。仓库中的真实运行截图如下在只有本机时这个命令并不刺激但它的价值在于当你有 1000 台服务器和设备时同样的单条命令可以瞬间探测所有系统是否就绪。模块的另一个真实使用场景文档给出了如下示例ansible webservers -m service -a namehttpd statestarted这条命令的含义是对清单inventory中名为webservers的主机组执行service模块参数namehttpd指定服务名、statestarted声明期望状态为已启动。它可以一次性确认所有 Web 服务器上的 httpd 服务是否都在运行。注意这里的webservers是主机组名它来源于/etc/ansible/hosts清单文件中的定义——这就引出了下一节的核心内容。hosts 清单定义你的目标基础设施为什么直接 ping 一台机器不行文档记录了一个关键实验作者试图直接对网络中另一台机器执行ansible 10.0.0.1 -m ping该 IP 是运行 VirtualBox 的 Windows 宿主机的网络适配器地址。结果很有意思——普通网络 ping 完全通ICMP 无丢包但ansible命令却报出警告传入的主机列表为空、无法匹配目标主机。原因在于Ansible 不会随意连接任意 IP它只操作清单文件中登记过的主机。目标机器必须先被定义进清单Ansible 才知道它属于哪个组、用什么样的连接参数去访问。这正是主机清单文件存在的意义。找到并编辑 /etc/ansible/hosts清单文件位于控制节点的/etc/ansible/目录下。ls该目录可以看到三个标准组成ansible.cfgAnsible 主配置文件hosts默认主机清单文件roles角色目录后续章节使用。用文本编辑器打开hosts文件文件内部本身就带有大量注释说明如何使用和修改。文档演示的操作是滚动到文件底部创建一个新的主机组[windows]并把 Windows 宿主机的 IP10.0.0.1加入该组然后保存文件[windows] 10.0.0.1第一次失败的教训SSH 才是 Ansible 的网线定义好组之后执行ansible windows -m ping。结果如文档所记录的那样——unreachable不可达因为目标主机无法通过 SSH22 端口建立连接这是一个非常典型的实战教训Ansible 的无代理特性意味着它完全依赖 SSH 通道。清单里登记了主机 ≠ 能管理主机目标节点必须满足SSH 服务开启、控制节点与其网络可达、凭据正确。前两条不满足时命令就会以 unreachable 结束。加入凭据并管理 Linux 组文档随后在 hosts 文件中继续添加主机并给 Linux 组配置了 SSH 登录凭据。清单内容大致如下[linux] 10.0.2.15 [linux:vars] ansible_uservagrant ansible_passwordvagrant这里的[linux:vars]是 Ansible 清单的**组变量group vars**语法对该组内所有主机生效的变量。ansible_user指定 SSH 登录用户名ansible_password指定登录密码演示环境为 VirtualBox 的 vagrant 默认凭据。再次运行ansible linux -m ping这次成功返回ping: pong状态为 SUCCESS同时输出了该主机的 Ansible facts例如发现的 Python 解释器路径清单文件的两个要点hosts是全部设备的登记簿文档特别指出这个文件的另一种叫法是inventory清单。不只是服务器网络设备、交换机、路由器等一切想自动化的设备都可以加进来并按用途分组变量与凭据可以内联在清单里[group:vars]段落为整组提供统一变量让 SSH 凭据等重复信息只写一次。托管节点的要求你不需要装任何客户端关于被管理的目标节点托管节点文档明确说明了其要求目标系统上不需要安装任何 Ansible 客户端虽然你可能会在后续步骤中通过 Ansible 安装软件但那不是 Ansible 自身的 agentAnsible 通过 SSH 建立连接文件与数据的传输走SFTP默认如果你已正确配置 SSH也可以选择使用 SCP 替代 SFTP。换句话说托管节点的最低门槛就是一台能通过 SSH 登录的机器。这也再次呼应了agentless设计管理数百台机器的成本只体现在控制节点的清单与凭据配置上而不是每台机器上的安装维护。Ad-hoc 命令声明式、幂等的一次性任务什么是 ad-hoc 命令前面用到的ansible linux -m ping、ansible windows -m ping都属于ad-hoc 命令ad hoc commands——不需要编写 Playbook直接在命令行上对一组机器执行单次任务的快速方式。文档强调如果你发现自己反复在手工敲同样的命令、甚至不得不逐个登录每台机器执行命令那么 Ansible 就是解决方案。一个非常实用的例子ansible linux -a cat /etc/os-release-a表示直接传递要执行的 shell 命令字符串默认模块为command。这条命令会一次性返回 Linux 组内所有系统的操作系统发行版详情——在几十上百台机器上这就是一条命令做全量巡检的典型场景。其他常见的使用场景还包括重启系统、复制文件、管理用户和软件包packs。同时ad-hoc 命令可以与 Ansible 模块组合使用如前面-m service -a namehttpd statestarted的写法形成模块 参数的统一调用范式。声明式模型与幂等性idempotence文档对 ad-hoc 命令的运行机制有一段精辟的总结值得完整保留Ad-hoc 命令使用一种声明式declarative模型计算并执行到达指定最终状态所需的动作。它们通过在执行前检查当前状态来实现一种幂等性idempotence——除非当前状态与指定的最终状态不同否则什么都不做。用大白话解释你声明httpd 服务应该是 started 状态Ansible 先去看它当前是不是 started如果是命令直接成功返回、不做任何多余操作如果不是才执行启动动作。这种先查后改、只改差异的行为使得重复执行同一条命令永远是安全的、可预期的——这正是自动化运维中最需要的性质也是后续 Playbook 章节反复出现的核心概念。从命令行到 Playbook仓库里的下一步证据ad-hoc 命令适合快速操作但正如文档预告的明天见 Day 65复杂的多步骤配置会演变成 Playbook剧本。仓库的 2022/Days/Configmgmt/ 目录已经准备好了这一演进路径的实例可以作为你验证与继续学习的素材simple_play.yml一个最小 Playbook对localhost执行ping模块并用debug模块打印{{ ansible_os_family }}事实——它把本文的 ad-hoc 操作剧本化了ansible-scenario1/playbook1.yml面向webservers组使用apt安装 apache2、用template渲染ports.conf.j2与index.html.j2、用service确保服务运行并借助notify/handlers实现配置变更后自动重启——这里state: latest、state: started的写法正是本文声明式期望状态思想的延续Vagrantfile定义了db01、web01、web02、loadbalancer四台 Ubuntu 虚拟机含 IP 与 SSH 端口映射用于构造一套可供 Ansible 管理的多节点实验环境。这些文件说明Day 64 的 ad-hoc 命令、hosts清单和模块概念在后续章节中会自然过渡为可复用的 Playbook 与角色roles。小结本文完整走通了 Ansible 从零到可用的关键路径理解了 Ansible 的定位RedHat 出品、agentless、SSH 驱动、跨平台2022/Days/day63.md 中与 Terraform 的对比可作进一步参考在 Ubuntu 控制节点上通过官方 PPA 完成安装并用ansible --version验证用ansible localhost -m ping验证本地链路理解了模块Module与ping/service的用法编辑/etc/ansible/hosts清单学会了分组、[group:vars]变量与 SSH 凭据配置并亲历了网络通但 SSH 不通 → unreachable的排错场景明确了托管节点的要求无需客户端SSH SFTP/SCP 即可掌握了 ad-hoc 命令的声明式模型与幂等执行原理。下一篇Day 65将在此基础上引入 Playbook仓库中 2022/Days/Configmgmt/ 的示例项目已经为你铺好了路。动手安装一个控制节点跑通ansible localhost -m ping再用-a cat /etc/os-release对你的机器做一次全量巡检你就正式进入 Ansible 的世界了。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 之 Ansible 入门实战控制节点、Inventory 与 Ad Hoc 命令Day 6490DaysOfDevOps 之 Ansible 入门实战控制节点、Inventory 与 Ad Hoc 命令Day 64 本篇指南承接 Day 63 配文档/教程90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、Inventory 主机清单与 ad-hoc 命令90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、Inventory 主机清单与 ad hoc 命令 本文是 90DaysO文档/教程90DaysOfDevOps 实战Ansible 入门——控制节点搭建、主机清单Inventory与 ad hoc 命令90DaysOfDevOps 实战Ansible 入门——控制节点搭建、主机清单Inventory与 ad hoc 命令 导读 本文是《90DaysOfD文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 之 Ansible 入门（Day 64）：从控制节点安装到主机清单与 Ad-hoc 命令实战
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90DaysOfDevOps 开源学习路线图中「配置管理Configuration Management」专题的实践开篇对应仓库 2022/vi/Days/day64.md越南语版本及其英文原版 2022/Days/day64.md。文章围绕 Ansible 的三大核心特性无代理、SSH 驱动、跨平台、在 Ubuntu 控制节点上的完整安装流程、/etc/ansible/hosts主机清单的编写方法以及 ad-hoc 命令的声明式与幂等执行模型展开。读完本文你将能够独立完成 Ansible 控制节点的搭建并在本地与远端节点上运行ping、service等模块化命令为后续编写 Playbook 打好基础。从昨天的大图到今天的动手Ansible 在配置管理中的定位在正式动手之前值得回顾一下 Ansible 在整套 DevOps 工具链中的位置。仓库中的前序文档 2022/Days/day63.md 已经给出了配置管理Configuration Management的大图IaC 负责让基础设施处于期望状态而配置管理工具则进一步保证操作系统设置与应用软件始终处于期望状态。在那个对比表格中Ansible 被归纳为类型配置管理工具与 Terraform 这类编排工具相对基础设施支持可变基础设施mutable infrastructure语言遵循过程式procedural描述方式供应能力提供部分供应能力VM、网络、存储打包对打包与模板化提供完整支持生命周期管理不依赖状态文件不像 Terraform 那样重度依赖 state 管理。也就是说Ansible 擅长的是把事情快速跑起来并保持系统与应用的期望状态这也是本文后续所有命令与清单设计的出发点。Ansible 是什么RedHat 出品、无代理、SSH 驱动2022/vi/Days/day64.md 在开头用三条结论概括了 Ansible 的本质Ansible 是 RedHat 的产品背后有成熟的企业支持同时存在付费的企业级选项核心本身是开源免费的。它是无代理agentless的不需要在被管理节点上安装任何 Ansible 客户端控制节点通过 SSH 连接到目标机器并下发命令。它是跨平台的支持 Linux、macOS 以及 WSL2并且是开源项目。这三条结论决定了 Ansible 的整个工作模型——控制节点Control Node→ SSH → 托管节点的推式架构。所有自动化逻辑集中在控制节点上目标机器只需要能通过 SSH 被访问即可。文档同时强调了一个重要的平台限制Windows 操作系统不能作为控制节点运行 Ansible官方安装文档中有明确说明。但 Windows 完全可以作为被管理的目标节点存在——本文后面就会看到作者把一个 Windows 主机加进了清单。安装 Ansible在 Ubuntu 控制节点上从零开始文档采用的演示环境是 Linux 虚拟机该虚拟机最早在 2022/Days/day20.md 的 Linux 章节中创建系统为 Ubuntu。安装命令如下它通过 Ansible 官方 PPAPersonal Package Archive获取软件包sudo apt update sudo apt install software-properties-common sudo add-apt-repository --yes --update ppa:ansible/ansible sudo apt install ansible逐条拆解这四条命令的作用sudo apt update刷新本地软件包索引确保能拿到最新可用的软件包信息sudo apt install software-properties-common安装add-apt-repository所需的软件包管理工具该命令在部分精简版 Ubuntu 中默认不包含sudo add-apt-repository --yes --update ppa:ansible/ansible添加 Ansible 官方 PPA 源。--yes跳过交互确认--update在添加源的同时立即刷新索引sudo apt install ansible正式安装 Ansible 本体及其依赖。安装完成后通过ansible --version验证安装结果。仓库中保存了当时的真实运行截图从截图中可以看到ansible --version输出的关键信息包括Ansible 核心版本号、ansible 可执行文件路径、配置文件位置/etc/ansible/ansible.cfg、模块搜索路径、使用的 Python 解释器版本以及依赖的 Jinja2 版本。这意味着安装成功控制节点已经就绪。控制节点的前置条件小结控制节点是唯一需要安装 Ansible 的系统控制节点不能是 Windows本文环境为 Ubuntu控制节点需要能通过 SSH 访问所有目标节点网络可达、SSH 服务开启、凭据可用。第一个模块命令对 localhost 运行 ping安装完成后的第一件事是验证 Ansible 本身的功能链路。文档给出的命令是ansible localhost -m ping这里使用了 Ansible 的模块Module机制——模块是 Ansible 执行任务的最小单元ping模块会测试控制节点与目标节点之间的 SSH 连接与 Python 可用性与 ICMP 的网络 ping 不同Ansible 的ping模块返回pong即表示 Ansible 自身通信链路正常。仓库中的真实运行截图如下在只有本机时这个命令并不刺激但它的价值在于当你有 1000 台服务器和设备时同样的单条命令可以瞬间探测所有系统是否就绪。模块的另一个真实使用场景文档给出了如下示例ansible webservers -m service -a namehttpd statestarted这条命令的含义是对清单inventory中名为webservers的主机组执行service模块参数namehttpd指定服务名、statestarted声明期望状态为已启动。它可以一次性确认所有 Web 服务器上的 httpd 服务是否都在运行。注意这里的webservers是主机组名它来源于/etc/ansible/hosts清单文件中的定义——这就引出了下一节的核心内容。hosts 清单定义你的目标基础设施为什么直接 ping 一台机器不行文档记录了一个关键实验作者试图直接对网络中另一台机器执行ansible 10.0.0.1 -m ping该 IP 是运行 VirtualBox 的 Windows 宿主机的网络适配器地址。结果很有意思——普通网络 ping 完全通ICMP 无丢包但ansible命令却报出警告传入的主机列表为空、无法匹配目标主机。原因在于Ansible 不会随意连接任意 IP它只操作清单文件中登记过的主机。目标机器必须先被定义进清单Ansible 才知道它属于哪个组、用什么样的连接参数去访问。这正是主机清单文件存在的意义。找到并编辑 /etc/ansible/hosts清单文件位于控制节点的/etc/ansible/目录下。ls该目录可以看到三个标准组成ansible.cfgAnsible 主配置文件hosts默认主机清单文件roles角色目录后续章节使用。用文本编辑器打开hosts文件文件内部本身就带有大量注释说明如何使用和修改。文档演示的操作是滚动到文件底部创建一个新的主机组[windows]并把 Windows 宿主机的 IP10.0.0.1加入该组然后保存文件[windows] 10.0.0.1第一次失败的教训SSH 才是 Ansible 的网线定义好组之后执行ansible windows -m ping。结果如文档所记录的那样——unreachable不可达因为目标主机无法通过 SSH22 端口建立连接这是一个非常典型的实战教训Ansible 的无代理特性意味着它完全依赖 SSH 通道。清单里登记了主机 ≠ 能管理主机目标节点必须满足SSH 服务开启、控制节点与其网络可达、凭据正确。前两条不满足时命令就会以 unreachable 结束。加入凭据并管理 Linux 组文档随后在 hosts 文件中继续添加主机并给 Linux 组配置了 SSH 登录凭据。清单内容大致如下[linux] 10.0.2.15 [linux:vars] ansible_uservagrant ansible_passwordvagrant这里的[linux:vars]是 Ansible 清单的**组变量group vars**语法对该组内所有主机生效的变量。ansible_user指定 SSH 登录用户名ansible_password指定登录密码演示环境为 VirtualBox 的 vagrant 默认凭据。再次运行ansible linux -m ping这次成功返回ping: pong状态为 SUCCESS同时输出了该主机的 Ansible facts例如发现的 Python 解释器路径清单文件的两个要点hosts是全部设备的登记簿文档特别指出这个文件的另一种叫法是inventory清单。不只是服务器网络设备、交换机、路由器等一切想自动化的设备都可以加进来并按用途分组变量与凭据可以内联在清单里[group:vars]段落为整组提供统一变量让 SSH 凭据等重复信息只写一次。托管节点的要求你不需要装任何客户端关于被管理的目标节点托管节点文档明确说明了其要求目标系统上不需要安装任何 Ansible 客户端虽然你可能会在后续步骤中通过 Ansible 安装软件但那不是 Ansible 自身的 agentAnsible 通过 SSH 建立连接文件与数据的传输走SFTP默认如果你已正确配置 SSH也可以选择使用 SCP 替代 SFTP。换句话说托管节点的最低门槛就是一台能通过 SSH 登录的机器。这也再次呼应了agentless设计管理数百台机器的成本只体现在控制节点的清单与凭据配置上而不是每台机器上的安装维护。Ad-hoc 命令声明式、幂等的一次性任务什么是 ad-hoc 命令前面用到的ansible linux -m ping、ansible windows -m ping都属于ad-hoc 命令ad hoc commands——不需要编写 Playbook直接在命令行上对一组机器执行单次任务的快速方式。文档强调如果你发现自己反复在手工敲同样的命令、甚至不得不逐个登录每台机器执行命令那么 Ansible 就是解决方案。一个非常实用的例子ansible linux -a cat /etc/os-release-a表示直接传递要执行的 shell 命令字符串默认模块为command。这条命令会一次性返回 Linux 组内所有系统的操作系统发行版详情——在几十上百台机器上这就是一条命令做全量巡检的典型场景。其他常见的使用场景还包括重启系统、复制文件、管理用户和软件包packs。同时ad-hoc 命令可以与 Ansible 模块组合使用如前面-m service -a namehttpd statestarted的写法形成模块 参数的统一调用范式。声明式模型与幂等性idempotence文档对 ad-hoc 命令的运行机制有一段精辟的总结值得完整保留Ad-hoc 命令使用一种声明式declarative模型计算并执行到达指定最终状态所需的动作。它们通过在执行前检查当前状态来实现一种幂等性idempotence——除非当前状态与指定的最终状态不同否则什么都不做。用大白话解释你声明httpd 服务应该是 started 状态Ansible 先去看它当前是不是 started如果是命令直接成功返回、不做任何多余操作如果不是才执行启动动作。这种先查后改、只改差异的行为使得重复执行同一条命令永远是安全的、可预期的——这正是自动化运维中最需要的性质也是后续 Playbook 章节反复出现的核心概念。从命令行到 Playbook仓库里的下一步证据ad-hoc 命令适合快速操作但正如文档预告的明天见 Day 65复杂的多步骤配置会演变成 Playbook剧本。仓库的 2022/Days/Configmgmt/ 目录已经准备好了这一演进路径的实例可以作为你验证与继续学习的素材simple_play.yml一个最小 Playbook对localhost执行ping模块并用debug模块打印{{ ansible_os_family }}事实——它把本文的 ad-hoc 操作剧本化了ansible-scenario1/playbook1.yml面向webservers组使用apt安装 apache2、用template渲染ports.conf.j2与index.html.j2、用service确保服务运行并借助notify/handlers实现配置变更后自动重启——这里state: latest、state: started的写法正是本文声明式期望状态思想的延续Vagrantfile定义了db01、web01、web02、loadbalancer四台 Ubuntu 虚拟机含 IP 与 SSH 端口映射用于构造一套可供 Ansible 管理的多节点实验环境。这些文件说明Day 64 的 ad-hoc 命令、hosts清单和模块概念在后续章节中会自然过渡为可复用的 Playbook 与角色roles。小结本文完整走通了 Ansible 从零到可用的关键路径理解了 Ansible 的定位RedHat 出品、agentless、SSH 驱动、跨平台2022/Days/day63.md 中与 Terraform 的对比可作进一步参考在 Ubuntu 控制节点上通过官方 PPA 完成安装并用ansible --version验证用ansible localhost -m ping验证本地链路理解了模块Module与ping/service的用法编辑/etc/ansible/hosts清单学会了分组、[group:vars]变量与 SSH 凭据配置并亲历了网络通但 SSH 不通 → unreachable的排错场景明确了托管节点的要求无需客户端SSH SFTP/SCP 即可掌握了 ad-hoc 命令的声明式模型与幂等执行原理。下一篇Day 65将在此基础上引入 Playbook仓库中 2022/Days/Configmgmt/ 的示例项目已经为你铺好了路。动手安装一个控制节点跑通ansible localhost -m ping再用-a cat /etc/os-release对你的机器做一次全量巡检你就正式进入 Ansible 的世界了。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 之 Ansible 入门实战控制节点、Inventory 与 Ad Hoc 命令Day 6490DaysOfDevOps 之 Ansible 入门实战控制节点、Inventory 与 Ad Hoc 命令Day 64 本篇指南承接 Day 63 配文档/教程90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、Inventory 主机清单与 ad-hoc 命令90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、Inventory 主机清单与 ad hoc 命令 本文是 90DaysO文档/教程90DaysOfDevOps 实战Ansible 入门——控制节点搭建、主机清单Inventory与 ad hoc 命令90DaysOfDevOps 实战Ansible 入门——控制节点搭建、主机清单Inventory与 ad hoc 命令 导读 本文是《90DaysOfD文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考