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

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

タグ:cloud

IBM Cloud から提供されている IoT サービスである IBM Watson IoT Platform (の QuickStart)にメッセージをパブリッシュする Node.js のサンプルアプリケーション(とソースコード)を作って公開しました:
https://github.com/dotnsf/mqtt_pub_ibmiot

2018051501


主要なソースコードは app.js だけですが、内部的に MQTT.js ライブラリを使っています:
2018051500


主な挙動としては settings.js で指定された内容に併せて、1秒(デフォルト)ごとに0から1つずつ増えるカウンタ値、タイムスタンプ値、実行したマシンの CPU 稼働率、12回周期のサイン値およびコサイン値、そしてランダムな値が JSON で IBM Watson IoT Platform の QuickStart に送られます。その際のデバイス ID 値は settings.js 内で指定されていればその値が、されていなければ動的に生成されるようにしました。


IBM Cloud 環境で Node-RED ランタイムを作ると動作を確認しやすく、またそのためカスタマイズの勘所が分かりやすいと思っています。以下、この環境での動作確認方法を紹介します。

まずはこのサンプルを動かす前提として Node.js がインストールされたマシンが必要です。Windows/MacOS/Linux/Raspberry Pi などなど、Node.js をインストール可能なマシンで導入を済ませていると仮定して以下を続けます。

次に上記リポジトリから git clone またはダウンロード&展開して、アプリケーションのソースコードを手元に用意します:
$ git clone https://github.com/dotnsf/mqtt_pub_ibmiot
$ cd mqtt_pub_ibmiot

必要に応じてテキストエディタで settings.js の中身を編集します。とはいえ、変える必要がありそうなのは exports.interval の値(メッセージデータを送信する時間間隔(ミリ秒)。デフォルト値は 1000 なので1秒ごとにメッセージを送信する)と、exports.deviceId の値(後で指定するデバイス ID。デフォルトは空文字列なので、後で自動生成された値になります)くらいです。なお、settings.js の値は変えなくても動きます。


※もし exports.deviceId の値を編集する場合は、("test" のような簡単な単語ではなく)他の人が使わないようなユニークな値になるよう指定してください。exports.deviceId の値をデフォルトのから文字列のままにする場合は、実行時ごとにデバイス ID を生成するので、この値は実行ごとに変わることに留意してください。


ではアプリケーションの動作に必要なライブラリをインストールします:
$ npm install

そして実行します:
$ node app

実行が成功して IBM Watson IoT Platform に接続すると、"client#connect: " という文字列に続いてデバイス ID が画面に表示されます(以下の例では 5d7436e992d0)。この値は settings.js で指定した場合はその値が、指定しなかった場合は自動生成された値が表示されます。この後で使うのでメモしておきます:
2018051502


※なお、メッセージを送信しているアプリケーションの終了方法は特に用意していないので、終了する場合は Ctrl+C で強制終了してください。


これでサンプルアプリケーションが IBM Watson IoT Platform に接続し、exports.interval で指定した値の間隔でメッセージデータを送信し続けている状態になりました。

最後にこの送信データを Node-RED で確認してみます。IBM Cloud で Node-RED ランタイムを作成し、IBM IoT のインプットノード(右側にジョイントのあるノード)と、debug アウトプットノードをキャンバスに配置して接続します:
2018051503


↑IBM Watson IoT Platform サーバーにメッセージが送られてきたらその payload の内容をデバッグタブに表示する、というシンプルなフローです。


IBM IoT インプットノードをダブルクリックし、Authentication が Quickstart になっていることを確認した上で、Device Id 欄に先程確認した実行中アプリケーションのデバイス ID を指定します。そして「完了」してから、このアプリケーションを「デプロイ」します:
2018051504


すると、Node-RED 画面右のデバッグタブに(デフォルトであれば)1秒おきにメッセージが追加されていく様子が確認できるはずです:
2018051505


メッセージの1つを選んで展開してみると、元のアプリケーションから送信されたカウント値(count)、タイムスタンプ値(timestamp)、CPU稼働率(cpu)、サイン値(sin)、コサイン値(cos)、そして乱数値(random)が確認できます。つまり Node.js を使って動かしたアプリケーションから MQTT 経由で実際にデータが送信されていて、その内容を Node-RED と IBM IoT インプットノードを使って取り出して確認できたことになります:
2018051506


送信データをカスタマイズしたり、別の値を送信したい場合は app.js をカスタマイズして、publish 時に送信する data 変数の中身を変える(必要な値を取得して、この中に JSON で入れる)ということになります。こちらはシンプルなのでなんとなく理解できるんじゃないかな・・・と期待しています。


また Node-RED の場合であれば node-red-dashboard と組み合わせることで、ここで取得した値を簡単にチャート化することもできます。例えば Gauge ノードと Chart ノードを使って CPU 負荷とサインカーブをこんな感じで・・・
2018051600


IBM Watson IoT Platform の Quickstart にデータを送信するサンプルとして使ってくださいませ。

IBM Cloud から提供されているコグニティブエンジン IBM Watson を使って、
 1. MNIST の手書き数字サンプルデータを学習させて、
 2. 実際に手書き数字データを送信して、認識させる
という、「学習」と「問い合わせ」のコグニティブエンジン一連の作業を再現させてみます(した)。


今回紹介する一連の作業では、IBM Cloud の以下のサービスを連動させて使います:
 ・IBM Watson Studio
 ・IBM Machine Learning
 ・IBM Cloud Storage
 ・SDK for Node.js ランタイム(上記2のサンプルをクラウド上で稼働させる場合)

以下で紹介する手順は IBM Cloud の無料版であるライトアカウントを使っても同様に動かすことができるようにしているので、興味ある方は是非挑戦してみてください。


1. MNIST の手書き数字サンプルデータを学習させる

人工知能とか機械学習とかを勉強していると、そのチュートリアルとして "MNIST" (Modified National Institute of Standards and Technology)を目にする機会があると思っています。機械学習のサンプルとして手書きで描かれた数字の画像データと、そのラベル(何の数字を描いた画像なのか、の答)が大量にサンプルデータとして公開されており、機械学習を説明する際の様々な場面で使われています:
2018050800


今回、この MNIST データを IBM Watson StudioIBM Watson Machine Learning を使って学習させ、かつ問い合わせ用の REST API を用意します。

・・・と、偉そうに書いていますが、この部分の手順については私の尊敬する大先輩・石田剛さんが Qiita 上でわかりやすく紹介していただいています。今回の学習部分についてはこの内容をそっくりそのまま使わせていただくことにします(石田さん、了承ありがとうございます):
Watson Studioのディープラーニング機能(DLaaS)を使ってみた 

2018050801

↑この作業で MNIST の手書き画像を IBM Watson Machine Learning を使って学習させ、その問い合わせ API を REST API で作成する、という所までが完了します。


2. 手書き数字データを送信して、認識させる

マウスやタッチ操作で画面に手書き数字を描き、その内容を 1. の作業で用意した REST API にポストして何の数字と認識するか、を確認できるようなアプリケーションを作成します。

・・・というか、しました(笑):
2018050804


PC またはスマホでこちらのサイトにアクセスすると体験できるようにしています:
https://dotnsf-fingerwrite-mnist.us-east.mybluemix.net/


フロントエンドはもともと以前に「イラツイ」という手描きイラスト付きツイートサービスを作った際のものを丸パク応用し、問い合わせ API を呼び出すバックエンド部分はデプロイしたモデルの Implementation タブ内にある JavaScript の Code Snippets を参考に作りました。この Code Snippents は各種言語のサンプル(アクセストークンを取得してエンドポイントにリクエストするサンプル)が用意されていて、とても便利です:
2018050809


アプリケーションの使い方はマウスまたは指でキャンパス部分に数字を描いて、"fingerwrite" ボタンを押すと、その描いた数字データを上記 1. で作成した REST API を使って識別し、最も可能性が高い、と判断された数値とその確率が表示される、というものです:
2018050805


PC 画面の場合に限りますが、デバッグコンソールを表示した状態で上記を実行すると、可能性が最も高いと思われた結果だけでなく、全ての数値ごとの確率を確認することもできます:
2018050806

↑常に「2」の確率が高くなってる気がする。。原因は学習の調整不足だろうか??それともデータを渡すフロントエンド側??(2018/May/09 ピクセル毎のデータを取り出すロジックに不具合があったので、修正しました)


なお、この 2. のサンプルアプリは Node.js のソースコードを公開しているので、興味ある方は自分でも同様のサイトを作成してみてください:
https://github.com/dotnsf/fingerwrite-mnist

2018050807


このソースコードから動かす場合、事前に settings.js ファイルを編集しておく必要があります:
2018050808


まず上の3つ、 exports.wml_url, exports.wml_username, exports.wml_password の3つの変数の値は 1. で MNIST データを学習した際に使った IBM Watson Machine Learning サービスのサービス資格情報を確認して、その中の url, username, password の値をそれぞれコピー&ペーストしてください(最初の exports.wml_url だけはおそらくデフォルトで url の値になっていると思います。異なっていた場合のみ編集してください):
2018050803


また一番下の exports.ws_endpoint の値は同様に 1. で使った IBM Watson Studio の Web サービスのエンドポイント(学習モデルをデプロイした時に作成した Web サービス画面の Implementation タブから確認できる Scoring End-point の値)をそのまま指定します:
2018050802


ここまでの準備ができた上でアプリケーションを実行します。ローカル環境で動かす場合は普通に npm install して node app で起動します:
$ npm install
$ node app

IBM Cloud (の SDK for Node.js)を使って動かす場合は、cf ツールbx ツールを使って、そのまま cf push で公開されます:
$ cf push (appname)


今回紹介した方法では IBM Watson Studio と IBM Watson Machine Learning を使って画像データを学習させ、その学習結果に対して REST API で問い合わせをする、という機械学習の一連の流れを体験できます。また学習データ(とモデリング)を変更することで、異なる内容の学習をさせる応用もできますし、学習した内容に問い合わせを行う API も自動生成されるので、フロントエンドの開発も非常に楽でした。
 

業務の忙しさを言いわけに、IBM Cloud の新しい情報に疎くなっていました。で「なんか面白そうな API ないかなあ」とカタログを眺めていたら・・・

「金融」カテゴリに、、ん??
2018041901


こっ、これはっ!? もしやシグナイト!?
2018041902


おー、やっぱりシグナイトだ。世界中の株や為替を始めとする色々なマーケット情報を提供するシグナイトの API が IBM Cloud のサードパーティ API としても登録されていたのでした(知りませんでした、何か)。ただこの API はここからそのまま使えるわけではなく、別途アカウント登録が必要なようで、↓ひとつ進んだこのページの "Xignite" と書かれたリンクからアカウント登録に進みます:
2018041903


すると、この↓ページにジャンプします。ほうほう、シグナイト API は本来有料なのですが、IBM Bluemix(Cloud) ユーザー向けに7日間のトライアルが提供されている模様です:
https://market-data.xignite.com/IBM_Marketplace.html

2018041900


で、ここから名前やメールアドレスを指定して登録し、アドレスに届いたメールの内容を使って申請していきます。途中、以下のような画面になり、こんかいのトライアルで利用する API を1つ指定します(どうやらトライアルで利用できるのは一つだけのようで複数指定はできないようでした)。迷いましたが、個人的にも取引経験のある FX 向けの XigniteGlobalCurrencies を選択しました:
42


更に先に進み、アカウントのパスワードを指定してアクティベートします:
33


アクティベートが完了すると登録したアドレスに以下のようなメールが届きます。ここから "token" と書かれたリンクをクリックして、API 用のトークンを確認できます:
18


再びシグナイトのページに移動し、以下の赤枠部分に API 用のトークンが表示されています。API 実行時にこのトークン文字列が必要になります:
52


次にどんな API が提供されているのか調べてみます。シグナイトの API カタログページから今回選択した API(上記例の場合は XigniteGlobalCurrencies)を探し、その "API List" と書かれたボタンをクリックします:
26


すると指定した種類(XigniteGlobalCurrencies)の API 一覧が表示されます。ここでどんな API が存在して、どうすると実行できるのか、実際の実行結果がどんなフォーマットになるのか、といった情報を確認したり、実際に実行したりできます:
2018041904


試しにひとつ使ってみます。左側の API 一覧からリアルタイムレートを参照する GetRealTimeRate を選びます。すると画面右側が GetRealTimeRate 用に切り替わり、ここから各種パラメータを指定して実際に実行することができます(注 実行できるのはログイン時のみ)。以下の例では Request タブで
 Symbol: USDJPY(米ドル円レート)
 Result Format: JSON(結果を JSON で取得)
を指定しました。するとその下の URL が動的に切り替わり、この条件で API を実行する際のエンドポイント URL を示してくれます。下図ではモザイクをかけていますが、この URL にはトークンが含まれているので、そのままコピペ等で実際に確認することも可能な URL になっています。最後に下の "View Result" ボタンを押して実行します:
2018041905


成功すると実行結果が下部に JSON フォーマットで表示されます:
2018041906


実際の中身はこんな感じ、ほぼリアルタイムに値が取得できています(このタイミングで1ドルを買うと 107.374 円、売ると 107.368 円で、仲値が 107.371 円、という結果でした):
{
 "Outcome": "Success",
 "Message": null,
 "Identity": "Request",
 "Delay": 0.0167211,
 "BaseCurrency": "USD",
 "QuoteCurrency": "JPY",
 "Symbol": "USDJPY",
 "Date": "04/19/2018",
 "Time": "9:18:18 AM",
 "QuoteType": "Spot",
 "Bid": 107.368,
 "Mid": 107.371,
 "Ask": 107.374,
 "Spread": 0.006,
 "Text": "1 United States dollar = 107.371 Japanese yen",
 "Source": "SIX Financial Information"
}

トライアルだと7日間限定とはいえ、こんな便利な API が IBM Cloud から利用できるようになっていたんですねー。パラメータを変えて実行したり、他の API もここから同様に試すことができそうです。


なお、トライアルではない正式版(?)の API の価格については Flexible Pricing Model が適用されるようで、価格そのものはウェブからは確認できませんでした。興味ある方はこちらから問い合わせる必要がありそうです:
https://www.xignite.com/Pricing

 

この記事の続きです:
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 のブロックチェーンサービスにデプロイすることを目的に説明します:
2018032601



【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
  (↑新たに作成したカードをインポート)
$ composer card list
  (↑カードの一覧を表示して、結果に admin@bcdev-basickit-network が含まれることを確認)

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


最後に admin@bcdev-basickit-network がビジネスネットワーク上で正しく動いている(アクセスできる)ことを確認します:
$ composer network ping -c admin@bcdev-basickit-network
  (↑admin@bcdev-basickit-network への ping が成功することを確認)

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


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

Swagger API Document は api/public/doc フォルダ内にあります。つまり api フォルダ内でアプリケーションを実行するのですが、一部設定項目があります。そのためにまずは一度アプリケーションを実行します:
$ cd api
  (↑ api/ フォルダへ移動)
$ npm install
  (↑ライブラリのインストール)
$ node app
  (↑アプリケーション実行)

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


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


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

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


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



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


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


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


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


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


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


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


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


なお、このログインに成功した時の実行結果本文は以下のような JSON になっています:
{
  "status": true,
  "token": "XXXXXXXXXXXXX(トークン文字列)XXXXXXXXX"
}

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


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


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


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


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


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


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


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


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

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

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

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


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


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


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

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


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



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



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




【チャネルの追加】
(↓2018/03/27 追記)
デフォルトで defaultchannel というチャネルが初めから追加されるようになりました。以下のチャネル追加作業は行わなくてもよくなりました。
(↑2018/03/27 追記)

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


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


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


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


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


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


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


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


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


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


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


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


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



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

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


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


この段階で、一度ダウンロードした JSON ファイルをテキストエディタで開きます。そして下部の方にある以下の2つの値(レジストラの 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" として追加してください:

2018032502


  (↓青字部分のように転記して保存する)
    :
    :
  "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 を作成して、システムにインポートすることができました:
2018032503


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

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


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


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


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


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


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


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


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


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



このページのトップヘ