稼働中 Azure Web Apps に影響を与える操作について (再起動とか) - poke_dev’s blog
Azure ポータルでは Web Apps に関して色々と操作出来るが、その際の稼働中 Web Apps の挙動について説明。 なお、Functions の挙動は異なるので注意 (https://poke-dev.hatenablog.com/entry/2019/11/24/160018)。 ここでは ASP.NET MVC のプロジェクト作成時の状態を Free/Basic プランの 1 インスタンス Web Apps で確認している。 Basic についても「常時接続」設定がオフの場合は、本件の確認内容については Free と本質的に差異はないはず。 また、Basic 以上のプランであれば 2 インスタンス以上にスケールアウトすることが可能だが、スケールアウト時は仮想マシン自体が増加するので、挙動の差異は特にないはず（同じ挙動が全インスタンスで同様に行われるだけ）。 なお、セッション
Azure Web Apps + ASP.NET での初回ページ表示遅延対策 - poke_dev’s blog
Azure Web Apps + ASP.NET の組み合わせでシステムを構築した場合、ページの初回表示が非常に遅い現象に見舞われる事がある。 どれぐらい遅いかと言うと、大体 10 ～ 30 秒ぐらい待つ感じ。 主な原因は下記 2 つ。 Azure Web Apps の「常時接続」設定がオフになっている ASP.NET のページのプリコンパイルを行っていない 前者の常時接続設定についてはそれ自体も遅延の原因にはなっているが、どちらかと言うと問題のメインは後者のプリコンパイルで、これに常時接続の問題が加わると状況が更に悪化する感じになる。 なお、Web Apps を Azure App Service プランの Basic 以上で作成した場合は既定で常時接続オンになっているはずなので、Free プランで作った環境でなければ常時接続は最初から問題にはなっていない可能性が高い。 以降では、ASP
Azure StorageでのRest APIの署名のつくりかた（with パケットキャプチャ） - Qiita
本記事に出てくる「アクセスキー」は、Azureポータルの以下画面の「キー」で確認できます。 （[ホーム] > [ストレージアカウント]でストレージアカウントを選択 > [アクセスキー]） アクセスキーは、Base64エンコードされた文字列です。本記事では、例示のためにVGhpcyBpcyBzYW1wbGUgb2YgQXp1cmUgU3RvcmFnZSBBY2Nlc3MgS2V5IHN0cmluZyBCYXNlNjQgRW5jb2RlZA==というキーを使用していますが、これは実在しないキーです。くれぐれも本物のアクセスキーをソースコードにハードコーディングしないようにご注意下さい。 本記事のサンプルコードはC#で記述していますが、C#特有の文法は使用していないため、C#未経験者でも内容が直観的に理解できるコードになっています。念のため説明しておきますと、string s = "abc";は
自動バックアップからのAzure SQL Databaseリストア設計 - Qiita
はじめに Azure SQL Databaseサービスを使う運用の場合、バックアップは原則自動バックアップを使う事になります。(自分でバックアップタイミングを指定したい場合はBACPACにファイルエクスポートする手段が一番簡易なのではないかと思います） ここではAzure SQL Databaseのバックアップ/リストア設計をするにあたり、実際本番環境DBサーバを復旧させるにあたっての具体的手順や状況別リストア方法の選択や注意点についてまとめたいと思います。 また、本文は2019/12月時点の情報で記載しています。 各リストア手法についての概要は、別の方がまとめて下さった↓がわかりやすかったです。 Qiita:Azure SQL Databaseリストア手法まとめ 注意事項/制限事項 設計にあたってAzure SQL Database特有の制限事項について先にまとめておきます。特にオンプレ
Azure SQL Databaseリストア手法まとめ - Qiita
Azure SQL Databaseのリストア手法がいくつかあったので纏めてみました。 バックアップ SQL Databaseではユーザが意識することなく、自動的にバックアップが取得されています。 取得タイミングはAzure側で決定されるため、ユーザが指定することはできません。 取得サイクル 完全バックアップ 毎週 差分バックアップ 数時間に1回 トランザクションログバックアップ 5～10分に1回 バックアップ保存期間はSQL Databaseのサービスレベルによって異なります。 保存期間 Basic 7日間 Standard 35日間 Premium 35日間 Point in Timeリストア 概要 同一サーバ内に新規データベースとして復元する手法 保存期間に合わせた任意の時間に復元することが可能 主な利用用途は、何か不具合発生時に過去に遡って検証したいケースが考えられます イメージ図
Azure SQL Database のユーザー追加方法 - poke_dev’s blog
基本的な考え方は、SQL Server と同じらしい。 SQL Database のユーザーは、インスタンス（サーバー）にログインする用の「ログインユーザー」と、インスタンスに含まれるデータベースを利用する用の「データベースユーザー」の 2 種類存在する。 インスタンスへのログインはログインユーザーを使用し（接続文字列とかで使用するログイン情報もこれ）、ログイン後のデータベース利用では当該ログインユーザーにマップされたデータベースユーザーが使用される。 特定のデータベースにのみアクセス可能なユーザーを追加するような場合、基本的にはログインユーザーとデータベースユーザー、それぞれについて追加が必要となる。 1 つのログインユーザーを複数のデータベースユーザーにマップする事も可能だが、各データベースユーザーにマップできるのは、1 ログインユーザーのみ。 データベースの権限設定は、ログインユーザ
Azure環境作ったら最初にやるべきこと（2021年版）
はじめに Azure環境作ったら最初にやるべきこと（2021年版）と題して一記事書いてみたいと思います。 ※補足事項 「Azure環境作ったら最初にやるべきこと」の定義 この場では「どんなサービス／リソースを使うかに関わらず、誰もが全環境でやるべき最初のステップ」という主旨ととらえていただければと思います。 Azure環境運用していくうえで、「SQL Databaseのベストプラクティスは何？」とか「Web Appsだったらこうやって使うよね」とか細かい設定を挙げると色々あるのですが、今回は対象外。 なので、基本的には「Azureを使うすべて人」にとって意味のある記事になってるはずです。 先駆者たちの情報を探す AWSだと個人のブログもいっぱいあるし、かの有名なClassmethodさんのブログでもこういった記事がまとめられています。 初心者に優しいというか、いろんな情報が転がっていて、「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
VB/C# REST APIによるAzureのストレージの読み書き
Azure リソースの省略形の例 - Cloud Adoption Framework
Microsoft Azure Portal