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.x（2018 年发布），而社区主流早已推进到 2.14+；Python 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 年底已正式归档（EOL），Ubuntu 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.1+dfsg-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 ansible==6.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 ansible==6.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。这种“交互式安装”会导致版本不可追溯——下次重装时，你无法知道当时装的是ansible==6.7.0还是ansible-core==2.14.3。必须通过requirements.txt管理。

3. 实战部署：从零构建可复现的 Ansible 环境（含完整命令与参数解析）

现在进入实操环节。以下所有命令均在 Ubuntu 18.04（Desktop 或 Server 版本）上实测通过，假设你以普通用户deployer登录，家目录为/home/deployer。我们将创建一个名为ansible-env的虚拟环境，安装 Ansible 6.7.0（对应ansible-core 2.14.3），并配置基础ansible.cfg。

3.1 创建并激活虚拟环境

# 确保系统已安装 python3-venv（Ubuntu 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 ansible==6.7.0 # 强制指定核心依赖版本，避免 pip 自动升级导致不兼容 pyyaml>=5.4,<6.0 jinja2>=3.0,<4.0 cryptography>=36.0,<39.0 paramiko>=2.11,<3.0

为什么这样写？

• ansible==6.7.0是精确版本锁定。Ansible 6.x 系列是最后一个支持 Python 3.6 的大版本（7.x 要求 Python 3.8+），而 Ubuntu 18.04 的 Python 3.6.9 是 LTS 支持的终点。
• pyyaml>=5.4,<6.0：YAML 解析器。<6.0是关键，因为 PyYAML 6.0 移除了yaml.load()的默认安全模式，而 Ansible 6.7.0 的部分内部代码仍依赖旧 API，若装 6.0+ 会报AttributeError: module 'yaml' has no attribute 'load'。
• jinja2>=3.0,<4.0：模板引擎。Jinja2 3.x 是 Ansible 6.x 的官方支持范围，4.x 引入了破坏性变更（如Environment类的enable_async参数移除），会导致template模块失效。
• cryptography>=36.0,<39.0：加密库。Ubuntu 18.04 的libssl1.1与 cryptography 39+ 不兼容（编译时报undefined symbol: OPENSSL_sk_num），36.0 是经过验证的稳定基线。
• paramiko>=2.11,<3.0：SSH 协议实现。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 "cryptography>=36.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 ControlMaster=auto -o ControlPersist=60s -o ConnectTimeout=10 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} # 创建简单 inventory（INI 格式） cat > /home/deployer/my-first-ansible-project/inventory/hosts << 'EOF' [webservers] web1 ansible_host=192.168.1.101 web2 ansible_host=192.168.1.102 [dbservers] db1 ansible_host=192.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等社区模块扩展功能；二是与 AWX（Red Hat Ansible Automation Platform 的开源上游）对接，实现图形化编排与审计。

4.1 安装并验证 community.general collection

community.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 要求requests>=2.25.0，但 Ubuntu 18.04 的requests2.18.4 是系统包，pip install docker会尝试升级它，引发前述的apt崩溃风险。解决方案是：在虚拟环境中单独安装dockerSDK，并确保其不触碰系统requests。

# 在 (ansible-env) 中安装 docker SDK（它会安装自己的 requests 副本） pip install "docker>=6.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 "name=test-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 CLI（awx命令行工具），是实现“本地编写 → 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。

因此，我们的完整工作流是：

1. 在ansible-env中安装awxkit；
2. 所有awx命令都在source ansible-env/bin/activate后执行；
3. ansible.cfg中的collections_paths必须包含~/.ansible/collections，确保 AWX CLI 能找到community.general；
4. AWX 项目同步时，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这样的 FQCN（Fully 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）。因此，保持ansible==6.8.0是最优解——它既获得安全更新，又无需重构代码。

升级操作（以 6.7.0 → 6.8.0 为例）：

# 修改 requirements.txt sed -i 's/ansible==6\.7\.0/ansible==6.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 分钟内定位：

这个清单的核心思想是：先确认执行环境，再确认连接介质，最后才是 Ansible 逻辑本身。很多“Ansible 报错”其实是 SSH 层面的问题，比如Permission denied (publickey)，但 Ansible 日志只显示UNREACHABLE!，让人误以为是配置问题。

5.3 备份与迁移：如何将整个环境迁移到新跳板机？

当旧跳板机需要退役，或团队新增成员时，快速迁移 Ansible 环境是刚需。最佳实践是：只备份requirements.txt和ansible.cfg，其余全部重建。原因在于，venv目录包含绝对路径（如home/deployer/ansible-env/bin/python3），直接 tar.gz 复制到新机器会失效。

迁移步骤：

1. 导出当前环境的精确依赖：

   # 在旧机器上（已激活环境） pip freeze > /home/deployer/ansible-env/requirements-frozen.txt # 此文件包含所有包的精确版本，如 ansible==6.7.0, pyyaml==5.4.1

2. 复制配置文件：

   cp /home/deployer/ansible-env/etc/ansible/ansible.cfg /tmp/ansible.cfg.backup

3. 在新机器上重建：

   # 新机器（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

4. 验证：

   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）、OpenSSL（1.1.1）、Python（3.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的配置，都是对不确定