規劃 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 的觀點評估安全性選項。 部署會自動進行，因此會據以對應訪問控制。
請考慮使用遵循定義完善的慣例的前置詞和後綴，以唯一識別每個已部署的資源。 當您部署相鄰的解決方案時，命名慣例可避免衝突，且有助於改善整體小組靈活度和輸送量。
清查您的工作流程，以協助您在一般和 Digital 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 金鑰保存庫 提供者來保護秘密、憑證和 連接字串。
避免硬式編碼的組態項目和設定，將部署並行度最大化。
依賴基礎結構部署和應用程式相關部署的已知慣例。 針對已啟用 Azure Arc 的 Kubernetes（預覽版）使用具有 Azure 原則 延伸模組的許可控制器，以驗證和強制執行慣例和其他已定義的原則。
透過安全性和原則一致地採用 Shift-left DevOps 方法：
- 安全性： 在管線早期新增容器掃描等弱點掃描工具。
- 原則： 使用原則做為程序代碼，並使用許可控制器以雲端原生方式強制執行原則。
將每個失敗、錯誤或中斷視為自動化並改善整體解決方案質量的機會。 在左移和 月臺可靠性工程 架構中整合此方法。