Ubuntu 18.04 上安全部署 Ansible 的最佳实践

1. 为什么 Ubuntu 18.04 上的 Ansible 安装不是“一键 pip install”就完事在 Ubuntu 18.04 上部署 Ansible表面看只是敲几行命令的事但实际踩过的坑远比想象中多。我第一次给客户环境装 Ansible 时用的是pip3 install ansible结果跑第一个 playbook 就报错ModuleNotFoundError: No module named yaml第二次换apt install ansible又发现版本卡在 2.5.1——而客户要求的模块比如community.general中的proxmox_kvm根本无法加载因为依赖的ansible-core 2.12不满足。这还不是最糟的有次在生产跳板机上执行apt upgrade系统自动把 Ansible 升级到了 2.9.x结果所有基于become_method: sudo的任务全部静默失败日志里只显示FAILED! {changed: false}连错误堆栈都不给——查了三小时才发现是sudo的requiretty默认策略被新版本 Ansible 更激进地触发了。Ubuntu 18.04 是一个典型的“LTS 旧内核 保守包管理”组合体。它的 APT 仓库里 Ansible 版本长期停留在 2.5.x2018 年发布而社区主流早已推进到 2.14Python 3.6 是默认解释器但很多新模块要求pyyaml 5.4、jinja2 3.0这些在系统源里要么没有要么版本太低。更关键的是Ansible 的运行机制高度依赖 Python 环境隔离性——它不希望你用系统全局的site-packages因为一旦某个运维脚本pip install -U requests整个 Ansible 的 HTTP 请求逻辑就可能崩掉。所以所谓“安装”本质是在 Ubuntu 18.04 这个老旧但稳定的底盘上构建一个可控、可复现、可审计的 Ansible 执行沙盒。这不是技术选型问题而是运维可靠性的底线工程。你可能会说“那直接用官方 PPA 不就行了吗”——确实ppa:ansible/ansible曾经是标准解法。但注意该 PPA 在 2021 年底已正式归档EOLUbuntu 18.04 的支持周期虽到 2023 年 4 月但其软件源从 2022 年起就不再接收新 Ansible 包。现在apt update apt install ansible拿到的仍是 2.5.1且无法通过apt upgrade更新。这意味着任何依赖现代 Ansible 特性如loop,vars_plugin,inventory plugin的动态分组的自动化流程在原生 Ubuntu 18.04 上根本跑不起来。这不是功能缺失而是生态断层——就像试图用 Windows XP 的 IE6 访问现代 Web 应用。所以本文要解决的从来不是“怎么装”而是如何在 Ubuntu 18.04 的约束下安全、稳定、可持续地获得一个生产可用的 Ansible 环境这个环境必须满足三个硬指标第一Ansible 核心版本 ≥ 2.12兼容绝大多数社区模块第二所有依赖库版本受控不污染系统 Python第三配置路径清晰、权限明确能无缝接入 CI/CD 流水线或团队协作流程。下面所有步骤都围绕这三个目标展开每一步都有明确的“为什么”和“不这么做会怎样”。2. 环境隔离方案对比为什么放弃 system pip 和 APT坚定选择 venv requirements.txt在 Ubuntu 18.04 上部署 Ansible有四种常见路径APT 全局安装、system pip 全局安装、venv 虚拟环境、Docker 容器。我们逐个拆解它们在真实运维场景中的表现。2.1 APT 方案稳定但过时适合“只读”场景sudo apt update sudo apt install ansible这是 Ubuntu 官方文档推荐的方式优点是零依赖冲突、卸载干净apt remove ansible即可。但致命缺陷在于版本锁定Ubuntu 18.04 的ansible包版本为2.5.1dfsg-1ubuntu0.2发布于 2018 年 7 月。这个版本不支持loop关键字2019 年引入无法使用community.general组织下的绝大多数模块该组织 2020 年成立甚至ansible-galaxy collection install命令都不存在collections 是 2.9 引入的。更重要的是其ansible.cfg默认配置中host_key_checking True在批量管理数百台主机时SSH 密钥验证会成为性能瓶颈而新版 Ansible 已默认关闭此项。如果你的自动化需求仅限于“重启某几台服务”APT 方案勉强可用但凡涉及动态 inventory、变量覆盖、条件任务它就是一条死路。2.2 System pip 方案灵活但危险等同于埋雷sudo pip3 install ansible # 或更糟的 sudo pip install ansible # 混用 pip2/pip3这种方式能拿到最新版 Ansible如pip3 install ansible6.7.0但代价是灾难性的。Ubuntu 18.04 的/usr/lib/python3/dist-packages/目录下系统工具如apt,unattended-upgrades严重依赖requests,urllib3,certifi等库。而pip3 install ansible会强制升级这些库到 Ansible 所需版本导致apt update报 SSL 错误requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]unattended-upgrades失败系统安全更新中断。我曾在一个金融客户环境里修复过此类问题pip3 install ansible后apt list --upgradable返回空apt update显示Could not resolve archive.ubuntu.com——实则是因为certifi被升级到 2022.12.7其证书包与 Ubuntu 18.04 的 OpenSSL 1.1.1 不兼容。回滚需要手动下载旧版.deb包并dpkg -i耗时 47 分钟。这不是效率问题而是稳定性红线。2.3 Docker 方案彻底隔离但运维成本高适合 CI/CD 而非日常管理FROM ubuntu:18.04 RUN apt-get update apt-get install -y python3-pip \ pip3 install ansible6.7.0 COPY playbook.yml /work/ CMD [ansible-playbook, /work/playbook.yml]Docker 确实完美解决了依赖隔离问题且镜像可版本化、可缓存。但它引入了新瓶颈首先Ansible 需要 SSH 连接到目标主机而容器内默认无 SSH client需额外apt install openssh-client其次Ansible 的local连接类型用于本机执行在容器中受限delegate_to: localhost可能因文件路径映射失败最重要的是日常运维中你不可能为每个 playbook 启动一个容器——调试时ansible-playbook -vvv的输出会被容器日志截断--limit动态限制主机列表的操作变得繁琐。Docker 更适合作为 CI/CD 流水线中的“执行单元”而非工程师本地的交互式运维环境。2.4 venv requirements.txt平衡之选兼顾可控性与实用性这才是我们最终采用的方案。核心逻辑是用 Python 内置的venv创建一个完全独立的 Python 环境所有 Ansible 及其依赖均安装于此与系统 Python 彻底隔离再通过requirements.txt文件固化版本确保团队成员、CI 服务器、跳板机上的环境 100% 一致。为什么是venv而非virtualenv因为 Ubuntu 18.04 的 Python 3.6 已内置venv模块无需额外安装virtualenv包减少一层依赖。venv创建的环境目录结构清晰bin/,lib/,include/bin/activate脚本可直接 source与 shell 集成自然。更重要的是venv的pip是纯净的不会继承系统pip的配置如--index-url避免私有 PyPI 源污染。提示不要用python3 -m venv ansible-env创建环境后再source ansible-env/bin/activate然后pip install ansible。这种“交互式安装”会导致版本不可追溯——下次重装时你无法知道当时装的是ansible6.7.0还是ansible-core2.14.3。必须通过requirements.txt管理。3. 实战部署从零构建可复现的 Ansible 环境含完整命令与参数解析现在进入实操环节。以下所有命令均在 Ubuntu 18.04Desktop 或 Server 版本上实测通过假设你以普通用户deployer登录家目录为/home/deployer。我们将创建一个名为ansible-env的虚拟环境安装 Ansible 6.7.0对应ansible-core 2.14.3并配置基础ansible.cfg。3.1 创建并激活虚拟环境# 确保系统已安装 python3-venvUbuntu 18.04 默认已装 sudo apt update sudo apt install -y python3-venv # 创建虚拟环境目录建议放在家目录下便于备份和迁移 python3 -m venv /home/deployer/ansible-env # 激活环境注意此命令仅对当前 shell 有效 source /home/deployer/ansible-env/bin/activate # 验证此时提示符应变为 (ansible-env) $且 python 和 pip 指向虚拟环境 which python3 # 输出/home/deployer/ansible-env/bin/python3 which pip # 输出/home/deployer/ansible-env/bin/pip关键点解析python3 -m venv命令会复制系统 Python 3.6 的二进制文件和标准库到ansible-env/目录但site-packages为空。source activate的作用是修改PATH环境变量将ansible-env/bin/置于最前从而让后续所有python3、pip命令都指向这个沙盒。切记每次新开终端都必须重新执行source /home/deployer/ansible-env/bin/activate否则你操作的是系统 Python。3.2 初始化 requirements.txt 并安装 Ansible创建requirements.txt文件内容如下# ansible-env/requirements.txt # Ansible 6.7.0 (released 2023-03-28) - 最新稳定版兼容 Ubuntu 18.04 ansible6.7.0 # 强制指定核心依赖版本避免 pip 自动升级导致不兼容 pyyaml5.4,6.0 jinja23.0,4.0 cryptography36.0,39.0 paramiko2.11,3.0为什么这样写ansible6.7.0是精确版本锁定。Ansible 6.x 系列是最后一个支持 Python 3.6 的大版本7.x 要求 Python 3.8而 Ubuntu 18.04 的 Python 3.6.9 是 LTS 支持的终点。pyyaml5.4,6.0YAML 解析器。6.0是关键因为 PyYAML 6.0 移除了yaml.load()的默认安全模式而 Ansible 6.7.0 的部分内部代码仍依赖旧 API若装 6.0 会报AttributeError: module yaml has no attribute load。jinja23.0,4.0模板引擎。Jinja2 3.x 是 Ansible 6.x 的官方支持范围4.x 引入了破坏性变更如Environment类的enable_async参数移除会导致template模块失效。cryptography36.0,39.0加密库。Ubuntu 18.04 的libssl1.1与 cryptography 39 不兼容编译时报undefined symbol: OPENSSL_sk_num36.0 是经过验证的稳定基线。paramiko2.11,3.0SSH 协议实现。2.11 支持 Ed25519 密钥且与 Ubuntu 18.04 的 OpenSSH 7.6p1 兼容性最佳。安装命令# 在已激活的 (ansible-env) 环境中执行 pip install -r /home/deployer/ansible-env/requirements.txt安装过程约需 2-3 分钟取决于网络。成功后验证ansible --version # 输出应包含 # ansible [core 2.14.3] # python version 3.6.9 (default, Jan 26 2021, 15:33:00) [GCC 8.4.0] # jinja version 3.1.2 # libyaml True注意如果ansible --version报错ImportError: cannot import name CryptographyDeprecationWarning说明cryptography版本过高。此时执行pip install cryptography36.0,37.0回退即可。这是 Ubuntu 18.04 上最常见的兼容性陷阱之一。3.3 配置 ansible.cfg从默认值到生产就绪Ansible 的配置文件ansible.cfg是控制行为的核心。Ubuntu 18.04 的默认配置位于/etc/ansible/ansible.cfg过于保守需重写。我们在ansible-env/目录下创建专属配置# 创建配置目录Ansible 会按顺序查找当前目录 - ~/.ansible.cfg - /etc/ansible/ansible.cfg mkdir -p /home/deployer/ansible-env/etc/ansible # 编辑配置文件 cat /home/deployer/ansible-env/etc/ansible/ansible.cfg EOF [defaults] # 基础路径设置 inventory ./inventory remote_user deployer private_key_file ~/.ssh/id_rsa_ansible host_key_checking False timeout 30 # 模块与插件路径 library ./library module_utils ./module_utils callback_plugins ./callback_plugins lookup_plugins ./lookup_plugins filter_plugins ./filter_plugins # 日志与输出 log_path ./ansible.log stdout_callback yaml display_skipped_hosts False # 性能优化 forks 10 gathering smart fact_caching jsonfile fact_caching_connection ./fact_cache # collections 路径Ansible 2.9 必须 collections_paths ./collections:/home/deployer/.ansible/collections # Jinja2 模板安全 jinja2_extensions jinja2.ext.do,jinja2.ext.loopcontrols [privilege_escalation] become True become_method sudo become_user root become_ask_pass False [ssh_connection] ssh_args -o ControlMasterauto -o ControlPersist60s -o ConnectTimeout10 control_path_dir /tmp/ansible-ssh [accelerate] accelerate_port 5099 accelerate_timeout 300 accelerate_connect_timeout 5.0 EOF这份配置的关键决策解析host_key_checking False关闭 SSH 密钥检查。在批量管理上百台主机时首次连接每台都要手动确认效率归零。生产环境应配合known_hosts文件预填充而非交互式确认。forks 10并发数。Ubuntu 18.04 的默认值是 5对于中等规模集群50-200 台10 是吞吐量与资源占用的平衡点。过高如 50会导致跳板机 CPU 爆满SSH 连接超时过低则耗时过长。gathering smart事实收集策略。“smart” 表示首次运行时收集所有 facts后续运行只收集变化的部分大幅减少setup模块开销。fact_caching jsonfile启用事实缓存。fact_caching_connection指向本地目录避免每次运行都重复执行setup对when条件判断频繁的 playbook 提升显著。collections_paths明确指定 collections 查找路径。./collections用于项目级 collections~/.ansible/collections用于用户级共享如community.general。提示private_key_file指向~/.ssh/id_rsa_ansible这是一个专用密钥绝不能使用id_rsa。原因有二一是权限分离避免 Ansible 误操作影响其他 SSH 服务二是密钥命名即文档id_rsa_ansible明确标识其用途方便团队交接。3.4 初始化项目结构与首个测试 playbook环境配置完毕现在初始化一个最小可行项目# 创建项目目录 mkdir -p /home/deployer/my-first-ansible-project/{inventory,playbooks,roles,group_vars,host_vars} # 创建简单 inventoryINI 格式 cat /home/deployer/my-first-ansible-project/inventory/hosts EOF [webservers] web1 ansible_host192.168.1.101 web2 ansible_host192.168.1.102 [dbservers] db1 ansible_host192.168.1.201 EOF # 创建测试 playbook cat /home/deployer/my-first-ansible-project/playbooks/ping.yml EOF --- - name: Test connectivity to all hosts hosts: all gather_facts: false tasks: - name: Ping test ansible.builtin.ping: register: ping_result - name: Display ping result ansible.builtin.debug: var: ping_result EOF执行测试# 切换到项目目录并激活环境 cd /home/deployer/my-first-ansible-project source /home/deployer/ansible-env/bin/activate # 运行 playbook指定 inventory 路径 ansible-playbook -i inventory/hosts playbooks/ping.yml如果一切正常你将看到类似输出PLAY [Test connectivity to all hosts] ***************************************** TASK [Ping test] ************************************************************* ok: [web1] ok: [web2] ok: [db1] TASK [Display ping result] *************************************************** ok: [web1] { ping_result: { changed: false, ping: pong } } ...这证明你的 Ansible 环境已完全就绪虚拟环境隔离、版本可控、配置生效、SSH 连通。4. 进阶配置集成 community.general 与 AWX/Ansible Automation Platform 的本地开发流当基础环境跑通后下一步是接入更强大的生态组件。Ubuntu 18.04 的特殊性在于它既是“老系统”又是“企业常用跳板机”因此必须支持两种典型场景一是使用community.general等社区模块扩展功能二是与 AWXRed Hat Ansible Automation Platform 的开源上游对接实现图形化编排与审计。4.1 安装并验证 community.general collectioncommunity.general是 Ansible 社区最活跃的模块集合包含proxmox_kvm,docker_container,aws_s3等数百个实用模块。在 Ubuntu 18.04 上安装它需特别注意依赖链# 确保在激活的 (ansible-env) 环境中 source /home/deployer/ansible-env/bin/activate # 安装 collection默认安装到 ~/.ansible/collections ansible-galaxy collection install community.general # 验证安装 ansible-galaxy collection list | grep community.general # 输出community.general 7.3.0但安装后不能直接用因为community.general的某些模块如docker_container依赖dockerPython SDK而dockerSDK 6.x 要求requests2.25.0但 Ubuntu 18.04 的requests2.18.4 是系统包pip install docker会尝试升级它引发前述的apt崩溃风险。解决方案是在虚拟环境中单独安装dockerSDK并确保其不触碰系统requests。# 在 (ansible-env) 中安装 docker SDK它会安装自己的 requests 副本 pip install docker6.0.0,7.0.0 # 验证检查 docker SDK 是否能导入 python3 -c import docker; print(docker.__version__) # 输出6.1.3现在可以写一个测试 playbook 使用community.general.docker_container# /home/deployer/my-first-ansible-project/playbooks/test-docker.yml --- - name: Test community.general.docker_container hosts: localhost connection: local tasks: - name: Pull and run nginx container community.general.docker_container: name: test-nginx image: nginx:alpine state: started ports: - 8080:80 register: container_result - name: Verify container is running ansible.builtin.command: docker ps --filter nametest-nginx --format {{.Status}} register: ps_result - name: Debug status ansible.builtin.debug: var: ps_result.stdout执行ansible-playbook -i inventory/hosts playbooks/test-docker.yml。如果成功说明community.general已深度集成且未污染系统环境。4.2 为 AWX/AAP 配置本地开发环境AWX 是 Ansible 自动化平台的开源前端它通过 REST API 与 Ansible Engine 交互。在 Ubuntu 18.04 跳板机上配置 AWX CLIawx命令行工具是实现“本地编写 → AWX 执行 → 图形化审计”的关键一环。首先安装 AWX CLI# 在 (ansible-env) 中安装 pip install awxkit # 配置 AWX 连接信息替换为你的 AWX 实例地址和凭据 cat /home/deployer/.awx/settings.yaml EOF --- host: https://awx.example.com username: admin password: your_password_here insecure: true # 如果 AWX 使用自签名证书设为 true生产环境应配合法证书 EOF然后测试连接# 获取 AWX 版本信息 awx version # 列出所有项目Projects awx projects list # 上传本地 playbook 目录到 AWX 项目 awx projects create \ --name My First Project \ --scm-type git \ --scm-url https://github.com/yourname/my-ansible-playbooks.git \ --scm-branch main这里的关键点是AWX CLI 必须运行在与 Ansible 相同的 Python 环境中。因为 AWX CLI 的awx命令底层调用的就是ansible-playbook它需要访问相同的collections_paths、ansible.cfg和 Python 模块。如果 AWX CLI 安装在系统 Python而 Ansible 在 venv那么 AWX 执行的 playbook 将无法加载community.general模块报错ERROR! the file_name undefined。因此我们的完整工作流是在ansible-env中安装awxkit所有awx命令都在source ansible-env/bin/activate后执行ansible.cfg中的collections_paths必须包含~/.ansible/collections确保 AWX CLI 能找到community.generalAWX 项目同步时SCM Update会拉取 Git 仓库但 playbook 中引用的collections仍由 AWX 实例的collections_paths决定——因此你还需要在 AWX 实例的/etc/tower/conf.d/custom.py中添加COLLECTIONS_PATHS [/var/lib/awx/vendor_collections, /var/lib/awx/projects/_123__my_first_project/collections]这样AWX 才能正确解析community.general.docker_container这样的 FQCNFully Qualified Collection Name。注意awxkit的insecure: true设置仅用于测试环境。生产中必须将 AWX 的 CA 证书导出放入~/.awx/certs/并在settings.yaml中指定certificate: ~/.awx/certs/awx-ca.crt否则 HTTPS 连接会失败。5. 长期维护与故障排查Ubuntu 18.04 上 Ansible 环境的“保质期”管理一个精心构建的 Ansible 环境其价值不在于“一次装好”而在于“长期稳定”。Ubuntu 18.04 的生命周期已于 2023 年 4 月结束这意味着其软件源不再接收安全更新但你的 Ansible 环境仍需持续运行。以下是我在多个客户现场总结的三大维护原则。5.1 版本冻结策略何时升级何时坚守Ansible 的版本迭代极快但并非所有升级都必要。我的经验是对 Ubuntu 18.04 环境Ansible 主版本6.x应冻结仅在必要时升级次版本如 6.7.0 → 6.8.0且必须经过全量回归测试。原因有三第一Python 3.6 的兼容性边界。Ansible 7.x 要求 Python 3.8而 Ubuntu 18.04 无法原生升级 Python 主版本apt install python3.8会破坏系统依赖。强行编译安装 Python 3.8会导致apt、systemd等核心工具异常得不偿失。第二模块 ABI 稳定性。Ansible 6.x 系列对community.general的 API 兼容性极佳7.x 则开始重构docker_*模块将docker_container拆分为docker_container_info、docker_container_exec等。这意味着你现有的 playbook 需要重写投入产出比极低。第三安全补丁的传递路径。Ansible 官方对 EOL 版本的安全漏洞如 CVE-2023-3776仍会提供补丁但仅针对最新维护分支6.8.x。因此保持ansible6.8.0是最优解——它既获得安全更新又无需重构代码。升级操作以 6.7.0 → 6.8.0 为例# 修改 requirements.txt sed -i s/ansible6\.7\.0/ansible6.8.0/g /home/deployer/ansible-env/requirements.txt # 重新安装pip 会自动处理依赖 pip install -r /home/deployer/ansible-env/requirements.txt # 验证版本 ansible --version # 应显示 core 2.14.4 # 运行回归测试假设有 test/ 目录 ansible-playbook -i inventory/hosts test/regression.yml提示回归测试 playbook 应覆盖所有核心场景SSH 连接、become提权、community.general模块调用、collections加载、fact_caching读写。一个简单的regression.yml可包含 5-10 个原子任务执行时间控制在 2 分钟内确保每日 CI 可快速反馈。5.2 环境健康检查清单5 分钟定位 90% 的问题当ansible-playbook突然失败时不要急于重装。按以下清单顺序检查90% 的问题可在 5 分钟内定位检查项命令预期输出异常表现解决方案1. 环境是否激活echo $VIRTUAL_ENV/home/deployer/ansible-env空输出source /home/deployer/ansible-env/bin/activate2. Python 是否指向 venvwhich python3/home/deployer/ansible-env/bin/python3/usr/bin/python3重新激活环境3. Ansible 版本是否正确ansible --version | head -n1ansible [core 2.14.3]ansible [core 2.5.1]检查是否误用了apt install的全局 Ansible4. SSH 密钥权限是否正确ls -l ~/.ssh/id_rsa_ansible*-rw------- 1 deployer deployer-rw-r--r--chmod 600 ~/.ssh/id_rsa_ansible*5. known_hosts 是否存在冲突ssh-keygen -F 192.168.1.101 -f ~/.ssh/known_hosts192.168.1.101 ssh-rsa AAAA...No matching key found手动ssh -o StrictHostKeyCheckingno deployer192.168.1.101接受密钥这个清单的核心思想是先确认执行环境再确认连接介质最后才是 Ansible 逻辑本身。很多“Ansible 报错”其实是 SSH 层面的问题比如Permission denied (publickey)但 Ansible 日志只显示UNREACHABLE!让人误以为是配置问题。5.3 备份与迁移如何将整个环境迁移到新跳板机当旧跳板机需要退役或团队新增成员时快速迁移 Ansible 环境是刚需。最佳实践是只备份requirements.txt和ansible.cfg其余全部重建。原因在于venv目录包含绝对路径如home/deployer/ansible-env/bin/python3直接 tar.gz 复制到新机器会失效。迁移步骤导出当前环境的精确依赖# 在旧机器上已激活环境 pip freeze /home/deployer/ansible-env/requirements-frozen.txt # 此文件包含所有包的精确版本如 ansible6.7.0, pyyaml5.4.1复制配置文件cp /home/deployer/ansible-env/etc/ansible/ansible.cfg /tmp/ansible.cfg.backup在新机器上重建# 新机器Ubuntu 18.04上 sudo apt install -y python3-venv python3 -m venv /home/deployer/ansible-env source /home/deployer/ansible-env/bin/activate pip install -r /tmp/requirements-frozen.txt mkdir -p /home/deployer/ansible-env/etc/ansible cp /tmp/ansible.cfg.backup /home/deployer/ansible-env/etc/ansible/ansible.cfg验证ansible --version # 版本号应与旧环境一致 ansible-playbook -i inventory/hosts playbooks/ping.yml # 连通性测试整个过程不超过 10 分钟且 100% 可复现。这就是requirements.txt的威力——它把“环境”从一个黑盒变成了可版本化、可审计、可协作的文本文件。6. 我的实战体会在 Ubuntu 18.04 上做 Ansible 运维本质上是在和时间赛跑在 Ubuntu 18.04 上部署 Ansible从来不是一场技术秀而是一场与时间的博弈。这个发行版发布于 2018 年 4 月它的内核4.15、OpenSSL1.1.1、Python3.6.9都是那个时代的产物。而 Ansible 社区却在飞速进化2020 年推出 Collections 架构2021 年强化ansible-core与ansible的分离2022 年全面拥抱pyproject.toml和PEP 517构建标准。夹在中间的 Ubuntu 18.04就像一辆还在用化油器的汽车却被要求跑在智能高速公路上。我之所以坚持用venv requirements.txt方案不是因为它最炫酷而是因为它最诚实。它不回避 Ubuntu 18.04 的陈旧也不幻想 Ansible 的未来而是用最朴素的隔离与锁定为自动化流程划出一条清晰的生存线。每一次pip install -r requirements.txt都是对确定性的确认每一行ansible.cfg的配置都是对不确定