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
が完了した状態が今回の初期状態とある。つまり前回解説した通り、
- チャンネル名
mychannel
があって、 - 以下のノードが登録されていて、
- orderer.example.com
- peer0.org1.example.com
- peer1.org1.example.com
- peer0.org2.example.com
- peer1.org2.example.com
- cli
- ChainCode
mycc
の v1.0 が以下 3 つの peer にインストールされていて、- peer0.org1.example.com
- peer0.org2.example.com
- peer1.org2.example.com
- ChainCode
mycc
の v1.0 がインスタンス化され、動作確認まで出来ている状態
ということになる。
./eyfn.sh generate
cryptogen
でorg3-artifacts/org3-crypto.yaml
の設定通りに証明書を発行して./org3-artifacts/crypto-config
を生成cryptogen
は以下を生成して、各ノード、ユーザの設定となるようディレクトリツリーをつくり配置する- org3.example.com ドメインの CA、全ユーザ(Admin, User1)、全ノード(peer0, peer1) それぞれに対する証明書と鍵
- 証明書はそれぞれ交互に配布しあう (ユーザ同士は交換しない)
- org3.example.com ドメインの CA、全ユーザ(Admin, User1)、全ノード(peer0, peer1) それぞれに対する証明書と鍵
configtxgen
でorg3-artifacts/configtx.yaml
の設定通りに Org3 の設定を生成して./channel-artifacts/org3.json
を生成- 前回と違って Anchor Peer の設定ファイルとして .tx ファイルを作ってるわけではない。
org3-artifacts/configtx.yaml
から organization の構成について抜粋したみたいなファイルを作っている。
crypto-config/ordererOrganizations
をorg3-artifacts/crypto-config/
にコピー- 前回作った Orderer まわりの証明書と鍵。
cli
にscripts/step1org3.sh
を実行させるapt-get install jq
- 知ってる人も多いと思うけど、
jq
は JSON の操作をするコマンド。色つけたり整形したりもできて便利なのでみんな使おう
- 知ってる人も多いと思うけど、
peer channel fetch config ...
- Orderer から
mychannel
の設定を取得している - 結果を
configtxlator proto_decode --type common.Block
することで JSON 形式に変換、jq
で必要情報を抜き出している- 内容は色々あるが、おおよそ
mychannel
の構成情報
- 内容は色々あるが、おおよそ
- Orderer から
- 上で抜き出した channel 設定に、上記で作成した
./channel-artifacts/org3.json
を埋め込み configtxlator proto_encode
,configtxlator compute_update
等を駆使して更新用のデータを作成- ここらへんの仕様にかんするドキュメントがまるで見当らないので詳細は不明
peer channel signconfigtx ...
peer0.org1
に対して上で作った更新用データへの署名を手動で付加
peer channel update ...
peer0.org2
に対して変更を送信- channel の管理者は
peer0.org*
の 2 つであり、変更ポリシは過半数の承認で受け入れれらるように設定されている。つまり 2 つ両方の承認が必要peer0.org1
は先ほど手動で署名済みpeer0.org2
は今回の要求でorg2
の Admin として送付されるため、問題なければ署名され、そのまま変更が受け入れられる
- なおコレが
mychannel
のブロック5 にあたる。
./byfn.sh up
この時点では、mychannel
に org3
を含ませるように設定できている。
だが実際に org3
の peer は mychannel
に参加はしていない。(というより、org3
の peer 自体まだ存在していない)
docker-compose
でorg3
の各ノードを起動する- 設定ファイルは
docker-compose-org3.yaml
- 内容的には
org1
,org2
と大差ない
- 内容的には
- 起動するのは以下。なおすべて
byfn
ネットワークに属する。- peer0.org3.example.com
- peer1.org3.example.com
- Org3cli
org3
専用のクライアントノード。
- 設定ファイルは
- 作った
Org3cli
にscripts/step2org3.sh
を実行させるpeer channel fetch 0 ...
- Orderer から
mychannel
のジェネシスブロックを取得している - 前回は
peer channel create
の結果として生成されていたので取得の必要はなかったが、今回はこうして取得する
- Orderer から
peer channel join
- Org3 の peer ノード(2つ)それぞれに対して実行してる。
- 上で取得した
mychannel.block
を渡して、対象 peer ノードを mychannel に参加させる
- 上で取得した
- Org3 の peer ノード(2つ)それぞれに対して実行してる。
peer chaincode install
- Anchor Peer である
peer0.org3.example.com
に対し実施- chaincode 名は
mycc
、 バージョン2.0
、実装言語はgolang
、とそれぞれ指定している。 - chaincode 自体には変更がないが、バージョンを前回の 1.0 でなく 2.0 としているところに注意
- chaincode 名は
- Anchor Peer である
cli
にscripts/step3org3.sh
を実行させる- ここだけ
Org3cli
ではなくcli
に実行させてるので注意 peer chaincode install
- Anchor Peer のうち残り 2 つである
peer0.org1.example.com
peer0.org2.example.com
に対し実施- chaincode 名は
mycc
、 バージョン2.0
、実装言語はgolang
、とそれぞれ指定している。 - org3 のとき同様、バージョンが上がっている。
- chaincode 名は
- Anchor Peer のうち残り 2 つである
peer chaincode upgrde
peer0.org1.example.com
ノード 1 つのみに対して実行されているpeer chaincode instantiate
とほとんど同じだが、バージョンアップ時はこちらを使うっぽい。- orderer
orderer.example.com
に対し、 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
をインスタンス化する
- orderer
- インスタンス化の操作は channel 内の全 peer に伝達される
- この時点で
Org3
は他のOrg1
,Org2
と同様にmychannel
の参加者となっている
- ここだけ
- 再度
Org3cli
にscripts/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 チュートリアルに進む予定。