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

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

この記事の続きです:
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月版)


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



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" だけに絞り込まれます。これを選択します:
2018032401


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


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


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


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


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


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


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

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



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


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

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

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


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


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


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


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


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


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


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


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


【アクセストークン取得】
インスタグラムの API は「アクセストークン」と呼ばれる文字列を使って利用します。このアクセストークンは上記手順で指定した情報を知っている(指定できる)人だけが取得できます。なお今回対象としている SandBox モードの場合、1つの登録アプリケーションにつき、アクセストークンが取得できるユーザーは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" をクリックして許可します:
2018032108


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


この値がアクセストークン値で、この文字列を使うことでインスタグラム API を利用することができるようになります。この値を控えておきます:
https://dotnsf-myphotos.us-east.mybluemix.net/#access_token=XXXXXX..XXXXXX


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

2018032101


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


2018032102


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


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


次/前の画像を見るには左右に(フリックやマウスドラッグで)スライドさせます:
IMG_2001
 (↑伝わりにくいけど、右から左へスライド中の様子)


すると次/前の画像に切り替わります:
IMG_2002


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


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



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

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

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









このページのトップヘ