パスワード変更方法と言うか、実際には新しいパスワードへのリセット方法。
Azure ポータルで当該 SQL Database を選択し、概要画面から当該 Database が格納されているサーバーを選択し、パスワードのリセットを実行する。
パスワードの変更というわけでもないので、現在のパスワードを入力する必要すらない。 また、本件とは直接関係ないが、サーバー管理者のアカウント名も SQL Server ブレードの概要画面で確認できる。
参考
Reset lost admin account password – Azure SQL Database Support
基本的な考え方は、SQL Server と同じらしい。
SQL Database のユーザーは、インスタンス（サーバー）にログインする用の「ログインユーザー」と、インスタンスに含まれるデータベースを利用する用の「データベースユーザー」の 2 種類存在する。
インスタンスへのログインはログインユーザーを使用し（接続文字列とかで使用するログイン情報もこれ）、ログイン後のデータベース利用では当該ログインユーザーにマップされたデータベースユーザーが使用される。
特定のデータベースにのみアクセス可能なユーザーを追加するような場合、基本的にはログインユーザーとデータベースユーザー、それぞれについて追加が必要となる。
1 つのログインユーザーを複数のデータベースユーザーにマップする事も可能だが、各データベースユーザーにマップできるのは、1 ログインユーザーのみ。
データベースの権限設定は、ログインユーザーではなく、データベースユーザーに対して行う。
ユーザーの追加作業は、SQL Server だと SSMS の GUI から行えるが、Azure SQL Database だとスクリプト実行するしかないみたい(GUI でメニュー項目を選択することは可能だが、結局スクリプトが開く)。
ユーザー追加例として、特定のデータベースのみ使用できるユーザーを追加する場合は、以下。
-- ログインユーザーを login_name/password で作成 -- ログインユーザーは master データベース上に作成する必要があるので、master データベースに接続してスクリプト実行 CREATE LOGIN login_name WITH PASSWORD = 'password' -- データベースユーザーを user_name で作成し、login_name ログインユーザーにマップ。デフォルトスキーマは dbo を指定（スキーマについてはあまりよく理解してない・・・） -- データベースユーザーは対象のデータベース上に作成する必要があるので、対象データベースに接続してスクリプト実行 CREATE USER user_name FOR LOGIN login_name WITH DEFAULT_SCHEMA = dbo -- 上記で作成したデータベースユーザーに対して、権限を設定する（ここでは完全なアクセス許可を持つ db_owner を設定） -- 接続して実行するデータベースはデータベースユーザー作成と同様に、当該データベース EXEC sp_addrolemember N'db_owner', N'user_name'
参考
ASP.NET のセッション情報の格納先は、オンプレでは StateServer モードを使うことが多いと思う (InProc は使わない前提)。 オンプレではステートサービスを利用する方法で良いが、Azure Web Apps 上で動作させる場合、ステートサービスが利用できない。 代替案として、Azure リソースの一つである Azure Redis Cache が利用できる。
Azure Redis Cache 自体は ASP.NET のセッション情報格納用に用意されているわけではなく、純粋に NoSQL DB として用意されているが、ASP.NET のセッション格納先として利用できる Microsoft.Web.RedisSessionStateProvider NuGet ライブラリが用意されていて、ASP.NET Web アプリ開発側としてはそこまで特殊な操作は必要ない。
Redis Cache をセッションの格納先に使用する場合、host, port, accessKey や databaseId などの設定は、基本的には web.config で設定することになる。 web.config による設定で問題ないプロジェクトであれば良いが、Azure Web Apps で ASP.NET を動かす場合、スロットを使用して本番とステージングで環境を分け、本番デプロイはスワップを使用する事が多いと思う。 この場合、web.config のみで対応すると、本番スワップ後に本番用の web.config 設定に手動で切り替える必要があり、変更の手間や間違える可能性が出てくる。
その為、Redis Cache の設定についてもアプリ設定などから環境ごとの設定を読み込み、その設定を自動で適用出来るのが望ましい。
使用しているのがセッションという比較的低レベルの場所の為、操作できるタイミングは多くないが、以下のように Global.asax の Application_Start イベントであれば、動的に設定を行うことが出来る。
protected void Application_Start() { ... SessionStateSection sessionStateSection = (SessionStateSection)WebConfigurationManager.GetSection("system.web/SessionState"); ProviderSettings ps = sessionStateSection.Providers[0]; ps.Parameters["host"] = "アプリ設定から取得した設定等"; }
※ なお、この記事の内容とは直接関係ないが、設定値に問題があるなどして上記処理でエラーが発生すると、ASP.NET 的に致命的なエラーの状態になりやすいので、注意
参考情報
Azure SQL Database (サーバーではないので注意) のバックアップ方法は、主に以下。
Azure ポータルで当該 SQL Database リソースを表示し、[概要] 画面の [コピー] メニューから、Azure SQL サーバーへのデータベースのコピーを行う。 バックアップとはまた少し違うが、対象データベースを基にした別データベースを作成するのであれば、この方法が一番手間がない。
後述するように Azure ポータルでのエクスポート作業時は Azure IP がファイアウォールで許可されている必要があるが、コピー操作ではそのような制限はない様子。 また、エクスポートでは 15 分前後かかるデータベースも、コピーだと数分で済むので、そういう意味でもコピーはお手軽。
コピー先データベースのリソースグループや価格レベルはコピー元と同じ設定となるが、どちらもコピー完了後に変更出来るので、特に問題はないはず。 （リソースグループの変更は、当該 SQL Database が格納されている SQL サーバーごと行う必要がある）
Azure ポータルで当該 SQL Database リソースを表示し、[概要] 画面の [エクスポート] メニューから、BACPAC ファイルの Azure ストレージへのエクスポートを行う。 事前にエクスポート先の Azure ストレージアカウントを用意しておく必要があるので、注意。 後述する SSMS のようにクライアント端末に SSMS をインストールする必要もなく、Azure ポータルだけで操作完了できるが、ファイアウォール設定で Azure の IP が許可されている必要があるようなので、その点だけ注意。
また、エクスポート処理にはほとんど使用していないような状態のデータベースでも 15 分前後かかり、DTU も 100% 使ったりするので、この点も注意。 公式ドキュメントでは、エクスポート操作が 20 時間を超える場合は処理がキャンセルされるので、エクスポート操作時だけコンピューティングサイズを増やして処理時間を短くするような方法も記載されているので、DB 的にかなり負荷がかかる処理の様子。
エクスポート状況は当該データベースの画面ではなく、当該データベースが格納されている SQL サーバーの画面から確認できる。
Azure ポータルでのエクスポートの、ローカル版。 SQL Server Management Studio (SSMS) で対象 DB に接続後、対象 Database を右クリックし、コンテキストメニューから [タスク] - [データ層アプリケーションのエクスポート] をクリックする。 格納しているデータがほとんどなくても、エクスポート処理には 15 分前後かかるので、注意。
Azure SQL Database は Azure 側の仕組みで常に自動バックアップされている。Basic プランでも直近一週間以内であれば任意の日時の時点を指定して復帰可能。 コピーやエクスポートについて上述したが、自動バックアップの期間内の状態に戻せれば良いのであれば、実質的に明示的なバックアップは不要となる。
名前付け規約に関する公式ドキュメントは以下。
Azure リソースは Azure ポータル一箇所で全て管理されているため、ひと目でリソースの種別や目的が分かるような名前付けをする事が非常に重要となる。 なお、ここでは一つのサブスクリプションで一つのプロジェクトのリソースを管理する状況を仮定する。 場合によっては複数プロジェクト（もしくは特にプロジェクトが決まっていない）のリソースを同一サブスクリプションで管理する状況もあるかもしれないが、その場合は更に検討が必要と思われる。
基本的な考え方としては、最初に一番重要な要素を持ってくるべき。また、各リソースはアイコン付きで表示されるのでリソース種別も基本的にはそれで分かるが、一応、リソース種別もリソース名に含めた方が無難。 まとめると、基本形としては全て小文字で以下を想定。
[ステージ名]-[サービス名]-[リソース種別]
なお、[ステージ名] は、本番については基本的に "prd" を付与せず、サービス名から始まるリソースを本番として扱う。
例：
[dev] dev-service1-rg
[stg] stg-service1-rg
[prd] service1-rg
リソースによってはハイフンなどの記号が使用できないのもあるので、その辺りはハイフン使わずに詰めて名前付けするなど、適宜対応する。
