你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure 上的 Red Hat Enterprise Linux 的平台自动化注意事项

本文介绍如何在 Azure 上管理 Red Hat Enterprise Linux(RHEL)的自动化。 本文介绍 Azure 生态系统中各种工具的设计注意事项、设计建议和选项,这些工具可用于实现一致的稳定环境。 本文提供了与各种客户方案、业务要求、运营实践和技术成熟度相符的指导。

概述

为 Azure 登陆区域自动执行 RHEL 时,可以使用 Red Hat 基础结构标准(RH-IS)和关联的 Red Hat 基础结构标准采用模型(RH-ISAM)来协调 Azure 登陆区域生命周期管理。 标准化系统,为解决方案提供可靠的基础。 RH-IS 定义标准操作环境,其中包括默认的软件组件和配置集。 可以通过 RH-ISAM、一组 DevOps 或 Git 操作原则、Azure 资源管理器模板(ARM 模板)、Terraform、Azure CLI 和 Azure PowerShell 将这些组件和配置应用于系统。

可以自动执行各种操作。 例如,可以使用自动化来:

  • 预配组件。
  • 管理系统。
  • 执行平台演变。
  • 合并基础结构操作。
  • 配置应用程序和工作负荷生命周期。

可以通过基础结构即代码(IaC)和配置即代码来实现这些操作。 若要减少错误并提高可靠性,请定义和测试配置。 若要加快大规模迁移速度,请自动进行预配。 自动配置可减少配置偏差,并确保系统正常运行。

设计注意事项

Red Hat 标识管理(IdM)提供了一个集中统一的平台,可用于管理 RHEL 系统的标识存储、身份验证策略和授权策略。 在混合方案中,可以跨虚拟专用网络或 Azure ExpressRoute 扩展现有的 Red Hat IdM 基础结构。 此配置将本地环境与 Azure 中的 RHEL 登陆区域连接。 若要支持混合云标识方案,请将本地环境扩展到 Azure,以便可以将工作负荷与 Microsoft Entra 集成。 有关详细信息,请参阅 Microsoft Entra 身份验证

作为替代标识管理解决方案,你可以加入 RHEL 以使用 Windows Server Active Directory 创建外部信任,或直接加入现有 Windows Server Active Directory 林。 有关详细信息,请参阅 直接将 RHEL 系统与 Windows Server Active Directory 集成。

Red Hat Satellite 是传送到托管 RHEL 系统的单个内容来源。 卫星包括 Red Hat 包和修补程序,以及应用程序开发团队开发的非Microsoft包和自定义包。 卫星充当 Red Hat Insights 的网关,它提供对配置进行预测分析,以识别安全或性能风险。 如果部署预配置的 RHEL 即用即付映像,则可以利用 适用于 Azure 的 Red Hat 更新基础结构,这是内置于即用即付映像中的更新工具。

Red Hat Ansible 自动化平台设计注意事项

Red Hat Ansible 自动化平台(AAP)有助于标准化技术工作流和定期任务。 可以使用 AAP 来协调工作流、为新系统预配流程以及创建定期操作任务。 若要降低复杂性,请使用一种常见的自动化平台和语言。 完全自动化工作流可加速应用程序创新,并简化跨本地环境和云环境的大规模工作负荷迁移。

RHEL 作为平台自动化策略的优势包括:

  • 新系统具有大规模完全自动化的预配,从而提高大规模迁移速度。

  • 提高了跨物理系统和虚拟系统测试系统的配置和应用程序安装的统一性。

  • 持续更新,因为修补程序管理立即可用。

  • 一个标准化和简化的平台,用于交付新的应用程序和工作负载。 员工有额外的时间来增加创新。

可以实现:

  • 通过本地基础结构、云基础结构或两者兼有的自管理 AAP 实例。 可以使用 RHEL 部署或 Red Hat OpenShift 容器平台部署。

  • 公有云中的自托管 AAP 实例。

  • 公有云中的托管 AAP 实例。

本地或云中的自托管 Red Hat AAP

在本地、云或混合基础结构中,在 Microsoft Azure 上部署 Red Hat AAP,以获得以下优势:

  • 体系结构和规模:确定支持自动化平台的理想体系结构。 可以在 RHEL 基础结构或 OpenShift 操作员部署的基础上构建体系结构。 根据机群大小和要求,选择控制器、执行节点和专用自动化中心实例的数量和实例大小调整。 有关体系结构、设计、配置和缩放的详细信息,请参阅 Red Hat AAP 规划指南

  • Azure 配置:为组织的 Azure 设计和配置优化自动化体系结构。

  • 自动化网格支持:使用 AAP 自动化网格功能跨混合云节点分配自动化工作负载,这些节点使用现有网络建立对等连接。 根据安全设计条件和网络拓扑将跃点节点放置在某个位置。

  • 自动化中心体系结构:优化自动化中心体系结构,以便缩放和放置专用自动化中心实例。 优化配置,增强安全自动化内容交付和对接近自动化执行资源的执行环境源的访问。 可以选择自动化使用者可以访问哪些 Ansible 内容集合和版本。

Azure 上的托管或自管理 Red Hat AAP

Microsoft Azure 上的 Red Hat AAP 可通过托管应用程序或自管理应用程序获得,这具有以下优势:

  • 由于易于使用,快速投资回报(ROI):可以直接从 Azure 市场 在 Azure 上部署 AAP。 此托管解决方案在部署后立即处于活动状态,可以在几分钟内开始自动管理 Azure 资源。 Red Hat 管理基础结构,因此你可以自由考虑对企业至关重要的其他系统。

  • 简化集成:Azure 上的 AAP 与 Azure 服务集成。 Microsoft以及 Red Hat 开发和安全性测试了适用于 Azure 的 Ansible 集合,因此需要最少的设置,并获得最大支持。 使用 Azure 上的 AAP 作为混合云自动化策略的一部分,以统一混合云、物联网和边缘部署的管理和自动化。

  • 现有已提交的 Azure 支出:可以将现有承诺支出与Microsoft一起使用,在 Azure 上购买 Red Hat AAP。 使用已提交的支出,以便整个组织中的团队可以无缝部署、配置和自动化组件。 集成计费意味着可以获得一个帐单并全面了解成本。

  • 云之外的自动化:在 Azure 上使用 AAP,可以在 Microsoft azure 云中部署应用程序,然后在基础结构中扩展应用程序。 跨 Azure 和混合云环境部署、运行和缩放应用程序。

  • 支持:Red Hat 和Microsoft合作伙伴在 Azure 上构建 AAP,以确保以安全为中心的一致操作。 Red Hat 管理、服务和支持应用程序,使 IT 团队能够专注于实现自动化策略。

托管模式的其他注意事项

可以在 Azure 上以托管模式安装 AAP,使之成为托管应用程序。 Red Hat 既管理基础 Azure 资源,又管理其上运行的软件。 该基础结构在 Azure 租户中运行。

托管应用程序资源组独立于租户中的其他资源组。 Red Hat 仅有权访问托管应用程序资源组,且无法查看其他租户资源。

有关详细信息,请参阅 Azure 托管应用程序概述

托管模式下的 Azure 上的 AAP 使用以下资源组:

  • 租户中的新资源组或现有资源组。 此资源组包含引用 Azure 托管应用程序部署上的 AAP 的单个资源。 Red Hat 有权访问托管应用来执行支持、维护和升级。 但 Red Hat 不管理资源组。

  • 多租户托管资源组(MRG), 其中包含在 Azure 上运行 AAP 所需的大部分基础结构。 Red Hat 租户和租户共享此多租户资源组。 Red Hat 具有完全的管理控制。 对资源组具有只读访问权限。

  • Azure Kubernetes 服务(AKS)节点池资源组(NPRG)。 Microsoft需要 AKS 部署的 NPRG。 NPRG 包含 AKS 用来运行的资源。 此资源组是在部署时创建的。 Red Hat 不管理此资源组。 有关详细信息,请参阅 Microsoft AKS 文档

对于托管模式下的 Azure 上的 AAP,还考虑以下因素:

  • 在 Azure 上安装 AAP 时,可以选择部署是公共部署还是专用部署,这会影响用户如何访问 AAP 用户界面。

  • 无论选择的是公共部署还是专用部署,都必须配置网络对等互连,以便从 AAP 到包含要自动执行的资源的专用网络进行出站对等互连。 可以将网络对等互连从 Azure 上的 AAP 配置到专用 Azure 虚拟网络和本地网络或使用 Azure 传输路由的多云网络。

自管理模式的其他注意事项

在自管理模式下的 Azure 上的 AAP 提供了许多与托管 AAP 相同的优势。 但是,在 AKS 群集中运行托管模式时,自管理模式自动化平台资源基于虚拟机(VM)。

对于在自管理模式下的 Azure 上的 AAP,请考虑以下因素:

  • 事件驱动 Ansible 包含在 Azure 上的自管理产品/服务中。 事件驱动的自动化可帮助你减少手动任务,并提供专注于创新的高效 IT 环境。 事件驱动 Ansible 处理事件,确定相应的响应,然后运行自动操作来修正事件。

  • 订阅以 100 个活动托管节点增量提供。 它们可在公共套餐或专用产品/服务中使用。

  • 在自管理模式下支撑 Azure 上的 AAP 的 VM 资源可以完全由Azure 市场映像或Azure 市场映像和客户管理的映像混合组成。

设计建议

为 Azure 登陆区域运行 RHEL 平台时,请使用 Red Hat 认证的内容和从 Red Hat 自动化中心验证的内容集合。 以下集合在自动化框架中具有突出角色:

  • redhat.rhel_idm

    • 配置 IdM 主 VM。
    • 配置 IdM 副本。
    • 将 RHEL 客户端与 IdM 集成和配置。
  • redhat.satelliteredhat.satellite_operationsredhat.rhel_system_roles

    • 部署卫星和胶囊。
    • 创建和配置 Satellite 对象和设置。
    • 预配和配置 RHEL 系统。
  • ansible.*ansible.controllerinfra.controller_configuration

    • 配置 AAP。
    • 创建和配置 AAP 作业模板和设置。

适用于 Azure 的 Ansible 集合包括 250 多个模块,可用于审讯、管理和自动化 Azure 资源类型,例如:

  • AKS。
  • 应用程序安全组。
  • Azure 容器注册表。
  • Azure 数据库服务。
  • Azure Key Vault。
  • Azure SQL 数据库。
  • Azure 虚拟机。
  • Microsoft Entra ID。
  • 网络。
  • 存储。

核心平台基础结构部署

建立概念和流程,以有效地部署核心平台基础结构并支持 Azure 登陆区域模型中的 RHEL 平台。

有关详细信息,请参阅:

  • 适用于平台自动化注意事项的 Azure 登陆区域设计指南。

  • 开发生命周期。 了解有关使用自动化创建登陆区域的关键设计注意事项和建议。 本指南讨论存储库、分支、自动化生成、部署和回滚策略。

  • IaC. 了解通过 IaC 实现 Azure 登陆区域的好处。 了解与代码结构、工具和技术相关的注意事项。

  • 环境。 了解如何使用多个环境以更高的速度和频率生成、测试和发布代码。 此方法使部署尽可能简单。

  • 体验驱动开发。 了解如何使用单元测试来提高新功能的质量,并改进 Azure 登陆区域代码库。

如果已准备好必要的源代码管理工具以及从前面部分建立的源代码管理过程,则可以实现自动化。 开发包含 IaC 或配置作为代码的 Ansible 自动化代码,以部署核心基础结构并支持用于 Azure 登陆区域模型的 RHEL 平台。 对于绿地部署,可以自动执行以下任务,以实现完整的环境实现。 对于棕色地带部署,只能自动执行用例所需的任务。

  • 创建 Azure 资源组。
  • 创建虚拟网络。
  • 创建子网。
  • 创建网络安全组。
  • 通过自动化 Red Hat 映像生成器为 Azure 创建 RHEL 8.x 和 9.x 黄金映像。
  • 创建 IdM 主 VM(预附属预配)。 通过配置作为代码配置 IdM 主 VM。
  • 创建附属 VM(预附属预配)。 通过配置将 Satellite 配置为代码。
  • 创建胶囊 VM(附属预配)。 通过配置将 Capsule 配置为代码。
  • 创建 IdM 副本 VM(附属预配)。 通过配置作为代码配置 IdM 副本。
  • 创建 AAP 基础结构(卫星预配),包括:
    • 自动化控制器 VM。
    • 执行节点 VM。
    • 跃点节点 VM(可选)。
    • 自动化中心 VM。
    • 事件驱动的 Ansible VM(如果已启用)。
    • Azure Database for PostgreSQL 服务器和控制器、中心和事件驱动 Ansible 组件所需的数据库。 高可用性或灾难恢复 Azure Database for PostgreSQL 配置需要通过复制传送、日志传送或 Crunchy Postgres 进行额外的自动化。
  • 创建负载均衡器(应用程序网关)。
    • 适用于 Capsule VM 的前端
    • AAP 控制器 VM 的前端
    • 自动化中心 VM 的前端
  • 创建应用程序安全组。
    • IdM 基础结构
    • AAP 基础结构
    • 卫星或胶囊基础结构

RHEL 系统生命周期管理

完成核心平台基础结构后,可以为 RHEL 应用程序和工作负荷生命周期实现自动化。 以下工作流介绍了开发生命周期管道的示例自动化实现:

  1. 更新 errata 筛选器结束日期,并在 Satellite 中发布内容。

  2. 将内容视图(CV)和复合内容视图(CCV)提升到开发。

  3. 从附属主机组部署 RHEL 开发测试系统。 通过自动化 Red Hat 映像生成器为 Azure 的 RHEL 8.x 和 9.x 黄金映像定义为卫星中的 Azure 计算资源。

  4. 根据应用程序通信路径更新或创建 Azure 网络安全组。

  5. 更新或创建 Azure 应用程序安全组,为多层应用程序堆栈提供额外的分层安全性。

  6. 更新 RHEL 开发系统,并从卫星开发 CV 或 CCV 部署和配置所需的应用程序。

    • 部署到简单应用程序堆栈的单个 RHEL 实例。
    • 部署到多层应用程序堆栈的多个 RHEL 实例。
    • 配置应用程序堆栈。
  7. 运行应用程序测试框架。

    • 如果测试失败,请通知 OnCall 自动化管理以帮助进行故障排除和分析。 退出自动化工作流。 RHEL 测试系统仍部署用于事后故障分析。
    • 如果测试成功,请继续执行这些步骤。
  8. 将 CSV 和 CCV 提升到质量保证(QA)。

  9. 销毁 RHEL 开发测试系统。

生命周期管道中的后续阶段与开发生命周期阶段略有不同。 只有开发阶段才使用初始内容发布和初始 CV 和 CCV 提升进行开发。 以下示例介绍非开发生命周期管道的自动化工作流,例如 QA、预生产管道和生产管道。

  1. 从附属主机组部署 RHEL QA 测试系统。 通过自动化 Red Hat 映像生成器为 Azure 的 RHEL 8.x 和 9.x 黄金映像定义为卫星中的 Azure 计算资源。

  2. 根据应用程序通信路径更新或创建 Azure 网络安全组。

  3. 更新或创建 Azure 应用程序安全组,为多层应用程序堆栈提供额外的分层安全性。

  4. 更新 RHEL QA 系统,并在卫星 QA 中从 CV 或 CCV 部署和配置所需的应用程序。

    • 部署到简单应用程序堆栈的单个 RHEL 实例。
    • 部署到多层应用程序堆栈的多个 RHEL 实例。
    • 配置应用程序堆栈。
  5. 运行应用程序测试框架。

    • 如果测试失败,请通知 OnCall 自动化管理以帮助进行故障排除和分析。 退出自动化工作流。 RHEL 测试系统仍部署用于事后故障分析。
    • 如果测试成功,请继续执行这些步骤。
  6. 将 CV 和 CCV 提升到生产环境。

  7. 销毁 RHEL QA 测试系统。

Azure 本机工具的其他设计注意事项

Azure 自动化

若要自动执行频繁、耗时且容易出错的管理任务,可以使用Azure 自动化中的流程自动化功能。 此功能可帮助你专注于增加业务价值的工作。 流程自动化可减少错误并提高效率,这有助于降低运营成本。 有关详细信息,请参阅 自动化概述

流程自动化支持 Azure 服务和其他合作伙伴系统的集成,例如 Red Hat,你需要部署、配置和管理端到端进程。 还可以使用此功能创作图形 PowerShell 和 Python Runbook

可以将 Runbook 用于各种自动化任务,例如管理资源、启动和停止 VM,以及处理 Azure 内外的维护任务。 有关详细信息,请参阅 Azure 自动化 Azure 自动化 中的帐户身份验证概述和 Runbook。

下表描述了支持的 Runbook 类型。

Runbook 类型 说明
PowerShell 基于 Windows PowerShell 脚本的文本 Runbook。 支持的版本是 PowerShell 7.2(GA)和 PowerShell 5.1(GA)。 PowerShell 父产品不再支持 PowerShell 7.1。 建议在长期支持的 PowerShell 7.2 版本中创建 Runbook。
PowerShell 工作流 基于 Windows PowerShell 工作流脚本的文本 Runbook。
Python 基于 Python 脚本的文本 Runbook。 支持的版本是 Python 3.8(GA)和 Python 3.10(预览版)。 Python 父产品不再支持 Python 2.7。 建议在长期支持的版本中创建 Runbook。
图形 基于 Windows PowerShell 的图形 Runbook,并在Azure 门户的图形编辑器中完全创建和编辑。
图形 PowerShell 工作流 基于 Windows PowerShell 工作流的图形 Runbook,并在Azure 门户的图形编辑器中完全创建和编辑。

使用 Webhook 来满足请求,并通过 Azure 逻辑应用、Azure Functions、IT 服务管理服务、DevOps 或监视系统触发自动化来确保持续交付和运营。

Azure Arc 在云计算方面具有显著的进步,并提供了一个统一的管理平台,可将 Azure 功能扩展到本地、多云和边缘环境。 Azure Arc 通过 VM 扩展框架与 Azure 自动化 服务集成,以部署混合 Runbook 辅助角色,并简化更新管理、更改跟踪和清单功能的加入。

显示 Azure Arc 生态系统的关系图。

有关详细信息,请参阅 将现有 Linux 服务器连接到 Azure Arc

ARM 模板

通过 ARM 模板的 IaC 提供了一致的声明性方法来部署和管理 Azure 资源。 使用 ARM 模板以 JSON 格式定义应用程序所需的基础结构。 ARM 模板是幂等的,这意味着你可以多次部署同一模板,并在同一状态下获取相同的资源类型。

有关详细信息,请参阅 ARM 模板文档

JSON 示例

{ 

  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", 
  "contentVersion": "1.0.0.0", 
  "parameters": { 
    "location": { 
      "type": "string", 
      "defaultValue": "[resourceGroup().location]" 
    }, 
    "storageAccountName": { 
      "type": "string", 
      "defaultValue": "[format('toylaunch{0}', uniqueString(resourceGroup().id))]" 
    } 
  }, 
  "resources": [ 
    { 
      "type": "Microsoft.Storage/storageAccounts", 
      "apiVersion": "2021-06-01", 
      "name": "[parameters('storageAccountName')]", 
      "location": "[parameters('location')]", 
      "sku": { 
        "name": "Standard_LRS" 
      }, 
      "kind": "StorageV2", 
      "properties": { 
        "accessTier": "Hot" 
      } 
    } 
  ] 
}  

可以使用 Bicep 特定于域的语言来降低 JSON 语法的复杂性,并最大程度地减少不熟悉 Azure 的人员的学习曲线。 与使用 JSON 的 ARM 模板相比,Bicep 是一种透明抽象,Bicep 保留了 JSON 模板功能。 在部署期间,Bicep 命令行接口将 Bicep 文件转换为使用 JSON 的 ARM 模板。

本节中的示例显示了 Bicep 文件和等效 JSON 模板之间的差异。 这两个示例都部署了一个存储帐户。

Bicep 示例

param location string = resourceGroup().location 
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}' 
 

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = { 
  name: storageAccountName 
  location: location 
  sku: { 
    name: 'Standard_LRS' 
  } 
  kind: 'StorageV2' 
  properties: { 
    accessTier: 'Hot' 
  } 
} 

Azure DevOps

Azure DevOps 是一套全面的开发工具,可为云和本地环境提供项目管理、持续集成和持续交付(CI/CD)服务和源代码存储库。 可以将这些功能与 Azure 测试计划、Azure Artifacts、逻辑应用和 Azure Functions 相结合,以便无缝协作、开发和交付新式软件项目。

Azure Boards

Azure Boards 支持用于云软件开发和项目管理的敏捷方法。 有关详细信息,请参阅 Azure Boards 文档配置和自定义 Azure Boards

若要充分利用 Azure Boards,请了解团队如何使用其工具和功能,例如 Scrum、Kanban 和 Scrumban,以及他们对配置和自定义的依赖项。

下表汇总了在构建项目时应考虑的主要项。

项目级别 团队级别
要定义的团队数 如何使用产品积压工作来规划和确定工作的优先级
如何构建区域路径以支持项目组合管理视图 无论是跟踪 bug 作为要求,还是将 bug 作为任务跟踪,还是根本不使用 bug
字段自定义 是否使用任务来跟踪时间和产能
自定义工作项类型 如何使用项目组合积压工作级别
组合积压工作自定义项 如何使用项目组合积压工作级别
工作流自定义 如何通知高层管理进度、状态和风险

Azure Pipelines

Azure Pipelines 提供了一种快速、简单且安全的方法来自动执行项目生成,并提供随时可用的一致和质量代码。

Azure Pipelines:

  • 适用于任何语言或平台。
  • 同时部署到不同类型的目标。
  • 与 Azure 部署集成。
  • 在 Windows、Linux 或 Mac 计算机上生成。
  • 与 GitHub 集成。
  • 适用于开源项目。

有关详细信息,请参阅 Azure Pipelines 文档

根据组织需求,可以选择 Azure Pipelines 的四种核心体系结构之一:

Azure Repos

Azure Repos 提供两种类型的版本控制、Git 版本控制和集中式版本控制

若要访问代码,请将开发环境连接到 Azure Repos。 通过:

有关详细信息,请参阅 Azure Repos Git 文档Team Foundation 版本控制文档

使用发布管道和 Azure Artifacts 源

开发人员可以使用 Azure Artifacts 从源和公共注册表(如 PyPI、Maven Central 和 NuGet.org)发布和使用各种类型的包。可以将 Azure Artifacts 与 Azure Pipelines 配合使用,以发布生成和管道项目、部署包或跨管道的各个阶段集成文件,以生成、测试或部署应用程序。

有关详细信息,请参阅:

将 Azure Policy 与 Azure DevOps 集成

Azure Policy 直接应用于 Azure 环境中的资源,但其原则和治理可以间接影响 Azure DevOps 实践。 例如,Azure Policy 可能会影响:

  • CI/CD 管道中的符合性:可以将合规性检查集成到管道中。 例如,确保通过 Azure DevOps 部署的任何基础结构都符合在 Azure Policy 中定义的策略。

  • 环境一致性:使用 Azure Policy 强制实施特定配置或资源类型,以确保通过 Azure DevOps 部署到的环境一致且合规。

  • 安全和治理:策略可以对 Azure DevOps Projects 管理的资源强制实施安全标准和治理做法。 此法规确保开发生命周期包括符合组织和法规标准。

若要有效地将 Azure Policy 与 Azure DevOps 集成,可以使用 Azure Policy 合规性数据和审核功能来通知 DevOps 实践。 调整管道或 IaC 定义,使其与通过 Azure Policy 强制执行的组织策略保持一致。

此集成可确保通过 Azure DevOps 部署和管理的资源始终符合公司的治理标准。 使用此方法可跨 Azure 环境增强安全性、一致性和成本管理。

后续步骤