尧图网站建设 
文档/教程【免费下载链接】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篇章的实战起点聚焦 Ansible 的从零上手安装、验证、定义主机清单以及运行 ad hoc 命令。读完本文你将掌握如何在 Linux 控制节点上安装 Ansible、通过ansible localhost -m ping验证安装、在/etc/ansible/hosts中按组定义受管节点并用ansible 组名 -m 模块 -a 参数的形式对成百上千台设备批量执行任务为后续编写 Playbook 打下基础。本文内容承接 Day 63配置管理大图景该篇对比了 Chef、Puppet、Ansible、SaltStack 等工具的架构、语言与优劣势并最终选定 Ansible 作为本系列配置管理章节的主工具。Ansible 是什么agentless 的配置管理工具在 Day 63 中我们已经从配置管理大图景角度介绍过 Ansible这里补充几个理解 Ansible 的关键维度出身Ansible 来自 RedHat红帽主导的开源项目同时提供开源免费版与付费的企业版如 Ansible Automation Platform。无代理agentlessAnsible 不像 Puppet、Chef、SaltStack 那样需要在目标节点上安装并常驻客户端代理agent。它通过 SSH 建立连接并下发命令执行完毕后连接即断开。跨平台控制节点与受管节点可运行在 Linux、macOS以及 Windows 下的 WSL2等环境但官方文档明确指出Windows 操作系统不能作为控制节点只能作为受管目标。推模型push model与 Chef/Puppet 的客户端主动拉取pull配置模型不同Ansible 采用控制节点主动推送push配置模型这与 Day 63 中对各工具架构Server/Clients vs Client Only的对比一致。环境准备选择并搭建控制节点Ansible 是 agentless 工具它被部署在一台称为控制节点Control Node的系统上由控制节点通过 SSH 管理其他机器、网络设备等。原文使用 Day 20 Linux 章节 中创建的 Ubuntu 虚拟机作为演示环境——该虚拟机运行 Ubuntu下面给出完整安装步骤。Ubuntu/Debian 系列安装 Ansible在 Ubuntu 控制节点上依次执行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等管理 PPA 所需的工具sudo add-apt-repository --yes --update ppa:ansible/ansible添加 Ansible 官方 PPA 并立即更新索引以获取比 Ubuntu 发行版自带版本更新的 Ansiblesudo apt install ansible安装 Ansible 本体。说明如果使用 macOS 可通过 Homebrewbrew install ansible安装使用 WSL2 的 Linux 发行版则与上述 Ubuntu 步骤一致。Windows 本身不能作为控制节点。验证安装ansible --version安装完成后运行ansible --version查看版本与环境信息。在本文对应的实验环境中输出如下截图见 Day64_config1.pngansible [core 2.12.2] config file /etc/ansible/ansible.cfg configured module search path [/home/vagrant/.ansible/plugins/modules, /usr/share/ansible/plugins/modules] ansible python module location /usr/lib/python3/dist-packages/ansible ansible collection location /home/vagrant/.ansible/collections:/usr/share/ansible/collections executable location /usr/bin/ansible python version 3.8.10 (default, Nov 26 2021, 20:14:08) [GCC 9.3.0] jinja version 2.10.1 libyaml True输出中的关键信息解读ansible [core 2.12.2]Ansible 核心版本号config file /etc/ansible/ansible.cfg默认配置文件路径configured module search path模块搜索路径用户级插件目录与系统级插件目录python version控制节点上 Ansible 所依赖的 Python 版本libyaml True已启用 libyaml 加速 YAML 解析。第一个模块验证ansible localhost -m ping在正式管理其他节点前可以先用模块对本机做一次冒烟测试。Ansible 通过模块Module完成具体任务例如ping模块用于测试控制节点与目标主机之间的连通性。运行ansible localhost -m pinglocalhost是 Ansible 内置的隐式主机无需在清单中定义即可直接使用。实验输出如下截图见 Day64_config2.pnglocalhost | SUCCESS { changed: false, ping: pong }解读SUCCESS任务执行成功失败时为红色UNREACHABLE/FAILEDchanged: falseping 模块只做连通性探测不会对系统做任何变更ping: pong模块返回的标准响应类似网络层的 ICMP echo 回复。本机验证的意义在于虽然对单个localhost执行意义有限但同样的命令可以扩展到1000 台服务器——想确认所有系统是否在线时一条ansible 组名 -m ping即可批量完成健康检查。实战场景service 模块管理服务状态模块的真实价值体现在批量化场景。例如检查所有 Web 服务器上的 httpd 服务是否处于运行状态ansible webservers -m service -a namehttpd statestartedwebservers清单中定义的主机组名后文会介绍如何定义-m service使用service模块管理系统服务-a namehttpd statestarted模块参数指定服务名与期望状态Ansible 会确保目标状态达成。定义主机清单Inventory/etc/ansible/hosts上一节中我们只对本机执行了命令。要管理网络中的其他机器必须把它们写入清单Inventory——即hosts文件。它位于控制节点的/etc/ansible/目录下该目录还包含ansible.cfg主配置文件见 Day64_config4.png。提示清单文件默认路径为/etc/ansible/hosts也可以通过ansible.cfg的inventory配置项指定其他路径。原文示例使用默认位置。hosts文件内置了大量注释说明指导你如何组织主机与分组。演示中我们在文件底部新建了[windows]组并加入 Windows 宿主机在 VirtualBox 网络中的网卡地址10.0.0.1见 Day64_config5.png[windows] 10.0.0.1关键前提SSH 可达性。保存文件后运行ansible windows -m ping结果却是不可达见 Day64_config6.png10.0.0.1 | UNREACHABLE! { msg: Failed to connect to the host via ssh: ..., unreachable: true }原因正如原文反复强调的Ansible 需要通过 SSH 连接目标主机。虽然该 IP 可以被 ping 通ICMP 层可达但目标未开放/未配置 SSH 服务因此 Ansible 无法建立连接。这清晰地区分了网络可达与Ansible 可管理两个概念——后者必须满足 SSH 通道可用。添加凭据与更多分组随后原文在hosts文件中继续补充了更多主机并新建了[linux]组同时为该组配置了连接凭据见 Day64_config7.png。典型的清单片段如下[linux] 10.0.2.15 ansible_uservagrant ansible_ssh_private_key_file~/.ssh/id_rsa [windows] 10.0.0.1常用主机变量说明ansible_userSSH 登录用户名ansible_ssh_private_key_fileSSH 私钥文件路径ansible_ssh_passSSH 密码安全起见建议优先使用密钥认证ansible_portSSH 端口默认 22可针对自定义端口指定。修改后再次运行ansible linux -m ping得到成功结果见 Day64_config8.png10.0.2.15 | SUCCESS { ansible_facts: { discovered_interpreter_python: /usr/bin/python3 }, changed: false, ping: pong }这里多出的ansible_facts.discovered_interpreter_python是 Ansible 自动探测到的目标节点 Python 解释器路径——模块在目标端执行依赖 Python若目标没有 Python 则需要预先处理极简环境可配置ansible_python_interpreter指向可用解释器。受管节点要求受管节点被自动化配置的目标系统不需要安装任何 Ansible 客户端——这正是 agentless 的核心体现。Ansible 通过 SSH 连接目标并通过 SFTP默认或 SCP在 SSH 配置允许时可在ansible.cfg中切换传输方式传输文件。即使目标上最终安装了某些软件那也来自 Ansible 模块的操作结果而非 Ansible 自身的常驻组件。清单文件的更多用途清单Inventory是定义全部设备的地方除了服务器网络设备交换机、路由器等同样可以按组纳入其中。例如[switches] sw1.example.com sw2.example.com [routers] r1.example.com分组让 ad hoc 命令和后续的 Playbook 可以按组批量作用也支持组嵌套[web:children]与主机变量/组变量的进阶组织方式可结合后续章节的 Playbook 深入学习。ad hoc 命令声明式与幂等性ansible 主机或组 -m 模块 -a 参数这种不落盘的一次性命令称为ad hoc 命令官方文档中称 ad hoc commands。除了ping、servicead hoc 命令的典型用法还包括批量执行 shell 命令例如查看 Linux 组内所有系统的操作系统发行信息ansible linux -a cat /etc/os-release不指定-m时默认使用command模块。重启系统ansible linux -m reboot复制文件ansible linux -m copy -a src/tmp/foo dest/etc/foo管理软件包ansible linux -m apt -a namenginx statepresent管理用户ansible linux -m user -a namedevops statepresent声明式模型与幂等性原文强调了 ad hoc 命令背后的两个核心设计思想值得展开声明式declarative模型你只描述期望的最终状态如statestarted、statepresent由 Ansible 计算并执行达到该状态所需的动作而不是像脚本那样一步步指定如何做。幂等性idempotenceAnsible 在执行前会先检查当前状态只有当当前状态与期望最终状态不一致时才执行变更如果状态已经符合预期则什么都不做对应changed: false。这也是配置管理的核心价值——重复执行不会引入额外变更配置漂移可被持续纠正。这一思想在后续 Playbook 中同样贯穿始终例如 simple_play.yml 中的ping任务以及 playbook1.yml 中apt/service等模块对目标状态的描述式声明。与仓库源码的印证后续 Playbook 与实验环境仓库的 Configmgmt 目录为本篇提供了完整的可运行实验环境与后续延伸材料Vagrantfile定义了一组 Ubuntu 21.10 虚拟机db01、web01、web02、loadbalancer可作为本篇中受管节点的批量实验集群其 IP 与 SSH 端口映射方式恰好对应清单文件中ansible_port等主机变量的使用场景simple_play.yml一个针对localhost的最简 Playbook包含ping任务与debug输出系统族ansible_os_family任务可直接对应本篇的ansible localhost -m ping验证ansible-scenario1/playbook1.yml针对webservers组的完整 Playbook演示apt安装 apache2、template渲染配置、service管理服务、notify/handlers触发重启是本篇 ad hoc 命令向可重复、可版本化方向演进的下一步Day 65 及后续章节将深入 Playbook。可以看出本篇解决的安装 → 连通性验证 → 清单定义 → ad hoc 命令正是通向 Playbook 自动化之前的必经阶段。小结知识点关键命令 / 文件要点安装sudo apt install ansiblePPA 方式控制节点需为 Linux/macOS/WSL2Windows 不行验证ansible --version查看版本、配置文件与模块搜索路径连通性测试ansible localhost -m ping返回SUCCESS、changed: false、ping: pong清单定义/etc/ansible/hosts按组[linux]、[windows]定义主机与凭据批量管理ansible 组 -m 模块 -a 参数覆盖 ping、service、copy、user、shell 等场景核心思想ad hoc / Playbook声明式模型 幂等性状态检查先行下一篇 Day 65 将基于本篇的环境与清单正式进入 Playbook 的编写与运行。赞分享文档/教程【免费下载链接】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 第 64 天Ansible 入门实战——控制节点安装、Inventory 主机清单与 ad-hoc 命令90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、Inventory 主机清单与 ad hoc 命令 本文是 90DaysO文档/教程90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、模块命令与 Inventory 主机清单配置90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、模块命令与 Inventory 主机清单配置 本文是 90DaysOfDe文档/教程90DaysOfDevOpsAnsible 入门实战——控制节点、Hosts 清单与 Ad Hoc 命令详解Day 6490DaysOfDevOpsAnsible 入门实战——控制节点、Hosts 清单与 Ad Hoc 命令详解Day 64 本文是 90DaysOfDevO文档/教程上一篇RocketRide 实践指南使用 aparavi_aql 节点以自然语言查询 Aparavi STORE 元数据下一篇Slang 编译期性能基准套件设计解析tools/compile-perf 的架构、工作负载与 CI 漂移检测创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 实战：Ansible 入门——控制节点搭建、主机清单（Inventory）与 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篇章的实战起点聚焦 Ansible 的从零上手安装、验证、定义主机清单以及运行 ad hoc 命令。读完本文你将掌握如何在 Linux 控制节点上安装 Ansible、通过ansible localhost -m ping验证安装、在/etc/ansible/hosts中按组定义受管节点并用ansible 组名 -m 模块 -a 参数的形式对成百上千台设备批量执行任务为后续编写 Playbook 打下基础。本文内容承接 Day 63配置管理大图景该篇对比了 Chef、Puppet、Ansible、SaltStack 等工具的架构、语言与优劣势并最终选定 Ansible 作为本系列配置管理章节的主工具。Ansible 是什么agentless 的配置管理工具在 Day 63 中我们已经从配置管理大图景角度介绍过 Ansible这里补充几个理解 Ansible 的关键维度出身Ansible 来自 RedHat红帽主导的开源项目同时提供开源免费版与付费的企业版如 Ansible Automation Platform。无代理agentlessAnsible 不像 Puppet、Chef、SaltStack 那样需要在目标节点上安装并常驻客户端代理agent。它通过 SSH 建立连接并下发命令执行完毕后连接即断开。跨平台控制节点与受管节点可运行在 Linux、macOS以及 Windows 下的 WSL2等环境但官方文档明确指出Windows 操作系统不能作为控制节点只能作为受管目标。推模型push model与 Chef/Puppet 的客户端主动拉取pull配置模型不同Ansible 采用控制节点主动推送push配置模型这与 Day 63 中对各工具架构Server/Clients vs Client Only的对比一致。环境准备选择并搭建控制节点Ansible 是 agentless 工具它被部署在一台称为控制节点Control Node的系统上由控制节点通过 SSH 管理其他机器、网络设备等。原文使用 Day 20 Linux 章节 中创建的 Ubuntu 虚拟机作为演示环境——该虚拟机运行 Ubuntu下面给出完整安装步骤。Ubuntu/Debian 系列安装 Ansible在 Ubuntu 控制节点上依次执行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等管理 PPA 所需的工具sudo add-apt-repository --yes --update ppa:ansible/ansible添加 Ansible 官方 PPA 并立即更新索引以获取比 Ubuntu 发行版自带版本更新的 Ansiblesudo apt install ansible安装 Ansible 本体。说明如果使用 macOS 可通过 Homebrewbrew install ansible安装使用 WSL2 的 Linux 发行版则与上述 Ubuntu 步骤一致。Windows 本身不能作为控制节点。验证安装ansible --version安装完成后运行ansible --version查看版本与环境信息。在本文对应的实验环境中输出如下截图见 Day64_config1.pngansible [core 2.12.2] config file /etc/ansible/ansible.cfg configured module search path [/home/vagrant/.ansible/plugins/modules, /usr/share/ansible/plugins/modules] ansible python module location /usr/lib/python3/dist-packages/ansible ansible collection location /home/vagrant/.ansible/collections:/usr/share/ansible/collections executable location /usr/bin/ansible python version 3.8.10 (default, Nov 26 2021, 20:14:08) [GCC 9.3.0] jinja version 2.10.1 libyaml True输出中的关键信息解读ansible [core 2.12.2]Ansible 核心版本号config file /etc/ansible/ansible.cfg默认配置文件路径configured module search path模块搜索路径用户级插件目录与系统级插件目录python version控制节点上 Ansible 所依赖的 Python 版本libyaml True已启用 libyaml 加速 YAML 解析。第一个模块验证ansible localhost -m ping在正式管理其他节点前可以先用模块对本机做一次冒烟测试。Ansible 通过模块Module完成具体任务例如ping模块用于测试控制节点与目标主机之间的连通性。运行ansible localhost -m pinglocalhost是 Ansible 内置的隐式主机无需在清单中定义即可直接使用。实验输出如下截图见 Day64_config2.pnglocalhost | SUCCESS { changed: false, ping: pong }解读SUCCESS任务执行成功失败时为红色UNREACHABLE/FAILEDchanged: falseping 模块只做连通性探测不会对系统做任何变更ping: pong模块返回的标准响应类似网络层的 ICMP echo 回复。本机验证的意义在于虽然对单个localhost执行意义有限但同样的命令可以扩展到1000 台服务器——想确认所有系统是否在线时一条ansible 组名 -m ping即可批量完成健康检查。实战场景service 模块管理服务状态模块的真实价值体现在批量化场景。例如检查所有 Web 服务器上的 httpd 服务是否处于运行状态ansible webservers -m service -a namehttpd statestartedwebservers清单中定义的主机组名后文会介绍如何定义-m service使用service模块管理系统服务-a namehttpd statestarted模块参数指定服务名与期望状态Ansible 会确保目标状态达成。定义主机清单Inventory/etc/ansible/hosts上一节中我们只对本机执行了命令。要管理网络中的其他机器必须把它们写入清单Inventory——即hosts文件。它位于控制节点的/etc/ansible/目录下该目录还包含ansible.cfg主配置文件见 Day64_config4.png。提示清单文件默认路径为/etc/ansible/hosts也可以通过ansible.cfg的inventory配置项指定其他路径。原文示例使用默认位置。hosts文件内置了大量注释说明指导你如何组织主机与分组。演示中我们在文件底部新建了[windows]组并加入 Windows 宿主机在 VirtualBox 网络中的网卡地址10.0.0.1见 Day64_config5.png[windows] 10.0.0.1关键前提SSH 可达性。保存文件后运行ansible windows -m ping结果却是不可达见 Day64_config6.png10.0.0.1 | UNREACHABLE! { msg: Failed to connect to the host via ssh: ..., unreachable: true }原因正如原文反复强调的Ansible 需要通过 SSH 连接目标主机。虽然该 IP 可以被 ping 通ICMP 层可达但目标未开放/未配置 SSH 服务因此 Ansible 无法建立连接。这清晰地区分了网络可达与Ansible 可管理两个概念——后者必须满足 SSH 通道可用。添加凭据与更多分组随后原文在hosts文件中继续补充了更多主机并新建了[linux]组同时为该组配置了连接凭据见 Day64_config7.png。典型的清单片段如下[linux] 10.0.2.15 ansible_uservagrant ansible_ssh_private_key_file~/.ssh/id_rsa [windows] 10.0.0.1常用主机变量说明ansible_userSSH 登录用户名ansible_ssh_private_key_fileSSH 私钥文件路径ansible_ssh_passSSH 密码安全起见建议优先使用密钥认证ansible_portSSH 端口默认 22可针对自定义端口指定。修改后再次运行ansible linux -m ping得到成功结果见 Day64_config8.png10.0.2.15 | SUCCESS { ansible_facts: { discovered_interpreter_python: /usr/bin/python3 }, changed: false, ping: pong }这里多出的ansible_facts.discovered_interpreter_python是 Ansible 自动探测到的目标节点 Python 解释器路径——模块在目标端执行依赖 Python若目标没有 Python 则需要预先处理极简环境可配置ansible_python_interpreter指向可用解释器。受管节点要求受管节点被自动化配置的目标系统不需要安装任何 Ansible 客户端——这正是 agentless 的核心体现。Ansible 通过 SSH 连接目标并通过 SFTP默认或 SCP在 SSH 配置允许时可在ansible.cfg中切换传输方式传输文件。即使目标上最终安装了某些软件那也来自 Ansible 模块的操作结果而非 Ansible 自身的常驻组件。清单文件的更多用途清单Inventory是定义全部设备的地方除了服务器网络设备交换机、路由器等同样可以按组纳入其中。例如[switches] sw1.example.com sw2.example.com [routers] r1.example.com分组让 ad hoc 命令和后续的 Playbook 可以按组批量作用也支持组嵌套[web:children]与主机变量/组变量的进阶组织方式可结合后续章节的 Playbook 深入学习。ad hoc 命令声明式与幂等性ansible 主机或组 -m 模块 -a 参数这种不落盘的一次性命令称为ad hoc 命令官方文档中称 ad hoc commands。除了ping、servicead hoc 命令的典型用法还包括批量执行 shell 命令例如查看 Linux 组内所有系统的操作系统发行信息ansible linux -a cat /etc/os-release不指定-m时默认使用command模块。重启系统ansible linux -m reboot复制文件ansible linux -m copy -a src/tmp/foo dest/etc/foo管理软件包ansible linux -m apt -a namenginx statepresent管理用户ansible linux -m user -a namedevops statepresent声明式模型与幂等性原文强调了 ad hoc 命令背后的两个核心设计思想值得展开声明式declarative模型你只描述期望的最终状态如statestarted、statepresent由 Ansible 计算并执行达到该状态所需的动作而不是像脚本那样一步步指定如何做。幂等性idempotenceAnsible 在执行前会先检查当前状态只有当当前状态与期望最终状态不一致时才执行变更如果状态已经符合预期则什么都不做对应changed: false。这也是配置管理的核心价值——重复执行不会引入额外变更配置漂移可被持续纠正。这一思想在后续 Playbook 中同样贯穿始终例如 simple_play.yml 中的ping任务以及 playbook1.yml 中apt/service等模块对目标状态的描述式声明。与仓库源码的印证后续 Playbook 与实验环境仓库的 Configmgmt 目录为本篇提供了完整的可运行实验环境与后续延伸材料Vagrantfile定义了一组 Ubuntu 21.10 虚拟机db01、web01、web02、loadbalancer可作为本篇中受管节点的批量实验集群其 IP 与 SSH 端口映射方式恰好对应清单文件中ansible_port等主机变量的使用场景simple_play.yml一个针对localhost的最简 Playbook包含ping任务与debug输出系统族ansible_os_family任务可直接对应本篇的ansible localhost -m ping验证ansible-scenario1/playbook1.yml针对webservers组的完整 Playbook演示apt安装 apache2、template渲染配置、service管理服务、notify/handlers触发重启是本篇 ad hoc 命令向可重复、可版本化方向演进的下一步Day 65 及后续章节将深入 Playbook。可以看出本篇解决的安装 → 连通性验证 → 清单定义 → ad hoc 命令正是通向 Playbook 自动化之前的必经阶段。小结知识点关键命令 / 文件要点安装sudo apt install ansiblePPA 方式控制节点需为 Linux/macOS/WSL2Windows 不行验证ansible --version查看版本、配置文件与模块搜索路径连通性测试ansible localhost -m ping返回SUCCESS、changed: false、ping: pong清单定义/etc/ansible/hosts按组[linux]、[windows]定义主机与凭据批量管理ansible 组 -m 模块 -a 参数覆盖 ping、service、copy、user、shell 等场景核心思想ad hoc / Playbook声明式模型 幂等性状态检查先行下一篇 Day 65 将基于本篇的环境与清单正式进入 Playbook 的编写与运行。赞分享文档/教程【免费下载链接】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 第 64 天Ansible 入门实战——控制节点安装、Inventory 主机清单与 ad-hoc 命令90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、Inventory 主机清单与 ad hoc 命令 本文是 90DaysO文档/教程90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、模块命令与 Inventory 主机清单配置90DaysOfDevOps 第 64 天Ansible 入门实战——控制节点安装、模块命令与 Inventory 主机清单配置 本文是 90DaysOfDe文档/教程90DaysOfDevOpsAnsible 入门实战——控制节点、Hosts 清单与 Ad Hoc 命令详解Day 6490DaysOfDevOpsAnsible 入门实战——控制节点、Hosts 清单与 Ad Hoc 命令详解Day 64 本文是 90DaysOfDevO文档/教程上一篇RocketRide 实践指南使用 aparavi_aql 节点以自然语言查询 Aparavi STORE 元数据下一篇Slang 编译期性能基准套件设计解析tools/compile-perf 的架构、工作负载与 CI 漂移检测创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考