尧图网站建设 
文档/教程【免费下载链接】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 生态中围绕核心自动化引擎的周边工具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企业版与开源上游AWXAnsible 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 AWXAWX 并非必须部署在 Kubernetes 集群中AWX 官方 GitHub 仓库提供了其他方式的细节但从18.0 版本起AWX Operator 是被推荐的首选安装方式。Operator 模式把 AWX 的部署、升级、回滚封装为 Kubernetes 自定义资源Custom Resource大幅降低了运维成本。第一步准备 minikube 集群如果你跟随本系列的 Kubernetes 部分操作过应该对 minikube 不陌生。使用以下命令创建带 ingress 插件的集群CPU 与内存按文档给出的建议值minikube start --cpus4 --memory6g --addonsingress第二步获取 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 注册的自定义资源定义CRDspec.service_type直接控制 AWX 实例对外暴露的 Kubernetes Service 类型。第四步定义命名空间并部署 Operator先导出命名空间变量再通过make deploy触发 Operator 的部署export NAMESPACEawx 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 等等待其全部进入 Runningkubectl 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 编码的passwordkubectl 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: 90DaysOfDevOpsmysql_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 ServiceKMS等这些可以作为后续深入的方向。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 Lintansible-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。赞分享文档/教程【免费下载链接】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 第 69 天Ansible 生态拓展——Automation Controller/AWX、Ansible Vault 与 Galaxy 实战90DaysOfDevOps 第 69 天Ansible 生态拓展——Automation Controller/AWX、Ansible Vault 与 Ga文档/教程90DaysOfDevOps 之 Ansible 生态进阶Automation Controller (AWX) 部署与 Ansible Vault 加密实战90DaysOfDevOps 之 Ansible 生态进阶Automation Controller AWX 部署与 Ansible Vault 加密实战 本文档/教程90DaysOfDevOps 配置管理收官篇Ansible Automation ControllerTower/ AWX 与 Vault 实战指南90DaysOfDevOps 配置管理收官篇Ansible Automation ControllerTower/ AWX 与 Vault 实战指南 本篇文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 学习笔记 Day 69：Ansible 生态收官——AWX / Automation Controller 部署与 Ansible Vault 实战
文档/教程【免费下载链接】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 生态中围绕核心自动化引擎的周边工具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企业版与开源上游AWXAnsible 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 AWXAWX 并非必须部署在 Kubernetes 集群中AWX 官方 GitHub 仓库提供了其他方式的细节但从18.0 版本起AWX Operator 是被推荐的首选安装方式。Operator 模式把 AWX 的部署、升级、回滚封装为 Kubernetes 自定义资源Custom Resource大幅降低了运维成本。第一步准备 minikube 集群如果你跟随本系列的 Kubernetes 部分操作过应该对 minikube 不陌生。使用以下命令创建带 ingress 插件的集群CPU 与内存按文档给出的建议值minikube start --cpus4 --memory6g --addonsingress第二步获取 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 注册的自定义资源定义CRDspec.service_type直接控制 AWX 实例对外暴露的 Kubernetes Service 类型。第四步定义命名空间并部署 Operator先导出命名空间变量再通过make deploy触发 Operator 的部署export NAMESPACEawx 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 等等待其全部进入 Runningkubectl 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 编码的passwordkubectl 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: 90DaysOfDevOpsmysql_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 ServiceKMS等这些可以作为后续深入的方向。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 Lintansible-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。赞分享文档/教程【免费下载链接】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 第 69 天Ansible 生态拓展——Automation Controller/AWX、Ansible Vault 与 Galaxy 实战90DaysOfDevOps 第 69 天Ansible 生态拓展——Automation Controller/AWX、Ansible Vault 与 Ga文档/教程90DaysOfDevOps 之 Ansible 生态进阶Automation Controller (AWX) 部署与 Ansible Vault 加密实战90DaysOfDevOps 之 Ansible 生态进阶Automation Controller AWX 部署与 Ansible Vault 加密实战 本文档/教程90DaysOfDevOps 配置管理收官篇Ansible Automation ControllerTower/ AWX 与 Vault 实战指南90DaysOfDevOps 配置管理收官篇Ansible Automation ControllerTower/ AWX 与 Vault 实战指南 本篇文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考