コードとしてのインフラストラクチャ (IaC) では、ネットワーク、仮想マシン、ロード バランサー、接続トポロジなどのインフラストラクチャを定義してデプロイするために、DevOps の方法論とバージョン管理を記述モデルで使用します。 同じソース コードが常に同じバイナリを生成するように、IaC モデルはデプロイするたびに同じ環境を生成します。
IaC は、DevOps の主要なプラクティスであり、 継続的デリバリーの構成要素です。 IaC を使用すると、DevOps チームは統合された一連のプラクティスとツールと連携して、アプリケーションとそのサポート インフラストラクチャを迅速かつ確実に大規模に提供できます。
一貫性を強制する手動構成を避ける
IaC は、リリース パイプラインでの 環境ドリフト の問題を解決するために進化しました。 IaC がない場合、チームはデプロイ環境設定を個別に維持する必要があります。 時間の経過と同時に、各環境は "snowflake" になり、自動的に再現できない固有の構成になります。 環境間の不整合により、デプロイの問題が発生する可能性があります。 インフラストラクチャの管理とメンテナンスには、エラーが発生しやすく追跡が困難な手動プロセスが含まれます。
IaC は手動構成を回避し、JSON などの形式で適切に文書化されたコードを使用して目的の環境の状態を表すことで一貫性を強制します。 IaC を使用したインフラストラクチャのデプロイは繰り返し可能であり、構成の誤差や依存関係の不足によって発生するランタイムの問題を防ぎます。 リリース パイプラインは、環境の説明とバージョンの構成モデルを実行して、ターゲット環境を構成します。 変更を加えるために、チームはターゲットではなくソースを編集します。
常に同じ結果を生成する操作の特性である冪等性は、重要な IaC の原則です。 デプロイ コマンドは、環境の開始状態に関係なく、常にターゲット環境を同じ構成に設定します。 べき等性は、既存のターゲットを自動的に構成するか、既存のターゲットを破棄して新しい環境を再作成することによって実現されます。
役に立つツール
大規模で安定したテスト環境を迅速に提供
IaC は、開発サイクルの早い段階で、DevOps チームが運用環境のような環境でアプリケーションをテストするのに役立ちます。 Teams では、必要に応じて複数のテスト環境を確実にプロビジョニングできます。 クラウドは、IaC 定義に基づいて環境を動的にプロビジョニングおよび破棄します。 インフラストラクチャ コード自体は、一般的なデプロイの問題を防ぐために検証およびテストできます。
宣言型定義ファイルを使用する
可能であれば、IaC は宣言型定義ファイルを使用する必要があります。 定義ファイルには、環境に必要なコンポーネントと構成が記述されていますが、その構成を実現する方法は必ずしも記述されていません。 たとえば、ファイルで必要なサーバーのバージョンと構成が定義されているが、サーバーのインストールと構成プロセスは指定されていない場合があります。 この抽象化により、インフラストラクチャ プロバイダーが提供する最適化された手法をより柔軟に使用できます。 宣言型の定義は、時間の経過と同時に発生する可能性のある命令型コード (デプロイ スクリプトなど) の維持に伴う技術的負債を減らすのにも役立ちます。
宣言型 IaC の標準構文はありません。 通常、IaC を記述するための構文は、ターゲット プラットフォームの要件によって異なります。 YAML、JSON、XML などのファイル形式は、さまざまなプラットフォームでサポートされています。
Azure に IaC をデプロイする
Azure では、 Azure Resource Manager モデルを使用した IaC のネイティブ サポートが提供されます。 Teams では、JSON 構文または Bicep を使用して宣言型 ARM テンプレートを定義し、ソリューションのデプロイに必要なインフラストラクチャを指定できます。 特定の Azure プロバイダーを介した Terraform などのサードパーティソリューションも利用できます。