Azure ではリソースに対して 診断設定 を実施することで、リソースに対しての各種情報を指定した宛先に保存することができます。
取得する項目の取得については、カテゴリ グループとカテゴリを使用して選択することができるのですが、この設定について、いくつか理解度が低いところがあり、改めて情報を確認した内容についてまとめておきたいと思います。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Azure ではリソースに対して 診断設定 を実施することで、リソースに対しての各種情報を指定した宛先に保存することができます。
取得する項目の取得については、カテゴリ グループとカテゴリを使用して選択することができるのですが、この設定について、いくつか理解度が低いところがあり、改めて情報を確認した内容についてまとめておきたいと思います。
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 の診断設定について調べておく必要があったので、メモを残しておきたいと思います。
データ収集ルール (DCR) を使用した情報の取得を検討する必要があり、基本となる情報は次のドキュメントの内容となります。
先日、Azure の 既定の送信アクセス廃止後の KMS によるライセンス認証について (2024/06/19 時点の動作) という投稿を書きました。
廃止予定の機能のアナウンスは Azure updates で実施されていますが、他にどのような方法があるのかが気にかかりましたので調べてみました。
※2024/06 時点の情報 / 環境で確認をしているため、今後動作は変わっている可能性があります。
2023/09/29 に Default outbound access for VMs in Azure will be retired? transition to a new method of internet access というアナウンスがありました。(2023/10/19 に Default outbound access for VMs in Azure will be retired? updates and more information 追加情報のアナウンスが行われています)
現状は、既定の送信アクセス が有効となっているため、明示的なインターネット送信接続の設定が行われていない場合、「既定の送信パブリック IP アドレス」が割り当てられ、インターネットへの送信接続が可能となっています。
2025/09/30 以降に新しくデプロイされたリソースについてはこの既定の送信アクセスが廃止され、これ以降にデプロイした VM については、既定の送信アクセス以外の方法 (パブリック IP アドレスの付与 / NAT ゲートウェイをサブネットに割り当て / パブリック IP アドレスを持つロードバランサーに割り当て) でインターネット送信接続の経路を確保する必要があります。
(期限日以降に展開した VM と VNET のどちらが対象となるのかが判断できていないため「リソース」という記載をしています)
今まで既定の送信アクセスを使用して、Windows のライセンス認証のための KMS にアクセスしていた VM について、既定の送信アクセスが廃止された後はどのような挙動になるのかが気になり試してみました。
Azure では、Marketplace から SQL Server インストール済みの VM イメージが公開されており、Azure VM で SQL Server を使用する場合は、このイメージで展開して PAYG で利用するのが一般的かと思います。
イメージは英語版を使用して構築されているため、日本語化する場合には、当ブログで書いた SQL Server on Azure VM (インストール済みイメージ) の日本語化 (2021/1 版) の方法や、SQL Server Support Blog で公開されている次の記事の対応を行う必要があります。
基本的な作業としては、次の流れとなるのではないでしょうか。
基本的な作業の流れとしてはこのようになりますが、この手順だけでは、VM の展開時に指定した SQL Server 構成の設定はクリアされた状態となってしまっています。
展開時に指定した内容と同等の設定で IaaS Agent を導入するためには、New-AzSqlVM で様々なオプションを指定して再導入をする必要があるのですが、オプションを一つ一つ設定するのは手間がかかるため、今回はその設定を Bicep で実施してしまおうというのが今回の趣旨となります。
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」から取得しているのですが、プロキシなどが入っている環境ではこの情報を取得する際にエラーが発生するようです。
Azure のハブアンドスポーク構成のネットワークの基本的な構成については次のドキュメントで解説が行われています。
ハブアンドスポーク構成の場合、ハブ間のネットワークは非推移的 (non-transitive) のため、ハブ間の直接通信はできません。
ハブ間で通信を行う場合、Azure Firewall / Network Virtual Appliance (NVA) / Virtual Network Manager をハブサイトに配置して、ネットワーク間の接続を行うという構成をとることがあるかと思います。
運用に関連するネットワークとして利用するために、高品質なネットワーク構成 / 管理 / 監視を実現するためには、これらの機能 / リソースを使用したほうが良いかと思います。
Azure Firewall をハブサイトに配置しなくても、Virtual Network Manager を使用することで、ハブ間の接続を容易に設定 / 管理できる状態にしておくことができますが、月額 1 万円程度はかかりますので、個人的な検証目的で常時設定を行っておくと、発生するコストも無視ができなくなってきます。
検証目的でシンプルなハブアンドスポーク構成でスポーク間の接続ができればよいというのであれば、Use Azure VPN Gateway To Route Traffic Between Spoke Networks に記載されているような設定を行うことで、ハブサイトとスポークサイトを VNet ピアリングとルートテーブル (UDR: ユーザー定義ルート) の設定でスポーク間の通信を実現することもできます。
Azure Disk Encrption – Key vault secret wrap with key encryption key failed に記載されている内容となります。
OS のイメージとして、Windows Server 2022 (Azure Edition 含む) を使用している環境に対して、Azure Disk Encryption を有効化すると、暗号化に使用されている拡張機能 (AzureDiskEncryption) のインストールで、次のようなエラーが発生し拡張機能のインストールが失敗することがあります。
{"customHtml":{"htmlTemplate":"<code><div><div>拡張機能 ‘AzureDiskEncryption’ (発行元 ‘Microsoft.Azure.Security’ および種類 ‘AzureDiskEncryption’) の処理中に VM から失敗が報告されました。エラー メッセージ: ‘[2.4.0.21] Failed to enable Azure Disk Encryption on the VM with the following exception details:\n Microsoft.Cis.Security.BitLocker.BitlockerIaasVMExtension.BitlockerFailedToSendEncryptionSettingsException: The fault reason was: ‘ 0xc142506f RUNTIME_E_KEYVAULT_SECRET_WRAP_WITH_KEK_FAILED Key vault secret wrap with key encryption key failed. ‘.\r\n at Microsoft.Cis.Security.BitLocker.BitlockerIaasVMExtension.WireProtocol.WireProtocolMessage.SendEncryptionSettingsToHost() in C:\\__w\\1\\s\\src\\BitLocker\\BitlockerIaasVMExtension\\WireProtocol\\WireProtocolMessage.cs:line 210\r\n at Microsoft.Cis.Security.BitLocker.BitlockerIaasVMExtension.BitlockerExtension.SendEncryptionSettingsToHostV3(VmEncryptionSettings vmSettings) in C:\\__w\\1\\s\\src\\BitLocker\\BitlockerIaasVMExtension\\BitlockerExtension.cs:line 1092’。トラブルシューティングの詳細については、<a target=\"_blank\" class=\"msportalfx-ext-link\" href=\"https://aka.ms/VMExtensionADEWindowsTroubleshoot\">https://aka.ms/VMExtensionADEWindowsTroubleshoot</a> を参照してください。 </div></div></code>","viewModel":null}}