Michael

Azure Functions 2.0を試す ②: Visual Studio CodeでJavaScript関数をデプロイする

Michaelです。
前回、「Azure Functions 2.0を試す ①」にてAzure Functions 2.0のFunction Appを作成しました。
今回は、Visual Studio Code (VS Code)から作成したFunction AppにJavaScript関数をデプロイしてみます。

事前準備

VS CodeからFunction Appに関数をデプロイする方法は、Azure Functions 1.0でも提供されていましたが、2.0へのアップデートに伴って、Function Appの仕組みやランタイムバージョンが変更されているため使用するツールが異なっています。そのため、2.0向けに関数を作成するための事前準備が必要になります。
WindowsでAzure Functions 2.0用JavaScript関数を作成する場合には、以下のツール、ランタイムが必要となるためインストールしていきます。

.NET Core 2.1

.NET Downloads のサイトからOSに合わせた.NET Core 2.1インストーラーをダウンロードしてインストールします。

Node.js 8.5以降

Node version manager (nvm-windows)かNode.jsのインストーラーを使用してNode.js 8.5以降とnpmをインストールします。

Azure Functions Core Tools バージョン 2.x

下記コマンドでAzure Functions Core Tools バージョン 2.xをインストールします。npmでインストールするため、Node.jsを先にインストールしておく必要があります。
[crayon-5f2cae8996d0e628154687/]

Azure Functions 拡張機能

VS Codeの拡張機能から「Azure Functions」を検索して、拡張機能をインストールします。

Azure Functions 拡張機能をVS Codeに追加するとアクティビティバーにAzureアイコンが追加され、サイドバーに「FUNCTIONS」の領域が追加されます。

VS CodeでAzureにログイン

サイドバーの「Sign in to Azure」をクリックすると、ウィンドウ右下にメッセージが表示されます。
メッセージの「Copy & Open」をクリックすると、ブラウザのログインページに誘導され、クリップボードにログイン用のコードがコピーされます。

ログインページのテキストボックスにログイン用のコードを入力して続行をクリックすると、そのままMicrosoftアカウントのログインページとなるため、使用するAzure サブスクリプションでログインします。

ログインに成功するとサイドバーにログイン中のサブスクリプションが表示されます。

プロジェクトの作成

はじめに、Function Appに関数を発行するためのプロジェクトを作成します。
「FUNCTIONS」領域にマウスオーバーで表示される「Create New Project」アイコンをクリックするとウィンドウ中央上部に対話形式でプロジェクトを作成するダイアログが表示されます。
まずは、プロジェクトを作成するフォルダを選択します。プロジェクトは1つのFunction Appに相当するため、複数Function Appを作成する予定であれば、プロジェクトごとにフォルダ分けします。

続いて、言語を選択します。今回はJavaScript関数を作成するため、「JavaScript」を選択します。

最後にプロジェクトをどこで開くか選択します。今回は既存のVS Codeのワークスペースに追加して作業するため「Add to workspace」を選択します。

以上を行うと、そのままダイアログが終了します。プロジェクト作成で選択したフォルダを開くと、Function Appの設定ファイルが自動で作成されていることを確認できます。

関数の作成

プロジェクトが作成出来たら、関数を作成します。今回は、HTTPトリガーの関数を作成していきます。
プロジェクト作成時と同様に「FUNCTIONS」領域にマウスオーバーし、「Create Function」アイコンをクリックします。

ウィンドウ中央上部に表示される対話形式のダイアログに沿って作成を進めます。
はじめに、関数を作成するプロジェクトを選択します。

続いて、作成する関数のテンプレートを選択します。今回は、HTTPトリガーの関数を作成するため、「HTTP trigger」を選択します。

関数名を入力します。関数名は、デフォルトではAPIエンドポイントのパスになります。

「HTTP trigger」のテンプレートでは、APIのアクセスレベルを設定します。「Anonymous」はパブリックアクセスが可能な権限、「Function」、「Admin」はそれぞれアクセスにAPIキーが必要な権限が割り当てられるので、必要に応じて設定します。

設定が終わると、ダイアログが閉じて「HTTP trigger」テンプレートのコードが表示されます。
テンプレートのコードは、クエリ、またはリクエスト本文の「name」の値を読み取って、「Hello {name}」のレスポンスを返すものになっています。

[crayon-5f2cae8996d28004632210/]

関数のテスト

Azure Functions Core Toolsをインストールしているため、作成した関数はローカル上でテストできます。
テストする場合は、F5キーでVS Codeのデバッグモードを実行します。
デバッグを開始するとウィンドウ下のターミナルにログが流れ、関数のローカルホストのURLが表示されます。

URLをブラウザに入力し、クエリに「name=Michael」を追加して開くと、「Hello Michael」の文字列が返ってくることが確認できました。

関数が正常に動作することが確認出来たら、デバッグモードを終了します。

Function Appに関数をデプロイ

関数をFunction Appにデプロイします。
「FUNCTIONS」領域にマウスオーバーし、「Deploy to Function App」アイコンをクリックします。
ウィンドウ中央上部に表示される対話形式のダイアログで、まずデプロイするプロジェクトを選択します。

続いて、デプロイ先のFunction Appを選択します。

確認用のダイアログウィンドウが表示されます。デプロイするとFunction Appの関数がすべて上書きされてしまうため、デプロイ先が正しいことを確認して「Deploy」をクリックします。

ウィンドウ右下にデプロイ中のメッセージが表示されるため、完了になるまで待機します。

AzureポータルのAzure Functionsを開くと関数が追加されていることが確認できました。

デプロイした関数の使用

デプロイした関数を実際に使用してみます。
Function App上の関数のURLは、サイドバーの「FUNCTIONS」のツリーからデプロイした関数を探して、右クリックメニューの「Copy Function Url」を選択します。

コピーしたURLをブラウザに入力し、ローカルデバッグと同様にクエリに「name=Michael」を追加して開くと、「Hello Michael」の文字列が返ってくることが確認できました。

まとめ

VS Codeを使用したAzure Functionsの開発は、関数の作成からデバッグ、デプロイまでの一貫して1つのウィンドウで行えるため非常に便利です。
デバッグに関してはローカル上で行うことができるため、余計なコストをかけることなく実施できることもメリットです。

---

by Michael

Azure Functions 2.0を試す ①

Michaelです。

今回は、Microsoft Ignite 2018でGAが発表されたAzure Functions 2.0の変更点とリソースのデプロイについてご紹介します。

Azure Functions 2.0の変更点

Azure Functions 2.0では、1.0から多くの変更が加えられています。

言語とランタイムバージョン

Azure Functions 1.0では、1つのFunction Appで複数の言語の関数を実行することができました。
Azure Functions 2.0では、1つのFunction Appで対応する言語が1つに限定され、言語に合わせたホストの最適化によるパフォーマンス向上が図られています。
また、対応する言語とランタイムバージョンも変更されています。対応言語とバージョンは以下のようになります。

言語	Functions 1.0	Functions 2.0
C#	GA (.NET Framework 4.7)	GA (.NET Core 2)
JavaScript	GA (Node 6)	GA (Node 8、10)
F#	GA (.NET Framework 4.7)	GA (.NET Core 2)
Java	×	プレビュー (Java 8)
Python	試験段階	Linuxホストでプレビュー (Python 3.6)
TypeScript	試験段階	JavaScript へのトランスパイリングでサポート
PHP	試験段階	×
バッチ (.cmd、.bat)	試験段階	×
Bash	試験段階	×
PowerShell	試験段階	×

トリガーとバインド

Azure Functions 2.0では、HTTP トリガーとタイマートリガーを除いて、関数で使用するトリガーとバインドを拡張機能としてインストールするように変更されています。これに伴って、関数の function.json やプロパティにいくつかの変更が生じています。

開発／実行環境

Azure Functions 2.0のランタイムは .NET Core 2 で実行されるようになり、macOSやLinuxなど、.NET Core でサポートされるすべてのプラットフォームで実行できるようになりました。Azure Functionsだけでなく、PC、オンプレミス、エッジデバイスといった様々なデバイス上で開発、実行ができるようになっています。

ホスティングプランとSLA

従来、App Serviceプランのみ99.95%のSLAとなっていましたが、新たに従量課金プランでも99.95%のSLAが適用されるようになりました。
また、App Serviceプランのみでしか利用できなかったLinuxホストが従量課金プランでも利用できるようになりました。

Durable Functions

関数のオーケストレーションが可能なDurable FunctionsがGAになりました。

1.0から2.0への移行の注意点

Azure Functions 2.0では大幅な変更が加えられているため、1.0から2.0への移行は、2.0のFunctions Appを新規作成して、手動で関数コードを移植する必要があります。
この時、ランタイムバージョンやトリガー、バインドなど2.0で変更された箇所に関しては、ランタイムバージョンやAPIの互換性に合わせてコードを書き直す必要があります。

リソースの作成

Azureポータルでは、Azure Functions 2.0のリソースを作成できるようになっています。
リソースを作成する場合、「＋リソースの作成」、もしくはApp Service画面の「＋追加」から「Function App」を検索します。

表示されるペインのテキストボックスに必要事項を入力していきます。
項目の中にAzure Functions 1.0ではなかった「ランタイムスタック」が追加されており、Function Appで使用する言語を選択できるようになっています。
すべて入力したら、「作成」をクリックしてFunction Appを作成します。

作成できたFunction Appを開いて、関数を新規作成するとこれまでとは異なる画面が表示されます。
「JavaScript用のAzure Functions - 作業の開始」とあるようにFunction AppがJavaScript専用に作成されていることがわかります。

まとめ

Azure Functions 2.0では、言語やバインドの扱いなど多くの点で変更が行われており、1.0から2.0への移行には注意が必要です。しかし、変更に伴って最適化が進んでおり、2.0に移行することで関数のパフォーマンス向上が期待できるため、既存のFunction Appも早い段階で2.0に移行していきたいものです。
次回からは、変更になった点を中心にAzure Functions 2.0を検証していきます。

---

by Michael

雑コラBotを作ろう④: Table StorageにAzure Functionsの実行履歴を保存する

Michaelです。

「雑コラBOT」の作成の過程からAzure Functionsの設定方法を紹介する「雑コラBotを作ろう」の4回目です。

今回は、Azure Functions のTable Storageバインドを設定して、画像処理用Functionの実行履歴をTable Storageに書き込む仕組みを作成します。ついでに、処理結果をSlackに投稿するための関数を起動するキューメッセージをQueue Storageに出力する構成も追加します。

追加する構成

Azure Functionsで画像処理した結果のステータスをTable Storageに出力します。
ついでに、処理結果をSlackに投稿するための関数を起動するキューをQueue Storageに出力する構成も追加します。

バインドの設定

実行結果のステータスを出力するためのバインドを設定します。
関数の「統合」メニューで「＋新しい出力」をクリックし、「Azure Table Storage」のバインドを選択します。
「Azure Table Storage output」の設定でステータスを出力するStorage Accountとテーブルを設定し、保存をクリックします。

続けて、メッセージ投稿用の関数を起動するためのQueue Storageバインドも設定します。

スクリプト

スクリプトは以下のように作成しました。
[crayon-5f2cae8998e3d810370470/]

スクリプトの説明

1. ライブラリの読み込み
   必要なライブラリを読み込みます。
   実行履歴としてダウンロードしたコンテンツのMD5値を書き出すため、「hashlib」を追加しています。
2. バインド設定の読み込み
   関数に設定しているバインドの設定値を読み込みます。
3. 出力メッセージ用データ作成
   Queue Storage、Table Storageに出力するデータを作成します。
   キューメッセージ、実行履歴に書き込むBlob Storageの出力パスとコンテンツのMD5値をここで生成します。
4. 出力メッセージの設定
   Queue Storageに出力するメッセージを設定します。
   後にSlack投稿用関数で使用するための必要な値を含めます。
5. キューメッセージの出力
   メッセージをQueue Storageに出力します。
   Blob Storageと同様に、環境変数で指定されるパスにファイルとして保存することで書き出すことができます。
6. 実行履歴の書き込み
   Table Storageに実行履歴を書き込みます。
   Table Storageでは「PartitonKey」、「RowKey」を設定する必要があるため、Queue Storageに出力したメッセージに「PartitonKey」、「RowKey」を追加してTable Storageに書き込みます。

実行結果

Slackの設定したチャンネルにメッセージを投稿すると、Azure Functionsにログが表示され、4秒ほどで関数が終了していることがわかります。

Table Storageを見ると、設定した名称のテーブルが作成されており、関数の終了と同時刻にテーブルにデータが書き込まれていることが確認できました。

同様に、Queue Storageでも関数の終了と同時刻にメッセージが書き込まれていました。

注意点

Table Storageの出力バインドは、データの更新に対応しておらず、PartitionKey、RowKeyの組がすでにテーブルに存在する場合には、「EntityAlreadyExists」の関数エラーが発生します。
ここで注意すべき点は、出力バインドによるデータの追加は関数の実行完了時に行われるため、出力バインドに関わるエラーを関数の例外処理で対処できないことです。出力バインドにTable Storageを使用する場合は、PartitionKey、RowKeyの組がユニークとなるように設定する必要があります。

まとめ

今回は、Azure FunctionsのTable Storageバインドを設定しました。サーバーレスとNo SQL DBは、ログ保存等によく用いられる組み合わせで、Table Storageであれば予約スループットの課金がなく安価に構成できます。
次回は、Blob Storageに保存した画像のSAS URLを発行してSlackに投稿する関数を作成し、今回作成したQueue Storageのメッセージで連携させます。

---

by Michael

雑コラBOTを作ろう③: Azure Functionsで画像をダウンロードしてBlob Storageに保存する

Michaelです。

「雑コラBOT」の作成の過程からAzure Functionsの設定方法を紹介する「雑コラBotを作ろう」の3回目です。

前回は、Slackに投稿されたメッセージを整形してQueue Storageに格納し、関数の連携ができる状態にしました。今回は、前回設定したキューメッセージをトリガーに起動する画像処理用Functionを作成し、キューメッセージ内のURLから画像をダウンロードしてBlob Storageに保存するように連携させていきます。

構成

Queue Storageに格納されたメッセージをトリガーに関数を開始し、メッセージ内のURLで画像をダウンロードしてBlob Storageに保存します。

関数の作成とバインドの設定

Azure Functionsの関数をPythonで作成します。
関数のテンプレートの「実験的な言語のサポート」を有効化し、一覧から「Queue trigger」を選択してPythonで作成を開始します。

関数の作成ペインで関数名とトリガーバインドを設定します。
キューは前回作成した関数の出力バインドと同じものを指定にします。

関数が作成されたら、出力バインドを設定します。
関数の「統合」メニューで「＋新しい出力」をクリックし、「Azure BLOB ストレージ」のバインドを選択します。
「Azure BLOB ストレージ output」の設定で画像を出力するストレージアカウントとパスを設定し、保存をクリックします。
出力パスには「{blob_path}」のバインディング式を設定しており、前回設定したキューメッセージ(JSON)の「blob_path」キーの値がパスに代入されるようにしています。

Pythonバージョンの変更

関数のPythonバージョンをデフォルトの2.7系から3.6系に変更します。
Python3インストールに関してはこちらの記事 を参照ください。

スクリプト

スクリプトは以下のように作成しました。
[crayon-5f2cae89991eb928273369/]

スクリプトの説明

1. ライブラリの読み込み
   処理に必要なライブラリを読み込みます。
2. キューメッセージ読み込み
   Queue Storageに格納されたメッセージを読み込みます。
   Python関数ではファイルから読み込む形でキューメッセージを受け取ります。
3. コンテンツのダウンロード
   Slackに投稿されたURLからコンテンツをダウンロードします。
4. 画像フォーマット判定
   ダウンロードしたコンテンツのフォーマットを判定します。
   前段の関数ではURLの有無を確認するのみで、フォーマット判定を行っていないため、ここで判別を行います
   画像フォーマットは後に使うFace APIに合わせ、JPEG、PNG、BMP、GIFのみ処理を続行するようにしています。
5. Blob Storageに画像を保存
   ダウンロードした画像をBlob Storage に保存します。
   Python関数では、環境変数で指定されるパスにファイルとして保存することでBlob Storageにファイルを書き出すことができます。

実行結果

Slackのチャンネルに画像のURLを投稿すると、投稿時刻とほぼ同時に関数のログが表示され、Queue Storageとトリガーにより関数が開始されていることが確認できました。

Blob Storageをみると、投稿したURLの画像と同じ画像が出力バインドで指定したパスに保存されており、画像のアップロードも正常に行えていることが確認できました。

まとめ

今回は、Queue StorageによるAzure FunctionsのPython関数のトリガーとBlob Storageの出力バインドを設定し、画像のダウンロードと保存までできました。

雑コラBotとしては、これに画像加工を行い、保存した画像をSlackに返送すれば一連の仕組みが完成しますが、次回は少し寄り道をして、Azure Functionsの実行履歴をTable Storageに保存する仕組みを追加します。

---

by Michael

雑コラBotを作ろう②: Azure FunctionsのQueue Storage バインドでSlack のメッセージをQueue Storageに格納する

Michaelです。

「雑コラBOT」の作成の過程からAzure Functionsの設定方法を紹介する「雑コラBotを作ろう」の2回目です。

前回は、Azure FunctionsでSlackのオウム返しBOTを作成しました。今回は、Azure Functions同士を連携するために、受けたメッセージからURLを抽出してQueue Storageに格納する仕組みを追加します。

構成

Azure Functionsで受けたSlackのメッセージにURLが含まれる場合に、URLを抽出してメッセージとともにQueue Storageに格納します。

 

バインド設定

前回作成した関数に出力バインドを追加します。
関数の「統合」メニューで「＋新しい出力」をクリックし、「Azure Queue Storage」のバインドを選択します。
「Azure Queue Storage output」の設定でキューを格納するStorage Accountとキュー名を設定し、保存をクリックします。

パッケージのインストール

メッセージを連携する画像処理用Functionでは、画像をBlob Storageに保存します。保存パスには、ランダムな文字列としてuuidを設定するため、「uuid」のパッケージをインストールします。
関数の「プラットフォーム機能」メニューで「高度なツール(Kudu)」をクリックします。

Kuduの画面で「Debug Console」→「CMD」を選択してコンソールを開き、パッケージをインストールする関数のディレクトリまで移動してnpmの初期化を実行します。
[crayon-5f2cae8999589103590204/]
npmの初期化を行ったら「uuid」のパッケージをインストールします。
[crayon-5f2cae8999598260977802/]

スクリプト

スクリプトは以下のように作成しました。
[crayon-5f2cae89995a2688926966/]

スクリプトの説明

1. モジュールの読み込み
   必要なモジュールを読み込みます。
2. 特定文字のアンエスケープ関数
   クエリのアンパサンド等decodeURIComponentでエスケープされてしまう文字をアンエスケープします。
3. メッセージ内のURLを抽出
   正規表現を使って、メッセージ内のすべてのURLを配列として抽出します。
   メッセージはURLエンコードされているため、デコードとアンエスケープをしてからURLを抽出します。
4. メッセージ内のURL有無のチェック
   メッセージ内にURLがない場合は処理を中断します。
5. メッセージとURLをJSONで配列に格納
   メッセージをQueue Storageバインドに渡すために、URLごとにメッセージとURLをJSON化して配列に格納します。
   Queue Storageバインドに配列を渡すと、要素ごとにキューを追加できるため、複数URLが投稿された場合でも対応できます。
6. Blob出力パスの設定
   URLを解析して画像を保存するBlob Storageのパスを設定します。保存パスは「{uuid}/{ファイル名}」の形になるようにしています。
7. メッセージをQueue Storageに出力
   メッセージ内容、URLのJSONをQueue Storageに追加します。

実行結果

Slackの設定したチャンネルにまずはURLでないテキストを投稿します。
前回同様に「テスト」のテキストを投稿しても、BOTからのレスポンスはありません。

続いてURLを投稿すると、BOTから開始のメッセージが返されました。

Azure Storageを確認すると、Slackにメッセージを投稿した同時刻に、指定したキューにメッセージが格納されていることがわかりました。

まとめ

Queue StorageはAzure Functionsの関数間連携の方法として一般的なものとなります
出力バインドにより容易にメッセージを追加でき、それトリガーに他の関数を発火できるため、関数間連携としてきわめて容易に構成することができます。

次回は、Slackに投稿した画像のURLをもとに画像のダウンロードとBlob Storageへの保存を行う関数を作成し、今回作成したキューメッセージで連携させてみます。

---

by Michael