你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
获取 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 范式转变的效果。 预计 Kubernetes 的 Pod 及其他组件为临时性质，并且相应调整自动化流程和管道架构。 不要依赖 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 Key Vault 提供程序 来保护机密、证书和连接字符串。
通过避免硬编码的配置项和设置，最大程度地提高部署并发性。
依赖于跨基础结构部署和应用程序相关部署的已知约定。 将 允许控制器 与 已启用 Azure Arc 的 Kubernetes（预览版）的 Azure Policy 扩展 配合使用，以验证和强制执行约定和其他定义的策略。
通过安全和策略始终融入Shift-left DevOps 方法：
- 安全： 在管道早期添加漏洞扫描工具，例如容器扫描。
- 政策： 使用策略作为代码，并使用允许控制器将策略强制实施为云原生策略。
将每个故障、错误或中断视为自动化和提高整体解决方案质量的机会。 在左侧移位策略和站点可靠性工程框架中集成此方法。