在 Microsoft Azure 上使用 Red Hat Ansible Automation Platform 指南

Red Hat Ansible Automation Platform 2.1

在 Microsoft Azure 上安装和配置 Red Hat Ansible Automation Platform

Red Hat Customer Content Services

摘要

提供反馈:
如果您对本文档有任何改进建议,或发现错误,请联系技术支持 https://access.redhat.com,使用 Docs组件在 Ansible Automation PlatformJIRA 项目中创建一个问题。

前言

感谢您对 Red Hat Ansible Automation Platform 的关注。Ansible Automation Platform 是一个商业产品,它可以帮助团队通过增加控制、知识、协调基于 Ansible 的环境来更好地管理多阶的复杂部署环境。

本指南帮助您了解 Microsoft Azure 上的 Ansible Automation Platform 的安装和使用。本文档已更新,以包含 Microsoft Azure 上 Ansible Automation Platform 最新版本的信息。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息

第 1 章 介绍在 Microsoft Azure 上使用 Ansible Automation Platform

1.1. 关于在 Microsoft Azure 上使用 Red Hat Ansible Automation Platform

Microsoft Azure 上的 Red Hat Ansible Automation Platform 是一个受管应用程序,您可以从 Azure Marketplace 门户部署到 Azure 租户中的资源组。Microsoft Azure 上的 Ansible Automation Platform 提供对 Ansible 内容集合库的访问,并与密钥 Azure 服务集成,以便您可以快速启动部署、配置和管理基础架构和应用程序。

以下 Red Hat Automation Platform 组件在 Microsoft Azure 上的 Red Hat Ansible Automation Platform 上提供:

  • 自动化控制器
  • Automation Hub
  • 私有 Automation Hub
  • Automation Service Catalog
  • Ansible 内容集合,包括 Azure 的 Microsoft 集合
  • 自动化执行环境
  • Ansible 内容工具,包括访问 Red Hat Insights for Red Hat Ansible Automation Platform
注意

Microsoft Azure 上的 Ansible Automation Platform 不提供自动化网格。

1.2. 应用程序架构

Microsoft Azure 上的 Red Hat Ansible Automation Platform 作为受管应用程序安装。红帽管理底层 Azure 资源以及其上运行的软件,同时基础架构在您的 Azure 租户中运行。

受管应用程序资源组与租户中的其他资源组完全分开。红帽只能访问受管应用程序资源组,对其他租户资源没有可见性。

有关如何操作以及如何将资源和访问与 Azure 资源的其余部分隔离的信息,请参阅 Microsoft Azure 受管应用程序指南中的 Azure 受管应用程序概述。

Microsoft Azure 上的 Ansible Automation Platform 使用以下资源组:

  • 租户中的新或现有资源组 (RG)。此资源组包含引用 Microsoft Azure 托管应用程序部署上的 Ansible Automation Platform 的单个资源。红帽可以访问受管应用程序来执行支持、维护和升级,但资源组在红帽管理之外。
  • 多租户管理资源组 (MRG),其中包含在 Microsoft Azure 上使用 Ansible Automation Platform 所需的大多数基础架构。此多租户资源组在红帽租户和您的租户之间共享。红帽拥有完全的管理控制,您有对资源组的只读访问权限。
  • AKS 节点池资源组 (NPRG)。Microsoft 需要用于 AKS 部署的 NPRG。它包含 AKS 用来运行的资源。它在部署时创建,位于红帽管理之外。有关 NPRG 的更多信息,请参阅 Microsoft 的 AKS 文档
注意

不要与节点池资源组 (NPRG) 中的任何资源进行交互,除非 Red Hat Ansible Automation Platform on Microsoft Azure SRE 团队明确要求您这样做。对 NPRG 中的资源的更改不受红帽保护,这可能会对应用程序造成无法恢复的破坏。

红帽无法限制您在 NPRG 中更改或删除资源。

当您在 Microsoft Azure 上安装 Ansible Automation Platform 时,您可以选择部署是公共还是私有。这会影响用户如何访问 Ansible Automation Platform 用户界面。

无论您选择公共或私有部署,都必须配置网络 peer,以便从 Ansible Automation Platform 的出站通信到含有您要自动化的资源的专用网络。您可以将从 Microsoft Azure 上的 Ansible Automation Platform 的网络对等配置为私有 Azure VNets,并在内部或多云网络(使用 Azure 传输路由)中。

1.2.1. 公共部署

公共部署允许通过公共互联网到 Microsoft Azure 用户界面中 Ansible Automation Platform 的入口流量。部署后,会向 Microsoft Azure 实例上的 Ansible Automation Platform 发出了一个域名。不需要进行配置就可以访问 Ansible Automation Platform。用户可以从公共互联网导航到域,并登录用户界面。

下图显示了在 Microsoft Azure 上公共部署 Ansible Automation Platform 的公共部署中部署到受管应用程序资源组中的应用程序资源和架构。IP 范围会根据您在部署上设置的网络地址范围而改变。

azure 公共部署中的一个 aap

1.2.2. 私有部署

Ansible Automation Platform 的专用部署位于隔离的 Azure VNet 中,无法访问外部来源:到公共互联网的流量和其他 Azure VNets 和子网。

要访问 Ansible Automation Platform 用户界面的 URL,您必须配置网络 peering。

配置了对等和路由后,用户可以通过连接的 Azure 子网上的虚拟机访问 Ansible Automation Platform,或者,如果您的机构已在 Azure 和本地网络间传输路由。

注意

没有两个 Azure 网络配置是相同的。要允许用户访问 Ansible Automation Platform URL,您的机构需要与您的 Azure 管理员一起工作,以连接私有访问部署。

下图显示了在 Microsoft Azure 上部署 Ansible Automation Platform 的私有部署中部署到受管应用程序资源组中的应用程序资源和架构。IP 范围会根据您在部署上设置的网络地址范围而改变。

azure 私有部署中的一个 aap

1.3. Network

您可以为 Microsoft Azure 应用程序上 Ansible Automation Platform 使用的 VNet 配置网络地址范围(CIDR 块)。当您在 Microsoft Azure 上部署 Ansible Automation Platform 时,您需要在网络配置表单中为应用程序设置 CIDR 块。在将 Ansible Automation Platform 部署到 Microsoft Azure 应用程序前,规划您的网络配置,因为部署后无法更改网络配置。

在规划网络配置时,请牢记以下几点:

  • 受管应用至少需要 /24 Vnet 划分为四个子网。子网具有最小地址空间。

    网络实体最小 CIDR 块

    VNet

    /24

    集群子网

    /26

    网关子网

    /28

    数据库子网

    /28

    私有链接子网

    /28

  • 确定您配置的 VNet 范围不会与 AKS 集群的默认 CIDR 块 (10.0.0.0/16) 进行交互。Azure 用户界面不会阻止您输入这个范围,而是对 VNet 使用默认 AKS CIDR 块会导致网络问题。
  • 为确保 Microsoft Azure 上的 Ansible Automation Platform 和现有网络之间的网络对等点和通信,您的企业网络范围不得与 VNet 网络范围重叠。
  • 如果您没有现有的 Azure VNet,Azure 用户界面会建议 VNet 的默认 CIDR 块和范围。不接受这些默认值。反之,使用您计划的网络配置。

有关规划网络地址范围并完成部署的网络配置表单的详情,请参考 Microsoft Azure VNet 上的 Red Hat Ansible Automation Platform

1.4. Microsoft Azure 上的 Ansible Automation Platform 基础架构使用

在 Microsoft Azure 上安装 Ansible Automation Platform 时,以下基础架构将部署到 Azure 订阅中:

Azure Kubernetes 服务(AKS)

用于部署 Ansible Automation Platform 应用程序和服务的 Kubernetes 集群。

Service Shape:

  • Compute 节点: Standard_D4s_v3(4 个 vCPU x 16 GiB)
  • 自动缩放最小节点:2
  • 自动缩放最大节点:20
受管身份
启用 Ansible Automation Platform 组件与其他 Azure 服务(如数据库、DNS、存储和其他服务)通信的 Azure 服务。
密钥库
用于存储对 Ansible Automation Platform 部署是唯一的 secret 的安全密钥库。
日志分析工作区(Log Analytics Workspace)
一个 Azure 服务,可以使红帽站点可靠性工程师检查 Microsoft Azure 上的 Ansible Automation Platform 的操作 。
私有 DNS 区域
管理 Microsoft Azure 上 Ansible Automation Platform 使用的服务的本地 DNS 请求。
PostgreSQL 的 Azure 数据库

用于 Ansible Automation Platform 的 PostgreSQL 数据库的 Azure 数据库服务。

Service Shape: 1 TB

存储帐户

Azure 服务用于文件和块存储用于本地存储、容器等。

Service Shape: StorageV2 - Standard_LRS

虚拟网络

Azure 服务用于管理所有内部网络和依赖服务,如 Azure 应用程序网关。

Service Shape: Application Gateway: WAF_v2

确切的基础架构使用取决于在租期中部署受管应用程序的时间长度,以及可能导致 Kubernetes 集群自动扩展以满足您的工作负载需求的自动化要求。

Microsoft 提供了一种 定价计算器,用于估算 Azure 产品和服务的成本。红帽已在定价计算器中配置了示例场景: 使用 Azure 基础架构上的 Red Hat Ansible Automation Platform 来根据机构的工作负载调整 Kubernetes 预期的自动扩展变量。

1.5. 生命周期管理

Red Hat Ansible 负责监控、健康和维护 Microsoft Azure 核心系统上的底层服务和 Ansible Automation Platform,以及 Microsoft Azure 本身上的 Ansible Automation Platform 的操作。这包括组件的生命周期管理。

1.6. Microsoft Azure 上的 Ansible Automation Platform 的扩展

用于自动扩展的 Microsoft Azure 集群自动扩展上的 Ansible Automation Platform 默认配置,使用以下设置来限制节点数量:

  • 最少节点数:1
  • 最大节点数:20

1.7. Migration(迁移)

红帽不提供将现有部署迁移到 Microsoft Azure 上的 Ansible Automation Platform 的解决方案。

第 2 章 在 Microsoft Azure 上安装 Red Hat Ansible Automation Platform

2.1. 先决条件

Azure 要求

  • Microsoft Azure 的订阅。
  • 对 Azure 订阅的贡献者或管理员访问权限。
  • 访问 Azure CLI。

Ansible Automation Platform 要求

  • 红帽客户门户网站中有一个帐户(access.redhat.com)。
  • 一个 Red Hat Ansible Automation Platform 的特定订阅权利。

2.1.1. Azure 资源配额和基础架构限制

Microsoft 在每个 Azure 区域内实施资源限值。CPU 限制是 Red Hat Ansible Automation Platform 对 Microsoft Azure 的影响最有可能。

在 Microsoft Azure 上安装 Ansible Automation Platform 前,请确保您有能力将受管应用程序部署到所需的区域。如需基础架构要求,请参阅 Azure 基础架构使用

2.1.1.1. 地区 vCPU 限制

部署受管应用程序时使用的 Azure 资源会临时超过 Azure 基础架构使用中的资源要求。部署受管应用程序时,会临时消耗总区域 vCPU 配额。

每个 Azure 区域都有单独的 Total Regional vCPU 配额。要防止安装失败,请确保在要部署受管应用程序的 Azure 区域中至少有 80 个 DS2_V3 vCPU。

以下步骤描述了如何查看 Azure 控制台的资源配额:

  1. 在 Azure 控制台中,搜索 Quotas 并打开 My Quotas 页面。
  2. 选择您要部署受管应用程序的区域,以查看该区域的分配和使用指标。确保您已选择一个区域。一次查看所有区域将不会显示单个 Azure 区域的限制。

2.1.1.2. 区域标准内核限制

StandardCore 限制是部署受管应用程序时暂时消耗的资源的计算指标。

Microsoft Azure 上的 Ansible Automation Platform 可能会在不达到 StandardCore 限制的情况下进行部署。当部署失败时,因为消耗的资源达到 StandardCore 限制,错误消息包括 container group quota 'StandardCores' exceeded:

code: DeploymentFailed
message:
  At least one resource deployment operation failed. Please list deployment operations for details.
  Please see https://aka.ms/DeployOperations for usage details.
details:
  - code: DeploymentScriptContainerGroupInvalidSettings
    message:
      Resource type 'Microsoft.ContainerInstance/containerGroups'
      container group quota 'StandardCores' exceeded in region 'eastus'.
      Limit: '10', Usage: '10' Requested: '1'.

请求 StandardCore 限制增加

Azure 控制台的 My Quotas 页面中不会显示 StandardCore 指标。要请求您地区限制的值,请直接联系 Microsoft。

如果您的部署因为消耗的资源达到这个限制而失败,您需要向 Microsoft 提交对 StandardCore 的资源增加请求。只有在遇到造成此问题的部署失败时,才提交配额增加请求。

使用以下信息响应 Microsoft 支持中的问题:

容器组在 Linux 或 Windows 中运行?
Linux
容器组实例中的内核和内存是什么?
红帽建议 20 个内核,16 GB
何时创建所有容器组实例?
在 Microsoft Azure 上管理的应用程序部署 Red Hat Ansible Automation Platform
创建/删除容器组的频率?
仅在 Microsoft Azure 上管理的应用程序部署 Red Hat Ansible Automation Platform 时

2.2. 创建服务主体

要启用 Ansible Automation Platform 应用程序访问和管理 Azure 资源,您必须在部署后提供授权凭证。Microsoft Azure 集合支持服务主体验证。

要创建服务主体,您必须在 Azure 租户上具有有租赁权限的管理员特权。Microsoft Azure 部署的 Ansible Automation Platform 将在与此步骤中创建的服务主体相同的订阅 ID 中置备。

  1. 进入到 Azure 门户,点 Cloud Shell 图标在浏览器中打开 bash Cloud Shell。
  2. 将 Azure CLI 设置为使用您要用于自动化 Azure 服务的订阅。在 shell 中运行以下命令:

    az account set --subscription <your_subscription_id>
  3. 使用 Azure CLI 运行以下命令,在 Azure AD 中创建特权服务主体:

    az ad sp create-for-rbac --name ansible --role Contributor

    输出显示服务主体的 appIDtenant 键:

    {
      "appId": "xxxxxxx-xxx-xxxx",
      "displayName": "ansible",
      "name": "xxxxxxx-xxx-xxxx",
      "password": "xxxxxxx-xxx-xxxx",
      "tenant": "xxxxxxx-xxx-xxxx"
    }
  4. 安全地存储服务主体详情,因为它们仅在创建 secret 时显示。部署 Automation 控制器时,您将需要它们。

2.2.1. 维护服务主体

服务主体凭证在 Azure AD 配置中设置有限的生命周期。如果要延长时间对 Azure 进行自动化,请跟踪服务主体的期限。您可以根据需要创建新名称。

要查看更新或删除的服务原则的记录,请运行以下命令:

az ad sp list -o table | grep ansible

此命令不显示服务主体的 secret。删除服务主体并在 secret 丢失时创建新主体。

当创建新服务主体来替换过期或删除时,您必须更新使用您要替换的服务主体的凭证。如果没有更新凭证,则使用该凭证的自动化会失败。

2.3. 从 Azure Marketplace 部署 Ansible Automation Platform

2.3.1. 在 Azure Marketplace 中查找 Ansible Automation Platform

  1. 在一个浏览器中,进入 Azure Marketplace。
  2. 在导航面板中,从屏幕左侧的菜单中选择 Private Products
  3. 搜索 Red Hat Ansible Automation Platform。
  4. 点搜索中返回的卡。请务必选择红帽的官方产品。
  5. Get it Now, Continue,然后点 Create 以启动部署过程。

2.3.2. 在 Microsoft Azure 上置备 Red Hat Ansible Automation Platform

当您初始部署来自 Azure marketplace 的 Red Hat Ansible Automation Platform 时,会在 Create Red Hat Ansible Automation Platform on Microsoft Azure 窗口中显示一个表单。

在填写表单前,决定是否要在 Microsoft Azure 上创建 Ansible Automation Platform 的公共部署:

  • 公共部署允许通过公共互联网访问 Microsoft Azure 用户界面上的 Ansible Automation Platform。不需要配置来访问应用 URL。
  • 在隔离 Azure VNet 中创建私有部署,用于阻止从公共互联网访问。要访问 Microsoft Azure 用户界面上的 Ansible Automation Platform,您必须配置网络对等和路由。

在启动部署时,您可以在 Microsoft Azure VNet 上为 Ansible Automation Platform 创建网络配置。在部署受管应用程序前,请参阅网络配置计划。有关规划网络配置的详情,请参考网络配置

完成表单,将 Red Hat Ansible Automation Platform 基础架构和资源置备到 Azure 租户中。

  1. 在以下字段中输入部署的值:

    • Subscription: 选择 Ansible on Clouds
    • 资源组:创建或选择要部署受管应用程序的资源组。
    • 区域:要部署应用的 Azure 区域。
    • 应用名称:受管应用程序的唯一名称。
    • 管理员密码:为您的部署创建一个管理员密码。

      管理员密码必须至少包含 8 个字符,且必须包含大写字母、小写字母和数字。

    • 确认管理员密码 :确认管理员密码
    • 访问 :选择您的部署是否为公共部署还是私有。
    • 受管资源组 :受管应用程序基础架构的资源组。

      使此资源组与其他资源组隔离,包括您要在其上部署受管应用程序的资源组

  2. 将您输入的信息存储在安全的地方。您需要提供管理员密码来访问自动化控制器和私有自动化中心。
  3. Next
  4. 按照 Microsoft Azure VNet 上的 Red Hat Ansible Automation Platform 中的步骤来配置网络配置。
  5. Review + Create
  6. 如果您在表单中输入的信息有效,则窗口会显示 Validation Passed
  7. 选择 I agree 接受 Co-Admin Access Permissions 的条款。
  8. Create 开始应用程序的置备过程。

应用程序将开始调配。

可能需要 30 分钟或更长时间才能完成基础架构和软件进行全面配置。

完成置备后,您可以访问并登录到新的 Ansible Automation Platform 实例,并启动自动化控制器和自动化中心。

2.4. 访问 Microsoft Azure 上的 Red Hat Ansible Automation Platform

当您初始部署来自 Azure marketplace 的 Red Hat Ansible Automation Platform 时,会在 Create Red Hat Ansible Automation Platform on Microsoft Azure 窗口中显示一个表单。完成表单,将 Ansible Automation Platform 基础架构和资源置备到 Azure 租户中。

  1. 在 Web 浏览器中打开 Azure 控制台中的 Managed Applications
  2. 选择您部署的 Microsoft Azure 上的 Red Hat Ansible Automation Platform 实例。
  3. 在左侧导航菜单中的 Settings 部分中,选择 Parameters and Outputs
  4. 复制自动化控制器和自动化中心的 URL 链接,然后保存它们。链接的名称为 automationControllerUrlautomationHubUrl
  5. 在浏览器中,导航到自动化控制器 URL,然后使用以下凭证登录:

    • Username: admin
    • Password :使用部署 Ansible Automation Platform 应用程序时提供的 Administrator 密码

第一次在 Microsoft Azure 上登录 Ansible Automation Platform 时,您必须配置订阅并同意条款和条件。

2.4.1. 许可证关联

当您订阅了 Microsoft Azure 上的 Red Hat Ansible Automation Platform 时,红帽提供了一个特定的订阅授权清单。

当要求提交有关许可证的信息时,请选择您从 access.redhat.com 获取的许可证清单文件。

2.4.2. Azure Active Directory(Azure AD)SSO 配置

按照以下步骤,使用 Azure Active Directory(Azure AD)配置 SSO。如果您的机构没有使用 Azure AD 进行应用程序授权,您可以在 Ansible Automation Platform 中的用户管理系统中创建用户。

为 Ansible Automation Platform 部署配置基本 URL

  1. 在浏览器中,进入到 Automation controller URL,并使用以下凭证登录:

    • 用户名:admin
    • 密码:使用部署 Ansible Automation Platform 应用程序时提供的 Administrator 密码
  2. 在 Automation 控制器控制台中,点 Settings
  3. System 设置下的 Miscellaneous System settings
  4. Edit。在 service 字段的 Base URl 中输入 Automation controller URL。
  5. 点击 Save

为 Ansible Automation Platform 配置身份验证

要为 Microsoft Azure Active Directory(Azure AD)设置企业级身份验证,您必须通过在 Azure 中注册 Ansible Automation Platform 部署来获取 OAuth2 密钥和 secret。

要在 Azure 中注册自动化控制器实例,您必须从自动化控制器设置中提供 Azure AD OAuth2 Callback URL

获取 Azure AD OAuth2 回调 URL

  1. 在 Web 浏览器中,打开自动化控制器控制台。
  2. 点菜单中的 Settings,打开主设置页面。
  3. Authentication 类别中的 Azure AD 设置 打开 Details 页面。
  4. 复制 Azure AD OAuth2 Callback URL 的值。当您在 Azure AD 中注册部署的应用程序时,您将需要这个值。

在 Azure AD 中创建注册的应用程序

  1. 在网页浏览器中,打开 Azure 门户。
  2. 确保您在使用在其中部署 Ansible Automation Platform 的租户。
  3. 在搜索栏中输入 Azure Active Directory
  4. 从搜索结果中选择 Azure Active Directory
  5. 在菜单选项中,选择 ManageApp registrations
  6. App registrations 页面中,点 + New registration
  7. 配置新注册,如下所示:

    • Name 字段中输入您用于部署的应用程序的相同名称。
    • 支持的帐户类型选择默认值。
    • Redirect URI (可选) 选择 Web
    • Redirect URI (可选) 字段中,输入您从自动化控制器获取的 Azure AD OAuth2 Callback URL 值。
  8. Register 创建注册。

注册完成后,会显示 Automation Controller 应用程序的注册页面。

为通信生成 secret

  1. 在 Azure 上的 Automation controller 应用程序注册页中,复制并保存 应用程序(客户端)ID 的值。

    在 Ansible Automation Platform 设置中,您将将此值设置为 Azure AD OAuth2 密钥。

  2. 选择 ManageCertificates & secrets
  3. Client secrets,然后点 New client secret
  4. 为新 secret 提供描述。

    无法再自动更新证书或识别证书何时过期。

    在描述中包含日期很有用,例如:AAP Client Secret <Today’s Date in YYYY-MM-DD format>

  5. 为新 secret 提供过期日期。

    证书的最大生命周期为 2 年。除非您有特定的安全需求,否则需要防止创建长期证书,否则请选择 24 months 过期日期。

  6. secret 值保存到本地机器上的位置。离开此页面后,它将会被隐藏,不再可以被检索。

在 Ansible Automation Platform 设置中添加 secret

将您在 Azure 中生成的 secret 的键 (Application (client) ID) 和值 (Value) 添加到 Ansible Automation Platform 实例中。

  1. 在 web 浏览器中打开自动化控制器控制台。
  2. SettingsAzure AD settings
  3. Edit
  4. 输入您在 Azure AD 中生成的 secret 的信息:
  5. Azure AD OAuth2 密钥 中,粘贴 应用程序(客户端)ID
  6. Azure AD OAuth2 Secret 中,粘贴 secret Value
  7. 点击 Save

在自动化控制器中添加 Azure 凭证

  1. 在 Web 浏览器中打开自动化控制器。
  2. 选择 ResourcesCredentials 并点 Add 以打开 Create New Credentials 页面。
  3. 输入新凭证的名称,并为凭证类型选择 Azure Resource Manager
  4. 使用 Service Principal 详情填写表单的值:

    • 名称 :为凭证选择一个描述性名称,如 *Azure Infrastructure*
    • 订阅 ID:输入您在 Azure 中创建资源的订阅 id。这是您的租户的唯一 ID。您的机构可能有多个订阅 id;请咨询您的 Azure 管理员有关您应该使用的订阅 ID。
    • Client ID :输入来自 Service Principal 创建的 appId 值。
    • Client Secret:输入来自 Service Principal 创建的密码。
    • 租户 ID :输入来自 Service Principal 创建的租户。
  5. Save 保存凭证。

第 3 章 专用网络 peering

Microsoft Azure 上的 Ansible Automation Platform 部署到带有自己的 Azure 虚拟网络(VNet)的独立受管资源组中。

最初部署时,Microsoft Azure 上的 Ansible Automation Platform 只能通过公共互联网向外部网络发送请求。

要在 Microsoft Azure 上启用 Ansible Automation Platform,以访问互联网部署中的资源,当资源通过私有网络时,您必须在您的私有虚拟网络和 Microsoft Azure 的受管应用程序 VNet 上配置 Azure 网络。

您可以配置 Azure VNets 以启用多个 Azure VNets 之间的私有通信,以及 Azure VNets 和外部 VPN 路由网络之间的私有传输路由。这些 VPN 网络可以位于内部或者其它云中。

没有两个 Azure 网络配置是相同的。要在 Microsoft Azure 上启用对 Ansible Automation Platform 的用户访问,请将您的部署连接到 VNets 和外部 VPN 路由网络。

注意

配置网络对等功能需要由您所在机构中的对网络 peering 非常熟悉的 Azure 管理员进行。在您的 Azure 帐户中对网络配置进行改变可能会导致停机或其他中断。

红帽不支持在本文档中介绍的网络 peering 步骤,因为进程和服务由 Microsoft Azure 控制和管理。联系 Microsoft 以获得对等 Azure 网络方面的帮助。

我们会尽力使这里的内容与 Microsoft 文档保持一致,但随着时间的推移,可能还有一些不同。Microsoft 的文档是有关 Azure 网络主题的确定性来源。

Azure 提供各种对等专用网络的方法。它们通常分为两类:

  • Hub-and-spoke peering: 在这个拓扑中,有一个集中的 hub VNet 供其他虚拟网络使用。这个 hub 网络具有通过传输路由路由流量的机制。云网络,包括 VPN/Express Connect 与内部和其他云网络的连接,可以通过 hub VNet 进行通信。
  • Azure Virtual WAN(VWAN): Azure Virtual WAN 是一个网络服务,它在 Azure、内部部署和其他 VPN/Direct Connect 网络中提供简化的 hub 和spoke 网络。有关 VWAN 的更多信息,请参阅微软的 虚拟 WAN 文档
  • 直接对等(Direct peering) :专用网络分别连接到另一个网络,且它们之间没有路由跃点。这是一个简单的对等点模型:当您只想连接几个网络时,这很有用。

请参阅 Microsoft 应用程序架构基本指南中的在虚拟网络对等和 VPN 网关之间进行选择,以确定您的机构的正确对等方法。

3.1. hub-and-spoke peering(Transit 路由)

注意

错误地更新路由表可能会破坏您的网络。仅当您确信可以撤销任何意外的网络行为时,才执行这些步骤。

3.1.1. hub-and-spoke peering 过程概述

先决条件

  • 您已在 Microsoft Azure 上部署了 Ansible Automation Platform。
  • 您已在 Azure 租户中配置了并测试了 Azure VNet hub-and-spoke 实现。这个先决条件需要配置很多 Azure 资源,包括虚拟网络网关。
  • 您已在 spoke 网络间配置了传输路由,包括 VPN。具体步骤请参考在 Microsoft Azure 文档中为虚拟网络对等配置 VPN 网关传输
  • 您已找出以下内容:

    • 现有 VNet 的 CIDR 块(包括 VPN 和直接连接)需要访问 Microsoft Azure UI 上的 Ansible Automation Platform。
    • 现有 VNet 的 CIDR 块(包括 VPN 和直接连接),它包含 Ansible 自动化的主机或端点。
    • Microsoft Azure VNet 上的 Ansible Automation Platform 的 CIDR 块来自应用程序的受管资源组。具体步骤请参阅查找受管资源组的 CIDR 块

在对等任何网络前,请确保您的私有 VNet 和 Microsoft Azure 网络上的 Ansible Automation Platform 之间没有网络地址空间重叠。

流程

  1. 在 Microsoft Azure 受管应用程序 Kubernetes 集群上找到 Ansible Automation Platform 的 CIDR 块。请参阅查找受管应用程序 Kubernetes 集群的 CIDR 块
  2. 使用 Ansible Automation Platform 子网配置网络 Peering。请参阅使用 Ansible Automation Platform 子网配置网络对等
  3. 更新路由表:

    1. 配置现有网络的路由表,将流量发送到受管应用程序 CIDR。您必须将路由添加到请求 Ansible Automation Platform 用户界面的每个网络的路由表中,以及将对其资源执行自动化的每个网络。请参阅路由到 Microsoft Azure 上的 Ansible Automation Platform
    2. 针对您想与 Ansible Automation Platform 通信的每个 spoke 网络配置 VNet 的路由,以用于自动化或访问用户界面。请参阅到 VNets 的路由

3.1.1.1. 查找受管资源组的 CIDR 块

  1. 进入 Azure 门户中的 Resource Groups 页面。
  2. 在 Microsoft Azure 上点 Red Hat Ansible Automation Platform 的受管资源组。资源组名称前缀为 "-mrg"。
  3. 选择资源组中的 VNet 在 Overview 页面中查看其设置。

    集群的 CIDR 块显示在 Address Space 中。

如需更多信息,请参阅 Microsoft Azure 虚拟网络指南中的查看虚拟网络和设置

3.1.1.2. 使用 Ansible Automation Platform 子网配置网络对等(peer)

在 Azure 控制台中,Azure 虚拟网络(VNet)被称为 这个虚拟网络,而您想要与 对等的 VNet 称为 远程虚拟网络

在 Azure 门户的 Virtual Networks 页面中,使用以下设置来配置 Azure VNet 和您要与 Microsoft Azure 应用程序上的 Ansible Automation Platform 对等的 VNet:

  • 此虚拟网络 下,选择 Microsoft Azure 虚拟网络上的 Ansible Automation Platform 的设置:

    • Peering link name: <hub_to_aap_peering_link_name>
    • Traffic to remote virtual network: Allow
    • Traffic forwarded from remove virtual network: Allow
    • 虚拟网络网关或 Route 服务器使用此网络的网关或 Route 服务器
  • Remote virtual network 下,选择您要与 Azure 对等的虚拟网络的设置:

    • 对等链接名称: <aap_to_hub_peering_link_name>
    • 到远程虚拟网络的流量: Allow
    • 从远程虚拟网络转发的流量Allow
    • 虚拟网络网关或 Route 服务器使用远程虚拟网络的网关或 Route 服务器

有关配置 peering 的更多信息,请参阅 Microsoft Azure 虚拟 网络指南中的创建对等点

3.1.1.3. 更新路由表

在更新路由表前,请确定您满足 hub-and-spoke peering 进程 的先决条件

Microsoft Azure 上的 Ansible Automation Platform 路由

  1. 进入 Azure 门户中的 Route Tables
  2. 作为 hub-and-spoke 配置的一部分,您可以创建一个或多个路由表来定义网络间的路由。点其中一个路由表。
  3. 在路由表菜单栏中,进入到 RoutesAdd
  4. 在路由表菜单栏中,选择 RoutesAdd
  5. 配置现有网络的路由,以将流量发送到 Ansible Automation Platform。您必须为任何请求 Ansible Automation Platform 用户界面以及针对其资源执行自动化的网络配置路由。对于您添加的每个路由,请输入以下信息:

    • 路由名称 :输入 Ansible Automation Platform 受管应用程序网络的路由名称
    • 地址前缀: 受管应用程序 kubernetes 集群的 CIDR 块
    • Next Hop Type: 虚拟网络网关
  6. OK,将新路由保存到路由列表。

对于您要将流量路由到 Ansible Automation Platform 的所有其他路由表,请重复此步骤。

到 VNet 的路由

为每个 spoke 网络添加路由,以与 Ansible Automation Platform 通信、用于自动化或访问用户界面。

  1. 进入 Azure 门户中的 Route Tables
  2. 在路由表列表中,选择 Microsoft Azure 受管集群上的 Ansible Automation Platform 的路由表。

    Ansible Automation Platform 路由表的名称使用以下惯例:

    aks-agentpool-<numbers>-routetable
  3. 在路由表菜单栏中,进入到 RoutesAdd
  4. 针对您想与 Ansible Automation Platform 通信的每个 spoke 网络配置 VNet 的路由,以用于自动化或访问用户界面。
  5. 对于您添加的每个路由,请输入以下信息:

    • 路由名称:输入您希望 Ansible Automation Platform 路由的 spoke 网络的路由名称
    • 地址前缀: spoke 网络的 CIDR 块
    • Next Hop Type: 虚拟网络网关
  6. OK,将新路由保存到路由列表。

配置路由规则后,通过 hub 网络将流量路由到和从 Azure 上的 Ansible Automation Platform 路由。

通过虚拟设备出站路由

如果您的组织使用 Azure 防火墙服务或第三方防火墙设备,则必须从托管应用程序配置出站连接,以便红帽维护应用程序并针对外部资源启用自动化。

最简单的方法是创建一个防火墙规则,该规则允许来自端口 443 的出站流量。

如果选择不允许所有来自端口 443 的出站流量,您必须配置路由。

  • 对于红帽在 Microsoft Azure 上管理和升级 Ansible Automation Platform,必须允许 Azure Kubernetes 服务 (AKS) 集群中的所有机器都可以提交请求,以拉取 Ansible Automation Platform 使用的容器的更新。在 Ansible Automation Platform 路由表中为从 Microsoft Azure 受管应用程序上 Ansible Automation Platform 的完整 CIDR 范围内的出站流量添加路由到以下域:

    • registry.redhat.io
    • quay.io
  • 您还必须允许来自防火墙的流量到您希望 Ansible Automation Platform 对运行自动化作业的任何其他外部域或 IP 地址。否则,您的防火墙将阻止 Ansible Automation Platform 和自动化目的地之间的连接。
3.1.1.3.1. 其他资源

有关在 Azure 中向路由表添加路由的更多信息,请参阅 Microsoft Azure 虚拟网络指南中的创建路由

3.2. Azure Virtual WAN(VWAN)

3.2.1. 将 VWAN Hub 对等到 Microsoft Azure Network 上的 Ansible Automation Platform

在 peering 之前,您必须将 hub 网络以及至少一个 spoke 网络连接到 Azure VWAN 的 hub 网络,用于将 Ansible Automation Platform 连接到 Microsoft Azure 上的 Ansible Automation Platform。

先决条件

  • 预先配置的 Azure VWAN。
  • 以下一个或多个连接到 VWAN 的连接:

    • 包含 Azure 虚拟机的 DMZ 网络,用户可以远程登录到 Microsoft Azure 上的 Ansible Automation Platform。
    • 包含本地机器可以使用 SSH 隧道连接到的 Azure 虚拟机的 DMZ 网络,以访问 Microsoft Azure 上的 Ansible Automation Platform。
    • VPN 或 Direct Connect 服务将流量从本地机器路由到 Microsoft Azure 上的 Ansible Automation Platform。

流程

  1. 进入到您要与 Ansible Automation Platform 实例对等的 VWAN 的虚拟网络连接页面。
  2. 要在 VWAN hub 和 Ansible Automation Platform 实例之间创建连接,请使用以下设置:

    • 连接名称: <Ansible_Automation_Platform_connection_name>
    • Hubs :选择受管应用程序 VNet 的一个或多个 VWAN hub 网络。
    • 订阅:选择在 Microsoft Azure 上部署 Ansible Automation Platform 的订阅。
    • 资源组 :受管应用程序的受管资源组。它通常以"mrg-"作为前缀。
    • 虚拟网络:受管应用程序的 VNet。受管资源组中只有一个 VNet。
    • Propagate to none: No
    • Connection Route Table: 选择 default 路由表或您的机构为 VWAN 配置的适当路由表。
    • 传播到 Route Tables :选择一个或多个默认路由表,或者您的机构为 VWAN 配置的适当路由表。
    • 传播到标签:如果您的机构使用标签,则选择标签。
    • 静态路由:不要完成此字段。

当网络 peering 完成后,使用 VWAN hub 网络,到 Microsoft Azure 上的 Ansible Automation Platform 的流量路由。

其他资源

3.3. Direct peering(直接对等)

您可以使用直接 peering 来直接连接虚拟网络。当两个网络对等时,Azure 会更新它们间的路由,以便流量在它们间自动流。

直接对等方法比 hub 和spoke 模型更容易配置。但是,直接网络 peering 的数量会被限制。随着虚拟网络数量的增加,直接对等变得难以管理,因为每个新网络都需要与所有其他网络对等。

3.3.1. 配置直接网络 peering

您可以在 Azure 门户的虚拟网络页面中配置 Azure 网络和 VNet 间的网络对等点。

在 Azure 控制台中,Azure 虚拟网络被称为 这个虚拟网络,而您想要与其对等的 VNet 称为远程虚拟网络

在 Azure 门户的虚拟网络页面中,使用以下设置来配置 Azure 网络,以及您要与 Microsoft Azure 应用程序上的 Ansible Automation Platform 对等的 VNet:

  • 此虚拟网络 下,选择 Microsoft Azure 虚拟网络上的 Ansible Automation Platform 的设置:

    • Peering link name: <hub_to_aap_peering_link_name>
    • 到远程虚拟网络的流量Allow
    • 从远程虚拟网络转发的流量Allow
    • 虚拟网络网关或 Route 服务器使用此网络的网关或 Route 服务器
  • Remote virtual network 下,选择您要与 Azure 对等的虚拟网络的设置:

    • 对等链接名称: <aap_to_hub_peering_link_name>
    • 订阅:选择在 Microsoft Azure 上部署 Ansible Automation Platform 的订阅
    • 虚拟网络:在 Microsoft Azure 虚拟网络上选择 Ansible Automation Platform: vnet-<aap_identifier>-<region>
    • 到远程虚拟网络的流量: Allow
    • 从远程虚拟网络转发的流量Allow
    • 虚拟网络网关或 Route 服务器使用远程虚拟网络的网关或 Route 服务器

配置了直接网络 peering 后,在 Microsoft Azure 上的 Ansible Automation Platform 和 Vnet 上的私有主机和 IP 间的流量路由。

有关配置 peering 的详细信息,请参阅 Microsoft Azure 虚拟网络指南中的创建对等

有关直接对等点的更多信息,请参阅 Microsoft Azure 虚拟网络指南中的虚拟网络 peering

第 4 章 连接到 Red Hat Ansible Automation Platform

当网络 peering 完成并且已建立 Azure 路由配置后,您可以选择您的团队如何通过 Azure 网络配置访问 Ansible Automation Platform。

4.1. 访问详情

无论 Ansible Automation Platform 是否使用公共或私有访问部署,都创建了一组 DNS 记录。创建 DNS 记录,以便 Ansible Automation Platform 可以为您的部署发布有效的 TLS 证书,并可轻松访问应用程序。

要查看 Ansible Automation Platform 应用程序的 URL 列表,进入到部署的 Azure Marketplace 受管应用程序列表的参数和输出页面。

4.2. 公共部署

如果在 Microsoft Azure 上部署的 Ansible Automation Platform 时选择了公共访问权限,您可以从浏览器通过公共互联网访问 Ansible Automation Platform 应用程序 URL。

4.3. 私有部署

如果在 Microsoft Azure 上部署 Ansible Automation Platform 时选择了私有访问权限,则向 Microsoft Azure 应用的 Red Hat Ansible Automation Platform 发出的 DNS 记录指向部署受管集群时选择的 CIDR 块中的私有地址。您必须在创建网络 peering 后配置对此地址的访问。

选择连接到 Microsoft Azure 上的 Ansible Automation Platform 的配置和访问方法取决于您的组织如何管理 Azure 基础架构。您的 Azure 管理员必须决定您所在机构的正确模型,并为您配置设置。

以下是最常见的选项:

4.3.1. Azure 托管的虚拟机

为少数用户访问 Azure 网络上的私有网络资源(DMZ VNet)配置访问权限是,用户可以从公共互联网远程登录到公共互联网上创建一个跳过虚拟机。jumpbox 虚拟机需要 GUI 和浏览器等 workstation 功能。

用户可以通过 VNC、RDP 或其他屏幕共享协议从内部机器远程登录公开访问的虚拟机。

要在 Azure 专用网络上访问 Ansible Automation Platform Web UI,用户可使用 jumpbox 虚拟机上的浏览器导航到 URL。

DMZ VNet 通过网络 peering 连接到其他 Azure VNets,并创建了路由规则,将网络流量发送到 Ansible Automation Platform VNet。

下图显示了通过 Azure 虚拟机配置私有网络访问示例的拓扑。

azure private nw access vm 上的 aap

4.3.2. VPN

如果您的组织要求许多用户通过专用连接访问 Ansible Automation Platform,或者如果您的组织已使用 VPN 或与 Azure 直接连接,则这个方法可能适合。

在这种配置中,您的内部基础架构通过网络应用程序网关连接到 Azure,并且具有可启用对本地网络上任何连接计算机的访问权限的路由规则。连接到虚拟网络网关的 VNet 通过网络 peering 连接到其他 Azure VNets,并创建了路由规则,将网络流量发送到 Ansible Automation Platform VNet。

使用这个配置,用户可以通过应用程序 URL 访问 Ansible Automation Platform,就像使用公共访问方法一样。

azure private nw access vpn 上的 aap

4.3.3. SSH 隧道

当 VPN 不是一个选项且您的本地用户更为技术时,SSH 隧道方法是一个安全的替代方案,允许用户从本地机器上浏览器访问 Ansible Automation Platform。

要实现此访问模型,请在 DMZ 网络中创建一个基于 Linux 的轻量级 SSH 服务器,类似于 Azure 托管的虚拟机方法。SSH 服务器不需要任何工作站功能,因为它只是作为 Microsoft Azure 上用户本地机器和 Ansible Automation Platform 之间的代理。

每一用户必须在服务器中配置为 SSH 用户。然后,用户可以从本地机器建立 SSH 隧道到 SSH 服务器,以路由 Microsoft Azure 上的 Ansible Automation Platform 的流量。

这种方法更易于在 Linux 和 macOS 主机中实施,但可以在 Windows 上完成。

  1. 更新本地主机文件,以便 Ansible Automation Platform URL 将流量路由到您的本地机器,而不是 DNS 记录配置的专用 IP。在您的主机文件中添加以下行:

    127.0.0.1 controller.<your_AAPonAzure_instance>.az.ansiblecloud.com

    以下示例显示了主机文件中的行:

    ##
    # Host Database
    #
    # localhost is used to configure the loopback interface
    # when the system is booting. Do not change this entry.
    #
    127.0.0.1       localhost
    255.255.255.255 broadcasthost
    ::1             localhost
    
    127.0.0.1 controller.<your_AAPonAzure_instance>.az.ansiblecloud.com
  2. 以具有 root 特权的用户身份,运行 ssh 命令建立 SSH 隧道。

    在以下示例中,SSH_server_IP 代表 DMZ 中的 SSH 服务器的 IP 地址。

    sudo ssh azureuser@<SSH_server_IP> -i ~/.ssh/id_ssh_key -N -f -L 443:controller.<your_AAPonAzure_instance>.az.ansiblecloud.com:443

    -L 标志使自动化控制器 URL 的本地系统路由流量通过端口 443(HTTPs)进行。

    注意

    您必须在路由路径两端使用端口 443。在本地机器上使用不同的端口会导致一些 Ansible Automation Platform 功能无法正常工作。

当建立 SSH 隧道并配置了 Azure 路由时,您可以从本地浏览器中通过 https://controller.<your_AAPonAzure_instance>.az.ansiblecloud.com 访问自动化控制器 URL。

azure private nw access ssh 上的 aap

 

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.