Infrastructure as Code とは

10 分

あなたは、コードとしてのインフラストラクチャが、あなたの会社でのリソースプロビジョニングに対する有益なアプローチであるかどうかを評価するよう依頼されました。デプロイに使用できる、次のようなオプションを確認します。

Azure portal
Azure CLI
Azure PowerShell
Azure Resource Manager テンプレート (JSON と Bicep)

あなたは繰り返し可能なオプションを探しています。また、Azure インフラストラクチャのデプロイに使用するテクノロジを決める必要があります。

このユニットでは、コードとしてのインフラストラクチャが、自動化された再現可能な方法で Azure インフラストラクチャをデプロイする上でどのように、なぜ役立つのかを学習します。

Azure CLI コマンドは、概念を示すために使用されます。コマンドを使用してリソースをデプロイする方法の詳細については、Bicep ラーニングパスの他のモジュール内で学習します。

コードとしてのインフラストラクチャの定義

あなたの会社は、市場に出すための新しい玩具を設計しています。新しい玩具の多くは、購入後に何らかの組み立てが必要です。会社の設計チームは、それぞれの玩具に付属する説明書を作成しています。各説明書には、玩具を適切に組み立てる方法が詳しく記載されています。

コードとしてのインフラストラクチャは、インフラストラクチャの取扱説明書のようなものとして考えることができます。説明書には、リソースの最終的な構成と、その構成状態に到達する方法が詳しく記載されています。

コードとしてのインフラストラクチャは、インフラストラクチャのプロビジョニングを自動化するプロセスです。記述的なコーディング言語とバージョン管理システムが使用されますが、それはソースコードに使用されるものと似ています。アプリケーションを作成する際には、ソースコードをコンパイルするたびに同じ結果が生成されます。同じように、コードとしてのインフラストラクチャのデプロイは自動化され、一貫しており、反復可能です。コードとしてのインフラストラクチャにより、仮想ネットワーク、仮想マシン、アプリケーション、ストレージなどのインフラストラクチャリソースのデプロイを自動化することができます。

Azure リソースをデプロイするテンプレートを含むソースコードリポジトリを使用したコードプロセスとしてのインフラストラクチャを示す図。

新しいおもちゃの取扱説明書を思い出してみると、取扱説明書を書く方法は複数あります。 1 つは、ビルドプロセスの各ステップを詳しく説明する方法です。玩具の組み立てに必要な部品やパーツの分解図を示す方法もあります。このユニットの後半では、命令型と宣言型のコードの違いと、それらが会社の取扱説明書とどのように関連するかについて学習します。

コードとしてのインフラストラクチャを使う理由

コードとしてのインフラストラクチャアプローチを採用することで、リソースのプロビジョニングに多くの利点がもたらされます。コードとしてのインフラストラクチャを使用すると、以下のことが可能です。

デプロイの信頼性を高める。
複数の環境を管理する。
クラウドリソースについての理解を深める。

自信を高める

コードとしてのインフラストラクチャを使用する利点の 1 つが、一貫性とセキュリティが向上し、デプロイ内での信頼性が高まることです。

現在のプロセスとの統合:組織が既に標準的な方法でソフトウェア開発を行っている場合は、同じプロセスをインフラストラクチャのデプロイに採用することができます。たとえば、ピアレビューは、手動で変更を行う際には検出が難しい構成内の問題の検出に役立つ可能性があります。
一貫性: コードとしてのインフラストラクチャアプローチを導入すると、チームが、適切に確立されたインフラストラクチャデプロイプロセスに従いやすくなります。これらのプロセスに従うことで、責任の所在が、少人数の個人から自動化プロセスやツールに移ることになります。コードとしてのインフラストラクチャは、リソースプロビジョニングにおけるヒューマンエラーを減らし、一貫性のあるデプロイを確保するうえで役立ちます。
自動スキャン:コード内のエラーをチェックできる自動ツールを使用して、コードとしてのインフラストラクチャ構成をスキャンすることができます。また、自動ツールは、セキュリティとパフォーマンスのプラクティスが確実に守られるように、提案された変更を確認することもできます。
シークレット管理: ソリューションの多くが、接続文字列、暗号化キー、クライアントシークレット、証明書などのシークレットを必要とします。 Azure では、これらのシークレットは、Azure Key Vault サービスを使用して安全に保存されます。コードとしてのインフラストラクチャの多くは、デプロイ時にこれらのシークレットに安全にアクセスできるように、Key Vault と統合することができます。
アクセス制御: コードとしてのインフラストラクチャのデプロイでは、マネージド ID またはサービスアカウントを使って、リソースのプロビジョニングを自動化できます。このプロセスにより、クラウドリソースを変更できるのはこれらの ID のみであることが保証されます。また、誤った構成が運用環境にデプロイされるのを防ぐのにも役立ちます。このプロセスは、必要に応じてオーバーライドできます。それには、緊急アクセスアカウント ("緊急用アカウント" と呼ばれます) を使うか、Microsoft Entra ID Privileged Identity Management 機能を使います。
構成ドリフトを避ける:"べき等" は、コードとしてのインフラストラクチャとの関連でよく使用される用語です。ある操作がべき等であるとは、それが実行のたびに同じ結果をもたらすことを意味します。べき等操作を使用するツールを選択すると、構成ドリフトを回避できます。

べき等の例として、次の Azure CLI コマンドを検討してください。このコマンドを実行すると、storage-resource-group という名前の Azure リソースグループが米国東部リージョンに作成されます。

az group create \
  --name storage-resource-group \
  --location eastus

このコマンドを 2 回目に実行すると、この Azure CLI コマンドはべき等になるように設計されているため、まったく同じ出力が返されます。エラーが発生したり、重複したリソースグループが返されることはありません。

コードとしてのインフラストラクチャを使用すると、ソリューションの各リリースで環境を再デプロイできます。これらのリリースには、小さな構成の変更や、重要な更新プログラムが含まれることがあります。このプロセスは、構成ドリフトを回避するのに役立ちます。リソースに誤って変更が行われた場合は、構成を再デプロイして修正できます。このアプローチに従って、コードを使用して環境を文書化します。

複数の環境を管理する

複数のアプリケーション環境を維持している組織は多数存在します。あなたの玩具会社の開発者は、さまざまな環境にリリースするために、複数のバージョンのアプリケーションコードをリポジトリにステージしている可能性があります。環境には開発環境、テスト環境、運用環境などがあります。組織によっては、グローバルに配布されるアプリケーション用に運用環境を複数維持しています。独立系ソフトウェアベンダー (ISV) のように、顧客向けに複数テナント環境を維持している組織もあります。

ここでは、コードとしてのインフラストラクチャが、主にどのように環境管理をサポートしているかをいくつか紹介します。

新しい環境のプロビジョニング: クラウドコンピューティングの主な利点の 1 つがスケーリング機能です。コードとしてのインフラストラクチャにより、複数のアプリケーションインスタンスにスケーリングできます。これらのインスタンスは、負荷が増加したときに役立つだけでなく、世界の他の領域のユーザーに対してデプロイすることもできます。また、この俊敏性は、侵入テスト、ロードテスト、バグテストなど、アプリケーションをテストするときにも有効です。明確に定義されたコードベースを使用すると、これらの新しい環境を一貫した方法で動的にプロビジョニングできます。
非運用環境:組織が直面する一般的な問題が、運用環境と非運用環境の違いです。別々の環境内でリソースを手動でプロビジョニングすると、最終的な構成が一致しないおそれがあります。たとえば、新しい機能を、運用環境と異なる非運用環境にデプロイする場合がそうです。 2 つの環境間の違いが原因で、新しい機能が運用環境で期待どおりに動作しないということが考えられます。コードとしてのインフラストラクチャは、このような問題を最小限に抑えるのに役立ちます。それぞれの環境に同じ構成ファイルを使用できますが、異なる入力パラメーターを指定するので、一意性が確保されます。
ディザスターリカバリー: 状況によっては、コードとしてのインフラストラクチャを、組織のディザスターリカバリー計画の一環として使用できます。たとえば、サービスが停止したため、環境を別のリージョンで再構築しなければならない場合があります。コードとしてのインフラストラクチャを使用すると、すべてを手動でデプロイして再構成するのではなく、新しいインスタンスを迅速にプロビジョニングして、フェールオーバーできます。

クラウドリソースについての理解を深める

コードとしてのインフラストラクチャは、クラウドリソースの状態についての理解を深めるうえで役に立ちます。

監査証跡: コードとしてのインフラストラクチャの構成の変更は、アプリケーションのソースコードと同じ方法でバージョン管理されます。これらの変更は、Git のバージョン履歴と同様、ツール内で追跡されます。この監査証跡によって、各変更の詳細と、いつだれが変更を行ったかを確認できます。
ドキュメント: コードとしてのインフラストラクチャの多くの構成を使って、構成内のコードの目的を説明するメタデータ (コメントなど) を追加できます。既にコードドキュメントプロセスに従っている組織については、インフラストラクチャコードに同じ手順を採用することを検討してください。
統合システム: 開発者が新しい機能に取り組む場合、アプリケーションコードとインフラストラクチャコードの変更が必要になることはよくあります。共通システムを使用すると、組織はアプリケーションとインフラストラクチャの関係についての理解を深めることができます。
クラウドインフラストラクチャについての理解を深める: Azure portal を使用してリソースをプロビジョニングすると、プロセスの多くがビューから抽象化されます。コードとしてのインフラストラクチャは、Azure のしくみと、問題が発生した場合のトラブルシューティング方法についての理解を深めるうえで役に立ちます。たとえば、Azure portal を使用して仮想マシンを作成すると、作成されるリソースの一部がビューから抽象化されます。マネージドディスクとネットワークインターフェイスカードは、バックグラウンドでデプロイされます。コードとしてのインフラストラクチャを使用して同じ仮想マシンをデプロイすると、作成されたすべてのリソースを完全に制御することができます。

命令型コードと宣言型コード

新しい玩具を組み立てるための説明書は、さまざまな方法で書くことができます。サービスとインフラストラクチャのデプロイを自動化する場合は、命令型と宣言型の 2 種類のアプローチを利用できます。

"命令型コード" を使用する場合、特定の順序でコマンドシーケンスを実行して、最終的な構成に到達します。このプロセスにより、コードで実行する必要があるものと、そのタスクを実行する方法が定義されます。命令型アプローチは、ステップバイステップの取扱説明書に似ています。
"宣言型コード" を使用する場合は、最終的な構成のみを指定します。タスクの実行方法は、このコードでは定義されません。宣言型アプローチは、分解図を示す説明書に似ています。

リソースのプロビジョニングに命令型アプローチと宣言型アプローチのどちらを採用するかを選択するときは、組織内で既に使用されている可能性のあるツールを考慮してください。また、どちらのアプローチがご自身のスキルに合っているかも考えてください。

命令型コード

Azure 内での命令型コードのアプローチは、Bash や Azure PowerShell などのスクリプト言語を使用してプログラムによって実現します。スクリプトによって、リソースを作成、変更、削除するための一連のステップが実行されます。

この例では、リソースグループとストレージアカウントを作成する 2 つの Azure CLI コマンドを示します。

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

最初のコマンドは、storage-resource-group という名前のリソースグループを米国東部リージョンに作成します。 2 番目のコマンドは、最初のコマンドで作成された storage-resource-group リソースグループ内に、mystorageaccount という名前のストレージアカウントを作成します。 2 番目のコマンドは、ストレージアカウントの種類、アクセス層など、ストレージアカウントのいくつかのプロパティも構成します。

命令型アプローチを使用すると、リソースのプロビジョニングを完全に自動化できますが、このアプローチには欠点がいくつかあります。アーキテクチャが成熟してくると、スクリプトの管理が複雑になることがあります。コマンドが更新されたり、非推奨になったりすることがあり、その場合、既存のスクリプトの見直しが必要になります。

宣言型コード

Azure 内での宣言型コードのアプローチは、"テンプレート" を使用して実現します。次に示すさまざまな種類のテンプレートを使用できます。

JSON
Bicep
Ansible (RedHat)
Terraform (HashiCorp)

Note

このモジュールでは、Bicep テンプレートの使用に焦点を当てます。

次の例を見てみましょう。これはストレージアカウントを構成する Bicep テンプレートの例です。ストレージアカウントの構成は、Azure CLI の例と一致します。

resource storageAccount 'Microsoft.Storage/storageAccounts@2203-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

resources セクションによって、ストレージアカウントの構成が定義されます。このセクションには、ストレージアカウントの名前、場所、プロパティ (SKU やアカウントの種類など) が含まれます。

Bicep テンプレートで、ストレージアカウントのデプロイ方法が指定されていないことにお気づきでしょうか。これによって指定されるのは、ストレージアカウントの外観のみです。このストレージアカウントを作成したり、仕様に合わせてそのアカウントを更新したりするためにバックグラウンドで実行される実際のステップは、Azure が判断します。