タイトルの通りですが、セキュリティ保護のためネットワーク制限をしたストレージアカウントを使用して Azure Functions (Function App) を「新規」に展開する場合の注意点として気づいた内容となります。
Archive for the ‘Azure’ Category
追加 BLOB の Azure Blob バックアップの制限について
Azure ストレージでは、ブロック BLOB / 追加 BLOB / ページ BLOB の 3 種類の BLOB を使用することができます。
SQL Database の監査ログ / 診断設定 / アクティビティログ / Azure Monitor のテーブルエクスポートのログなどは「追加 BLOB」としてファイルが出力されていますが、追加 BLOB については、Azure Blob バックアップの取得対象とならないという制限がありますので、情報をまとめておきたいと思います
今回は追加 BLOB のバックアップの制限についての情報の整理となりますが追加 BLOB では、階層化 (ホット / クール / コールド層への移動) がサポートされていない という制限もありますので、追加 BLOB を使用した場合はブロック BLOB とは異なる運用が必要となるということは意識しておいたほうが良いかと思います。
OsProfile を使用した Windows の Azure VM のタイムゾーン設定
以前 osProfile が存在しない Windows の Azure VM の修正方法 という投稿をしましたが、Azure VM では OsProfile を設定することで、VM の展開時に OS の設定を変更することができる仕組みが提供されています。
PowerShell で実行する場合は、New-AzVMConfig を使用して、OSProfile プロパティを操作することになるのかと。
Windows の VM を Azure で展開する場合、カスタマイズしたイメージを作成する場合、イメージのカスタマイズを実施して イメージ作成前に VM をプロビジョニング解除または一般化し、マシン固有の情報を削除します の方法でイメージ化するのが一般的な方法となります。
日本で VM のイメージを作成する場合、日本語化の設定 を行った状態でイメージ化して、展開を行いますが、このイメージを単純に展開すると、イメージ化する前に日本語のタイムゾーンに設定をしていても展開時には UTC のタイムゾーンとなり展開が行われます。
イメージを展開した直後に任意のタイムゾーンを設定した状態にしたい場合には、前述の OsProfile の WindowsConfiguration の TimeZone を使用することで、UTC 以外のタイムゾーンを設定した状態で展開することができます。
診断設定と Log Analytics ワークスペースの AzureDiagnostics テーブルについて
Azure のリソースで診断設定で Log Analytics ワークスペースにログを格納すると「AzureDiagnostics」テーブルに対してログの取得が行われることがあります。
この AzureDiagnostics テーブルについての理解度が低かったので一度整理してみました。
Microsoft Copilot skills in Azure SQL Database を使用したデータベースの稼働状況の調査について
Microsoft Copilot in Azure では、SQL Database 向けのスキルが組み込まれており、Azure ポータルから Copilot で、データベース向けの質問をチャットすることで、SQL Database に特化した回答を得ることができます。
大きなカテゴリとして、次の二つの機能があり、データベースの稼働状況の調査を行う場合には「1.」を活用することになります。
- Microsoft Copilot in Azure 統合
- 自然言語からの SQL 生成
この機能を活用すると、次の画像のように実際のデータベースの稼働状況に応じた回答が生成されます。
この機能がどのようにして動作しているのかが気になったので少し調べてみました。
この機能については Microsoft Copilot in Azure と SQL Database で公開されている記事も参考となります。
osProfile が存在しない Windows の Azure VM の修正方法
Azyre VM の構成情報には osProfile という設定があります。Windows の場合、osProfile 配下の windowsConfiguration にパッチの自動適用の設定が登録されています。
Azure VM のブレードでは JSON ビューというリンクがあります。
このリンクをクリックすると、osProfile の設定を確認することができ、Marketplace で登録されている標準の Windows イメージで展開した Azure VM であれば基本的にはこの設定が含まれている状態となっています。
しかし、enable for existing vms? #62655 のように、VM に対してパッチ関連の設定を変更しようとすると「Couldn't find 'windowsConfiguration' in 'osProfile'. 'osProfile' does not support further indexing.」が発生するケースがあります。
このエラーが発生する VM では、JSON を確認すると、上述の osProfile が存在しない状態となっています。
Bicep の Tips (2024/07 版)
直近で 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 の診断設定のカテゴリ グループとカテゴリ
Azure ではリソースに対して 診断設定 を実施することで、リソースに対しての各種情報を指定した宛先に保存することができます。
取得する項目の取得については、カテゴリ グループとカテゴリを使用して選択することができるのですが、この設定について、いくつか理解度が低いところがあり、改めて情報を確認した内容についてまとめておきたいと思います。
Bicep を使用して異なるモジュールで作成したリソースをシンボリック名として利用する
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 で公開しています。
今回は作成したストレージアカウントに対して、診断設定を行うというシナリオを検討しています。