Red Hat Ansible Automation Platform 创建指南

下表显示了 Ansible Automation Platform 2.0 上可用的工具的安排和使用，以及如何使用它们：

Playbook 是使用 YAML 编写的文件，其中包含特定组人类可读的指令或 "plays"，供您发送到在单个目标或目标组上运行。

Playbook 可用于管理远程机器的配置和部署，以及涉及滚动更新的多层部署顺序。使用 playbook 将操作委派给其他主机，并在此过程中与监控服务器和负载平衡器交互。编写完 playbook 后，您可以在企业内重复使用 playbook 实现自动化。

角色是 Ansible 捆绑自动化内容的方法，以及利用已知文件结构自动加载相关变量、文件、任务、处理程序和其他工件。除了创建具有数百个任务的大型 playbook 外，您可以使用角色将任务划分为更小、分散的工作单元。

您可以查找用于调配基础架构、部署应用以及 Ansible Galaxy 上每天执行的所有任务的角色。根据 Type 过滤您的搜索并选择 Role。找到感兴趣的角色后，您可以使用 Ansible 捆绑的 ansible-galaxy 命令下载角色：

$ ansible-galaxy role install username.rolename

Ansible 内容集合是用于自动化的现成工具包。它包括几种类型的内容，如 playbook、角色、模块和插件。下图显示了集合的基本结构：

collection/
├── docs/
├── galaxy.yml
├── meta/
│   └── runtime.yml
├── plugins/
│   ├── modules/
│   │   └── module1.py
│   ├── inventory/
│   ├── lookup/
│   ├── filter/
│   └── .../
├── README.md
├── roles/
│   ├── role1/
│   ├── role2/
│   └── .../
├── playbooks/
│   ├── files/
│   ├── vars/
│   ├── templates/
│   ├── playbook1.yml
│   └── tasks/
└── tests/
    ├── integration/
    └── unit/

在 Red Hat Ansible Automation Platform 中，自动化中心充当 Ansible 认证内容集合的来源。

自动化执行环境是一致且可共享的容器镜像，充当 Ansible 控制节点。自动化执行环境减少了共享具有外部依赖项的 Ansible 内容的挑战。

自动化执行环境包括：

您可以使用 Ansible Builder 定义并创建自动化执行环境。

Ansible Builder（Ansible 构建器）是一个命令行工具，它通过使用各种 Ansible Collections 中定义的元数据以及用户自动构建自动化执行环境的过程。

在开发 Ansible Builder 之前，Red Hat Ansible Automation Platform 用户可以在创建自定义虚拟环境或容器（包含所有必要的依赖项）时遇到依赖项问题和错误。

现在，使用 Ansible Builder 时，您可以轻松地创建一个可自定义的自动化执行环境定义文件，该文件指定了自动化执行环境中包含的内容，如集合、第三方 Python 要求和系统级别软件包。这可让您满足所有必要的要求和依赖项来获取作业运行。

自动化内容导航器是一种命令行以内容创建者为导向的工具，具有基于文本的用户界面。您可以使用自动化内容导航器进行：

Automation Hub 为红帽订阅的用户提供了一个途径，以便快速查找和使用红帽及我们的技术合作伙伴支持的内容，以便为最要求的环境提供额外的保证。

在高级别上，自动化中心为所有合作伙伴提供参与并提供经过认证的支持内容的概述。

从中央视图中，用户可以深入了解每个合作伙伴并签出集合。

此外，也可搜索所有可用集合的概述。

在命令行中使用 Ansible 是运行您不经常重复的任务的有用方法。处理重复任务的建议方法是编写 playbook。

命令行中 Ansible 的临时命令遵循以下结构：

$ ansible [pattern] -m [module] -a "[module options]"

您可以从 RPM 在 Red Hat Enterprise Linux (RHEL)上安装自动化内容导航程序。

以下示例演示了成功安装：

Ansible Automation Platform 2.0 附带的基础镜像托管在红帽生态系统目录(registry.redhat.io)上。

Playbook 包含一个或多个 play。基本 play 包括以下部分：

- name: Set Up a Project and Job Template
  hosts: host.name.ip
  become: true

  tasks:
    - name: Create a Project
      ansible.controller.project:
        name: Job Template Test Project
        state: present
        scm_type: git
        scm_url: https://github.com/ansible/ansible-tower-samples.git

    - name: Create a Job Template
      ansible.controller.job_template:
        name: my-job-1
        project: Job Template Test Project
        inventory: Demo Inventory
        playbook: hello_world.yml
        job_type: run
        state: present

您可以使用 Ansible Galaxy CLI 工具在本地创建自己的集合。您可以使用 collection 子命令激活特定于集合的命令。

前面的 命令将从命名空间参数（如果尚未存在）创建名为 的目录，然后在 下创建一个具有集合名称的目录。该目录内为默认值或"框架"集合。在这里，您可以添加角色或插件，并开始开发自己的集合。

对于执行环境，集合开发人员可以通过在 Ansible Builder 中提供适当的元数据来声明其内容的要求。

集合的要求可以通过以下方法识别：

集合维护者可以使用 introspection 命令验证 ansible-builder 是否识别他们期望的要求：

$ ansible-builder introspect --sanitize ~/.ansible/collections/

您可以使用 Ansible Galaxy CLI 工具创建角色。您可以从 roles 子命令访问特定于角色的命令。

ansible-galaxy role init <role_name>

仍然支持集合之外的独立角色，但在集合内创建新的角色，以利用 Ansible Automation Platform 必须提供的所有功能。

这将通过将 ~/role_skeleton 的内容复制到 my _role 来创建名为 my_role 的角色。role_skeleton 的内容可以是在角色目录中有效的任何文件或文件夹。

为环境指定一组集合的概念是解析并安装其依赖项。不需要将集合本身安装到您要在其上生成自动化执行环境的机器上。

从此定义构建自动化执行环境，生成容器镜像。请阅读 Ansible Builder 文档，以了解创建这些镜像涉及的步骤。

升级到 Red Hat Ansible Automation Platform 2.0 和自动化控制器 4.0 后，请使用以下部分协助迁移过程中的其他步骤。

# Discovered virtual environments:
/var/lib/awx/venv/testing
/var/lib/venv/new_env

To export the contents of a virtual environment, re-run while supplying the path as an argument:
awx-manage export_custom_venv /path/to/venv

inventory_sources:
- id: 15
  name: celery
job_templates:
- id: 9
  name: Demo Job Template @ 2:40:47 PM
- id: 13
  name: elephant
organizations
- id: 3
  name: alternating_bongo_meow
- id: 1
  name: Default
projects: []

numpy==1.20.2
pandas==1.2.4
python-dateutil==2.8.1
pytz==2021.1
six==1.16.0

To list all available custom virtual environments run:
awx-manage list_custom_venvs

在 Ansible 核心版本之间迁移需要您更新 playbook、插件和 Ansible 基础架构的其他部分，以确保它们使用最新版本。此过程要求根据对每个连续版本的 Ansible Core 所做的更新来验证更改。如果您要从 Ansible 的早期版本迁移到 Ansible-core 2.15，您首先需要验证是否满足遵循您的版本的 Ansible 版本的要求，并从那里对 2.15 进行连续的更新。

作为内容创建者，您可以使用自动化内容导航器并以交互方式执行 Ansible playbook，以交互方式进入每个 play 的结果，以及验证或排除 playbook 的任务。您还可以在执行环境中执行 Ansible playbook，且无需执行环境，以比较和排除任何问题。