ARMテンプレートは過去の遺物？使って感じたAzure Bicepの優れていること【ITエンジニアの腕の見せ所💪】

最近、周りで筋トレをする人が本当に多いんです。
同期の中には、ベンチプレス140kgを挙げられると豪語するゴリマッチョや、フィジーク大会に出場する本格派まで現れる始末。
ついには、私の母までちょこっと筋トレできるライトなジムに通い始めてしまいました。

そんな筋トレブームを横目に、私が力を入れているのが「Azure Bicep」です。
IaCを用いた強靭で美しい環境を作り上げることに情熱を燃やしています！

Bicepとは
ポータル操作と比較した利点
ARMテンプレートと比較
1. コードを比較して分かること
Bicepでストレージをデプロイしてみる
さいごに

Bicepとは

Bicepを和訳すると上腕二頭筋になります。いわゆる力こぶ💪のことです。
bicepの意味・使い方・読み方 | Weblio英和辞書

なぜ力こぶ？名前の由来が気になります。
元々Azureでは腕のアーム（ARM：Azure Resource Manager）がインフラ構築する際のテンプレートとして利用されていたが、これからは力こぶでさらにパワーを強調するぞ！！などと開発者は考えたのかもと想像してしまいます。
真相は定かではありませんが、コードでインフラを構築する力強さを表現していると感じています。

JSON形式のARMテンプレートは記述が冗長になりやすく、可読性も低い課題がありました。
そこで開発されたのがBicepです。ARMテンプレートをよりシンプルに、より直感的に記述できるように設計されたDSL（ドメイン固有言語）なのです。

Bicep とは - Azure Resource Manager

インフラストラクチャを Azure にデプロイするための Bicep 言語を理解します。 JSON を使用してテンプレートを開発する場合に比べてオーサリングがしやすくなります。

ポータル操作と比較した利点

Bicepに限らずですが、私が感じたIaCの利点はミスなし、複製よし、の2点です。

ミスなし：ヒューマンエラーの抑制
ポータル上をポチポチしながら構築すると、どうしてもミスが発生します。
設定漏れや間違った項目の選択など色々な事象が起き得ます。
IaC なら「一度正しい設定をコード化すれば、後は何度デプロイしても同じ構成が再現される」という特徴があるので、人間の手による作業が減る分の品質向上に寄与できるのです。
複製よし：リソースの複製が簡単
実際の案件では、同じような設定のリソースを何度も作成する必要があります。
仮想マシン2台、ストレージ1台、データベース1台、…みたいな少量だけ作成することはあり得ないですよね。
同じような設定のコードをコピーしてパラメータを変更すれば、瞬時にリソースを複製できます。
私が災対環境構築に携わった際も、本番環境の Bicep コードを流用することでスムーズに構築できました。

ただしデメリットもあります。それは学習コストが高いこと。
ツールの設定や記述方法などに慣れる必要があり、初学者だと厳しいところがあります。
公式ドキュメント見ながらコード記述するのは、私もかなり骨が折れました。

Azure リソースリファレンス - Bicep, ARM template & Terraform AzAPI reference

Bicep、Azure Resource Manager テンプレート、Terraform AzAPI プロバイダーを使用してリソースをデプロイするためのリファレンスドキュメントを参照してください。すべてのリソースの種類を表示します。

また私の案件では、災対切り替えを行うのは私ではなく運用チームです。
その際にBicepでやるのは難しいので、ポータル操作で対応するとの噂を聞きました。
ちょっと悲しいですが、災対切り替えがスムーズに行えない可能性を考えればしょうがないかもと考えています。

ARMテンプレートと比較

Bicep が ARM テンプレートよりも優れている点は、その可読性と記述の容易さにあります。具体的にコードを比較してみましょう。
今回は、以下の要件でストレージアカウントを作成する場合を例に、Bicep と ARM テンプレートのコードを比較します。

要件のパラメータ

名前：sttomioka88
リージョン：東日本リージョン
SKU：Standard_LRS
ストレージの種類：StorageV2
アクセス層：Hot

Bicepのコード

param location string = 'japaneast'
param storageAccountName string = 'sttomioka88'
resource storageAccount 'Microsoft.Storage/storageAccounts@2024-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

ARMテンプレート（JSON）のコード

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "defaultValue": "japaneast"
    },
    "storageAccountName": {
      "type": "string",
      "defaultValue": "sttomioka88"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2024-01-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "properties": {
        "accessTier": "Hot"
      }
    }
  ]
}

コードを比較して分かること

直感的な構文
Bicep ではパラメータの参照に”[parameters(‘storageAccountName’)]”のような式を使う必要がありません。
paramで指定した値を直接参照できるのです。そのためコードの可読性が向上してます。
ちなみに.bicepparamファイルを作れば、パラメータの管理もさらに綺麗になります。案件でもこの運用をしてました。

ネスト構造の簡略化
Bicep ではリソースのプロパティをネスト構造で記述する必要がなくなり、より容易な構造で記述できます。
カッコが無い分コードの見通しが良くなります。
そもそもJSON形式にカッコが多すぎますので、本当にあって良かったBicep。

これらの違いによりBicep を使うことで、ARM テンプレートよりも短時間で簡単にインフラをコード化することができます。
次のセクションでは、実際に Bicep を使ってストレージを作成してみますね。