Share via

オートメーション

  • [アーティクル]

ソフトウェア定義クラウド インフラストラクチャでは、チームはさまざまなツールと手法を使用して、インフラストラクチャのプロビジョニング、構成、管理を行います。 チームは、その発展と成長に合わせて、ポータルの使用や手動の作業から、コードと自動化を使用したインフラストラクチャとサービスのプロビジョニング、構成、管理に移行できます。

プラットフォームの自動化の考慮事項

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

プラットフォーム自動化の設計に関する推奨事項

  • Azure プラットフォーム、ドキュメント、デプロイ、テスト プロセスの完全な透明性と構成制御のために、Everything as Code アプローチに従います。
  • バージョン管理を使用して、次を含むすべてのコード リポジトリを管理します。
    • コードとしてのインフラストラクチャ
    • コードとしてのポリシー
    • コードとしての構成
    • コードとしてのデプロイ
    • コードとしてのドキュメント
  • 4 つ目の原則と "ピア プログラミング" または "ピア レビュー" のプロセスを実装して、すべてのコード変更が、運用環境にデプロイする前にチームによって確実にレビューされるようにします。
  • チームにブランチ戦略を採用し、保護するブランチにブランチ ポリシーを設定します。 ブランチ ポリシーでは、チームは pull request 使用してマージを変更する必要があります。
  • 継続的インテグレーションと継続的デリバリー (CI/CD) を使用して、さまざまな環境へのコード テストとデプロイを自動化します。
  • プラットフォームのプロビジョニング、構成、管理、ワークロード チームのランディング ゾーン サブスクリプションのプロビジョニングなど、すべてを自動化する作業を行います。
  • チームの機能に一致する利用可能なアクセラレータのいずれかを使用して、Azure ランディング ゾーンのデプロイを開始します。
  • 多層デプロイ アプローチを使用して、アクセラレータではカバーされていないが、ワークロード チームを完全にサポートするために必要な機能を追加することを計画します。
  • コードを使用してクイック修正を実装するプロセスを確立します。 チームのバックログにクイック修正を常に登録して、各修正を後で修正し、技術的負債を制限できるようにします。
  • コードとしてのインフラストラクチャを使用して、Azure Policy (多くの場合、コードとしてのポリシーと呼ばれます) をデプロイおよび管理します
  • ポリシーの適用除外プロセスを実装します。 ワークロード チームがポリシーの適用除外を要求し、必要に応じてチームのブロックを解除する準備を整えるように計画します。
  • "ポリシー主導のガバナンス" を使用して、ワークロード チームがセキュリティ コントロールを満たしていないリソースをデプロイしようとしているときにブロックします。 これにより、コードで最終的にデプロイされる状態とは異なる状態が宣言される構成のずれを減らすことができます。

詳細情報