Bicep で App Configuration の接続文字列を取得する

Bicep 上で、App Configuration の接続文字列が欲しい時があったので、備忘録として残します。

やってみる

次のような Bicep を書けば取得できます。

なんでこうなるの

App Configuration を listKeys() すると、実体は次のような構造の json になっているので、filter 関数で、キーをフィルターして最初のモノを取得すると接続文字列が取得できます。

{
  "value": [
    {
      "id": "abcdefg123456789",
      "name": "Primary",
      "value": "000000000000000000000000000000000000000000000000000000",
      "connectionString": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "lastModified": "2023-06-06T00:00:00+00:00",
      "readOnly": false
    },
    {
      "id": "abcdefg1234567891",
      "name": "Secondary",
      "value": "000000000000000000000000000000000000000000000000000000",
      "connectionString": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "lastModified": "2023-06-06T00:00:00+00:00",
      "readOnly": false
    },
    {
      "id": "abcdefg1234567892",
      "name": "Primary Read Only",
      "value": "000000000000000000000000000000000000000000000000000000",
      "connectionString": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "lastModified": "2023-06-06T00:00:00+00:00",
      "readOnly": true
    },
    {
      "id": "abcdefg1234567893",
      "name": "Secondary Read Only",
      "value": "000000000000000000000000000000000000000000000000000000",
      "connectionString": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "lastModified": "2023-06-06T00:00:00+00:00",
      "readOnly": true
    }
  ]
}

注意点

取得した接続文字列を output で返そうとすると、ログに接続文字列が露出するので、絶対にやめましょう。

現在、output で secure string を扱えるように対応が進んでるはずなので、その対応が終わるまでは、絶対に output しないようにしましょう。

まとめ

接続文字列が必要な場合は、これで対応できました。

が、お遊びやミニマムなテスト環境以外で利用する場合は、普通に Managed Identity を利用しましょう。

Azure Blob Storage に配置されたファイルを SQL Database に Bulk Insert する

業務システムなどで、 Blob に CSV が配置されていて、そのファイルの内容を DB に Bulk Insert したいといった要望は、比較的あるあるかと思います。

ファイルサイズが小さければどうとでもなるのですが、それなりにサイズの大きなファイルですと、ちまちまインサートするとそれだけで日が暮れてしまうので、 SQL Database (SQL server)の機能を頑張って使って、あれこれやった備忘録を残します。

今回の動機

今まで、Azure Functions の Blob トリガーでファイルの配置を検知し、PowerShell Function から BCP コマンドを流したりして頑張っていました。

ですが、ここ半年ほど不可解な挙動をするようになり(流したいコマンドをまとめたファイルが、不定期に読み込みに失敗する等)ちょっと運用が辛い問題がありました。

そこで、そういう問題が極力減るように、SQL Server 側でファイルを読み込み、C# の Function App でトリガーだけする方式に切り替えようとしたためです。

SQL Server から Blob へアクセスできるようにする

マスターキーを作成する

まず初めに、SQL Database でデータベースマスターキーを作成していない方は、次のようにマスターキーを作成します。

CREATE MASTER KEY ENCRYPTION BY PASSWORD='{Your Password}'

データベース資格情報を作成する

次に Blob のコンテナにアクセスするための資格情報を作成します。

資格情報の作成には、SAS が必要なので、Storage Explorer なり、ポータルなりで SAS を生成してください。

SAS がある人は、次の SQL を実行します。

CREATE DATABASE SCOPED CREDENTIAL [{Your Credential Name}]
WITH IDENTITY = 'Shared Access Signature',
SECRET = '{Your SAS}'

• Your Credential Name : 資格情報名(コンテナの URL とかにしておくと分かりやすい気がします。)
• Your SAS : sv ~ から始まる SAS を指定します。ポータルなどでコピーしてくると先頭に ? が付いてくるかもしれないので、それは削除しましょう

この SQL が成功したら、次の SQL を実行して、実際に登録されているか確認します。

SELECT * FROM sys.[database_scoped_credentials]

name が先ほどの資格情報名のモノが出てきたら成功です。

外部ソースを設定する

最後に外部ソースとして、コンテナを登録します。

次の SQL を実行します。

CREATE EXTERNAL DATA SOURCE [{Your External Source Name}]
WITH(
    TYPE = BLOB_STORAGE,
    LOCATION = '{Your Blob Url}',
    CREDENTIAL = [Your Credential Name]
)

• Your External Source Name : 外部ソース名です。SQL からこの外部ソースを参照する場合に指定するモノなので、分かりやすいものを付けましょう。
• Your Blob Url : Blob ストレージの URL を指定します。(https://{ストレージアカウント名}.blob.core.windows.net)
• Your Credential Name : 使用するデータベース資格情報名を指定します。

この SQL が成功したら、次の SQL を実行します。

name が先ほどの外部ソース名のモノが出てきたら、成功です。

SELECT * FROM sys.[external_data_sources]

実際に Bulk Insert してみる

事前に Insert したいテーブルなどは準備しておきましょう

次のような SQL で利用できます。

BULK INSERT {Your Table Name}
FROM '{Your Container Name}/{Blob Name}'
WITH 
(
    DATA_SOURCE = '{Your External Source Name}'
    , CODEPAGE = '65001'
    , FORMAT = 'CSV'
    , ROWTERMINATOR = '0x0a'
)

• Your Table Name : Insert したいテーブル名
• Your Container Name : 対象のコンテナ名
• Blob Name : コンテナに配置されている Blob 名
• Your External Source Name : 先ほど作成した外部ソース名

その他の設定としては、コードページが 65001、フォーマットが CSV、改行が 0x0a のファイルという情報を与えています。

細かいパラメータは、公式ドキュメントをご参照ください。

learn.microsoft.com

まとめ

これで、資格情報等は全て SQL Server 側に保持され、SQL さえ呼び出せれば、処理は全て SQL Server 側で行ってくれるようになります。

次回は、Azure Functions と組み合わせた例をまとめます。(気が向いたら)

bicep の新しいパラメータファイル .bicepparam について

Bicep をデプロイする際、通常では、外部から注入したいパラメータを ARM Template と同様の json ファイルを利用していますが、 今後新しく、.bicepparam という形式が利用可能になります。

恐らく、今後はこちらが主流になっていくと思われるので、簡単に概要をまとめます。

前提条件

今回は、次の環境を基に記載します。

• Azure CLI : v2.48.1
• Bicep : v0.17.1

事前準備

.bicepparam は、Bicep 0.17.1 では、Experimental features に該当する為、利用する場合、 bicepconfig.json が必要です。

ミニマムなファイルは次の通りです。

{
    "experimentalFeaturesEnabled": {
        "paramsFiles": true
    }
}

このファイルを main.bicep と同じフォルダに配置します。

App Service をデプロイしてみる

Bicep の準備

シンプルな App Service のデプロイで使い方を見ていきます。

App Service をデプロイする為の Bicep は、次の通りです。

param location string = resourceGroup().location

var suffix = guid('guid')

resource plan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'plan-demo-lab-${suffix}'
  location: location
  kind: 'app'
  sku: {
    name: 'B1'
  }
}

resource app 'Microsoft.Web/sites@2022-03-01' = {
  name: 'app-demo-lab-${suffix}'
  location: location
  kind: 'app'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: plan.id
  }
}

パラメータとして、location を受け取れるようになっています。

これを、main.bicep として保存します。

次に、パラメータファイルを作成します。

内容は、次の通りです。

using 'main.bicep'

param location = 'japaneast'

using 文に、利用したい bicep ファイルを指定します。

今回は、main.bicep です。

次に、bicep のように param {パラメータ名} = {値} として、値を渡します。

パラメータを渡す対象を using 文で読み込んでいる為、パラメータは、intellisense が利用できます。

このファイルを param.bicepparam として保存します。

デプロイする

後は、通常の Bicep と同じようにデプロイします。

az deployment group create -f main.bicep -g {リソースグループ名} -p param.bicepparam

想定通りならば、通常の json ファイルと同じようにデプロイ出来ます。

まとめ

parameter.json は、記述量も多いですし、intellisense も利用できない為、あまり使い勝手が良くありませんでしたが、今後はシンプルな方向に倒れるという事で、より使いやすくなるかと思います。

この機能は、6/1 リリース予定の bicep 0.18 で正式に搭載予定なので、今のうちに覚えておくと良いかもしれません。

dotnet コマンドの nuget ソースから特定のソースを除外したい

dotnet コマンドでリストア処理が走る際に、nuget のソースから特定のソースを除外したい場合が稀にあると思います。

例えば、普段は社内向けのクローズドな NuGet サーバをソースとして設定しているけど、今回はそのソースを参照したくないといった場合です。

nuget.config を書いてもいいんですが、わざわざファイルを用意するよりは、コマンドで済ませたいという場合もあると思います。(というかあった)

ので、備忘録として残します。

現在設定されているソースを確認する

次のコマンドで現在 dotnet コマンドが利用する NuGet サーバのソースが一覧できます。

dotnet nuget list source

出力結果に Enabled とついているものが、現在有効なソースです。

特定のソースを有効化・無効化する

無効化する

次のコマンドで、無効化が出来ます。

dotnet nuget disable source {ソース名}

nuget.org を無効化したい場合は、次のような形です。

dotnet nuget disable source nuget.org

有効化する

先ほどとは逆に有効化する場合は、次の通りです。

dotnet nuget enable source {ソース名}

nuget.org を有効化したい場合は、次のような形です。

dotnet nuget enable source nuget.org

まとめ

多分年1くらいでググるヤツ

Azure Developer CLI の基本的な使い方について

Azure Developer CLI は、Azure を使う開発者を支援する為のツールです。

便利なんですが、多機能な分、色々覚えることが多いので、基本的な事を備忘録として残します。

何ができるツールなのか

次のようなことが出来ます。

• Azure へリソースの作成(Bicep、Terraform を利用)
• Azure へアプリケーションのデプロイ
• デプロイしたリソースの一括削除
• CI/CD パイプラインの構築(Azure Pipeline、GitHub Actions をサポート)
• Azure リソース、アプリケーションのテンプレート化

想定シナリオとしては、Staging 環境へデプロイする前段階として、個々人が自由にスクラップ & ビルド出来る Dev 環境を提供するといったシナリオです。

また、Azure リソースとアプリケーションをテンプレート化出来る為、新しくチームに参加するメンバーにも既存のチームメンバーと同等の環境をすぐに提供できるようになります。

DevContainer と組み合わせれば、環境構築コストを大幅に下げることが可能になりそうです。

Overview は、こちら

learn.microsoft.com

また、OSS で開発されているので、コードを見たい場合や、コントリビュートしたい場合は、こちらから

github.com

早速セットアップしてみる

今回の想定環境は、Windows 11 + PowerShell です。

必要なツール

次のツールが事前にインストールされている前提なので、入れてない場合はインストールしましょう

• Git

PowerShell で次のコードを実行

powershell -ex AllSigned -c "Invoke-RestMethod 'https://aka.ms/install-azd.ps1' | Invoke-Expression"

実行が終わったら、PowerShell の再起動が必要です。

PowerShell を再起動しても反映されない場合は、マシンを再起動しましょう

azd コマンドが通ったらインストール完了です

実際に動かしてみる

テンプレートを生成する

次のコマンドを入れて、テンプレートを指定します。

azd init

Empty Template は、テンプレートを自作する場合に選択するので、今回は別のものを利用します。

テンプレートを選択すると、environment name の指定を促されるので、Development など適当な名前を付けましょう。 この Environment name が、各コマンドを流した際の環境識別に利用されます。

この後、画面の指示に従って、利用するサブスクリプションとリージョンを指定します。

デプロイする

コマンドは、全てテンプレートが入ってるフォルダのルートで実行します。

インフラやソースコードのパスをカスタマイズしたい場合は、ルートに azure.yml を配置して制御しますが、その仕様については割愛します。(また別の記事で)

インフラをでデプロイする

インフラをデプロイしたい場合は、次のコマンドを実行します。

azd provision

これにより、デフォルトでは、infra/main.bicep がデプロイされます。

アプリケーションをデプロイする

アプリケーションをデプロイしたい場合は、次のコマンドを実行します。

azd deploy

これにより、デフォルトでは、src/ においてあるアプリケーションがデプロイされます。

2023年03月現在にサポートされているアプリケーションは、.NET、Java、Python、Node.js です。

インフラとアプリケーションを同時にデプロイする

azd up

リソースを削除する

デプロイしたリソースをクリーンしたい場合は、次のコマンドを実行します。(クリーンすると、Resoruce Group 丸ごと削除されます。)

azd down

まとめ

基本的な使い方は、今回書いた通りです。

正直これだけだと、実際の運用でどう使えばいいのかイメージが湧かないと思います。

次は、実際の開発で利用することが想定される独自テンプレートの作り方についてまとめようと思います。

Azure API Management でバックエンドの状態によってリダイレクトを行う

API Management は、あまりこういう用途で使うことは無いと思いますが、いざという時に困らない為に備忘録として残します。

どういう状況なのか

• バックエンドが特定のステータスコードを返した場合だけ、指定の URL へリダイレクトを行いたい

※ 今回は、500 を返した場合

やってみる

サンプルの全文は、次の通りです。

outbound 内で choose ポリシーで、レスポンスのステータスコードをチェックします。

今回は、500 の場合だけリダイレクトをしたいので、500 かどうかをチェックします。

次に、ステータスコードをリダイレクト用の 3xx に書き換えます。

最後に、location header を書き換えて、リダイレクトさせたい URL を書き込みます。

まとめ

普通に考えたら、ステータスコードとヘッダを書き換えられる時点で出来るけど、備忘録として

Bicep で SQL Database の Allow Azure services and resources to access this server を有効する

最近はあまり使わなくなりましたが、SQL Database で Azure 内からのアクセスだけを許可したい場合は、専用のフラグが用意されています。

Bicep でそのフラグを設定したい場合、ちょっと設定が分かりづらいので、備忘録として残します。

やり方

ファイアウォールルールとして、特別なルールを設定すると、フラグがオンになります。

name に AllowAllWindowsAzureIps、startIpAddress、endIpAddress に 0.0.0.0 を設定すると、有効化されます。

まとめ

bool とかで用意して欲しかった