Azure ストレージはカスタムドメインは使えるが、カスタムドメインの SSL はサポートしていない。カスタムドメイン＋SSL での HTTPS アクセスが必要な場合、CDN 経由で行う必要があるらしい。
BLOB ファイルに HTTP 経由でアクセスしたい場合、選択肢は基本的に以下 2 つになる。
参考
AzCopy コマンドでのファイル転送は出来るが、FTP は今の所サポートされていない。
参考
ファイルの補足情報として、メタデータの付与が可能。プログラムでも利用できるので、メタデータを基に動的にファイル処理できる可能性が広がる。 ただ、ファイル上書きでもメタデータは消えてしまうのと、Azure Storage Explorer の一覧画面ではメタデータの内容を確認できない点などは注意する必要がある（1 ファイルごとにプロパティで確認は可能）。
参考
一般的なプロジェクトの開発からリリースまでの流れとして、
となる事が多いと思うが（他知らないので、その前提で進めます）、このステップを踏む場合、Azure のリソースも基本的にはそれぞれのステージごとに用意する必要がある。 けど、Azure のリソースを使う場合この選択肢がいくつかあるので、どれを選択するかと言う話。
この話については、当該システムでどの Azure リソースを使うかにもよるので一概にこの方法でと言うのは言えないが、ここでは Web Apps を使ったシステムを例に考えてみる。
自分が考えつく各ステージごとのリソースの分け方としては、以下のような分け方がある。
基本的には、上に行くほどコストや手間がかかるがリソースとしては安定し、下に行くほどコストや手間がかからないがリソースとしては安定しない。 色々と考え方はあると思うが、個人的には、本番とそれ以外は、サブスクリプションを分けてしまった方が、ヒューマンエラーなども起こりづらく、色々すっきりすると思う。 それぞれの方法について、メリットとデメリットを挙げると、以下な感じ。
なるべくコストを低く抑えたいと言うのは普通どこでも最初に挙げる要望だと思う。ただ、メリットとデメリット、リスクとリターンのバランスを考慮する必要がある。 ヒューマンエラーの可能性とリソースの安定性、デプロイの影響、URL などの接続情報の分離、コストなどを総合的に鑑みた場合、自分としては以下のような選択肢が思い浮かぶ。
上述した内容は同じアプリの Dev, Stg, Prd 毎の扱いについてだが、やろうと思えば異なるアプリも同じような考えで同一リソースに共存することが可能。 ただ、異なるアプリを同一リソースで動作させる場合、最低でも、デプロイや URL、バックアップの単位などは他に影響ないように分けるべき。
例えば Web Apps に関して言えば、App Service プランを共有するのはギリギリいけるとしても、Web App リソースは完全に分けるべき。 Blob ストレージも、接続時の URL が同じで困るのであれば、ストレージ アカウントを分ける。 同様に DB も、DB コピーの単位がスキーマ単位なので、最低限スキーマ単位では分ける、など。
Azure AD アカウントのパスワード有効期限は既定で 90 日。 どのようなポリシーを採用するかにもよるが、基本的には定期的にパスワード変更するよりかは無期限の方が良いと思われる。
Azure ポータルで無期限に変更することは今の所できないようで、変更するには Azure AD PowerShell モジュールのコマンドレットを使用する (端末へのモジュールインストールが必要)。 使用するコマンドレットは Set-AzureADUser (v2 用)。
参考 URL
Microsoft Teams はデスクトップアプリもブラウザアプリも出ているが、どちらもアカウントは一つしか使えない。 使いたい Teams のアカウントが一つであれば問題ないが、複数アカウントを同時に使いたい時に困る事になるので、その時の対応方法。 なお、アカウントが一つであれば、動作が安定していて軽い、デスクトップアプリの使用を強く推奨。
一つのアプリで一つのアカウントしか使えないのはもうどうしようもないので、デスクトップアプリとブラウザアプリを同時に使って、複数アカウントを同時に使う。
Azure Functions で使用するログとして一番簡単なのは、既定で使用可能な、Azure ストレージを使用する組み込みログ。 追加で必要な設定なども特に不要で、Azure ポータルからもすぐに確認できるので初めは便利だが、Azure ポータルで表示されない事も多々あり、サブやテスト的に使う以外はあまりお勧めできない。 メインのログとして記録・参照する必要があるのであれば、Application Insights (AI) の使用に切り替えるのをお勧めする。
AI も取りこぼしがなくてそこまで信頼性が高いかと言われると微妙なところだが、組み込みのログよりは全然マシ。 また、機能的にもライブ メトリック ストリームでリアルタイムに確認できたり、一般的な検索も Azure ポータルから簡単に行える。やろうと思えば、クエリによる検索も可能。
AI でデバッグログやトレースログを含む大量のログ出力を行った事がないので、本当は AI 一本でも可能なのかもしれないが、大量に出力される可能性があるデバッグ系ログは、今のところ自分は log4net を使用したファイル出力で対応している。 通常のログファイルとしてダウンロードしてエディタで見れるので、誰でも直感的に確認しやすい。
ただ注意点として、Azure Functions の永続ストレージ（ローカルストレージ）が、同一ストレージリソースを複数インスタンスで共通して利用する仕様の為、複数インスタンスから単純にログ出力すると、排他制御で問題が発生する点がある。MinimalLock モードで書き込み毎に排他すれば複数インスタンスからの同一ログ書き込み自体は行えるが、今度はログの取りこぼしが結構な割り合いで発生するので、これも個人的にはお勧めできない。
複数インスタンスでも取りこぼしなくログ出力するには、ログファイル名にインスタンスの情報を含めるとかが考えられるが、それはそれでログ内容を検索するのが大変になりそうなので、そこまでするなら AI や DB など排他の心配が不要なリソースを利用した方が良いかもしれない。
基本は、Application Insights を使用。Info 系、Error 系など最低限のログ出力であれば、リアルタイムで確認できることもあり、便利。 AI にプラスして、Debug 系など大量に出力される可能性があるログに関しては、単一インスタンスであれば log4net によるログファイル出力が簡単。 複数インスタンスで実行される可能性がある場合は、単純な log4net ログファイル出力だと排他の問題が発生する為、AI や DB など排他の心配が不要なリソースの利用を検討する。
赤枠は同一 App Service で 2 インスタンス使用している時の例
参考ドキュメント
