みなさんこんにちは。

Azureのリソースをデプロイする際、どのようなツールをご利用でしょうか。 Azure Portal、Azure CLI、Azure PowerShell、ARM(Azure Resource Manager)テンプレートなど、Azureリソースをデプロイするために利用できるツールはさまざまあります。 今回はBicepによるリソースのデプロイについてご紹介いたします。

Bicepを学ぶ動機

Azureを扱うなかで以下のようなご経験はないでしょうか。
・複数のリソースをひとつひとつデプロイする手間を負担に感じた
・以前存在していたリソースを再現したくなったがどのような操作で環境を作成したか(実行コマンドを)忘れてしまった
・リソースデプロイの手順(またはコマンド)を間違えてしまった

Bicepを利用することで、こういった困りごとが解決できるかもしれません。

Bicepは宣言型でAzureインフラを定義できる言語です。 Bicepでは拡張子「.bicep」のファイルに「最終的にどうなっていてほしいか(どんなリソースがほしいか)」を記述します。 宣言型であるため、ユーザーが目的達成(必要なリソースの作成完了)までの道のりを考えずに扱えるようになっています。下図の左側のように、欲しいものをまとめて宣言しておけばよいのです。

一度Bicepファイルを作っておけば、ファイル内で宣言されているリソースを繰り返しデプロイすることもできます。 また、デプロイするリソースをコード化するためGitなどでコード管理できるほか、Azureにおける操作ミスを防ぐ効果も期待できます。

Bicepを利用する利点についてはMicrosoft Learnにまとめられています。 こちらには記載されていませんが、Azureの情報収集にも役立つ場面があるかもしれません。 Azureのサンプルなど、GitHubで公開されるケースも増えてきました。例えばAzure OpenAI ServiceのEntra認証に関するコードサンプルがこちらで公開されていますが、GitHubを見てみると「infra」内に拡張子.bicepのファイルが存在します。 Bicepを知っておくことで、こういったサンプルがどういったリソースで構成されるか把握しやすくなるのではないでしょうか。

ARMテンプレート(JSON)との関係性

Azureのリソースを宣言型で定義する方法としてはJSON形式で記述するARMテンプレートもあります。こちらの方が馴染みがあるという方もいらっしゃるかもしれません。

Bicepファイルを使用したリソースデプロイでは、自動で ARM テンプレートに変換(コンパイル)されるようになっています。(この動作についてはこちらで説明されています。) JSON形式のARMテンプレートをBicep形式に逆コンパイルすることも可能です。

JSONでもBicepでもAzureのリソースを宣言型で定義できますが、Bicepの方がより読みやすくなります。 2つの手法の比較についてはこちらをご参照ください。

Bicepを扱う環境の準備

まずはBicepを扱うための環境を準備しておくとよいでしょう。 環境の準備についてはMicrosoft Learnにまとめられています。 本ブログ記事ではBicep拡張機能をインストールしたVisual Studio Codeを利用してBicepファイルを作成し、Azureへのサインインやデプロイの実行などにはAzure CLIを利用します。

また、本ブログ記事においてAzure CLIを実行する際はVisual Studio Codeの統合ターミナルを利用します。
　

初歩的なBicepファイルの作成と実行

まずはBicepファイルを作成します。 ここではmain.bicepというファイルを作成し、以下のような内容を記述しました。

resource azureOpenaiService 'Microsoft.CognitiveServices/accounts@2023-05-01' = {
  name: 'oai-jpe-20241108'
  location: 'japaneast'
  sku: {
    name: 'S0'
  }
  kind: 'OpenAI'
  properties: {
    customSubDomainName: 'oai-jpe-20241108'
    networkAcls: {
      defaultAction: 'Allow'
    }
    publicNetworkAccess: 'Enabled'
  }
}

今回記述した内容はAzure OpenAI Serviceリソースの定義です。 モデルのデプロイは含まれていません。 また、エンドポイントへのパブリックネットワーク経由のアクセスを許可する設定になっていますのでご留意ください。

本Bicepファイルの内容についてご説明しますと、冒頭の"resource"によりリソースの定義であることを示しており、その後ろにリソースのシンボリック名を記述します。 今回はシンボリック名を"azureOpenaiService"としています。 こちらはリソース名ではなく、Bicepファイル内の他の部分からこの定義を参照したいときにシンボリック名を使えるというものです。 その次にリソースの種類とAPIバージョンを指定します。さらにその次の= {}の部分では、括弧内でリソース名や場所などを指定しています。

resource <シンボリック名> '<リソースの種類>@<APIバージョン>' = {
  name: '<リソース名>'
    ...
}

リソースの種別やAPIバージョン、リソースのプロパティに関してはリファレンスで確認でき、先のBicepファイルで定義していた「Microsoft.CognitiveServices/accounts」のリファレンスはこちらです。

※リソースの種類の指定が"CognitiveServices"となっていますが、こちらはAzure AI Servicesの旧称です。

Visual Studio CodeのBicep拡張機能では以下のようにIntelliSenseで補完してもらうことも可能です。 より新しいAPIバージョンもありますが、今回はリファレンスに記載されている中で最新のバージョンにしました。

resourceの記述についてはMicrosoft Learnに記載があり、シンボリック名として利用できる文字などの説明もありますので併せてご参照ください。

Bicepファイルによるリソースの作成

まずは以下のコマンドでAzureにサインインします。使用しているAzure CLIのバージョンにもよりますが、サブスクリプションの選択が求められた場合はリソースデプロイ時に使うサブスクリプションを選択します。

az login

※サブスクリプションの選択が求められない場合は、以下のコマンドで使用するサブスクリプションを指定しておくことができます。

az account set --subscription <サブスクリプションID>

後続のコマンドでリソースグループの指定を省略できるように、利用するリソースグループを以下のコマンドで指定しておきます。(今回は「bicep-rg」というリソースグループを利用します。)

az configure --defaults group=<リソースグループ名>

以下のコマンドを実行し、Bicepファイルからリソースを作成します。

az deployment group create --template-file main.bicep

結果の確認

以下のコマンドで結果を確認できます。

az deployment group list --output table

Azure Portalでもデプロイを確認するとAzure OpenAI Serviceリソースのデプロイ完了を確認できます。

展開モード

Azure Resource Managerにはリソースの展開モードとして「完全」と「増分」が存在します。

完全モードでARMテンプレートを使用した場合、既存のリソースがテンプレートに記載されていないとそのリソースは削除されます。一方、増分モードでは、既存のリソースがテンプレートに含まれていなくてもそのまま残されます。 デフォルトのモードは増分です。

ここでは前述のBicepファイルを使用するにあたってモードを変えるとどうなるかを見てみたいと思います。 動作のご説明のため、先程と同じリソースグループ内にキーコンテナー(Azure Key Vault)を追加しておきました。
AzureではARMテンプレートやBicepファイルによって変更される内容を事前に確認することができます。 こちらは一般に「What-If操作」と呼ばれるものでAzure CLIで利用できるほか、Azure PowerShellやREST APIでも利用できます。特に完全モードはリソースが削除される可能性があるため、デプロイの前に必ずWhat-If 操作を行うことをおすすめいたします。

増分モード

まずは以下のコマンドを実行し、増分モードにおけるWhat-If操作の結果を見てみます。(増分モードがデフォルトですが、ここでは明示的にモードを指定しています。)

az deployment group what-if --mode Incremental --template-file main.bicep

赤枠部分をご覧いただくと、Azure OpenAI Serviceに関してはBicepファイルで定義されており設定内容の変更もないため"Nochange"(変更なし)という判定になっています。(行頭の"="がNochangeを示しています。) キーコンテナーに関してはBicepファイルに定義されていないため"Ignore"(無視)と判定されています。(行頭の"*"がIgnoreを示しています。) 変更の種類に関してはこちらをご参照ください。

完全モード

今度は完全モードでのWhat-If操作の結果を見てみます。

az deployment group what-if --mode Complete --template-file main.bicep

オレンジの文字で表示されている部分が、本Bicepファイルを使用することにより"Delete"(削除)されるリソースです。(行頭の"-"がDeleteを示しています。) Bicepファイルにはキーコンテナーの定義がされていないため、デプロイするとキーコンテナーが削除されてしまいます。 Azure OpenAI Serviceに関しては先程と同様に "Nochange"(変更なし)の判定です。

次に、以下のコマンドにより完全モードでデプロイしてみます。

az deployment group create --mode Complete --template-file main.bicep

結果を確認すると、対象のリソースグループにはBicepファイルで定義していたAzure OpenAI Serviceのみが残っており、キーコンテナーは消えています。

アクティビティログには"Delete Key Vault"のログが残っています。

今回の展開モードに関するご説明を簡単な図にしたものが以下です。 用途に応じて展開モードを使い分けていただければと思います。
　

まとめ

今回はBicepの基礎的な情報をご紹介しました。

利用したAzureリソースをBicepファイルにしておくと、環境の再現や繰り返しのデプロイが楽になります。 Azureでの開発や学習においては試行錯誤のためにリソースの作成と削除を何度も行うようなケースもあるでしょう。 インフラをコード化しておけばリソース再作成のハードルが下げられるかと思います。 また、再作成時の操作手順の誤りやコマンドの実行漏れなどを防ぐ効果も期待できます。

今回はBicepの簡単なサンプルをご紹介しましたが、こちらはごく初歩的な内容のため繰り返し利用するような場合など少し不便かもしれません。 より効率的な記述方法もありますので、また改めてご紹介できればと思います。

なお、BicepはAzure専用の言語ですのでMicrosoft Learnでトレーニング用のコンテンツも用意されています。 セルフペースで学べるようになっていますので、よろしければご活用ください。

Azureを取り扱われているパートナー企業様へ様々なご支援のメニューを用意しております。 メニューの詳細やAzureに関するご相談等につきましては以下の「Azure相談センター」をご確認ください。

Azure相談センター
https://licensecounter.jp/azure/

※ 本ブログ記事は弊社にて把握、確認された内容を基に作成したものであり、サービス・製品の動作や仕様について担保・保証するものではありません。サービス・製品の動作、仕様等に関しては、予告なく変更される場合があります。