IaCとは
Infrastructure as Codeの頭文字でインフラをコードで管理することです。
コードと聞くといかにも技術のような印象がありますが、
- どういうシステムの完成系を目指しているか
- 完成系に至るまで、どのように作業していくか
- 完成系を継続的にどのように運用していくか
ということに対するGUI・CLIのような操作論・方法論の一つだと捉えています。
なせIaC？
IaCはスクリプトと違い、コードで完成系を定義します。
IaCで構築・運用するメリットは大きく以下4つが考えられます。
再現性・一貫性
コードで定義したものと全く同じものがリソースとしてデプロイされるため、
- ポータルで操作する時にコピペが抜けていた
- コマンドで操作する時に１行飛ばしていた
というような人的事故を防ぎ、一貫性を保つことができます。（勿論、コードの記述にミスがあれば間違った状態でデプロイされるので、コード自体の精査は重要です。）
また、コードは再利用が可能なので、本番環境と同じ環境を検証環境でデプロイし検証を行い、終わったらリソースを全部削除するというクラウドの俊敏性とも相性が良く、運用品質の確保やコストメリットを出すことが可能です。
変更履歴の可視化
GitHubなどのバージョン管理システムと合わせることで、「誰が、いつ、どういう理由で、何を」設定変更したか追跡できます。
GUIでもAzureのアクティビティログからのログは見れますが、GitHubで記載できるコミットメッセージや変更差分などを可視化できます。
レビューと品質管理
コードで記載するので、いわゆるコードレビューができます。
作業内容（操作内容）をチェックするのではなく変更内容をチェックできるので、作業に係る影響を拾いやすくなります。
ドキュメントとして利用できる
コードがそのままパラメーターシートになるので、Excelなどの煩雑な管理を簡略化できます。
Bicepとは
宣言型の構文を利用してAzureリソースをデプロイするためのドメイン固有言語（DSL）です。
※宣言型＝上記で説明した「完成系」を定義すること
※ドメイン固有言語：プログラミング言語のようなもので、特定のシーンで利用されることを前提に設計された言語。SQL（DBMS専用）やVBA（Office専用）など
もともとARMテンプレートというJSON形式のコードでリソースを定義する考え方がありましたが、Bicepはより簡潔に読みやすくするために作られた言語です。
ARMテンプレートがなくなったわけではなく、ユーザーがBicepで記述しデプロイを行うと裏側でBicep→ARMテンプレートにコンパイルされて実行されるため、BicepはARMテンプレートよりもユーザー側に近いインターフェースのようなものと理解して良いと思います。
VSCodeとは
Microsoftが提供する、Bicepを含むコードを記述するエディタです。
ただコードを記述するだけでなく、GitHubやAzureサブスクリプションとの連携だったり、
拡張機能によるCopilotとの連携
cmdやターミナルといった機能を具備しているIDE（統合開発環境）のようなものです。
セットアップ手順については以下の記事に纏めています。
Bicepを使ってAzure VMを作ってみよう
実際にAzure VMをBicepで定義して作成してみたいと思います。
事前準備
コード自体の記述はGitHub Copilotがほとんどできるので、お作法を細かく覚える必要もありません。
個人的には小規模でも構成図を書くことでプロンプトの精度が上がるのでお勧めです。
※ざっくりしたプロンプトでもリソース定義はできますが、リソースの定義漏れなどは発見しにくかったりするので、正規な状態を自分で把握できるようにしておくことが大事です。
単純なVMを建てる作業でも意外と決めておくことがあります。
ここからプロンプトを生成してみます。
VM作成用プロンプト
Azure Bicepを使用して、以下の構成図の通りにインフラを構築するコードを作成してください。
すべてのリソースは `japaneast` (東日本) リージョンに作成します。
## 構成要件
1. **仮想ネットワーク (VNet)**
* リソース名: `vnet-bicep`
* アドレス空間: `192.168.0.0/16`
* サブネット:
* 名前: `subnet-bicep`
* アドレス範囲: `192.168.10.0/24`
2. **ネットワークセキュリティグループ (NSG)**
* リソース名: `nsg-bicep`
* ルール:
* **Inbound**: Internet (`*`) からのSSH (Port 22)を許可
* **Outbound**: Internetへのすべての通信を許可 (`*`)
* 関連付け: `subnet-bicep` に適用
3. **パブリックIP (PIP)**
* リソース名: `pip-vm-bicep`
* SKU: Standard
* ※VMにパブリックアクセスできるように作成してください。
4. **ネットワークインターフェース (NIC)**
* リソース名: `nic-vm-bicep`
* サブネット接続: `subnet-bicep`
* パブリックIP構成: 上記PIPを関連付け
* プライベートIP割り当て: Dynamic (動的)
* ※固定IPではなく、サブネットのレンジから自動割り当てとすること。
5. **仮想マシン (Virtual Machine)**
* リソース名: `vm-bicep`
* サイズ: `Standard_B2ms`
* OS: **Ubuntu Server 24.04 LTS**
* OSディスク設定:
* **サイズ**: 指定なし（OSイメージの既定サイズを使用すること）。
* 認証方式: `adminUsername` と `adminPassword`をパラメータで受け取る実装にすること。
* ネットワーク: 上記NICを接続
* **データディスク接続**: 下記の「データディスク」をLUN 0等にアタッチすること。
6. **データディスク (Managed Disk)**
* ※OSディスクとは別に作成し、VMにアタッチする外部ストレージとして定義してください。
* 名前: `disk-bicep`
* SKU: Standard SSD (`StandardSSD_LRS`)
* サイズ: 64GB
* createOption: Empty (空のディスクを作成)
## 出力要件
* リソース名、ロケーション、管理ユーザー情報は `param` として定義し、再利用性を高めてください。
* **モジュール分割**:
* `network.bicep` (VNet, Subnet, NSG, PIP, NIC)
* `virtualMachine.bicep` (VM, Data Disk)
* `main.bicep` (上記モジュールの呼び出し)
の形に分割して出力してください。コーディング
GitHubリポジトリの作成
まずはGitHubリポジトリを作成します。
今回はCI/CDなどは組まないのでコードの保管庫としての役割になりますが、
コードを管理していく上で変更履歴や変更点を追えるのは便利です。
GitHubのリポジトリからNewで作成します。
リポジトリ名は適当に決めます。
Choose Visibilityは今回publicにしますが、本番システムの情報やコードが乗っている場合はpublicにしましょう。（情報漏洩や攻撃対象の可能性があります）
README.mdもメモで使うことが多いので最初からOnにしておきます。
VSCodeでGitHubリポジトリをクローン
変なマークのところを押して先ほど作成したリポジトリをクローン（コピー＆連携）します。
上のコマンドパネルにこんなのが出てくるので、GitHubから複製をします。
自分の所有するリポジトリが出てくるので、先ほど作成したリポジトリを選択します。
ファイルの保管場所を聞かれるので、適当な良き場所を指定してください。
指定したら開くと、README.mdだけのフォルダが開かれます。
GitHub Copilotを使ったコーディング
ここで新規ファイル作成して先ほど作ったプロンプトを入れておきます。
プロンプトはそのままCopilotに読み込ませて、Bicepファイルを作成します。
GitHub Copilotはただコードを返すだけでなく、ファイル作成やフォルダ作成なども自動でおこないます。
内容をチェックし、プロンプトで指定漏れしていた部分や意にそぐわない部分を修正します。
これも手動修正もできますが、Copilotに修正依頼をかけることもできます。
最終的なコードは参考程度で以下のリポジトリに格納しています。
デプロイ
冒頭でIaCはGUIやCLIといった操作論の一つと言いましたが、
デプロイトリガーにはコマンドを使います。
CI/CDパイプラインを組んだりするとこのコマンドも不要になりますが、今回はそこまで触れていないので、PowerShellでデプロイを動画も交えて解説します。
ログイン
PowerShellターミナルからAzureにログインします。
PowerShellターミナルはVSCode上で使えます。
az loginログイン画面が出てくるので、自分のAzureアカウントでログインします。
その後、ターミナル上でサブスクリプションの選択を求められますが、1つしかない場合はそのままEnter押してOKです。
リソースグループの作成
az group create --name rg-bicep-vm --location japaneastリソースグループがない場合は作成を行います。
今回はrg-bicep-vmというリソースグループ名で東日本リージョンに作成します。
Bicepファイルのデプロイ
az deployment group create `
--resource-group rg-bicep-vm `
--template-file main.bicep `
--parameters location=japaneast `
vnetName=vnet-bicep `
nsgName=nsg-bicep `
pipName=pip-vm-bicep `
nicName=nic-vm-bicep `
vmName=vm-bicep `
dataDiskName=disk-bicep `
adminUsername=<ユーザー名> `
adminPassword=<パスワード>デプロイ先をリソースグループに指定してmain.bicepをデプロイします。
main.bicepから作成した仮想マシン用モジュールとネットワーク用モジュールが呼び出され、デプロイされます。
デプロイ進捗はリソースグループのデプロイブレードからも確認できます。
修正
今回のプロンプトではいくつか問題がありました。
- 外部マネージドディスクのつもりで作成したマネージドディスクがOSディスクになっていた
- Ubuntuの24のimageがちゃんと指定されていなかった
- NSGの優先順位を指定していないので1000番から採番された
これらはCopilotに支持を出せば全て修正してくれます。
しかしながら、ちゃんと精査しないと上記がそのままデプロイされてしまうので、AIの成果物にはある程度注意を払ってみる必要はあります。
成果物の確認
まずはsshでサーバーにアクセスできるかを確認します。
ssh <ユーザー名>@<パブリックIPアドレス>そのほか、Azure Portalで構成図とパラメータを比較します。
例えば、
- VNET、Subnetのアドレス空間は一致しているか
- NSGはSubnetに関連づいているか
- VMはSubnet内のプライベートIPとパブリックIPを持っているか
- VMのOS、サイズ、ディスクなどは一致しているか
など、自分で定義した部分が正常に反映されていることを確認できます。
削除
確認が終了したらリソースグループごと削除できます。
デプロイコマンド1発で必ず同じ形を作成できるので「また作るのも面倒だしVMだけ停止しておくか」と、ディスクのお金を払い続ける必要もありません。
コードの管理
現在コマンドはローカルのファイルにのみ保持されています。
個人作業であれば問題ありませんが、組織で共有・修正などを行う場合はGitで管理することになるので、先ほどのコードもGitHubに保存します。
この保存の一連の流れをpushするといったりcommitすると言ったりします。
GitHubへの接続は最初のクローンでできているので、GitHubへpushしていきます。
本リポジトリは今後作業を続けていくため、作業ごとに保管しておきたいので「ブランチ」を切ります。
※ブランチ：論理的な作業場所・保管場所のようなものです。
PowerShellターミナルで以下のコマンドを実行します。
git checkout -b simple-vm-deploy-bicepこれで作業場所がsimple-vm-deploy-bicepという場所に移りましたので、simple-vm-deploy-bicepにコードを保存します。
git add .
git commit -m "シンプルなVMをデプロイするBicepファイルの作成"
git push origin simple-vm-deploy-biceppushが完了し、今の手元にあるコードが全てGitHub上のリポジトリに保存されました。
このリポジトリは公開なので、先ほどのGitHubリンクから確認できます。
まとめ
今回はIaC、Bicepについて解説し、Bicepを使ったVMのデプロイ方法を実演しました。
今後もIaCをやっていく上で押さえておきたい特性や、構築・運用が便利になる機能などを紹介していきます。
コメント