ソフトウェア定義のクラウド インフラストラクチャでは、チームはさまざまなツールと手法を使用してインフラストラクチャをプロビジョニング、構成、管理します。 チームの進化と成長に合わせて、ポータルの使用や手動での作業から、コードと自動化を使用してインフラストラクチャとサービスをプロビジョニング、構成、管理するように移行できます。
プラットフォームの自動化に関する考慮事項
- コードとしてのすべて (EaC) 手法を実装することで、チームは重要な利点のロックを解除し、強力な開発文化を作成し、各チームの全員がデプロイされる方法とリソースを検査できます。 EaC は、プラットフォーム チームが機敏性と効率を向上させる主要な開発プラクティスを採用するのにも役立ちます。 チームは、リポジトリにコードを格納し、バージョン管理システムを使用して管理することで、変更を追跡し、運用環境に移行する変更を制御できます。
- Teams は 4つの目の原則 に従って、ペアプログラミング や ピアレビュー を活用し、コード変更が決して単独で行われないようにすることができます。 ピア プログラミングとピア レビューにより、コードの品質が向上し、チームは変更に対する責任を共有し、合意と展開の内容に関するチームの知識を増やします。 コード レビューは、チーム メンバーがコーディングと自動化のための新しい手法と方法を学習するための素晴らしい方法です。
- Teams では、Git などのバージョン管理システムを Git リポジトリと共に使用して、ピア レビューを適用する必要があります。 Git リポジトリを使用すると、チームは重要なブランチを定義し、 ブランチ ポリシーで保護できます。 ポリシーを使用すると、保護されたブランチにマージする前に、チーム メンバーの承認の最小数など、特定の条件を満たすように、これらのブランチのコード変更を要求できます。
- Teams は、EaC 手法と変更レビュー プロセスを 継続的インテグレーションと継続的デリバリー (CI/CD) プロセスと結び 付けます。 すべてのコード変更によって、静的コード分析、検証、およびテストデプロイを実行する CI プロセスが自動的にトリガーされます。 CI を使用すると、開発者は将来の問題を引き起こす可能性のあるエラーを早期に確認できます (これは「早期失敗」または「シフト左テスト」と呼ばれることがよくあります)。 チームが使用 するブランチ戦略 に応じて、重要なブランチを変更すると、異なる 環境へのデプロイがトリガーされます。 変更が承認され、
mainにマージされると、CD プロセスによってそれらの変更が運用環境にデプロイされます。 このコード管理システムは、各環境で実行されている内容に関する 単一の信頼のソース をチームに提供します。 - プラットフォームが完全に自己復旧され、ワークロード チームにセルフサービスが提供されるようにするには、プラットフォーム チームは、プロビジョニング、構成、プラットフォーム管理からワークロード チームのランディング ゾーン サブスクリプション プロビジョニングまで、すべてを自動化する ( Extreme Automation と呼ばれる) 作業を行う必要があります。 極端な自動化により、プラットフォーム チームは、プラットフォームのデプロイ、構成、管理ではなく、価値の提供に集中できます。 また、極端な自動化により、自己拡張サイクルが作成され、チームがより多くの自動化を構築する時間が増えます。
- プラットフォーム チームは、運用アクティビティを自動化し、人間の介入を減らすため、Azure でのワークロード チームのイノベーションを可能にし、加速させる重要なタスクに焦点を移す必要があります。 これを実現するには、プラットフォーム チームは、プラットフォームのツール、スクリプト、機能の強化を実施する中で、ビルドと開発の複数のサイクルを繰り返す必要があります。
- チームが Azure ランディング ゾーンのデプロイを開始するのに役立つ複数のオプションがあります。 これらのオプションは、チームの現在の機能によって異なります。チームの進化に合わせて拡張できます。 具体的には、 プラットフォームのデプロイでは、それぞれのチームのコードとしてのインフラストラクチャ (IaC) の能力とツールの好みに応じて、ポータル、Bicep、または Terraform ベースのエクスペリエンスのいずれかを選択できます。
- IaC をまだ知り、ポータルを使用してリソースをデプロイおよび管理することに慣れている新しいプラットフォーム チームは、Azure ランディング ゾーン ポータル アクセラレータを使用できます。 このアクセラレータは、現在 ClickOps アプローチを使用しているチームをサポートします。 ClickOps は、ポータル、管理コンソール、ウィザードをクリックしてリソースをプロビジョニング、構成、管理するプロセスです。 このアクセラレータを使用すると、チームはポータルを初期デプロイ ツールとして使用できます。 プラットフォーム エンジニアリングの成熟度が高まるにつれて、チームは Azure CLI、PowerShell、または IaC を徐々に組み込むことができます。
- 確立されたスキルと機能を持つプラットフォーム チームは、 DevOps の原則とプラクティスに従った体系化されたアプローチを採用できます。 チームは、IaC と最新の開発プラクティスに重点を置いて、個人アカウントで Azure アクセスを使用したり、CI/CD パイプラインを通じてすべての操作を実行したりしないようにする必要があります。 チームでは、 Azure ランディング ゾーンのコードとしてのインフラストラクチャ (IaC) アクセラレータなど、IaC ベースのアクセラレータを使用する必要があります。
- IaC ベースのアクセラレータには、管理スコープが制限されています。 新しいバージョンでは、より多くの機能とリソース管理機能が提供されます。 アクセラレータを使用する場合、チームはアクセラレータで始まる階層化されたアプローチを検討し、自動化のレイヤーを追加する必要があります。 自動化レイヤーは、レガシ アプリケーションのドメイン コントローラーデプロイなどのプラットフォーム機能を使用してワークロード チームを完全にサポートするために、チームが必要とする機能を提供します。
- プラットフォーム チームが DevOps アプローチに移行する際に、緊急修正を処理するためのプロセスを確立する必要があります。 Privileged Identity Management (PIM) の対象となるアクセス許可を使用して、修正を実行するためのアクセスを要求し、後でコードに戻して構成ドリフトを制限したり、コードを使用してクイック修正を実装したりできます。 チームは、後で各修正をやり直して技術的負債を制限できるように、常にバックログにクイック修正を登録する必要があります。 技術的負債が多すぎると、一部のプラットフォーム コードが完全にレビューされておらず、チームコーディングのガイドラインと原則を満たしていないため、将来の減速につながります。
- Azure Policies を使用して、プラットフォームにいくつかの自動化を追加できます。 IaC を使用して Azure ポリシー (多くの場合、コードとしてのポリシー (PaC) と呼ばれる) をデプロイおよび管理することを検討してください。 これらのポリシーを使用すると、ログ収集などのアクティビティを自動化できます。 多くの PaC フレームワークでも除外プロセスが実装されているため、ワークロード チームがポリシーの除外を要求するように計画します。
- "ポリシー駆動型ガバナンス" を使用して、セキュリティコントロールを満たしていないリソースをデプロイしようとしたときにワークロード チームに通知します。 このような状況で
deny効果を持つポリシーをデプロイすることを検討してください。これにより、ワークロード チームは、すべてをコードとして扱い、コードが 1 つのことを宣言し、ポリシーがデプロイ時に設定を変更する構成のずれを回避することもできます。 ワークロード チームがコードで定義されたmodifyを使用してストレージ アカウントをデプロイする場合など、supportOnlyHttpsTraffic = false効果を使用しないでください。この場合、modifyポリシーは、コンプライアンスを維持するためにデプロイ時にtrueに変更されます。 これにより、デプロイされたものからコードがずれることになります。
プラットフォーム自動化の設計に関する推奨事項
- Azure プラットフォーム、ドキュメント、デプロイ、およびテスト プロセスの完全な透明性と構成制御については、 コードとしてのすべてのもの のアプローチに従ってください。
-
バージョン管理を使用して、次のようなすべてのコード リポジトリを管理します。
- コードとしてのインフラストラクチャ
- コードとしてのポリシー
- コードとしての構成
- コードとしてのデプロイ
- コードとしてのドキュメント
- 運用環境にデプロイする前に、 4 目の原則 と ピア プログラミング または ピア レビュー のプロセスを実装して、すべてのコード変更がチームによってレビューされるようにします。
- チームの ブランチ戦略を 採用し、保護する ブランチのブランチ ポリシーを設定 します。 ブランチ ポリシーでは、チームは プル要求を 使用してマージの変更を行う必要があります。
- 継続的インテグレーションと継続的デリバリー (CI/CD) を使用して、さまざまな環境へのコード テストとデプロイを自動化します。
- プラットフォームのプロビジョニング、構成、管理、ワークロード チームのランディング ゾーン サブスクリプションのプロビジョニングなど、 すべてを自動化する作業を行います。
- チームの機能に一致する利用可能なアクセラレータのいずれかを使用して、Azure ランディング ゾーンのデプロイを開始します。
- 多層デプロイ アプローチを使用して、アクセラレータの対象ではありませんが、ワークロード チームを完全にサポートするために必要な機能を追加することを計画します。
- コードを使用してクイック修正を実装するプロセスを確立します。 チームのバックログにクイック修正を常に登録して、後で修正をやり直し、技術的負債を制限できるようにします。
- コードとしてのインフラストラクチャを使用して Azure ポリシーをデプロイおよび管理する (多くの場合、コードとしてのポリシーと呼ばれます)
- ポリシーの除外プロセスを実装します。 業務負荷がかかるチームがポリシーからの免除を要求することを念頭に置き、必要に応じてそれらのチームが円滑に業務を進行できるように準備を整える計画を立てる。
- "ポリシー駆動型ガバナンス" を使用して、セキュリティコントロールを満たしていないリソースをデプロイしようとしたときにワークロード チームをブロックします。 これにより、コードがデプロイされる状態とは異なる状態を宣言する構成誤差を減らすことができます。