いるねすのブログ

働きたくない系SEが無駄に遊んだ記録

Hyperledger Fabric と戯れる part.2

ということで、今日も今日とてチュートリアル。まだコード書かないんかい。

前回の補足

前回やってたチュートリアルはこちら。

hyperledger-fabric.readthedocs.io

./byfn.sh down しないで以下のようにコンテナとイメージを削除するだけだと次の ./byfn.sh up でいろいろ失敗する。なにがいかんのかはパッと見分からなかったが、とにかく ./byfn.sh down しよう。

$ docker rm -f $(docker ps -aq)
$ docker rmi -f $(docker images | grep 'dev-' | awk '{print $3}')
$ git clean -fdx .

Adding an Org to a Channel チュートリアル

hyperledger-fabric.readthedocs.io

今回から eyfn.sh を使う。byfn が Build Your First Network の略っぽいから、eyfn は Edit 以下略とかって事なのかな。 ネーミングセンス・・・

ともあれ、 eyfn.sh にも サブコマンド generate, up, down (あと一応 restart も) がある。

チュートリアル本文では generate を省略して up を呼ぶ指示があるが、これは up のなかで generate の出力の有無をチェックして、必要があれば適宜呼んでいるから。(実は ./byfn.sh もここらへんの仕組みは同じ。)

初期状態 (前回のおさらい)

./byfn.sh up が完了した状態が今回の初期状態とある。つまり前回解説した通り、

ということになる。

./eyfn.sh generate

  1. cryptogenorg3-artifacts/org3-crypto.yaml の設定通りに証明書を発行して ./org3-artifacts/crypto-config を生成
    • cryptogen は以下を生成して、各ノード、ユーザの設定となるようディレクトリツリーをつくり配置する
      • org3.example.com ドメインの CA、全ユーザ(Admin, User1)、全ノード(peer0, peer1) それぞれに対する証明書と鍵
        • 証明書はそれぞれ交互に配布しあう (ユーザ同士は交換しない)
  2. configtxgenorg3-artifacts/configtx.yaml の設定通りに Org3 の設定を生成して ./channel-artifacts/org3.json を生成
    • 前回と違って Anchor Peer の設定ファイルとして .tx ファイルを作ってるわけではない。
    • org3-artifacts/configtx.yaml から organization の構成について抜粋したみたいなファイルを作っている。
  3. crypto-config/ordererOrganizationsorg3-artifacts/crypto-config/ にコピー
    • 前回作った Orderer まわりの証明書と鍵。
  4. cliscripts/step1org3.sh を実行させる
    1. apt-get install jq
      • 知ってる人も多いと思うけど、 jqJSON の操作をするコマンド。色つけたり整形したりもできて便利なのでみんな使おう
    2. peer channel fetch config ...
      • Orderer から mychannel の設定を取得している
      • 結果を configtxlator proto_decode --type common.Block することで JSON 形式に変換、 jq で必要情報を抜き出している
        • 内容は色々あるが、おおよそ mychannel の構成情報
    3. 上で抜き出した channel 設定に、上記で作成した ./channel-artifacts/org3.json を埋め込み
    4. configtxlator proto_encode, configtxlator compute_update 等を駆使して更新用のデータを作成
      • ここらへんの仕様にかんするドキュメントがまるで見当らないので詳細は不明
    5. peer channel signconfigtx ...
      • peer0.org1 に対して上で作った更新用データへの署名を手動で付加
    6. peer channel update ...
      • peer0.org2 に対して変更を送信
      • channel の管理者は peer0.org* の 2 つであり、変更ポリシは過半数の承認で受け入れれらるように設定されている。つまり 2 つ両方の承認が必要
        • peer0.org1 は先ほど手動で署名済み
        • peer0.org2 は今回の要求で org2 の Admin として送付されるため、問題なければ署名され、そのまま変更が受け入れられる
      • なおコレが mychannel のブロック5 にあたる。
        • ブロック 0 はジェネシスブロック (チャンネル初期設定)
        • ブロック 1 は Org1 のアンカーピア更新
        • ブロック 2 は Org2 のアンカーピア更新
        • ブロック 3 は myccインスタンス
        • ブロック 4 は mycc への invoke (byfn.sh で動作確認したやつ)
        • ブロック 5 が今回の org3 追加

./byfn.sh up

この時点では、mychannelorg3 を含ませるように設定できている。 だが実際に org3 の peer は mychannel に参加はしていない。(というより、org3 の peer 自体まだ存在していない)

  1. docker-composeorg3 の各ノードを起動する
    • 設定ファイルは docker-compose-org3.yaml
      • 内容的には org1, org2 と大差ない
    • 起動するのは以下。なおすべて byfn ネットワークに属する。
  2. 作った Org3cliscripts/step2org3.sh を実行させる
    1. peer channel fetch 0 ...
      • Orderer から mychannelジェネシスブロックを取得している
      • 前回は peer channel create の結果として生成されていたので取得の必要はなかったが、今回はこうして取得する
    2. peer channel join
      • Org3 の peer ノード(2つ)それぞれに対して実行してる。
        • 上で取得した mychannel.block を渡して、対象 peer ノードを mychannel に参加させる
    3. peer chaincode install
      • Anchor Peer である peer0.org3.example.com に対し実施
        • chaincode 名は mycc、 バージョン 2.0、実装言語は golang、とそれぞれ指定している。
        • chaincode 自体には変更がないが、バージョンを前回の 1.0 でなく 2.0 としているところに注意
  3. cliscripts/step3org3.sh を実行させる
    • ここだけ Org3cli ではなく cli に実行させてるので注意
    • peer chaincode install
      • Anchor Peer のうち残り 2 つである peer0.org1.example.com peer0.org2.example.com に対し実施
        • chaincode 名は mycc、 バージョン 2.0、実装言語は golang、とそれぞれ指定している。
        • org3 のとき同様、バージョンが上がっている。
    • peer chaincode upgrde
      • peer0.org1.example.com ノード 1 つのみに対して実行されている
      • peer chaincode instantiate とほとんど同じだが、バージョンアップ時はこちらを使うっぽい。
        • orderer orderer.example.com に対し、
          • TLS を有効にし、crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pemTLS CA 証明書として付加したうえで、
        • mychannel において、
        • 初期化メッセージ {"Args":["init","a","90","b","210"]} を渡し、
          • "a" に "90" を、 "b" に "210" をそれぞれセットしているっぽい
        • ポリシー AND ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer') も渡して、
          • Org1、Org2、Org3 の承認の 3 つが必要ということ
        • mycc のバージョン 2.0インスタンス化する
      • インスタンス化の操作は channel 内の全 peer に伝達される
      • この時点で Org3 は他の Org1, Org2 と同様に mychannel の参加者となっている
  4. 再度 Org3cliscripts/testorg3.sh を実行させる
    • 動作確認。目新しいことはしていないので省略。

ここで、Docker コンテナを一覧してみると

$ docker ps --format "table {{.Names}}\t{{.CreatedAt}}\t{{.Status}}\t{{.Ports}}" | sort
NAMES                                 CREATED AT                      STATUS              PORTS
Org3cli                               2019-04-15 13:50:36 +0900 JST   Up About an hour
cli                                   2019-04-15 10:55:05 +0900 JST   Up 4 hours
dev-peer0.org1.example.com-mycc-1.0   2019-04-15 10:55:56 +0900 JST   Up 4 hours
dev-peer0.org1.example.com-mycc-2.0   2019-04-15 13:50:51 +0900 JST   Up About an hour
dev-peer0.org2.example.com-mycc-1.0   2019-04-15 10:55:39 +0900 JST   Up 4 hours
dev-peer0.org2.example.com-mycc-2.0   2019-04-15 13:51:24 +0900 JST   Up About an hour
dev-peer0.org3.example.com-mycc-2.0   2019-04-15 13:51:09 +0900 JST   Up About an hour
dev-peer1.org2.example.com-mycc-1.0   2019-04-15 10:56:13 +0900 JST   Up 4 hours
orderer.example.com                   2019-04-15 10:55:04 +0900 JST   Up 4 hours          0.0.0.0:7050->7050/tcp
peer0.org1.example.com                2019-04-15 10:55:04 +0900 JST   Up 4 hours          0.0.0.0:7051->7051/tcp
peer0.org2.example.com                2019-04-15 10:55:04 +0900 JST   Up 4 hours          0.0.0.0:9051->9051/tcp
peer0.org3.example.com                2019-04-15 13:50:35 +0900 JST   Up About an hour    0.0.0.0:11051->11051/tcp
peer1.org1.example.com                2019-04-15 10:55:04 +0900 JST   Up 4 hours          0.0.0.0:8051->8051/tcp
peer1.org2.example.com                2019-04-15 10:55:04 +0900 JST   Up 4 hours          0.0.0.0:10051->10051/tcp
peer1.org3.example.com                2019-04-15 13:50:35 +0900 JST   Up About an hour    0.0.0.0:12051->12051/tcp

のように、

  • クライアントノード 2 種
  • mycc v1.0 インスタンス 3つ (peer0.org1, peer0.org2, peer1.org2)
  • mycc v2.0 インスタンス 3つ (peer0.org1, peer0.org2, peer0.org3)
  • orderer 1 つ
  • org 3種 x peer 2つで計 6 つの Peer ノード

が起動していることがわかる。 chaincode はアップグレードしてもコンテナ自体は消えないのな。

./eyfn.sh down

単純なおそうじスクリプト。上記までで作ったものをみんな削除する。

おしまい

今回は前回の内容を踏襲してる部分が殆どだったので、わりと簡単だった。

次回は、前回飛ばしていた Writing Your First Application チュートリアルに進む予定。

hyperledger-fabric.readthedocs.io