Azure Blob StorageのURLでコンテナを経由せずにBlobを参照したいケースがあると思いますので備忘もかねて投稿します。
※この記事は2021/05/02時点の記事となります
基本編
Azure Storage BlobをURL参照するときは下記のようにコンテナ名が付与されると思います。
https://hoge.blob.core.windows.net/{コンテナ名}/test.txt
Azure Storage AccountのFQDNで直にBLOBを参照したいケースの場合はルートコンテナを作成しましょう。そうすれば「FQDN/Blob名」で参照することができます。
「$root」と明示的に入力してルートコンテナを作成することでコンテナを経由せずにアクセスすることができます。作成した後に「パブリックアクセスレベル」を「読み取りアクセス」以上に変更するのを忘れないでください。
作成した後はルートコンテナに何かしらファイルをアップロードしてアクセスしてみてください。
コンテナ名を省略してBlobを参照することができるようになったと思います。ルートコンテナについての詳細は下記を参考にしてください。
実をいうとこの方法は結構前からありました。私がこの方法を知ったのは2013年ごろにSilverLightの開発を行っていたとき、「Client Access Policy」を参照するためにのルートコンテナを作成するというTipsからでした。いま思うと懐かしい。
応用編
ルートコンテナを利用することで例えばAzure Front Door経由でアクセスするWebAppsの「robots.txt」や「sitemap.xml」をWebサイトから分離して管理することができます。
通常ではrobots.txtやsitemap.xmlはサイトのルート直下に配置する必要があるため、webのプロジェクトにバンドルしてデプロイすることが多いと思います。この場合はrobots.txtを変更したときに運用中のサイトをデプロイしなおす必要があるため運用コストがかかります。
Azure Front Doorを利用している場合、Azure Storageのルートコンテナをバックエンドプールに指定してrobots.txtやsitemap.txtに対してルーティング設定することでWebAppsプロジェクトから分離して管理することができます。robots.txtやsitemap.txtなどをデプロイなしで編集できるので運用リスクを低減することができます。
しかしながら、この方法には賛否両論があがりました。内輪でこの方法を提案したのですが一部からはCICDさえ組んでいればデプロイにかかる運用コストもそこまでかからないし、WebAppsのプロジェクトに含めておくことでGitリポジトリで変更の管理ができるメリットがあるのでこの方法が必要であるケースは少ないだろうと意見があがりました。確かにCICDを利用することで運用リスクは低減できますが、リポジトリ管理しつつ緊急的な変更に対応しやすいルートコンテナでの管理のほうがしやすいという声も上がりました。ここら辺は運用ルールに依るものが大きいかもしれませんが、応用トピックとしてやり方を頭の片隅にでも置いておいてもらえればと思います。
その他の特殊なコンテナ
ルートコンテナ以外にも「$web」や「$logs」などの特殊コンテナがあります。
「$web」はStatic Web Hosting用に自動で作成されるコンテナです。詳細は下記を参照してください。
「$logs」はログ出力用に自動で作成されるコンテナです。このコンテナはログ出力先として指定されている間は権限により削除することができません。詳細は下記を参照してください。
コメント