你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
规划 Azure Red Hat OpenShift 的平台自动化和 DevOps
获取 Azure Red Hat OpenShift 登陆区域加速器的平台自动化和 DevOps 的设计注意事项和建议。 依靠自动化和常规 DevOps 最佳做法来规划 Azure Red Hat OpenShift 的高度自动化 DevOps 平台。
设计注意事项
为 Azure Red Hat OpenShift 登陆区域加速器规划平台自动化和 DevOps 时，请考虑以下设计注意事项：
选择工程和自动化方法时， 请考虑 Azure 服务限制 以及持续集成和持续交付（CI/CD）环境。 有关示例，请参阅 GitHub 使用限制。
在保护对开发、测试、Q&A 和生产环境的访问权限时，请从 CI/CD 的角度评估安全选项。 部署是自动进行的，因此请相应地映射访问控制。
请考虑使用遵循定义完善的约定的前缀和后缀来唯一标识每个已部署的资源。 命名约定可避免在部署相邻解决方案时发生冲突，它们有助于提高整体团队敏捷性和吞吐量。
清点工作流，以帮助你在正常和数字 Rebar 预配方案中设计、更新和部署解决方案。 若要最大程度地提高熟悉性和工作效率，请考虑将管道映射到工作流。
示例包括：
- 群集部署和升级
- 应用程序部署和升级
- 灾难恢复故障转移
- 蓝绿部署
- Canary 环境维护
考虑部署 已启用 Azure Arc 的 Open Service Mesh ，以向工作负荷添加更多安全性、加密和日志功能。
请考虑部署其他资源，例如订阅、标记和标签，以支持 DevOps 体验。 使用这些资源跟踪和跟踪部署和相关项目。
考虑牛与宠物 DevOps 范式转变的效果。 预期 Pod 和 Kubernetes 的其他方面是暂时的，并相应地调整自动化和管道基础结构。 不要指望 IP 地址或其他资源是固定的或永久的。
设计建议
使用这些设计建议规划 Azure RedHat OpenShift 的平台自动化和 DevOps：
使用管道或操作执行以下操作：
- 在整个团队中最大程度地落实已应用的做法。
- 消除新发展的重担。
- 提供整体质量和敏捷性的可预测性和见解。
通过使用基于触发器的管道和计划的管道，尽早且经常进行部署。 基于触发器的管道可确保更改经过适当的验证。 计划管道管理更改环境中的行为。
将基础结构部署与应用程序部署分开。 与应用程序相比，核心基础结构的更改频率更低。 将每种部署类型视为单独的工作流和管道。
使用 云原生 选项进行部署。 使用 基础结构即代码 部署基础结构。 使用 Kubernetes 中的 Helm 和操作员模式部署和维护 Kubernetes 本机组件。
使用 GitOps 来部署和维护应用程序。 GitOps 使用 Git 存储库作为单一事实来源。 可以在回滚和相关过程中避免配置偏移并提高工作效率和可靠性。
另请考虑使用 Red Hat OpenShift GitOps。 Red Hat OpenShift GitOps 使用 Argo CD 来维护群集资源并支持应用程序 CI/CD。
使用用于机密存储 CSI 驱动程序的 Azure 密钥库 提供程序来保护机密、证书和连接字符串。
通过避免硬编码的配置项和设置，最大程度地提高部署并发性。
依赖于跨基础结构部署和应用程序相关部署的已知约定。 将允许控制器与已启用 Azure Arc 的 Kubernetes（预览版）的 Azure Policy 扩展配合使用，以验证和强制执行约定和其他定义的策略。
通过安全和策略始终 采用 Shift-left DevOps 方法：
- 安全性： 在管道早期添加漏洞扫描工具，例如容器扫描。
- 策略： 使用策略作为代码，并使用允许控制器将策略强制实施为云原生策略。
将每个故障、错误或中断看作是可实现自动化和提高整体解决方案质量的机会。 在左移和 站点可靠性工程 框架中集成此方法。