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