SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
直近で Bicep を使用する機会があったのですが、その際に得られた知見についてまとめておきたいと思います。
Bicep と書いていますが、ARM でも共通する内容となるかと思います。
2024/07/29 追記
本投稿について X でコメントをいただいていたので、そちらを追記させていただきました。
素晴らしいbicepの記事を発見、いくつかコメントhttps://t.co/7ObOpZoRXb
— OMI Takekazu (@takekazuomi) July 28, 2024
miteta // Bicep の Tips (2024/07 版) at SE の雑記https://t.co/u1B3Yyp5lH
— guitarrapc_tech (@guitarrapc_tech) July 28, 2024
Azure ストレージには静的な Web サイトの機能があり、静的コンテンツを Azure ストレージで公開する際に活用することができます。
この機能を Bicep で有効にしようとしたのですが、Bicep の定義として設定する機能が提供されていませんでした。
実施した対応としては Storage Account – Enable Static web site #10337 と同じですが、現状は deploymentSciprts で対応をする必要があるようですね。
Azure の Data Factory / Synapse / Data Explorer といったリソースでは、マネージド仮想ネットワーク内にプライベートエンドポイントを作成することができる、「マネージドプライベートエンドポイント」というリソースを作成することができます。
通常のプライベートエンドポイントは、仮想ネットワーク内に展開を行います。
しかし、上述のリソースは仮想ネットワーク内に展開することができないのですが、このようなリソースで、使用できるプライベートエンドポイントを作成する方法として、マネージドプライベートエンドポイントという機能が提供されています。
マネージドプライベートエンドポイントを作成することで、セキュリティで保護されている特定のリソースへのアクセスポイントを、仮想ネットワーク内に展開することができないリソースでも作成することができます。
Synapse についてはドキュメントが見つからなかったのですが、ADF と ADX については、マネージドプライベートエンドポイントをBicep で作成することが可能となっています。
マネージドプライベートエンドポイントを作成する場合は、上述のキュメントの内容で Bicep を作成すればよいのですが、作成したエンドポイントの承認まで Bicep で実施しようとすると少し手間がかかったので、本投稿で承認をした際の内容をまとめておこうと思います。
今回はストレージアカウントの BLOB に対してプライベートエンドポイントを作成することを想定しています。
作成したサンプルについては https://github.com/MasayukiOzawa/bicep-sample/tree/main/managed-private-endpoint に置いてあります。
Bicep を使用して、Azure リソースの設定を行う際に、scope / parent で 拡張リソース を使用することで、設定を行うというケースがあります。
これらの属性にリソースを設定する際には、リソースの ID / 名称ではなく、Bicep 内で定義しているリソースのシンボリック名を指定する必要があります。
実際の設定例としては、診断設定のリソースとなる Microsoft.Insights/diagnosticSettings があります。
このリソースは Azure の「診断設定」を行うためのリソース定義となりますが、「どのリソースに対して診断設定を行うか」については、「scope」に対して、「resourceSymbolicName」を指定する必要があります。
Azure ストレージを例とすると、ストレージアカウントを作成するための Microsoft.Storage/storageAccounts の Bicep 内で診断設定を実施するのであれば、同一のファイル内にストレージアカウントを作成する定義があるため、ストレージ対しての診断設定のためのシンボリック名を指定することは容易です。
診断設定は様々なリソースに対して設定が可能なため「診断設定をまとめたモジュールを作成したい」というような場合には、診断設定を行うための Bicep のファイル内でシンボリック名を定義する必要があるのではないでしょうか。
本投稿では、異なるモジュールで定義されたリソースを、シンボリック名として作成するための方法について考えてみたいと思います。
サンプルとして作成した Bicep ファイルについては https://github.com/MasayukiOzawa/bicep-sample/tree/main/diagSetting で公開しています。
今回は作成したストレージアカウントに対して、診断設定を行うというシナリオを検討しています。
Azure のリソース名のルールとして、次のようなドキュメントが公開されています。
Azure Portal から VM を展開した場合、VM のリソース名が展開後の VM のホスト名として設定されますが、Windows ではコンピューター名の上限が 15 文字となっています。
はい。 コンピューター名は最大 15 文字の長さまで指定できます。 リソースの名前付けの詳細については、名前付け規則と制約事項に関する記事を参照してください。
1-15 (Windows)
1-64 (Linux)
下記の「注意」を参照。Azure 仮想マシンには、リソース名とホスト名の 2 つの異なる名前があります。 ポータルで仮想マシンを作成すると、両方の名前に同じ値が使用されます。 前の表に記載されている制限事項は、ホスト名に適用されます。 実際のリソース名の最大文字数は 64 文字です。
Windows の場合、15 文字の制限があるため、15 文字を超えるリソース名を設定した場合は 15 文字に省略されてホスト名が設定されます。
名前付け規則を定義する の案として次のような形式が提示されていますが、VM のリソース名でこのルールを適用した場合、15 文字の制限に達する可能性があるのではないでしょうか。
展開後に、ホスト名を表示および変更する の方法で変更することもできるのですが、本投稿では展開時に任意のホスト名を設定した状態で展開をしてみます。
事象としては、az bicep install error #25471 となりますが、Bicep を使用するために「az bicep install」を実行すると、ネットワーク環境によっては次のようなエラーが発生することがあります。
Error while attempting to retrieve the latest Bicep version: HTTPSConnectionPool(host=’aka.ms’, port=443): Max retries exceeded with url: /BicepLatestRelease (Caused by SSLError(SSLCertVerificationError(1, ‘[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1006)’))).
Bicep のインストールを実施する際には、最新の情報を「https://aka.ms/BicepLatestRelease」から取得しているのですが、プロキシなどが入っている環境ではこの情報を取得する際にエラーが発生するようです。
