Zenn
🎼

[Azure] Terraform or Bicep を考えてみた

2024/09/07に公開
Azure
Terraform
IaC
Bicep
tech

最近は関わる案件の多くで IaC を前提とすることが多くなってきました。

Azure においては、主に Terraform と Bicep という選択肢があると思うのですが、改めて自分なりにどちらを使うと良さそうか考えてみたので、残しておこうと思います。

1. それぞれのメリット／デメリット

「👍️」は特に良いと感じる点、「🤯」は特に辛いと感じる点です。

Terraform のメリット

  1. 👍️マルチクラウド対応: Azure だけでなく、AWS, GCP などのクラウドプロバイダに対応しているため、異なるクラウド環境で一貫した管理が可能。
  2. 大規模なエコシステム: Terraform には多くのプロバイダとモジュールが存在し、広範なコミュニティサポートがある。
  3. 成熟したツール: 長く利用されているため、ドキュメントが充実しており、企業での導入事例やベストプラクティスも多い。
  4. プランニング機能: terraform plan コマンドにより、適用前に変更内容を確認することができる。
  5. 👍️状態管理: 状態ファイル (state file) を用いて、現在のインフラ状態を管理し、差分を検出する機能が強力。

Terraform のデメリット

  1. 追加のセットアップ: 初期セットアップや状態管理のために、リモートバックエンドや状態ファイルの設定が必要。
  2. 学習曲線: HCL (HashiCorp Configuration Language) を学習する必要がある。
  3. 🤯リソースの整合性問題: 状態ファイルの不整合が発生した場合、修復が難しい場合がある。
  4. 更新のタイミング: Azure の新サービスに対応するプロバイダの更新が、Bicep に比べると遅れることがある。(※)
  5. 外部依存: HashiCorp のプロバイダと一部のサービスに依存するため、ツール自体が外部の開発企業に依存している。

Bicep のメリット

  1. 👍️Azureネイティブ: Microsoft の Azure に特化して設計されているため、Azure リソースに対するサポートが充実。
  2. シンプルな構文: ARM Template の複雑さを簡略化したシンプルな構文であり、学習が比較的容易。
  3. 👍️迅速な更新: Azure の新サービスやリソースは、Bicep の方がサポートされるのが早い。(※)
  4. 無料かつオープンソース: 追加コストがかからず、誰でも利用できる。
  5. シームレスな統合: Azure DevOps や Azure Resource Manager とのシームレスな統合が可能。

Bicep のデメリット

  1. 単一クラウド限定: Azure に特化しているため、他のクラウドプロバイダには対応していない。
  2. 若いツール: Terraform に比べ成熟度が低く、エコシステムやコミュニティサポートがまだ不足している。
  3. 🤯状態管理の欠如: Terraform のような状態ファイルによる差分管理機能がない。
  4. エコシステムの小ささ: モジュールやサードパーティツールの数が少ない。
  5. 依存パッケージの少なさ: 既存の再利用可能なモジュールの数が少ないため、独自の定義が必要な場合が多い。

2. 「状態管理」の有無は良し悪し

Terraform では、状態ファイルを利用することで状態管理ができます。それにより、「IaC コードと、現在の実環境のデプロイ状況の差異」を簡単に確認することができます。

これは、継続して IaC コードを育てながら実環境も適応させていくのに便利です。最初にランダム文字列を生成する関数を使って作成したリソースであっても、状態ファイルの取り回しさえ間違えなければ、同じ文字列を使い続けてくれます。

一方、Bicep は状態を持ちません。以前にデプロイした状況は知らぬ存ぜぬであり、「増分モード」と「完全モード」というデプロイモードを選びつつなんとかします。

「IaC コードと、実環境は一致させたい」のであれば、「完全デプロイモード」を使うことになりますが、それでも削除しきれないなど完全には一致しないケースがあります。この点については、「デプロイスタック」などの仕組みもできてきており、今後改善されていくかもしれません。

状態 (状態ファイル) を持たないため、「別端末で実行するにあたり、状態ファイルをどうやって共有するか…」とか「状態ファイルが壊れたっぽいけどどうするか…」といったことを考えなくて済みます。その意味では楽です。

個人的には、小さめの環境であったり、ラボ環境など比較的イミュータブル・新機能も使う環境であれば、Terraform をインストールしなくて良い Bicep が取り回しやすく、ガッツリ IaC として運用するなら、Terraform の方がデファクトの学習という意味でも得られるものは多いかなぁと感じています。

3. Bicep はランダム文字列生成にクセがある

Terraform は Random Provider を活用することで簡単にランダム文字列を生成できます。そして、前述の通り状態ファイルさえ残っていれば、次回実行時も同じ文字列を使ってリソースを更新したりすることが可能です。

Bicep はランダム文字列を生成する関数がありません。代替手段として、リソースグループの ID など、生成する文字列を一意にしたいスコープにあたる文字列にハッシュ関数 (uniqueString) を適用し、必要に応じて短くしたりします。

同一スコープ内であれば次回実行時も同じ文字列になってくれます。が、例えば二個のリソースを作成したい場合、uniqueString(resourceGroup().id) だけだと一個目のリソースも二個目のリソースも同じ文字列になってしまうため、生成した文字列を更に加工する工夫が必要です。

どうしてもランダム文字列を使いたい場合は、時刻文字列 (utcNow) の結果をハッシュ関数にかける方法を使います。

時刻を用いたランダム文字列を生成して使うと、次回の実行ではまず同一の文字列にはならないですし、状態を持っていないので同じ文字列を取る手段が無いため、リソースが再作成されることになる点には注意が必要です。

4. 以上を踏まえて

これらの特徴を踏まえ、記事公開時点の認識としては下記のように捉えています。

  • マルチクラウド利用 / Terraform に慣れている or 慣れたい、なら Terraform
  • Azure Only で今から学習する / Microsoft サポートに頼りたい / 新機能を結構頻繁に試す、なら Bicep

そして、どちらかの経験があるものの別の方を採用する場合は、上述の通り状態管理に対する考え方の違いに注意しておきましょう！

Discussion