ランダムなデータを生成する JSON API

Random Data Web API というものを作成しました (正確には、2014 年に作成したものを最近改修しました)。
ランダムなデータを生成するための JSON Web API です。以下のデータを生成できます。

  • アルファベット
  • アルファベットと数字
  • バイト列
    • 16進数形式、Base64 形式
  • UUID (GUID)
  • 時刻順の ID
    • 現在の時刻をもとに、並べ替え可能な GUID を生成
    • SQL Server の uniqueidentifier 型にも対応

内容自体はとくに変哲のない API です。時刻順の ID は少し珍しいかもしれませんが。
また、仕様が記述されたヘルプページ、および jQuery を利用したテストページが付属しています。

Test page

さて、従来の一般的な Web API の問題点として、利用する開発者の意思に反してサービスが終了してしまうということがよくあります。
無償・有償を問わずサービスが永久に提供されるとは限らないため、
なるべく自身のアプリをそれに依存させず、自身でサービスを運用することが望ましいでしょう。

そこでこの Web API では、ソースコードをオープンソース ライセンスのもとで提供し、
それを利用する開発者自身がサービスをホストすることを想定します。
例えば Azure Web App などの PaaS を利用すれば GitHub から直接ビルドおよびデプロイができるため、
簡単な手順でサービスの運用を開始させることができます。
またこの場合は継続的デプロイが構成され、fork したリポジトリが更新されれば Azure Web App も自動的に更新されます。

詳細の方法については Azure Web App にデプロイする手順にまとめてあります。
なお、randomdata.azurewebsites.net は配置例として提供しているものです。このサイトに保証・サポートはありません。

Deployment Option

技術的な特徴としては、以下が挙げられます。

  • ASP.NET Web API
    • XML Formatter を無効化して、JSON 形式のみをサポート
  • ASP.NET Web API Help Page
    • ソースコード内のコメントから自動生成
    • いろいろカスタマイズして利用
  • ASP.NET Web API Cross-Origin Support
    • CORS (Cross-Origin Resource Sharing)
  • HTTPS 必須化

ヘルプページの多言語対応については、ブラウザーの翻訳機能を利用すれば何とかなるでしょう。

Help Translation

バージョン情報

  • .NET Framework 4.5
  • ASP.NET Web API 5.2.3
  • ASP.NET Web API Help Page 5.2.3
  • ASP.NET Web API Cross-Origin Support 5.2.3
  • Blaze 1.1.10

参照

広告

Azure と VSTS で継続的デプロイ (2017)

以前に Azure と GitHub で継続的インテグレーション
Azure と Visual Studio Online (Git) で継続的インテグレーションなどの記事を書きましたが、
情報が古くなっているため、現在の環境で改めて検証しました。

現在の Azure Web App でバージョン管理システムからの継続的デプロイ (Continuous Deployment, CD) を構成する方法としては、

  • [デプロイ オプション] を設定する
  • [継続的配信] を設定する (ただしプレビュー)

の 2 種類があり、いずれかを選択することになります。

image

いずれの方法でも、バージョン管理システムとして Visual Studio Team Services (VSTS) も GitHub もサポートしています。
この 2 つの主な違いは、

  • [デプロイ オプション] では、リポジトリ内に含められる Web アプリケーションは 1 つ。
  • [継続的配信] では、対象の .sln を指定できるため、リポジトリ内に Web アプリケーションが複数存在してもよい。
    その他にも、細かい設定ができる。

です。

 

[デプロイ オプション] を設定する方法については前回の Azure と GitHub で継続的デプロイ (2017) で書きました。
今回は Visual Studio Team Services (VSTS) の Git リポジトリに対して [継続的配信] を設定してみます。

まず VSTS の Git リポジトリに Web アプリケーションを commit/push します。
今回は例として、ASP.NET MVC Web アプリケーションとします。
リポジトリに bin フォルダーなどを含める必要はありません。

image

 

次に、Azure で Web App を作成します。

image

作成が完了したら、その Web App の [継続的配信] を構成していきます。

image

ソースとして VSTS を選択し、アカウント、リポジトリ、ブランチを選択します。

image

 

基本的な設定はこれだけです。設定完了と同時に、ビルドとデプロイが開始されます。

image

以降も、ソースコードを変更してリポジトリに commit/push するだけで、自動的にビルドとデプロイが実行されます。 
開発時には、開発用のブランチおよび Web App を利用するとよいでしょう。

image

VSTS のリポジトリの [Services] で、Azure Web App と連携していることを確認できます。

image

 

VSTS の Web 画面で、ビルド定義の表示・編集ができます。詳細の設定はここでできます。
なお、Visual Studio 上での表示・編集はできなくなっているようです。

主に使われる設定としては以下が挙げられるでしょう。

  • ビルド定義の名前の変更
  • .sln ファイルのパスの指定
  • ブランチの変更
  • 継続的デプロイか、手動デプロイか (Enable continuous integration)
  • ビルド番号の形式

image

image

image

ビルドで生成された実行ファイルは [Artifacts] で取得できます。

image

[Release] から、過去のバージョンを選択して再デプロイすることもできます。

image

 

注意点:

  • VSTS 以外の Git (GitHub など) でも同様の手順で構成できますが、
    ビルド定義を VSTS のリポジトリに保存するため、VSTS のアカウントが必要です。
  • 管理者権限を与えられた別の Azure アカウントだと、エラーが発生して [継続的配信] を設定できませんでした。

 

前回:Azure と GitHub で継続的デプロイ (2017)

参照
Build and deploy to an Azure Web App

Azure と GitHub で継続的インテグレーション (旧版)
Azure と Visual Studio Online (Git) で継続的インテグレーション (旧版)

Azure と GitHub で継続的デプロイ (2017)

以前に Azure と GitHub で継続的インテグレーション
Azure と Visual Studio Online (Git) で継続的インテグレーションなどの記事を書きましたが、
情報が古くなっているため、現在の環境で改めて検証しました。

現在の Azure Web App でバージョン管理システムからの継続的デプロイ (Continuous Deployment, CD) を構成する方法としては、

  • [デプロイ オプション] を設定する
  • [継続的配信] を設定する (ただしプレビュー)

の 2 種類があり、いずれかを選択することになります。

image

いずれの方法でも、バージョン管理システムとして Visual Studio Team Services (VSTS) も GitHub もサポートしています。
この 2 つの主な違いは、

  • [デプロイ オプション] では、リポジトリ内に含められる Web アプリケーションは 1 つ。
  • [継続的配信] では、対象の .sln を指定できるため、リポジトリ内に Web アプリケーションが複数存在してもよい。
    その他にも、細かい設定ができる。

です。
Web アプリケーションが 1 つしか含まれていないリポジトリをシンプルに運用したいのであれば、[デプロイ オプション] でよいでしょう。

 

以下では GitHub のリポジトリに対して [デプロイ オプション] を設定してみます。
なお、GitHub 以外の Git (VSTS など) でも同様の手順で構成できます。
[継続的配信] については次回の Azure と VSTS で継続的デプロイ (2017) で書いています。

まず GitHub のリポジトリに Web アプリケーションを commit/push します。
今回は例として、ASP.NET MVC Web アプリケーションとします。
リポジトリに bin フォルダーなどを含める必要はありません。

image

リポジトリはパブリックでもプライベートでもかまいませんが、
自分が所有しているリポジトリでなければならないため、他の人のリポジトリであれば fork しておきます。

 

次に、Azure で Web App を作成します。

image

作成が完了したら、[デプロイ オプション] を構成します。
ソースとして GitHub を選択すると、アカウント承認の画面が現れます。
さらにリポジトリとブランチを選択します。

image

 

必要な設定はこれだけです。設定完了と同時に、ビルドとデプロイが開始されます。
[継続的配信] では数分かかるのに対して、かなり早く完了します。

image

以降も、ソースコードを変更してリポジトリに commit/push するだけで、自動的にビルドとデプロイが実行されます。
開発時には、開発用のブランチおよび Web App を利用するとよいでしょう。

image

過去のバージョンを選択して再デプロイすることもできます。

image

GitHub のリポジトリの [Settings] – [Webhooks] で、Azure Web App と連携していることを確認できます。

image

 

次回:Azure と VSTS で継続的デプロイ (2017)

参照
Azure App Service への継続的なデプロイ

Azure と GitHub で継続的インテグレーション (旧版)
Azure と Visual Studio Online (Git) で継続的インテグレーション (旧版)

カテゴリー: ALM, クラウド. タグ: , . 3 Comments »

Azure Web ジョブでバッチを実行する

Azure Web ジョブでバッチを実行するための簡易的な作業手順と、タイムアウトなどの注意点について記述します。

まず、Azure Web ジョブを配置するまでの基本的な流れは次の通りです。

  • ストレージを作成する
  • Web App を作成する
  • Web ジョブを開発して配置する

これらについて、以下に詳細を書いていきます。

■ ストレージを作成する

Azure ポータルで、ストレージを 1 つ作成します。
厳密には、

  • ログを格納するためのストレージ (AzureWebJobsDashboard)
  • バッチが利用するストレージ (AzureWebJobsStorage)

の 2 種類なのですが、1 つのストレージに両方の役割を持たせてもかまいません。
また、後の手順で接続文字列を使うため、[キー] からコピーしておきます。

■ Web App を作成する

Azure のポータルで、Web App を作成します。
[アプリケーション設定] の [接続文字列] で、「AzureWebJobsDashboard」をキーとする設定を追加します。
これで、WebJobs ダッシュボードを利用できるようになります。

接続文字列

 

■ Web ジョブを開発して配置する

Visual Studio で、新規のプロジェクトを [Azure WebJob] のテンプレートから作成します。
App.config を開くと、接続文字列の設定が 2 種類あります。
この両方に、先ほどと同じ接続文字列を設定します。

接続文字列

以下、Web ジョブの開発の流れを簡単に書いておきます。
なお、今回作成したサンプルは TaskWebJob (GitHub) にあります。バッチ処理の題材として、素数を求めています

(1) 手動またはスケジュールで開始する場合
詳細は Web ジョブ SDK を使用して Azure テーブル ストレージを使用する方法などを参照。

  • メソッドに [NoAutomaticTrigger] を付ける
  • JobHost.Call メソッドで、そのメソッドを呼び出す
  • Azure WebJob として発行する
    • オンデマンド実行またはスケジュール実行を選択する
  • 実行するには、ポータルの Web App の [Web ジョブ] で実行する

(2) キューをトリガーとして開始する場合
詳細は Web ジョブ SDK を使用して Azure キュー ストレージを操作する方法などを参照。

  • メソッドの引数に [QueueTrigger] を付ける
  • JobHost.RunAndBlock メソッドを使う
  • Azure WebJob として発行する
    • 連続実行を選択する
  • 実行するには、指定したキューにメッセージを追加する
    • 引数を渡すこともできる

 

以上で、Azure Web ジョブにバッチを配置することができました。
さて、バッチを実際に実行してみると、タイムアウトしてしまうことがあります。
以下では、タイムアウトについて書いていきます。

■ 有料プランの場合

既定では Web App の [アプリケーション設定] の [常時接続] がオフに設定されており、
Web App (というより Kudu?) が 20 分ほどでタイムアウトしてしまいます。
[常時接続] をオンに設定すれば解決します。

■ 無料プランの場合

無料プランでは、[常時接続] をオンにできません。
バッチの実行がタイムアウトする原因は 2 つあります。

  • Web App のタイムアウト
    • タイムアウトは 20 分ほどです。
    • Kudu への要求が連続的にされていれば、タイムアウトは延長されます。
  • CPU 時間の制限
    • 実際の時間ではなく、CPU を使用した時間です。
    • 例えば、連続して 3 分使うと、Web App が停止します。

したがって、WebJobs ダッシュボードなどを表示したままにして、
かつ CPU 使用率の低いバッチであれば実行可能ということになります。

そこで、例えば Thread.Sleep メソッドをコードに含めるという方法があります。
Thread.Sleep などでスレッドを中断しながら実行すると、CPU 利用率を激減させることができます。

CPU 時間の使用量は [クォータ] で見ることができます。

クォータ

 

作成したサンプル
TaskWebJob (GitHub)

参照
Azure Web ジョブのリソース
Azure App Service に .NET Web ジョブを作成する
Web ジョブ SDK を使用して Azure キュー ストレージを操作する方法
Web ジョブ SDK を使用して Azure テーブル ストレージを使用する方法
Web ジョブでバックグラウンド タスクを実行する
Visual Studio を使用して Web ジョブを展開する

LINQ で素数を求める (C#)

カテゴリー: クラウド. タグ: , . Leave a Comment »

Azure Web App をファイル サーバーとして使う

Azure Web App を、単にファイルを置く場所として使う方法について書いていきます。
基本的には Web App を作成するだけですが、フォルダーやファイルの一覧を表示する機能についても紹介します。

Azure のダッシュボードで [App Service] の [Web App] を作成します。

image

Web App が作成されると、https://xxx.azurewebsites.net の形式の URL でサイトにアクセスできるようになります。

image

作成した Web App で [ツール] – [Visual Studio Online (プレビュー)] を表示し、[オン] に切り替えます。

image

[移動] をクリックすると、Visual Studio Online "Monaco" が表示されます。

image

基本的な設定はこれでもう終了で、
あとはこの画面の [wwwroot] の下にフォルダーやファイルを追加していくだけです。
PC 上のファイルをドラッグ アンド ドロップしても追加できます。
テキスト ファイルであれば直接編集できます。

例えば [wwwroot] の下に test.txt を置いたとすると、
https://xxx.azurewebsites.net/test.txt の URL でファイルにアクセスできます。

 

以下は、フォルダーやファイルの一覧を表示するための手順です。

まず、[wwwroot] の下の hostingstart.html を削除します。
次に [wwwroot] の下に [Web.config] という名前のファイルを追加して、次の内容をコピーします。

image

再びサイトにアクセスすれば、次のような画面になります。

image

フォルダーやファイルを追加してみます。

image

すると、一覧として表示されます。

image

 

ファイルを配置する方法としては、
上記のように Visual Studio Online "Monaco" を使うほか、FTP を使うことができます

ディスクの容量については、無料プランでは 1GB までです。
その他のプランの場合は、価格 – App Service を参照してください。

参照
ディレクトリの参照 <directoryBrowse>
Azure Web App に FTP でデプロイする

カテゴリー: クラウド. タグ: . Leave a Comment »

Azure Web App の仮想ディレクトリにサブドメインを設定する

前回は Azure の DNS ゾーンでカスタム ドメインを使うという記事を書きましたが、
今回はさらに、Azure Web App の仮想ディレクトリにサブドメインを対応させる方法について書きます。

つまり、1 つの独自ドメインと 1 つの Azure Web App (Shared 以上) があれば、
複数のサブドメインをホストできるということです。

方針としては、DNS ゾーンではワイルドカード ドメインを設定して、
Azure Web App で仮想ディレクトリとサブドメインの対応を設定します。
例えば abc.com が abccom.azurewebsites.net に対応しているとしたら、
app1.abc.com を abccom.azurewebsites.net/app1 に対応するようにします。

以下、設定手順です。

 

DNS ゾーンの設定

DNS ゾーンでワイルドカード ドメインを受け付けるように設定します。
[レコード セットの追加] で次の 3 つのレコードを登録します。

@ A xxx.xxx.xxx.xxx (IP アドレス)
awverify CNAME awverify.app-name.azurewebsites.net
* CNAME app-name.azurewebsites.net

前回のときに www としていた部分を * (ワイルドカード) に変更しただけです。

レコード セット

 

Web App の設定

Azure Web App の [アプリケーション設定] – [仮想アプリケーションとディレクトリ] で仮想ディレクトリを作成します。

仮想アプリケーションとディレクトリ

指定された仮想ディレクトリには、Web Deploy や FTP などを使って Web アプリケーションを配置しておきます。
(詳細不明ですが、Web アプリケーション プロジェクトに Application Insights を追加しておかないと、
配置後に実行時エラーになりました。)

Web を発行

 

次に [カスタム ドメインおよび SSL] で、利用可能にしたいサブドメインを追加します。
これで、サブドメインへのアクセスもこの Web App で受け付けられるようになります。
(ここでワイルドカード ドメインを登録する方法もあるでしょう。)

カスタム ドメインおよび SSL

 

このままだと、サブドメインへのアクセスがすべてルートのアプリケーションに流れてしまいます。
そこで www 以外のサブドメインと仮想ディレクトリを対応させるため、URL Rewrite を使います。
ルートの Web アプリケーションの Web.config に次の設定を追加します。

 

以上で、test1.saka-pon.net または saka-pon.net/test1 の URL で仮想アプリケーションにアクセスできるようになりました。

サブドメイン

 

前回: Azure の DNS ゾーンでカスタム ドメインを使う

参照
Creating Rewrite Rules for the URL Rewrite Module
URL Rewrite Module 2.0 Configuration Reference
URL 書き換えモジュール構成のリファレンス
Windows IIS/Azure WebサイトのURL Rewrite機能でURLを書き換える(基本編)

Azure Web App に FTP でデプロイする
Visual Studio から Windows Azure にデプロイする

Azure の DNS ゾーンでカスタム ドメインを使う

Microsoft Azure には DNS ゾーンの機能がありますが、管理ポータルの GUI で設定ができるようになりました。
(以前は PowerShell で設定していたようです)
以下では、DNS ゾーンを設定して、Azure Web App をカスタム ドメインで使うための手順を示します。

前提として、次のものを用意します。

  • Web サイトに設定したい独自ドメイン
  • Web サイトの実体となる Azure Web App
    • この時点では app-name.azurewebsites.net の形式でのみアクセスできる
    • 独自ドメインを利用するには、価格レベルは Shared 以上が必要

この Azure Web App に、abc.com および www.abc.com の形式のドメインでアクセスできることを目標とします。

 

Azure 管理ポータルの [DNS ゾーンの作成] で、[名前] にはドメインを入力します。

DNS ゾーンの作成

これで DNS ゾーンが作成されます。
次に [レコード セットの追加] で、次の 3 つを登録します。

@ A xxx.xxx.xxx.xxx (IP アドレス)
awverify CNAME awverify.app-name.azurewebsites.net
www CNAME app-name.azurewebsites.net

Azure Web App の IP アドレスは、後述する [外部ドメインの使用] を開くと表示されます。
また、awverify は Azure Web App を利用する場合の固有のもので、作業者が同一であるかを確認するために必要です。
この設定がないと、後述する [外部ドメインの使用] でエラーとなります。

[名前] を空欄にすれば、自動的に @ (ルート) になります。

レコード セットの追加

レコード セットを追加すると、次の画面のようになります。
SOA レコードと NS レコードは最初から登録されています。

レコード セット

 

上の画面には「ネーム サーバー」がいくつか表示されています。
これらをドメイン管理サービスの DNS サーバーとして設定します。
次に示すのはデータ・ジャパンの管理サイトです。

DNS サーバー

基本的にはすぐにネットワークに設定が反映されますが、かなり時間がかかることもあるようです。
設定が反映されているかどうかは、Dig web interface などで確認できます。

Dig web interface

 

最後に、Azure 管理ポータルに戻り、Azure Web App の [カスタム ドメインおよび SSL] – [外部ドメインの使用] で
利用したいドメインを割り当てれば完了です。
ここでは、ドメインのルートのほか、www 付きのドメインも指定しています。

カスタム ドメインおよび SSL

ちなみに、DNS ゾーンで www のレコードを

www CNAME saka-pon.net

と設定した場合は、この [外部ドメインの使用] で www 付きのドメインを割り当てようとしたときにエラーとなりました。
(おそらく awverify が理由)

 

次回: Azure Web App の仮想ディレクトリにサブドメインを設定する

参照
Azure DNS の使用を開始する
Azure App Service のカスタム ドメイン名の構成
Windows Azure Web サイトに独自ドメイン ( カスタムドメイン ) を設定し使用する
Dig web interface