FIXER Tech Blog - Development

FIXER cloud.config Tech Blog

null_resourceではなくazapi_resourceを使いましょう

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「まだnull_resourceでがんばっているの？」を再編集したものです。

※お詫びと訂正：本記事の初出時、タイトルと転載した本文内容が食い違っておりました。お詫びのうえ訂正いたします。（2023年1月12日 編集部）

こちらはFIXER Rookies Advent Calendar 2022の5日目の記事です。

みんな大好きAzureくん。

そんなAzureのリソースをTerraformでコード化する業務を普段行っているのですが、最近null_resourceで書かれたコードをazapi_resourceに書き換える機会が多かったためメモ代わりに共有していきたいと思います。

そもそもnull_resourceとは？

null_resourceを用いることにより、Providerが存在しない処理をTerraformで実行することができます。

しかしnull_resourceは名前の通りリソースが存在しないプロバイダーのため、tfstateを確認するとinstancesの中に処理の結果が記録されず、null_resourceと他のProvider間の依存関係をTerraformはサポートしません。

メリット

・Terraform上でリソースの作成 ＆+α が実現できる

・Terraformでサポートされていない処理を実装できる

デメリット

・コード間の依存関係を持つことが難しい

・内部の処理をtfstate上で確認することができず、デバッグ等が難しい

azapi_resourceで安心安全の処理を実現

そこでazapi_resourceをできる限り使いましょう。 これはAzure REST APIをTerraformで実行＆管理するProviderです。 先ほどnull_resourceで挙げた例をazapi_resourceで再現した場合、

tfstate上に処理の結果が記録されるため、azapi_resourceで実行したデータを他のProviderに反映することができ、依存関係をTerraformが保証するため、Azure RedHat OpenShiftやAzure Container Appsなど作成に時間がかかるリソースはazapi_resourceを活用した方が安全安心です。

メリット

・Azure Portalで実現可能な作業 ≒ Terraformで再現可能

・tfstate上に実行ログが残るため、デバッグ時に重宝する

・他のProviderと明確な依存関係を持つことができる

デメリット

ignore_changesでフィールド名を個別に宣言することができず、bodyしか宣言できない。

まとめ

azapi_resourceを使うことにより、依存関係がはっきりしたコードを書くことができるため、できる限りnull_resourceで「えいや～～～」っとコードを書かないようにしましょう。 また筆者は最近Terraformの限界を感じ始めたので、「Azure SDK for GoでIaCを実現した方がリソースの作成+αが簡単にできて便利なのでは？？？」と模索しています。

西村 凌／FIXER
インフラエンジニア1年生

[転載元]
　まだnull_resourceでがんばっているの？

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER