2018/03

2018/03/27

IBM Cloud のブロックチェーンサービスを使う（後編）

コメント数:
0 コメント
by dotnsf

この記事の続きです：
IBM Cloud のブロックチェーンサービスを使う（前編）
IBM Cloud のブロックチェーンサービスを使う（中編）

IBM Cloud から提供されているマネージド・ブロックチェーン・サービスを使う手順を紹介しています。前編ではベータ版で無料（2018/03/27 時点）のサービスインスタンスである Starter Membership Plan の作成手順を紹介し、中編ではこのサービスインスタンスを Hyperledger Composer のカードファイルを使ってセットアップしました。今回の後編ではこのインスタンスに実際にビジネスネットワークをデプロイして動かすまでの手順を紹介します。なおあくまでベータ版であり、今後の仕様変更等により以下の内容は正しい情報ではなくなる可能性もあります。以下の内容は 2018/03/27 時点での情報であることをご了承ください。

【BNA（Business Network Archive）ファイルの準備】
まずはデプロイするビジネスネットワークを用意します。IBM Cloud のブロックチェーンサービスはオープンソースのブロックチェーン基盤である Hyperledger Fabric をベースとしており、関連プロダクトである Hyperledger Composer もサポートしています。ビジネスネットワークは Hyperledger Composer や Hyperledger Composer Playground を使うと BNA(Business Network Archive)ファイルとして比較的簡単に定義することができるので、今回はこの方法を使います。

すでに BNA ファイルをお持ちであれば、そのファイルを使っていただいても構いません。お持ちでない場合は私が github.com で公開しているこちらのコードを使ってください：
https://github.com/dotnsf/bcdev-basickit

↑この公開プロジェクトは名前の通り、bcdev(BlockChain DEVelopment) の BasicKit として開発・公開したものです。Hyperleger Fabric & Hyperledger Composer を使って、ごくシンプルなビジネスネットワークを作り、そのビジネスネットワーク上で動作する API とサンプルアプリケーションが含まれています。簡単に言えば「ブロックチェーン開発の雛形キット」として開発したものです。

上記リポジトリを（Node.js を導入したシステムに）ダウンロードするか git clone して、一連のファイルを手元に用意してください。そしてこの中の /api/bcdev-basickit-network.bna というファイルが Hyperledger Composer 用のビジネスネットワーク定義ファイルになっています。以降の説明はこの bcdev-basickit-network.bna ファイルを前回説明＆作成した IBM Cloud のブロックチェーンサービスにデプロイすることを目的に説明します：

【BNA（Business Network Archive）ファイルのデプロイ】
まずは中編のおさらいを兼ねて、ここまでに設定した内容と、この bcdev-basickit アプリケーションを動かすために設定する内容を記載しておきます。まずは前回の設定内容がこちら：

項目	設定値
作成した管理者向けのカード名	admin@fabric-network
上記管理者の公開鍵ファイル	~/.identityCredentials/admin-pub.pem
上記管理者の秘密鍵ファイル	~/.identityCredentials/admin-priv.pem
接続プロファイル	~/mychannel1/connection.json

そして、今回動かそうとしている bcdev-basickit アプリケーションが想定しているブロックチェーン上のビジネスネットワークの設定がこちらです：

項目	設定する値
アプリケーションの実行ユーザーのカード名※	admin@bcdev-basickit-network
アプリケーションの BNA ファイル	./api/bcdev-basickit-network.bna

※Hyperledger Composer に慣れていないとわかりにくいかもしれませんが、/api/settings.js の中でカード名を指定していて、ここで指定したカード名でビジネスネットワークにアクセスできるよう設定されている前提でアプリケーションが作られています。またビジネスネットワークそのものは api/ フォルダの下にある bcdev-basickit-network.bna ファイルで定義されています。このファイルを指定してデプロイします。

では composer コマンドを順次実行して設定していきます。まず最初に admin@fabric-network の管理者でビジネスネットワークアーカイブファイルをデプロイします：

$ composer runtime install --card admin@fabric-network --businessNetworkName bcdev-basickit-network
　　（↑空のビジネスネットワークを作成）
$ composer network start --card admin@fabric-network --networkAdmin admin --networkAdminEnrollSecret adminpw --archiveFile ./api/bcdev-basickit-network.bna --file admin@fabric-network.card
　　（↑空のビジネスネットワークにユーザー名(admin)と BNA ファイルを指定してデプロイ）

【アクセス用カードファイルの準備とインポート】
ここまでの作業が成功すると、ブロックチェーンサービス上でビジネスネットワークが稼働している状態になります。このままでも使えないことはないのですが、一般的には個別のビジネスネットワークにアクセスするための個別のユーザー（カード）を作って利用します。特にこの bcdev-basickit-network というアプリケーションでは（デフォルト状態では）admin@bcdev-basickit-network というカードでアクセスすることを想定して開発されているので、このカードを作ってインポートします：

$ composer card create -n bcdev-basickit-network -p connection.json -u admin -c ~/.identityCredentials/admin-pub.pem -k ~/.identityCredentials/admin-priv.pem
　　（↑このビジネスネットワークにアクセスするためのカード（admin@bcdev-basickit-network）を作成）
$ composer card import -f admin@bcdev-basickit-network.card
　　（↑新たに作成したカードをインポート）
$ composer card list
　　（↑カードの一覧を表示して、結果に admin@bcdev-basickit-network が含まれることを確認）

カードの一覧に admin@bcdev-basickit-network が含まれていることを確認します：

最後に admin@bcdev-basickit-network がビジネスネットワーク上で正しく動いている（アクセスできる）ことを確認します：

$ composer network ping -c admin@bcdev-basickit-network
　　（↑admin@bcdev-basickit-network への ping が成功することを確認）

この結果が "Command succeeded" になればデプロイされたビジネスネットワークを使う準備が整ったことになります：

【ブロックチェーンアプリケーションの利用】
ここまでの準備が整っていればアプリケーションからビジネスネットワークを利用することができます。今回用意したモジュールには Swagger ベースの API Document が含まれているので、これを動かしてみましょう。

Swagger API Document は api/public/doc フォルダ内にあります。つまり api フォルダ内でアプリケーションを実行するのですが、一部設定項目があります。そのためにまずは一度アプリケーションを実行します：

$ cd api
　　（↑ api/ フォルダへ移動）
$ npm install
　　（↑ライブラリのインストール）
$ node app
　　（↑アプリケーション実行）

実行が成功すると "server starting on XXXX ..." というメッセージが表示されます。この "XXXX" という部分（下図の場合 6017）をメモします：

一旦アプリケーションを終了し（Ctrl+C）、api/public/doc/swagger.yaml ファイルをテキストエディタで開きます。そして６行目の host: で始まる行の続きを　このシステムの IP アドレス:XXXX　という内容に書き換えて保存します：

もしこのアプリケーションを手元のシステムではなく IBM Cloud などのパブリッククラウド上のアプリケーションサーバーにデプロイして実行する場合は、この host の値をアプリケーションサーバー名に書き換えて保存してください。

保存後、あらためてアプリケーションを実行し、ウェブブラウザで /doc/ パスにアクセスすると、Swagger Open API ドキュメントの画面が表示されます（Basic URL の値が swagger.yaml で編集した host の値になっていることを確認してください）：

（注　IBM クラウドの Cloud Foundry ランタイムで実行している場合は、API ドキュメントのスキーマを HTTP から HTTPS に変更してから以下を実行してください）
2018032705

この画面はブロックチェーンサービスと接続された API サーバーのインタラクティブドキュメントになっているので、実際に動かすことが可能です。一例としていくつかの処理を実行してみましょう。まずは管理ユーザーを作成するために POST /api/adminuser と書かれた項目をクリックして展開します。するとこの API に関する説明が表示されると同時に、"Try it out" というボタンが表示され、ここをクリックすると実際に実行することができます：

この API では管理ユーザー（admin）のパスワードを生成します。仮にパスワードを P@ssw0rd とする場合は { "password": "P@ssw0rd" } という JSON を指定します。最後に Execute をクリックします：

実行結果や実行内容が画面下部に表示されます。ここで行った処理を curl コマンドで実行する場合のコマンドなども表示されます。以下の例では実行結果として HTTP コード 200 が返り、{ "status": true } という本文が戻されました。API 実行コマンドは成功して、このアプリケーションの管理者をブロックチェーン内に作成することができたようです：

では作成したユーザーでログインしてみましょう。API Document 画面の１つ下に POST /api/login という API があり、この API でログイン処理を行うことができます。この項目を選択して展開し、同様に "Try it out" をクリックします：

この API では { "id": "ユーザーID", "password": "パスワード" } というフォーマットの JSON でログインパラメータを渡します。最初はわざと間違えてみることにするので、{ "id": "admin", "password": "string" } というパラメータを指定して、"Execute" をクリックしてみます（正しいパスワードは上記で設定した値 "P@ssword" です）：

この API が実行されて、結果が出力されます。HTTP コードは 401、実行結果本文は { "status": false, "message": "Not valid id/password." } が得られました。一応期待通りの結果といえます：

改めて正しい内容でログインしてみます。実行パラメータを { "id": "admin", "password": "P@ssw0rd" } に変更して再び "Execute" をクリックします：

今度は成功して、HTTP ステータス 200 が返ってきました：

なお、このログインに成功した時の実行結果本文は以下のような JSON になっています：

{
  "status": true,
  "token": "XXXXXXXXXXXXX（トークン文字列）XXXXXXXXX"
}

この token の値がログインに成功した証となるトークンで、他の API 実行時に必要になります（実際のアプリケーションではセッションなどに保管して使うことを想定しています）。例えばユーザーの一覧を取得する API である GET /api/users ではここで取得したトークン文字列をパラメータとして指定する必要があります：

わざと何も入力しなかったり、適当な文字列を入力してこの API を実行しても、{ "status": false, "message": "Invalid token" } とだけ返ってきます：

一方、先程のログイン時に取得したトークンの値をここに指定してから実行すると、ユーザーの一覧（この時点では admin ユーザーのみ）が取得できることが確認できます：

【ブロックチェーンの管理】
こんな感じでブロックチェーンを読み書きできるような REST API を定義するアプリケーションがデプロイ／実行できることが分かりました。実際にはこれ以外にもユーザーを新規に作成したり（POST /api/user）、ユーザーが所有する商品を新規に作成したり（POST /api/item）、その商品の一覧を取得したり（GET /api/items）する API が提供されています。興味があればこれらも使ってみてください。

最後に、何回かブロックチェーンに対してトランザクションを実行した後でブロックチェーンサービス側がどのようになっているかをダッシュボードから確認する方法を紹介します。ダッシュボード画面でチャネルメニューを選択すると、利用中のチャネル一覧が表示されますが、その中の「ブロックの高さ」という数値がブロックチェーン上に記録されているブロックの数を表しています（前回の画面ではここは２でしたので、いくつか積み重なっていることがわかります）：

該当行をクリックして先に進むと、更に詳細な情報を見ることが出来ます。例えば下図の一番上にあるブロックの ">" をクリックして展開します：

「アクション」メニューから「詳細の表示」を選択すると：

このブロックで実行された内容や実行結果を確認することもできます。こういった管理機能が初めから提供されていたり、ストレージなどのインフラ環境を意識する必要がなくなることもマネージドサービスのメリットと考えることができます：

【感想】
以上、ここまで３回に渡って IBM Cloud のマネージド・ブロックチェーンサービスの使い方を紹介してきました。最後にこのサービスを使ってみた上での感想に触れておきます。

まず、これまで自分は業務内外で Hyperledger Fabric ベースのブロックチェーン環境やアプリケーションを構築・開発・運用してきました。慣れもあって構築作業（正確には「開発用途での構築作業」）そのものはあまり苦にならないレベルの作業になっています。ただ起動や停止、再起動といったプリミティブな作業も含めて、構築したブロックチェーン環境のインフラを管理するのはやはり面倒で、本来の目的（この場合は開発用途）を考えると苦痛を伴うものでした。その点から開放されて、開発やテストに注力できる意味や意義は小さくないと感じています。

また「ブロックチェーン内の各ブロックの様子を確認する」というよくある要望に対する機能もサービス内に標準装備されています（これまではそのための参照アプリを別途用意する必要があった）。これによってデバッグの効率も上がりました。このあたりは「マネージドサービスらしい」機能が提供されていると感じます。

一方で、個別アプリケーションをデプロイするまでの手順についてはもう少し簡略化できるのではないかとも考えます。（2018/03/27 時点での）現状の「空の管理者ユーザーを一度作って、ファイルをダウンロードしたら、ユーザーを消してまた管理者ユーザーを作り直してアップロードし直して・・・」という作業は改善の余地があるようにも感じています。この辺りは時間が解決してくれることを期待します。

改めて、このようなブロックチェーンのマネージドサービスが（ベータ版とはいえ）無料で提供されていることは素晴らしいです。興味ある方は是非使ってみていただきたいです。

タグ：: ibm; cloud; hyperledger; fabric; composer; bluemix; blockchain

2018/03/26

IBM Cloud のブロックチェーンサービスを使う（中編）

コメント数:
0 コメント
by dotnsf

この記事の続きです：
IBM Cloud のブロックチェーンサービスを使う（前編）

IBM Cloud から提供されているマネージド・ブロックチェーン・サービスを使う手順を紹介しています。前編ではベータ版で無料（2018/03/26 時点）のサービスインスタンスである Starter Membership Plan の作成手順を紹介しました。今回の中編ではこのインスタンスに実際にビジネスネットワークをデプロイする直前までの、管理者カードを作成する手順を紹介します。なおあくまでベータ版であり、今後の仕様変更等により以下の内容は正しい情報ではなくなる可能性もあります。以下の内容は 2018/03/26 時点での情報であることをご了承ください。

この中編で行う内容は大きく以下の４つあります。結構長くなりますが、順に説明していきます：
・作業の準備
・チャネルの追加
・接続プロファイルのダウンロード
・管理用カードの作成と証明書のアップロード

まず現時点でのダッシュボードの概要画面がこちらです。オーダラー(orderer)、CA、そしてピア(org1-peer1)が１つ動いていることが確認できます：

　（↑前回はここまで）

なお、今回紹介する手順は基本的にはこちらのドキュメントの内容をベースにしています。ただ書かれている内容は Starter Membership Plan 向けのものではなく、Enterprise Membership Plan 向けのものになっています。また内容そのものは少し古いような印象を持っていて、2018/03/26 時点ではここに書かれた内容をそのまま行ってもうまく動かなかったため、少し補足した内容になっています：
https://ibm-blockchain.github.io/platform-deployment/

【作業の準備】
以下のデプロイ作業を行う中で Node.js コマンドを使います。そのため手元の環境に Node.js が導入されている必要があります。各システムに併せた Node.js をインストールしておいてください：

【チャネルの追加】
（↓2018/03/27 追記）
Starter Membership Plan ではデフォルトで defaultchannel というチャネルが初めから追加されるようになりました。以下のチャネル追加作業は行わなくてもよくなりました。ただし Enterprise Membership Plan では引き続きチャネルの追加作業から行う必要があります。
（↑2018/03/27 追記）

最初にチャネルを追加して、ピアに結合する必要があります。またチャネルに参加するメンバー組織を指定する必要もあります。というわけでまずは現在のメンバーを確認しておきます。ダッシュボードのメンバーメニューを表示すると、最初から２つの組織(Company A と Company B)が作成されていることがわかります。今回はこのうちの前者(Company A)だけを使うことにします：

あらためてチャネルメニューを選択します。ここに現在作成済みのチャネル一覧が表示されますが、まだ１つも作っていないので何も表示されません。新規に作成するために「チャネルの要求」をクリックします：

新規に作成するチャネルの情報を入力します。チャネル名称（以下の例では "mychannel1"）と（必要であれば）その説明文を入力して、「次へ」ボタンをクリックします：

次にこのチャネルに最初から参加するメンバー組織を指定します。今回は Company A だけを参加させたいので、Company A の「オペレーター」にチェックを入れます（必要であればここで Company B を参加させることも可能です）。そして「次へ」：

ポリシーを指定して、内容を確認して「要求の送信」ボタンをクリックします。なおポリシーでは承認条件を指定しますが、今回はオペレーターが１名だけなので、その１名の同意を持って承認となります（他の選択肢はありません）：

この時点で Company A をチャネルに参加させるための要求が送信された状態になり、「通知」メニューに保留状態として登録されていることがわかるようになります。この画面のまま「要求の確認」をクリックします：

Company A がチャネルに参加するための同意を行います。（この時点では「拒否」も可能ですが）保留中の内容を「承認」します：

すると承認され（ポリシーが満たされ）、状態が「同意」になります。この同意した状態であらためて「要求の送信」を実行します：

Company A をチャネルに参加させるための「送信」をクリックします（この段階ではもう「拒否」はできません）：

ここまでの作業で保留中だったリクエストが処理され、Company A がチャネルに追加されました：

この状態で「チャネル」メニューを選択すると、作成したチャネルが一覧内に表示されているはずです。ただまだどのピアにも結合されていません。このチャネルを org1-peer1 に結合するため、一覧からチャネルをクリックします：

するとピアをチャネルと結合するためのダイアログが表示されます。現在ピアは org1-peer1 の１つしかないので、このピアを選択（チェック）して、「選択された結合」をクリックします：

これでチャネルを作成し、作成したチャネルを既存のピアを結合することができました：

【接続プロファイルのダウンロード】
次に IBM Cloud のブロックチェーンサービスインスタンスから、接続に必要なプロファイル情報（の元になるファイル）をダウンロードします。この手順は上記のチャネルのピアとの結合を行った後に実行する必要があります（チャネルが結合された状態での接続プロファイルをダウンロードする必要があります）。　

前回の手順を参照してブロックチェーンインスタンスのダッシュボード画面を表示し、概説メニューの接続プロファイルボタンをクリックします：

すると JSON フォーマットで接続情報が記載されたテキストが表示されます。ここから「ダウンロード」ボタンをクリックして、この内容をダウンロードします（ダウンロードファイル名は creds_XXX（文字列）XXX.json という名称になります）。なお、ダウンロードした JSON ファイルは Node.js が導入されたシステム上に保存してください：

この段階で、一度ダウンロードした JSON ファイルをテキストエディタで開きます。そして下部の方にある以下の２つの値（レジストラの enrollId と enrollSecret の値）を確認します（この後で指定することになる値です）：

    :
    :
  "registrar": [
    {
      "enrollId": "xxxxxxxxxx",
      "enrollSecret": "yyyyyyyyy"
    }
  ],
    :
    :

ダウンロードした JSON ファイルを接続プロファイルにコンバートします。この作業は connection-profile-converter というツールを使って行います。まずはこのツールを npm でインストールします（npm は Node.js インストール時に導入されているはずです）：

$ sudo npm install connection-profile-converter -g

connection-profile-converter がインストールできたら、同ツールを使って接続プロファイル（connection.json）を作成します。上記でダウンロードした JSON ファイル、作成したチャネルの名称（上記例であれば mychannel1）、そして出力ファイル名（connection.json）を指定して、以下のように実行します：

$ connection-profile-converter --input （ダウンロードした JSON ファイル名） --output connection.json --channel （作成したチャネル名）

実行後、connection.json というファイルが生成されていれば成功です。失敗する場合、上記のチャネル結合が正しく行えていない可能性があるので再確認してください。

（↓注意）
なお 2018/03/25 時点では、この connection-profile-converter ツールが一部正しく動かない現象を確認しています。具体的には出力結果に含まれるべき requestURL と eventURL の値が正しく含まれないケースがあるようです。この現象に該当するかどうかを確認するには、上記手順の結果生成された connection.json をテキストエディタで開き、"peers" という文字列を検索します：

    :
    :
  "peers": [
    {
      "cert": "-----BEGIN CERTIFICATE----- ******"  //. ← "cert" だけで "requestURL" と "eventURL" がない！
    }
  ],
    :
    :

"peers" は配列値となっているはずですが、その各要素の中に "requestURL" と "eventURL" の値が含まれている必要があるのですが、上記例のようにこれらの値が含まれていないケースがあることを確認しています。その場合は以下のようにテキストエディタで直接編集して、これらの値を記入してください。なおここで記入する値はダウンロード前に確認した接続プロファイル情報内の peers 配列内に書かれた "url" の値を "requestURL" として、また "eventURL" の値をそのまま "eventURL" として追加してください：

　　（↓青字部分のように転記して保存する）

    :
    :
  "peers": [
    {
      "requestURL": "grpcs://*****-org1-peer1.us2.blockchain.ibm.com:31002",
      "eventURL": "grpcs://*****-org1-peer1.us2.blockchain.ibm.com:31003",
      "cert": "-----BEGIN CERTIFICATE----- ******"
    }
  ],
    :
    :

Starter Membership Plan の場合はこれでいいのですが、Enterprise Membership Plan で、ピアが複数ある場合はすべてのピアについて同様の転記を行う必要があります。

（↑注意）

これで接続プロファイルの準備ができました。

【管理用カードの作成と証明書のアップロード】
次に BNA ファイルのデプロイするための管理者向けカードを用意する必要がありますが、そのための準備として一時的な管理者権限や各種証明書ファイルをサービスから取得してカードを作り、その証明書をサーバーにアップロードする、という手順を行う必要があります。

上記手順で作成した connection.json ファイルと、その前に取得した ID とシークレットの情報を使って、コマンドラインから順に操作します：

$ sudo npm install composer-cli -g
　　（↑composer コマンドをインストール）
$ composer card create -p connection.json -u xxxxxxxxxx -s yyyyyyyyy -r PeerAdmin -r ChannelAdmin
　　（↑上記で確認した enrollId と enrollSecret の値を使って一時的な管理者用カードファイル: admin@fabric-network.card を作成）
$ composer card import -f admin@fabric-network.card
　　（↑作成した管理者用カードをシステムにインポート）
$ composer card list
　　（↑インポートできたこと（出力結果に admin@fabric-network のカードが含まれていること）を確認）
$ mkdir ~/.identityCredentials
　　（↑証明書保存用ディレクトリを作っておく）
$ composer identity request --card admin@fabric-network --path ~/.identityCredentials
　　（↑証明書ファイルをダウンロード。~/.identifyCredentials に *.pem ファイルがダウンロードされる）
$ composer card delete --name admin@fabric-network
　　（↑一時的に作成したカードを削除）
$ composer card list
　　（↑出力結果から admin@fabric-network のカードが消えていることを確認）
$ composer card create -p connection.json -u admin -c ~/.identityCredentials/admin-pub.pem -k ~/.identityCredentials/admin-priv.pem
　　（↑改めて証明書ファイルを使って管理者用カードファイル: admin@fabric-network.card を作成）
$ composer card import -f admin@fabric-network.card
　　（↑作成した管理者用カードをシステムにインポート）
$ composer card list
　　（↑インポートできたこと（出力結果に admin@fabric-network のカードが含まれていること）を確認）

ここまでの作業でブロックチェーンサービスに対する管理者カード admin@fabric-netowrk を作成して、システムにインポートすることができました：

最後にここで使った公開鍵（admin-pub.pem）の内容をサーバーにもアップロードしておく必要があります。

ダッシュボード画面に戻り、「メンバー」の「証明書」タブを選択します。ここには証明書の一覧が表示されますが、この時点では何も表示されていません。新しい証明書をアップロードするので、「証明書の追加」ボタンをクリックします：

「証明書の追加」ダイアログが表示されたら、証明書の名前（ハイフンなどは使えません）を指定した後に、ダウンロードした admin-pub.pem ファイルの内容を（-----BEGIN CERTIFICATE----- から -----END CERTIFICATE----- まで）コピー＆ペーストして入力し、「送信」ボタンをクリックします：

ピアの再起動を確認するメッセージが表示されたら「再起動」をクリックしてピアに再起動をかけます：

正しく再起動が行われると、先程まで空だった証明書一覧に指定した証明書が表示されるようになります：

この証明書をチャネルに同期します。ダッシュボードの「チャネル」メニューから該当チャネル（下図では "mychannel1"）のアクションメニューを開き、「証明書の同期」を選択します：

証明書を同期する確認ダイアログが表示されるので「送信」をクリック：

証明書の同期が行われました。これでブロックチェーンサービス内のネットワーク（fabric-network）にアプリケーションをデプロイするための管理者アカウント（admin@fabric-network）と、そのカードファイル（admin@fabric-netowrk.card）が作成され、サービス側に証明書が用意された状態になりました：

ここまで来ると、Hyperledger Composer Playground 等で作成したビジネスネットワークアーカイブファイル（BNA ファイル）をデプロイしてビジネスネットワークを開始することができるようになりました。ここまでの作業を自分のマシンや IaaS 環境で行おうとするとこちらで紹介するような作業が必要になり、その上起動や停止、再起動といった管理・運用を自分で行う必要があるわけです。ここまでの手間はともかく、少なくとも管理・運用部分は必要なくなる環境が用意されているという意味ではやはり便利だと感じています：
Hyperledger Fabric & Composer 環境の導入手順（2018/2月版）

実際に個別のアプリケーションをデプロイする手順についてはまた次回に。

タグ：: ibm; cloud; bluemix; hyperledger; fabric; composer; blockchain

2018/03/25

IBM Cloud のブロックチェーンサービスを使う（前編）

コメント数:
0 コメント
by dotnsf

IBM Cloud からはオープンソースのブロックチェーン基盤である Hyperledger Fabric をベースとしたマネージドなブロックチェーン環境が提供されています。この 3/21 からは Starter Membership Plan という、名前の通りに小規模向けの比較的安価なプランも提供されるようになりました。2018/03/25 時点ではベータ版で、通常プランと比較していくつかの制約はありますが、無料で利用できます。早速使ってみました。今回のブログエントリではサービスを選択して利用可能にする所までの手順を紹介します。あくまでベータ版であり、今後の仕様変更等により以下の内容は正しい情報ではなくなる可能性もあります。以下の内容は 2018/03/25 時点での情報であることをご了承ください。

また、以下で紹介する IBM Cloud から提供されているブロックチェーンサービスは、IBM Cloud の無料アカウント版であるライトプランからは利用できません（2018/03/25 時点）。以下で紹介する Starter Membership Plan のベータ版は無料ですが、ライトプランのアカウントからはサービスを選択することはできません。実際に試す場合はクレジットカードを登録するなどしてスタンダードプラン等に移行してからご利用ください。

IBM Cloud にログインしてからカタログを表示し、ブロックチェーンカテゴリーを選択すると、対象サービスが "Blockchain" だけに絞り込まれます。これを選択します：

次の画面でリージョンやプランを選択します。今回紹介する Starter Membership Plan は 2018/03/25 時点では米国南部リージョンからのみ提供されています。そのためロケーションを選択する箇所で「米国南部」を選ぶようにしてください：

画面を下にスクロールすると利用プランの選択画面になります。上記で米国南部リージョンを選択しているとここが選択肢になっていて、Starter Membership Plan か Enterprise Membership Plan が選べるようになっているはずです（米国南部以外のリージョンだと有料の Enterprise Membership Plan のみ）。ここで Starter Membership Plan を選択して「作成」ボタンをクリックします：

なお上図にも書かれているように Starter Membership Plan の場合、以下のような制約事項があります。シングルピア環境なので多数決をとるようなスマートコントラクトを実装することはできませんが、アプリケーションとしての実装はほぼ変わらないものを動かすことが可能になります：
・組織は２つまで
・各組織ごとに１ピアまで

サービスが作成されるとダッシュボード内のサービス一覧内にブロックチェーンサービスが表示されるようになります：

作成したブロックチェーンサービスを選択するとブロックチェーンサービスの概要が表示されます（この辺りはプランによる違いはないと思われます）。ここから実際にブロックチェーンを操作したり管理するためのダッシュボードを開いてみます。「管理」タブの「起動」ボタンをクリックします：

すると別ウィンドウでブロックチェーン環境のダッシュボードが表示されます。下画面ではトランザクションの順番を決定するオーダラーや、CA（認証局）、そしてピアとなるサーバー環境が動いている様子が確認できます：

これまで自分で Hyperledger Fabric 環境を構築しようとすると、サーバー環境を用意した上でこれらの各種サーバーを自分で作って運用する必要がありました。そこまでの構築作業とサーバーとしての運用部分を IBM Cloud に任せて、実際のアプリケーション開発・実行やユーザー登録といった実務に集中できる環境として提供されていることが分かります。ブロックチェーンに興味のある方は是非今のうちに色々使ってみてはいかがでしょうか？

なお、今回は IBM Cloud 上にサービスを作る作業までを紹介しました。次回以降でこのサービスにビジネスネットワークアプリケーションをデプロイして動かせるようになるまでの手順を紹介する予定です。

タグ：: ibm; cloud; bluemix; blockchain; hyperledger; fabric; composer; node; bna

2018/03/21

Instagram API を使う（SandBox モード）

コメント数:
0 コメント
by dotnsf

インスタグラムの API を使うと、インスタグラムの写真を使ったアプリケーションを開発することができます。その開発例を準備段階から説明します。詳しくは後述しますが、今回はインスタグラム API の "SandBox" モードを使ったサンプルを紹介します。

【アプリケーション登録】
まず大大大前提としてインスタグラムのアカウントが必要です。こちらは取得済みとした上で以下を記載します。

インスタグラム API を使うには、インスタグラムデベロッパーであらかじめアプリケーションを登録しておく必要があります。これから API を使って作るアプリケーションを最初に登録しておく必要がある、という意味です。

というわけでまずは PC からインスタグラムデベロッパーにアクセスしてログインし、"Manage Clients" をクリックします：

すると現在登録済みのアプリケーションの一覧が表示されます（まだ１つも登録していない場合は何も表示されません）。新たにアプリケーションを登録するにはこの画面で "Register a New Client" をクリック：

新規登録画面ではまず最初に "Security" タブを選んで、"Disable implicit OAuth" のチェックを外しておきます：

改めて "Details" タブに移動し、必要な項目を入力します。Application Name（アプリケーション名）は任意に指定できますが、"Instagram" や "Insta", "IG" といった文字列は使えない、という規約があるようです。後は Description（説明）を記入して、Company Name（会社名）は個人名でも空でもいいようです。大事なのは Website URL と Valid redirect URIs、ここはこの後の OAuth 認証で使うため、（アプリケーションとして動いていなくてもよいので）実在する URL を指定する必要があります。なおここで指定する値は後から編集することも可能です：

すべて指定したら下にスクロールして「私はロボットではありません」の横をチェックします：

自動化されたロボットでないことを証明するための質問に答えます。下の例では画像からお店を選べ、とのこと：

まあこれとこれとこれ、、かな？？　という感じにチェックして確認ボタン：

正しい選択ができているとロボットではないことが証明できて、"Register" ボタンがクリックできるようになります：

無事にアプリケーションの登録が完了し、CLIENT ID が取得できました。ここに表示されている CLIENT ID の値はこの後に利用するので控えておいてください：

【アクセストークン取得】
インスタグラムの API は「アクセストークン」と呼ばれる文字列を使って利用します。このアクセストークンは上記手順で指定した情報を知っている（指定できる）人だけが取得できます。なお今回対象としている SandBox モードの場合、１つの登録アプリケーションにつき、アクセストークンが取得できるユーザーは20人までという上限がありますが、以下で紹介するアプリケーションの場合は本人だけが使う想定なので問題ないと思っています。

ウェブブラウザで以下の URL にアクセスします：

https://instagram.com/oauth/authorize/?client_id=(Client ID)&redirect_uri=(Redirect URI)&response_type=token&scope=public_content

(CLIENT ID) 部分には上記で取得した CLIENT ID の値を、(Redirect URI) 部分には取得時に指定した Valid Redirect URI の値にそれぞれ置き換えて指定します。すると以下のような画面になり、Instagram の画像やプロフィール情報にアクセスすることを許可するか？という確認画面が表示されるので "Authorize" をクリックして許可します：

するとブラウザ画面が切り替わり、Rediret URI で指定した URL に転送されます。この時の URL には acess_token=XXXXXX..XXXXXX という形でアクセストークンが付与されています：

この値がアクセストークン値で、この文字列を使うことでインスタグラム API を利用することができるようになります。この値を控えておきます：

https://dotnsf-myphotos.us-east.mybluemix.net/#access_token=XXXXXX..XXXXXX

【サンプルアプリケーション実行】
インスタグラム API を使った Node.js のサンプルウェブアプリケーションをこちらに用意しておきました：
https://github.com/dotnsf/myphotos

このコードをダウンロード＆展開するか、git clone して手元に用意してください。そして settings.js ファイルをテキストエディタで開き、exports.access_token の値を先程確認したアクセストークンの値に編集して保存します：

この状態のアプリケーションを指定した Redirect URI で動くように転送／コピー／デプロイします。これで準備は完了です。

実際の動作を確認するには（できればスマホで）Redirect URI にアクセスします。すると自分のインスタグラムの最新20件の画像／動画が確認できるアプリケーションが表示されます：

次／前の画像を見るには左右に（フリックやマウスドラッグで）スライドさせます：

　（↑伝わりにくいけど、右から左へスライド中の様子）

すると次／前の画像に切り替わります：

表示されている画像をタップすると、インスタグラム上の同画像ページに移動し、タイトルやタグ、コメントも確認できます：

インスタグラムの API を使って自分の画像をカルーセル表示する、というサンプルでした。実際に API が正しく動いて画像を取得できていることも確認できました。

【Sandbox モードについて】
Sandbox モードは誰でも気軽にインスタグラム API を使えるように 2016 年６月に用意されたモードです。アカウントと（上記の）アプリケーションの登録をするだけで使えるようになるというメリットがあります。

一方で、その利用には制約があります。使える API やその結果は限られたものだけです。私個人が確認した限りでは、ユーザー名からユーザー ID を検索する API は自分自身の ID については期待通りに動いたのですが、フォローしているユーザーや他のユーザーの検索はできませんでした（実行結果が空だった）。といった制約があり、この制約をなくすには Sandbox モードではなく、正式な API を利用する必要があり、そのためにはアプリケーションの申請が必要になります。個人的に正式な申請をした経験はないのですが、ウェブ上にはそういった情報もあるようです。１つだけ参照リンクを貼っておきます：
Instagram APIの審査を通した人に話を聞いてみた。

また Sandbox モードにおける制約等の（最新の）情報は公式ドキュメントを参照ください：
Sandbox Mode

タグ：: instagram; api; sandbox

2018/03/19

Node-RED で if 分岐処理は意外と面倒？

コメント数:
0 コメント
by dotnsf

Node-RED は GUI で便利にデータの流れを定義することができるビジュアルデータフローエディタです。HTTP(S) や MQTT など多くのプロトコルにも対応しており、これまでプログラミングを記述しないと実現できなかったようなデータの流れを、個別の機能を持ったノードを組み合わせることで、ほぼコーディングレスで実現できるという点が画期的なツールです。このブログでも何度か紹介してきました。

（このエントリで紹介した時のデータフロー。これだけでデータベース入出力を行うウェブアプリケーションを作ってます）

さてそんな簡単で便利な Node-RED ですが、「Node-RED だと（一般的なプログラミングと比較して）処理が複雑になるケース」もあります。こういう視点で語られているドキュメントを目にすること-がなかったこともありますが、Node-RED がより多くの現場で使われていく上での適材適所を考える上では必要になってくると思っていることもあり、そんな例を紹介しようと思いました。

今回、Node-RED と比較するプログラミング環境はサーバーサイド JavaScript である Node.js とします。もともと Node-RED 自体が Node.js 上で動くアプリケーションであり、Node-RED の function ノード内では JavaScript を直接記述することもできるという点で、比較対象としては相応しいのではないかと思っています。

で、この「Node-RED での処理が複雑になるケース」の典型例の１つが if 分岐処理だと自分の拙い経験上で思っています。if 分岐はプログラミング言語を学ぶ中でのかなり早い段階で遭遇することになる基本的な処理ですが、Node-RED では必ずしも基本的とは言えない内容だと感じています。

例を挙げて説明します。例えばこんな処理を行うケース：

・気温(temp)と湿度(humid)という２つの変数値から「不快」か「不快ではない」かを判断する。
・気温が 30 以上で、かつ humid が 50 以上だと不快
・気温が 30 未満で、かつ humid が 80 以上だと不快
・それ以外は不快ではない

よくあるレベルのシンプルな分岐処理ですよね（湿度は％単位で与えられるものとします）。この処理を Node.js （や他の一般的なプログラミング言語）の if 分岐で行おうとすると、こんなシンプルな感じになると思います：

if( ( temp >= 30 && humid >= 50 ) || ( temp < 30 && humid >= 80 ) ){
  //. 不快と判断

}else{
  //. 不快ではないと判断

}

では同じ処理を Node-RED で実現しようとするとどうなるでしょうか？仮に msg.payload.temp と msg.payload.humid にそれぞれ温度と湿度の値が入っているという前提で作ることを考えてみます。

Node-RED で条件分岐を行うノードは "switch" ノードです。機能カテゴリ内にある switch ノードをキャンバスにドラッグ＆ドロップします：

ドロップした switch ノードをダブルクリックして、処理内容を設定する画面に切り替えます：

このノードでは温度(msg.payload.temp)に関する条件分岐を行うことにします。今回は30度以上か、30度未満かで処理を分岐する必要があります。というわけで、プロパティの値を (msg.)payload.temp にして、その条件を指定する部分では「30以上の数値」となるように指定します。またノードの表示用の名前を「温度」と設定します：

今回の処理では温度が「30 以上の場合」と「30 未満の場合」の２つの条件に分岐する必要があります。前者は上記で指定したので後者を追加します。この画面内の「追加」ボタンをクリックします：

すると条件部分が１行追加され、もう１つの条件を指定できるようになりました。ここでは「 30 未満の数値」となるような条件を指定します（下図のようにするか、または後述のように"otherwise"（その他）という選択肢でも同じ結果になります）。　これで msg.payload.temp の値が 30 以上であれば１へ、30 未満であれば 2 へ行く、という分岐処理が定義できたことになります。ここまでできていることを確認して「完了」ボタンをクリック：

すると switch ノードに指定した名前が表示されるのと同時に、ノード右側の出口が２つに増えていることが分かります。上側の接続子が１、下側の接続子が２を意味しており、ここから条件を分岐して処理できるようになりました：
2018031307

続けて湿度の条件を追加します。温度 switch ノードの①に別の switch ノードを追加して接続します：

追加した switch ノードをダブルクリックして編集ダイアログを出し、以下のように設定します。　名前は「湿度」、プロパティは湿度の値である (msg.)payload.humid 、ここは温度が 30 度以上の場合に処理されるノードなので、分岐の条件は「 50 以上の数値」か「otherwise（それ以外）」として、最後に「完了」をクリックします：

この時点でキャンバス上は以下のような２つのノードが設定されているはずです。③は温度が30度以上で、湿度は50以上なので「不快」、④は温度は30度以上ですが、湿度は50未満なので「不快ではない」という分岐がされたことになります：

では続けて②のノードの続きの処理を追加します。更にもう１つの switch ノードをキャンバスに追加し、温度 switch ノードの②と接続します。そしてノードの設定内容を以下のようにします。先程の湿度ノードに近い内容ですが、このノードは温度が 30 度未満の場合に処理されるので、湿度が 80 以上だった場合に不快、それ以外であれば不快ではないと分岐するノードにしています：

ここまでの作業でキャンバスには以下のように３つの switch ノードが用意されているはずです。そして③と⑤が不快、④と⑥が不快ではない場合の処理を行う流れになります：

後はこの分岐した条件にあわせて処理を繋げていけばよいので、例えばこんなフローになっていくんでしょうかね：

というわけで、目的の条件分岐を Node-RED で実現することはできました。　ただ Node.js では以下のような超シンプルな分岐処理だった割にはフローが複雑になってしまっている面は否めません。これが更に複雑な分岐処理だった場合、Node-RED ではどれだけ switch ノードを並べないと行けなくなるのか・・・：

if( ( temp >= 30 && humid >= 50 ) || ( temp < 30 && humid >= 80 ) ){
  //. 不快と判断

}else{
  //. 不快ではないと判断

}

原因というわけではないのですが、Node-RED の switch ノードは単一のプロパティに対する条件分岐しか行えないため、複数の値を元に条件を分岐するようなケースではどうしてもノードを多用する必要が出てきてしまいます。この部分だけを切り取って結論にはできないと思いますが、Node-RED では if 文による分岐処理は必ずしも簡単ではないということだと思います。

タグ：: nodered; node-red

まだプログラマーですが何か？

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf