ランダムなデータを生成する 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 »

Logic Apps から Slack に通知する

以前に Bot Framework で Slack の bot を構成するを書きましたが、
今回はこの素因数分解の bot を Logic Apps で作成してみます。
自然数をランダムに生成して素因数分解してその結果を Slack に通知する、
というのを 10 分間隔で実行することにします。

まず、Azure ポータルで Logic App を作成します (手順は初めてのロジック アプリの作成を参照)。
名前は、グローバルに一意である必要はありません。

次に、デザイナーでロジックを追加していきます。
完成したワークフローを先に示します。

 

以下は、各アクションについての説明や注意点です。

(1) 繰り返し (Recurrence)
最初のトリガーとして [繰り返し] を選択し、10 分間隔で実行されるようにしています。

(2) Azure Functions
アクションとして [Azure Functions] を選択すると、同じアカウント内で作成済みの関数を選択できます。
([HTTP] というアクションで URL を指定する方法もあります。)

Logic-Apps-Functions

ここでは、前回の Azure Functions で Web API を作成するで用意した Azure Functions の 2 つの関数を利用します。

(3) データ操作 – JSON の解析
前の関数からは

{ "result": "5439 = 3 ・ 7^2 ・ 37" }

という形式の JSON が返るため、あとで必要になる文字列 (result プロパティの値) を取り出すためにこれを解析します。
[スキーマ] は、この JSON を入力すれば作成されます。

(4) Slack – 投稿メッセージ
投稿先のチャネルとメッセージを指定します。
初回の設定時にはアカウントを認証する必要があります。Logic Apps 上の画面で失敗する場合は、[API 接続] から設定できます。

Logic-Apps-Slack

 

以上で完成です。
下図は Slack のスクリーン ショットです。

Factorization-Slack

 

前回: Azure Functions で Web API を作成する

参照
Flow、Logic Apps、Functions、WebJobs の比較
Logic Apps とは
Azure Functions を使用したロジック アプリのカスタム コードの追加と実行

Bot Framework で Slack の bot を構成する

Azure Functions で Web API を作成する

Azure Functions では、単機能の Web API やバッチを作成することができます。
とくに、Web アプリケーション全体を構築する必要がなく、開発者が管理するのは関数のソースコードのみで済むという利点があります。

Azure Functions で関数を作成するための詳細の手順は Azure Portal で初めての関数を作成するに記載されていますが、
概略は以下の通りです。

  • Function App を作成する
    • この段階では、Web サイトが作成されるのみ
    • Web サイトとして作成されるため、名前はグローバルに一意でなければならない
  • 関数を作成する
    • 一つの Function App に、複数の関数を作成できる
    • シナリオに応じてテンプレートを選択する
    • 言語が C# の場合、関数は、拡張子が「.csx」のファイルで表される
    • このポータル上で、コードの修正とテストができる

Azure-Functions-App  Azure-Functions-Files

 

以下では、Web API を作成するときに選択できるテンプレートについて書いていきます。
Web API を作成するには、「HTTP トリガー」を利用することになります。

Azure-Functions-Templates-API

HTTP トリガーでは、以下のことができます。

  • 利用できる HTTP メソッド (GET, POST など) を指定できる
  • 「Shops/{id:int?}」 のように URL ルーティングを指定できる (パラメーターは Run メソッドの引数になる)
  • 応答の本文は JSON になる。new { message = "Hello." } のようなオブジェクトも指定できる

HTTP トリガーには、以下のテンプレートがあります。

  • HttpTrigger
    • 汎用の HTTP トリガー
  • HttpTriggerWithParameters
    • パラメーターとしてクエリ文字列を利用する場合のテンプレート
    • HTTP メソッドは GET のみ有効
  • GenericWebHook
    • Webhook のテンプレート
    • 規約上は POST で本文に JSON を送るものだが、かまわず通常の HTTP トリガーとしても使えるっぽい

 

例として、簡単な Web API を作ってみます。

こちらはランダムに自然数を生成するもので、入力データを必要としていません。
HttpTrigger テンプレートから作っています。

次は、入力された自然数を素因数分解する関数です。
以前に Bot Framework で Slack の bot を構成するで作成したメソッドを再利用しています。
こちらは GenericWebHook テンプレートから作っており、要求の本文に { "n": 123 } のような JSON が渡される想定です。

本文がテキストの場合は req.Content.ReadAsStringAsync() としてもよいですが、JSON の場合は

dynamic data = await req.Content.ReadAsAsync<object>();

とすればよいでしょう。

また、クエリ文字列からの入力は req.GetQueryNameValuePairs() で読み込むことができます。

 

なお、下図はデータと連携したバッチを作成するときのテンプレートです。

Azure-Functions-Templates-Data

 

次回は、これらの関数を使って Logic Apps で Slack bot を作ってみます。

次回: Logic Apps から Slack に通知する

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

参照
Azure Functions の概要
Azure Functions における HTTP と Webhook のバインド

Bot Framework で Slack の bot を構成する

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