コードとしてのインフラストラクチャの使用に関する推奨事項

  • [アーティクル]

この Azure Well-Architected Framework オペレーショナル エクセレンスチェックリストの推奨事項に適用されます。

OE:05 標準化されたコードとしてのインフラストラクチャ (IaC) アプローチを使用して、リソースとその構成を準備します。 他のコードと同様に、一貫したスタイル、適切なモジュール化、品質保証を使用して IaC を設計します。 可能な場合は宣言型のアプローチを使用します。

このガイドでは、インフラストラクチャのデプロイの標準として IaC を使用するための推奨事項について説明します。 IaC を使用すると、インフラストラクチャのデプロイと管理を既存のソフトウェア開発プラクティスに統合できます。 ワークロードのすべてのコンポーネントに対して、開発とデプロイのための一貫した標準的な手法が提供されます。 手動デプロイに依存すると、ワークロードの構成が一貫性がなく、安全でない可能性のある設計のリスクにさらされます。

定義

期間 定義
宣言型ツール デプロイの終了状態を定義し、システムに依存して、定義された終了状態と一致するようにリソースをデプロイする方法を決定するツールのカテゴリ。
イミュータブル インフラストラクチャ 新しい構成を各デプロイで実行する新しいインフラストラクチャに置き換えることを目的としたインフラストラクチャ。 変更しないでください。
命令型ツール 目的の終了状態になる実行ステップを一覧表示するツールのカテゴリ。
モジュール 複雑なデプロイを簡略化するためにリソースのグループを分割するための抽象化の単位。
変更可能なインフラストラクチャ 適切に変更することを意図したインフラストラクチャ。 デプロイでは、新しいインフラストラクチャに置き換えるのではなく、インフラストラクチャの構成が変更されます。

主要な設計戦略

サプライ チェーンと標準化ツールとプロセス ガイドで説明したように、コードを介してのみインフラストラクチャの変更 (構成変更を含む) をデプロイする厳密なポリシーが必要です。 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを通じて IaC をデプロイする必要があります。 これらのポリシーを採用すると、すべての IaC デプロイにプロセスの一貫性が適用され、環境全体の構成ドリフトのリスクが最小限に抑え、環境全体のインフラストラクチャの一貫性が確保されます。 さらに、スタイル ガイドで IaC 開発およびデプロイ ツールとプロセスを標準化する必要があります。 スタイル ガイドの推奨事項は次のとおりです。

命令型ツールよりも宣言型を優先します。 宣言型ツールとそれに関連するファイルは、命令型ツールよりも IaC のデプロイと管理に関する全体的な選択肢として優れています。 宣言型ツールでは、定義ファイルに対してより単純な構文が使用され、デプロイが完了した後の環境の目的の状態のみが定義されます。 命令型ツールは、目的の終了状態に到達するために必要な手順を定義することに依存するため、ファイルは宣言型ファイルよりもはるかに複雑になる可能性があります。 宣言型定義ファイルは、時間の経過と同時に発生する可能性がある、デプロイ スクリプトなどの命令型コードを維持するという技術的負債を減らすのにも役立ちます。

クラウド プラットフォームのネイティブ ツールと、プラットフォームにネイティブに統合される業界で実績のあるその他のツールを使用します。 クラウド プラットフォームには、IaC のデプロイを簡単かつ簡単にするためのツールが用意されています。 独自のソリューションを開発するのではなく、これらのツールと、Terraform などのネイティブ統合を持つ他のサードパーティ製ツールを利用します。 ネイティブ ツールはプラットフォームでサポートされており、ほとんどのニーズに対応する組み込みの機能が含まれています。 これらはプラットフォーム プロバイダーによって継続的に更新され、プラットフォームの進化に合って役立ちます。

注意

クラウド プロバイダーやサードパーティの開発者がツールと API を更新すると、ワークロードで最新バージョンを使用するときに予期しない問題のリスクが発生する可能性があることに注意してください。 新しいバージョンのツールと API を採用する前に、十分にテストしてください。 同様に、デプロイ コードでツールまたは API で を呼び出すときは、'latest' フラグを使用しないでください。 ワークロードの最新の既知の適切なバージョンを呼び出すことに注意してください。

特定のタスクとインフラストラクチャの種類に適したツールを使用します。 デプロイ以外の複数のタスクは、インフラストラクチャのライフサイクルに関係します。 たとえば、構成を適用して維持する必要があり、Bicep などのデプロイのスクリプト作成に使用するツールが、すべての管理操作に最適なツールではない場合があります。

同様に、インフラストラクチャの種類ごとに目的の状態構成 (DSC) を適用するには、異なるツールが必要になる場合があります。 たとえば、VM の DSC を管理するための Ansible などの特定のツールがありますが、Flux は Kubernetes クラスターで DSC を管理するための優れたツールです。 サービスとしてのプラットフォーム (PaaS) サービスでは、IaC を介して処理できる構成管理 (Azure App Configuration など) のさまざまなツールが提供される場合があります。 サービスとしてのソフトウェア (SaaS) サービスは、プラットフォームによってより厳密に制御されるため、より制限される可能性があります。

IaC プラクティスの対象となるすべてのタスクと種類のインフラストラクチャについて考え、必要なジョブを実行し、開発と管理のプラクティスに統合できるツールを標準化します。

スクリプトとテンプレートは、さまざまな環境を簡単にデプロイするのに十分な柔軟性が必要です。 パラメーター、変数、および構成ファイルを使用して、コード プロモーション スタック内の任意の環境をデプロイするように変更できるリソースの標準セットをデプロイします。 リソース サイズ、数、名前、デプロイ先の場所、一部の構成設定などの抽象設定。 ただし、抽象化しすぎないように注意してください。 パラメーターまたは変数を使用して抽象化できる設定があり、ワークロードのライフサイクルの過程で実際には変更されないか、ほとんど変更されない可能性があります。 抽象化しないでください。

注意

環境ごとに異なる IaC 資産を使用しないでください。 たとえば、運用環境とテスト環境に異なる Terraform ファイルを含めることはできません。 すべての環境で 1 つのファイルを使用する必要があります。 必要に応じて、そのファイルを操作してさまざまな環境にデプロイできます。

モジュールの使用について戦略を立て、標準化する。 パラメーターや変数と同様に、モジュールを使用すると、インフラストラクチャのデプロイを繰り返し可能にすることができます。 ただし、それらをどのように使用するかについては、慎重に行う必要があります。 標準化された抽象化戦略は、合意された特定の目標を満たすようにモジュールを構築するのに役立ちます。 モジュールを使用して、複雑な構成またはリソースの組み合わせをカプセル化します。 リソースの既定の構成のみを使用している場合は、モジュールを避けてください。 さらに、新しいモジュールの開発に慎重に取り組んでください。 必要に応じて、管理されたオープン ソース モジュールを使用します (たとえば、非センシーティブなシナリオ)。

手動ステップの標準を文書化します。 環境に特有の手動介入を必要とするインフラストラクチャのデプロイと保守に関連する手順が存在する場合があります。 これらの手順が可能な限り最小限に抑えられ、明確に文書化されていることを確認します。 スタイル ガイドと標準的な操作手順では、手動の手順を標準化して、タスクが安全かつ一貫して実行されるようにします。

孤立したリソースを処理するための標準を文書化します。 構成管理に使用するツールとその制限によっては、ワークロードで特定のリソースが不要になり、IaC ツールでリソースを自動的に削除できない場合があります。 たとえば、何らかの機能のために VM から PaaS サービスに移行する場合、IaC ツールには廃止されたリソースを削除するロジックが含まれていないとします。 ワークロード チームが手動で削除することを忘れない場合、これらのリソースは孤立する可能性があります。 これらのシナリオを処理するには、孤立したリソースをスキャンして削除する戦略を標準化します。 また、テンプレートが最新であることを確認する方法も検討する必要があります。 IaC ツールの制限事項を調べ、このような状況で何を計画する必要があるかを理解します。

その他の IaC 戦略

ワークロードに IaC を使用する場合に適用される次の推奨事項を検討してください。

階層化されたアプローチを使用して、ワークロード スタック内の IaC パイプラインを調整します。 IaC パイプラインをレイヤーに分離すると、複雑な環境を管理できます。 モノリシック パッケージとして数十または数百のリソースをデプロイすることは非効率的であり、破損した依存関係など、複数の問題が発生する可能性があります。 デプロイライフサイクルや機能などの要因が密接に一致するリソースで構成されるレイヤーに合わせた複数のパイプラインを使用すると、IaC デプロイの管理が容易になります。

ネットワーク リソースなどのコア インフラストラクチャでは、構成の更新よりも複雑な変更が必要になることはほとんどありません。そのため、これらのリソースは ロータッチ の IaC パイプラインを構成する必要があります。 ワークロードの複雑さに応じて、リソース用の 1 つ以上の ミディアムタッチ および ハイタッチ IaC パイプラインがある場合があります。 Kubernetes ベースのアプリケーション スタックを例として使用すると、1 つのメディア タッチ レイヤーがクラスター、ストレージ リソース、およびデータベース サービスで構成される場合があります。 ハイタッチ レイヤーは、継続的デリバリー モードで頻繁に更新されるアプリケーション コンテナーで構成されます。

IaC とアプリケーション コードを同じように扱います。 IaC 成果物をアプリケーション コード成果物と同じように扱うと、すべてのパイプラインでコードを管理するために同じ厳格性を適用できます。 さらに、IaC の開発とデプロイのプラクティスでは、アプリケーションプラクティスをミラーする必要があります。 バージョン管理、分岐、コードの昇格、品質の標準はすべて同じである必要があります。 また、IaC アセットをアプリケーション コード資産と併置することも検討してください。 これを行うと、すべてのデプロイで同じプロセスが確実に実行され、必要なアプリケーション コードの前にインフラストラクチャを誤ってデプロイするなどの問題を回避するのに役立ちます。またはその逆も同様です。

標準化と再利用のために、organization内の他のチームと共同作業を行います。 大規模な組織では、複数のチームがワークロードの開発とサポートを行う場合があります。 標準に同意するためのチーム間のコラボレーションは、ライブラリ、テンプレート、モジュールを再利用して、ワークロード環境全体で効率と一貫性を確保するのに役立ちます。 同様に、IaC ツールは、実用的な範囲でorganization全体で標準化する必要があります。

"コードとしてのセキュリティ" の原則を適用して、セキュリティがデプロイ パイプラインの一部であることを確認します。 IaC 開発プロセスの一部として、脆弱性スキャンと構成の強化を含めます。 IaC リポジトリで、公開されているキーとシークレットをスキャンします。 IaC を使用する利点の 1 つは、セキュリティに重点を置いたチーム メンバーがデプロイ前にコードを確認して、セキュリティによってリリースが承認された構成が実際に運用環境にデプロイされていることを確認できることです。 詳細なガイダンスについては、「 開発ライフサイクルをセキュリティで保護するための推奨事項」を参照してください。

ルーチンアクティビティと非ルーチンアクティビティをテストします。 デプロイ、構成の更新、および復旧プロセス (デプロイ/ロールバック プロセスを含む) をテストします。

変更可能なインフラストラクチャと変更できないインフラストラクチャ

変更可能なインフラストラクチャと不変のインフラストラクチャのどちらをデプロイするかの選択は、いくつかの要因によって異なります。 ワークロードがビジネス クリティカルな場合は、不変インフラストラクチャを使用することをお勧めします。 同様に、 デプロイ スタンプに基づく成熟したインフラストラクチャ設計がある場合は、アプリケーション コードと新しいインフラストラクチャを確実にデプロイできるため、不変インフラストラクチャを使用するのが理にかなっています。 逆に、 安全なデプロイプラクティス で、デプロイの問題が発生したときにデプロイをロールフォワードすることが推奨される場合は、変更可能なインフラストラクチャを使用することをお勧めします。 この場合は、インフラストラクチャを更新する可能性があります。

考慮事項

特殊化の強化: 場合によっては、ワークロード チームに新しい言語を導入すると学習曲線が付き、ベンダーのロックインによって選択が不十分になる場合があります。 チーム メンバーをトレーニングし、クラウド プロバイダーのツール サポートに基づいて適切なツールを分析する必要があります。

メンテナンス作業の増加: IaC 実装を最新かつ安全に保つためには、コード ベースとツールのメンテナンスが必要です。 技術的負債を適切に追跡し、負債の削減が報われる文化を育てます。

構成変更の時間の増加: コマンドライン命令を使用して、またはポータルから直接インフラストラクチャをデプロイする場合、コーディング時間やテスト成果物は必要ありません。 コード レビューや品質保証プラクティスなどの推奨されるプラクティスに従って、デプロイ時間を最小限に抑えます。

モジュール化の複雑さの増加: より多くのモジュールとパラメーター化を使用すると、システムのデバッグと文書化にかかる時間が長く、抽象化レイヤーが追加されます。 モジュール化の使用のバランスを取り、複雑さを軽減し、過剰なエンジニアリングを回避します。

Azure ファシリテーション

Azure Resource Manager テンプレート (ARM テンプレート) と Bicep は、宣言構文を使用してインフラストラクチャをデプロイするための Azure ネイティブ ツールです。 ARM テンプレートは JSON で記述されますが、Bicep はドメイン固有の言語です。 どちらも、Azure パイプラインまたは CI/CD パイプラインGitHub Actions簡単に統合できます。

Terraform は、Azure で完全にサポートされているもう 1 つの宣言型 IaC ツールです。 これは、インフラストラクチャのデプロイと管理に使用でき、CI/CD パイプラインに統合できます。

Microsoft Defender for Cloud を使用して、IaC の構成ミスを検出できます。

例

提供されたResource Manager、Bicep、または Terraform ファイルを使用してデプロイできる Virtual Desktop 実装の例については、Azure Virtual Desktop ランディング ゾーン アクセラレータアーキテクチャと関連する参照実装に関するページを参照してください。

オペレーショナル エクセレンスチェックリスト

推奨事項の完全なセットを参照してください。

オペレーショナル エクセレンスチェックリスト