90DaysOfDevOps 学习笔记 Day 69：Ansible 生态收官——AWX / Automation Controller 部署与 Ansible Vault 实战

• 文档/教程

本篇是 90DaysOfDevOps 系列中配置管理（Configuration Management）大章的收官篇，聚焦 Ansible 生态中围绕核心自动化引擎的周边工具：Red Hat Ansible Automation Platform 的控制平面Automation Controller（前身 Ansible Tower）及其开源上游项目AWX，并完整演示如何借助 AWX Operator 在本地 minikube Kubernetes 集群中部署 AWX 实例；随后引入ansible-vault解决本系列此前一直以明文存放敏感信息的问题，并顺带梳理 Ansible Galaxy、Molecule 与 ansible-lint 等测试与分发工具。读完本文，你将掌握从零搭建一套集中化、可视化、支持 RBAC 与工作流编排的 Ansible 控制平台的全过程，以及为已有 playbook 数据文件加解密的基本方法。

Ansible 自动化平台全景：不止是 ansible-playbook

在前 68 天里，我们一直在使用 Ansible 命令行工具链（ansible、ansible-playbook、ansible-galaxy）从单一控制节点操作被管主机。但真实的 Ansible 自动化平台（Red Hat Ansible Automation Platform）由大量产品共同组成，它是"在整个组织内构建和运行自动化的基础"，包含实现企业级自动化所需的全部工具。本仓库对应章节的英文原文位于 day69.md，越南语译文位于 day69.md，配图归档在 2022/Days/Images/ 下。

下图展示了该平台的产品组成：

本文档将介绍其中若干关键组件；完整的平台信息应以 Red Hat 官方站点为准。下面先从两个功能高度相似的项目讲起。

Automation Controller 与 AWX：企业版与开源上游

AWX（Ansible Workflow eXecution，项目名即 AWX）是由 Red Hat 赞助的开源社区项目，让你能够在环境中更好地控制 Ansible 项目。关键定位是：AWX 是 Automation Controller 组件所衍生的上游项目——也就是说，社区版 AWX 先行，企业版在此基础上商业化。

• Automation Controller：面向企业的解决方案，即 Ansible Automation Platform 的控制平面（control plane），过去更广为人知的名字是Ansible Tower。企业版需要为 Red Hat 的技术支持付费。
• AWX：免费且开源，功能与 Automation Controller 高度相似，适合学习、测试与预算有限的团队。

两者相对我们此前一直使用的命令行 + 单一控制节点模式，共同引入了以下核心能力：

• 用户界面（User Interface）：基于 Web 的可视化管理入口；
• 基于角色的访问控制（Role-Based Access Control）：可按团队/用户/项目划分权限；
• 工作流（Workflows）：将多个作业模板编排为可视化流程；
• CI/CD 集成：可通过 API/令牌对接流水线，把配置变更纳入持续交付链路。

下面我们进入实战：在本地 minikube 集群中部署 AWX。

实战：在 minikube 上部署 Ansible AWX

AWX 并非必须部署在 Kubernetes 集群中（AWX 官方 GitHub 仓库提供了其他方式的细节），但从18.0 版本起，AWX Operator 是被推荐的首选安装方式。Operator 模式把 AWX 的部署、升级、回滚封装为 Kubernetes 自定义资源（Custom Resource），大幅降低了运维成本。

第一步：准备 minikube 集群

如果你跟随本系列的 Kubernetes 部分操作过，应该对 minikube 不陌生。使用以下命令创建带 ingress 插件的集群（CPU 与内存按文档给出的建议值）：

minikube start --cpus=4 --memory=6g --addons=ingress

第二步：获取 awx-operator 仓库

AWX Operator 的安装文档要求克隆其仓库，再执行仓库内的部署清单。原作者的做法是 fork 后克隆：

git clone https://github.com/MichaelCade/awx-operator.git

这里给出一条实用建议：不要依赖他人（包括原作者）的 fork 仓库，因为上游可能修改或删除；应当基于官方 awx-operator 仓库自行 fork/clone，以保证清单与当前版本匹配。

第三步：调整 awx-demo.yml 的服务类型

在克隆下来的仓库中会看到一个awx-demo.yml文件，它声明了一个kind: AWX的自定义资源。默认配置下服务类型是NodePort，为了让后续能通过 minikube ingress 访问，需要将其改为ClusterIP：

--- apiVersion: awx.ansible.com/v1beta1 kind: AWX metadata: name: awx-demo spec: service_type: ClusterIP

这个清单体现了 Operator 的声明式特点：apiVersion: awx.ansible.com/v1beta1对应 AWX Operator 注册的自定义资源定义（CRD），spec.service_type直接控制 AWX 实例对外暴露的 Kubernetes Service 类型。

第四步：定义命名空间并部署 Operator

先导出命名空间变量，再通过make deploy触发 Operator 的部署：

export NAMESPACE=awx make deploy

完成后检查命名空间与控制器 Pod 是否就绪：

kubectl get pods -n awx

此时应能看到awx-operator-controllerPod 正在运行：

第五步：创建 AWX 实例

把调整后的awx-demo.yml提交到集群与awx命名空间：

kubectl create -f awx-demo.yml -n awx

随后持续观察 Pod 状态，AWX 会拉起多个相关组件（web、task 等），等待其全部进入 Running：

kubectl get pods -n awx -w

一切正常时，Pod 列表大致如下（持续处于 Ready/Running 状态）：

第六步：通过 ingress 暴露服务

在新的终端里运行以下命令，获取 AWX 服务的访问地址：

minikube service awx-demo-service --url -n $NAMESPACE

在浏览器中打开该地址，会看到登录页面，需要输入用户名和密码：

第七步：获取默认管理员密码

默认用户名为admin。初始密码由 AWX 自动生成并保存在 Kubernetes Secret 中，可通过以下命令解码获取（Secret 名称为awx-demo-admin-password，数据字段为 base64 编码的password）：

kubectl get secret awx-demo-admin-password -o jsonpath="{.data.password}" -n awx | base64 --decode

至此，你拥有了一套集中化的 Web UI，可以在同一位置管理 playbook 与配置管理任务，并支持团队成员协作——这正是我们此前从单一 Ansible 控制站操作所不具备的。AWX 能力面很广（凭证管理、作业模板、调查表单、RBAC、工作流画布等），值得专门花时间逐个体验。

Ansible Vault：为明文敏感信息加密

在贯穿本系列的多个演示场景中，我们都把敏感信息以明文形式写进了配置文件。以本仓库中的数据库场景为例，变量文件 common_variables.yml 直接存放了：

http_port: 8000 https_port: 4443 html_welcome_msg: "Hello 90DaysOfDevOps - Welcome to Day 68!" mysql_user_name: root mysql_user_password: vagrant db_user: devops db_pass: DevOps90 db_name: 90DaysOfDevOps

mysql_user_password、db_pass这类凭据以明文入库，一旦仓库泄露即等于凭据泄露——这正是 Day 69 明确指出需要解决的问题。

ansible-vault内置于 Ansible 二进制中，用于加密和解密 Ansible 数据文件，从而把敏感信息"掩盖"起来。常用操作包括：

# 创建新的加密文件 ansible-vault create secrets.yml # 加密现有文件 ansible-vault encrypt group_vars/all/common_variables.yml # 查看加密文件内容（交互式提示密码） ansible-vault view group_vars/all/common_variables.yml # 编辑加密文件 ansible-vault edit group_vars/all/common_variables.yml # 修改密码 ansible-vault rekey group_vars/all/common_variables.yml # 解密回明文 ansible-vault decrypt group_vars/all/common_variables.yml

加密后的文件以$ANSIBLE_VAULT;1.1;AES256头标识：

运行 playbook 时通过--ask-vault-pass交互式输入密码，或使用--vault-password-file指定密码文件；对于 inventory 里的密码、vars_password等敏感项，还可以进一步使用ansible-vault encrypt_string做字符串级加密。解密时机由 Ansible 在任务执行前自动处理，被管主机上始终只看到解密后的值。

Secrets Management（密钥管理）本身已发展为一个独立的专业领域，可延伸的工具还包括 HashiCorp Vault、AWS Key Management Service（KMS）等，这些可以作为后续深入的方向。

Ansible Galaxy：内容的发现与分享枢纽

在之前的演示项目中，我们已经多次使用ansible-galaxy来初始化 role 的目录骨架（例如ansible-galaxy init roles/mysql），生成 defaults/handlers/meta/tasks/templates/vars/tests 等标准结构，仓库中的 ansible-scenario7/roles/ 就是这种结构的实例。

除此之外，Ansible Galaxy本身也是一个 Web 平台——"Galaxy 是用于发现和分享 Ansible 内容的中心（hub）"。你可以：

• 通过ansible-galaxy install <namespace>.<collection>安装社区 role/collection；
• 通过ansible-galaxy role init、ansible-galaxy collection init创建本地内容；
• 发布自己维护的 role/collection 供社区复用。

将团队自研的 role 收敛为 Galaxy 内容，是让自动化资产在组织内规模化复用的关键一步。

Ansible 测试与质量保障：Molecule 与 ansible-lint

自动化代码同样需要测试与静态检查，Day 69 文档列出了两个核心工具：

• Ansible Molecule：专为辅助 Ansible role 的开发与测试而设计的项目。它提供多场景（scenario）测试框架，可基于 Docker、Vagrant、Podman 等驱动创建临时实例，执行 converge/verify/idempotence 等测试步骤，验证 role 的幂等性与正确性。本仓库中每个 role 都预置了tests/inventory与tests/test.yml（例如 roles/common/tests/），正是为这类测试预留的挂载点。
• Ansible Lint（ansible-lint）：用于对playbooks、roles 与 collections进行 lint 的 CLI 工具。它能发现语法问题、最佳实践偏离（如become使用不当、任务缺少name、YAML 风格问题等），适合接入 CI 在合并前自动检查。

将两者结合（lint 保证静态质量，molecule 保证运行行为），再接入 AWX 的 CI/CD 集成能力，即可构建"代码提交 → 静态检查 → 容器化测试 → 上线执行"的完整自动化治理链路。

参考资料与下一步

• Ansible 官方文档（含ansible-vault、ansible-galaxy、AWX 运维等全部模块的权威说明）
• 本系列此前 68 天沉淀的 playbook 示例，均可从仓库 2022/Days/Configmgmt/ 目录查阅，例如 playbook7.yml 及其对应的 Vagrantfile 环境定义

本文发布后，配置管理（Configuration Management）大章即告一段落。下一阶段将进入CI/CD Pipelines，研究并实践应用开发与发布流水线中的工具和流程——参见 Day 70。

• 文档/教程