Azure StorageにClient Side Blazorをデプロイします。
Client Side Blazorの作成
Blazorのプロジェクトを作成し、Publish(発行)しておきます。
dotnet new blazorwasm -o ClientSideBlazorSample cd ClientSideBlazorSample dotnet publish -c Release -o out
Azure CLIのインストール
AzureをCLIで操作するためにAzure CLIをインストールします。
私はChocolately経由で入れた覚えがあります。
Chocolatelyでのインストールコマンドはこちら。
choco install azure-cli
Azure Storageを設定
az login
az group create -n {ResouceGroup名} -l japaneast
az storage account create -n {StorageAccount名} -g {ResouceGroup名} --kind StorageV2 -l japaneast --https-only true --sku Standard_LRS
今回は以下のように設定しました。
ResouceGroup名 : ClientSideBlazorSample
StorageAccount名 : blazorsamplestorage
※Storage名は文字列長3-24の英数の小文字のみ使用可能です。
設定が終わると、Azureでリソースグループに追加されているはずです。
静的Webサイトの設定
Azure DevOpsから追加したStorage Accountのページを開きます。
追加したResourceGroupからStorage Accountを選択し、静的なWebサイトを選択します。
静的なWebサイトを有効にし、インデックス ドキュメント名とエラー ドキュメントのパスをindex.htmlに指定します。
保存ボタンを押下すると、プライマリ エンドポイントが表示されます。
このエンドポイントがBlazorのURLになります。
Deploy
ファイルをアップロードすることでアプリをデプロイします。
デプロイするオブジェクトはdistフォルダ以下のファイル群です。
PowerShellの場合は以下の通りです。
cd out\ClientSideBlazorSample\dist
az storage blob upload-batch --account-name {StorageAccount名} -s . -d `$web
注意点としては、使用しているTerminalの種類に応じて-dのEscape文字を変更する必要があります。
WASMのContent Typeの設定
ファイルのアップロードが完了しましたが、前途したコマンドでアップロードした場合
_framework\wasm\mono.wasmのContent Typeはapplication/octet-streamになってしまいます。
確認のコマンドは以下の通り。
az storage blob show --account-name {StorageAccount名} -c `$web -n _framework\wasm\mono.wasm
Microsoft Azure Storage Explorerで確認した画面は以下の通り。
以下のコマンドでwasmのContent Typeをapplication/wasmに変更します。
例によって、-dのオプションは使用しているTerminalに応じて書き換えてください。
az storage blob update --account-name {StorageAccount名} -c `$web -n _framework/wasm/mono.wasm --content-type application/wasm
完成
先ほどのエンドポイントにアクセスします。
おわり
Client Size Blazorを簡単にDeployすることができました
Azure CLI経由でファイルをアップロードするとContent Typeを変更しなければならない点が面倒ですね。
Microsoft Azure Storage Explorerでアップロードすると、きちんとContent Typeが設定されるんですけどねー...。
追記:2019/10/29
> インデックス ドキュメント名とエラー ドキュメントのパスをindex.htmlに指定します。
— @jsakamoto (@jsakamoto) October 28, 2019
この、"エラードキュメントのパス" をも index.html に設定するのがなかなかのポイントですね。
@jsakamoto様の仰る通り、ポイントですね。
エラードキュメントのパスをindex.htmlに指定するのは、404とかのエラー発生時にBlazor内で用意したエラー画面を表示するためです。
※Blazorにエラーハンドリングを任せています。
試しに存在しないアドレスにアクセスしてみます。
Blazorがちゃんとエラーハンドリングしてくれています。
※このページはApp.razorの
もちろん別途Htmlファイルを用意してAzureのエラードキュメントのパスを用意したHtmlパスを指定すれば、そちらのエラー画面が表示されます。