AzureクラウドプラットフォームでのHyperledgerファブリックの構築とデプロイ-パート3-LinuxFoundation-トレーニング

By Matt Zand and Abhik Banerjee

要約

このシリーズの最初の記事では、以下のトピックについて学びました。

ブロックチェーンアプリケーションのためのAzureクラウド
Fabricマーケットプレイスのテンプレートとマニュアル設定
Ordererやピア組織のデプロイ

このシリーズの 2番目の記事このシリーズでは、次のことについて説明しました。

開発環境のセットアップ
注文者とピアの構成の設定
開発用のポッドとボリュームマウントのセットアップ

シリーズのこの最後の記事では、以下について説明します。

チャネルを作成する
ネットワーク、チャネル、ノードへのピアの追加
チェーンコードのデプロイと運用

この記事は初心者向けですが、Azure、Kubernetes APIs、および Azure Kubernetes Service (AKS) について理解しておくほうがよいでしょう。また、この記事で説明されている手順を実行するには、Hyperledger Fabric とそのコンポーネントに関する十分な知識が必要です。この記事で取り上げるトピックと手順は、ブロックチェーンのコンサルティングや開発に興味のある方にも有益です。

7 - チャネルを作成する

開発ポッドが稼働したら、チャネルを作成し、連続した手順でクラスターを追加できます。

チャネルを作成するには、1つの注文サービスでチャネルを立ち上げる必要があります。これがOrdererOrgクラスターです。したがって、チャネルを作成するには、最初にOrdererクラスターの開発ポッドから開始する必要があります。上記のポッド内にいると仮定すると、次のコマンドを実行してチャネルを簡単に作成できます。

configtxgen -profile SampleChannel -outputCreateChannelTx ./channel.tx -channelID ch01 -configPath ./

configtxgenツールはHyperledgerFabricバイナリでデフォルトで提供され、ポッドはHFがすでにインストールされ、必要なパスが設定されているイメージに基づいているため、このツールは「ch01」という名前の新しいチャネルを作成します。この場合、特定の詳細についてSampleChannelプロファイルが使用されます。

チャネルの詳細は、channel.txトランザクションファイル内に保存されます。ご存知かもしれませんが、これはこのチャネルのジェネシスブロックを作成するために必要な非常に重要なファイルです。次の手順では、このファイルを使用して、注文サービスのプロバイダーとしてOrdererOrgを使用してチャネルを起動します。

Peer channel create -o [URL of your Orderer Cluster] -c [Channel Name/ID] -f ./channel.tx –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

-oフラグにはオーダラーのAKSクラスターのURL、-cフラグにはチャネルID（ここではch01）を指定します。 -fフラグには、channel.txトランザクションファイルへのパスが必要です。これらはHFによって提供されるAPIであるため、使用するクラウドプラットフォームに関係なく、ほとんど同じです。

8- ネットワーク、チャネル、ノードにピアを追加する

チャネルは、クラウドプラットフォームの仮想プライベートクラウド（VPC）に類似していると理解できます。通常、どのクラウドプラットフォームでも、デフォルトの仮想プライベートクラウドがあります（オファリング名はクラウドプラットフォームごとに異なる場合があります）。次に、VMなどのコンピューティングリソース間の分離のレイヤーを提供するVPC内のサブネットがあります。 VMは複数のvNICを持つことができ、複数のサブネットの一部にすることができます。

Hyperledger Fabricに関しては、ピアノードとオーダラーをVMと考えてください。サブネットとしての共通チェーンコードを容易にするチャネル。複数のチャネルの一部であるノード（異なるサブネットのVMの一部など）は、クロスチャネル通信を容易にし、「アンカーノード」と呼ばれます。また、すべてのサブネットを含むVPCと同様に、ネットワーク全体を管理するためのチャネルがあります。これはデフォルトで「testchainid」です（詳細については、HFの構成ファイルを確認してください）。ネットワークに新しいピアを追加するには、Ordererノードのシステムチャネル構成の変更を考慮に入れたトランザクションを提案するだけです。トランザクションが記録され、新しいピアの追加が元帳に追加されます。新しいピアのMSPが記録されるため、メンバーシップサービスプロバイダー（MSP）の役割がここで果たすようになります。

ピアからネットワーク

まず、ピアクラスターで作成した開発環境にログインすることから始めます。これは、kubectlがそれを指すようにしてから、開発ポッドにアクセスすることで実行できます（「ポッドとボリュームマウントの設定」セクションを参照）。次に、ここでconfigtx.yamlを生成する必要があります。このconfig.yamlは、ホストされているコードを介して提供されるconfigtx.yamlに似ており、Org01の情報を詳しく説明しているconfigtx.yamlの44行目までしか必要ありません。新しいconfigtx.yamlが派生/作成されたら、configtxgenツールを使用してピア組織の構成をJSONファイルとして生成します。次に、それをAzure Shellにコピーする必要があります。そこから、OrdererClusterの開発ポッドにコピーします。次のコマンドは、その方法を示しています。

configtxgen -printOrg Org01 -configPath ./> Org01.json && exit
kubectl cp -n hlf-admin devenv:/var/hyperledger/admin/Org01.json Org01.json
az aks get-credentials –resource-group [Orderer Resource Group] –name [Orderer AKS Cluster Name] –subscription [Subscription ID]
kubectl cp -n hlf-admin Org01.json devenv:/var/hyperledger/admin/Org01.json
kubectl exec -n hlf-admin -it devenv /bin/bash

ピア構成のJSONを生成してから、AzureShellに戻ります。そこから、ピア（ここではOrg01.json）の構成をAzureシェルにコピーします。次に、手順3でピアクラスタからOrdererクラスタを指すようにkubectlを取得し、後続の手順で構成をOrderer DevPodの/var/hyperledger/adminにコピーします。次の手順では、sys_config_block.jsonという名前のJSONファイルでシステムチャネル（チャネル名はtestchainid）の構成をフェッチします。以降の手順では、変更を変更して新しいファイル（modified_sys_config.json）に保存します。

Peer channel fetch config sys_config_block.pb -o [Replace with Orderer URL] -c testchainid –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem
configtxlator proto_decode –input sys_config_block.pb –type common.Block > sys_config_block.json
jq .data.data[0].payload.data.config sys_config_block.json > original_sys_config.json
jq -s “.[0] * {\”channel_group\”:{\”groups\”:{\”Consortiums\”:{\”groups\”: {\”SampleConsortium\”: {\”groups\”: {\”Org01\”:.[1]}}}}}}}” original_sys_config.json Org01.json > modified_sys_config.json

上記の手順で行っていることは、基本的に、ネットワーク内に新しい組織があることを示す修正を含む新しいファイルを作成することです。Consortiumプロパティの変更は、modified_sys_config.jsonに反映されます。この元の設定と新しい設定の違いは、ネットワークの台帳に記録されます。これは、反論の余地のない、Peer Organization Org01の参加の証明になります。これは、以下のようにして実現します。

configtxlator proto_encode –input original_sys_config.json –type common.Config > original_sys_config.pb
configtxlator proto_encode –input modified_sys_config.json –type common.Config > modified_sys_config.pb
configtxlator compute_update –channel_id testchainid –original original_sys_config.pb –updated modified_sys_config.pb > differed_sys_config.pb
configtxlator proto_decode –input differented_sys_config.pb –type common.ConfigUpdate> differented_sys_config.json
echo ‘{“payload”:{“header”:{“channel_header”:{“channel_id”:”testchainid”, “type”:2}},”data”:{“config_update”:’$(cat differed_sys_config.json)’}}}’ > modreqst_sys_config.json
configtxlator proto_encode –input modreqst_sys_config.json –type common.Envelope> modreqst_sys_config.pb

configtxlatorツールを使用して、2つの構成の違いを計算します。このツールは、HFで好まれる媒体であるため、JSONをProtobufに変換する際にも使用されます。この差は最終的にmodreqst_sys_config.pbとして反映され、次のコマンドでOrderer（技術的にはPeerでもある）を介して更新リクエストを作成する際に使用されます。

Peer channel update -f modreqst_sys_config.pb -o [Orderer URL Here] -c testchainid –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

これにより、新しい組織（Org01）がネットワークの一部になり、ほぼ70%の作業が完了します。次のセクションでは、Org01をチャネルch01に追加してから、Org01が所有するノード（ここではAKS上のピアクラスタ）をネットワーク内の信頼できるコンポーネントとして追加します。

ピアからチャネル

VPCでたとえるなら、新しいVM（Org01 Peer）は電源が入り、VPCに含まれていますが、まだサブネットが割り当てられていません。その時点では実質的に使い物になりません。サブネットを取得して初めて、その権限に応じて入出力が可能になります。

それと同じように、先ほどのセクションで作成したチャンネルch01に、新たに導入されたOrg01を含める必要があります。これもOrderer Dev Podから行う必要があります。システムのチャンネル（testchannelid）の設定を編集する代わりに、私たちのチャンネル（ch01）の設定を編集し、元の設定と変更した設定の差分を元帳のトランザクションとして記録します。これにより、Org01がチャンネルに入ったことが証明されます。次のステップでは、元のch01の設定を取得し、読みやすいようにJSONファイルに保存します。

Peer channel fetch config ch01_config_block.pb -o [Orderer URL here] -c ch01 –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem
configtxlator proto_decode –input ch01_config_block.pb –type common.Block > ch01_config_block.json
jq .data.data[0].payload.data.config ch01_config_block.json > original_ch01_config.json
jq -s “.[0] * {\”channel_group\”:{\”groups\”:{\”Application\”:{\”groups\”: {\”Org01\”:.[1]}}}}}” original_ch01_config.json Org01.json > modified_ch01_config.json

元の設定を入手したら、手順3と4でOrg01がチャンネルch01に入ったことを反映した修正設定を作成します。前と同じく、新しい設定と古い設定の差を計算することで、修正された設定を説明する必要がありますが、これもprotobuf形式で行います。

configtxlator proto_encode –input original_ch01_config.json –type common.Config> original_ch01_config.pb
configtxlator proto_encode –input modified_ch01_config.json –type common.Config > modified_ch01_config.pb
configtxlator compute_update –channel_id ch01 –original original_ch01_config.pb –updated modified_ch01_config.pb > differed_ch01_config.pb
configtxlator proto_decode –input differed_ch01_config.pb –type common.ConfigUpdate > differed_ch01_config.json
echo ‘{“payload”:{“header”:{“channel_header”:{“channel_id”:”ch01″, “type”:2}},”data”:{“config_update”:’$(cat differed_ch01_config.json)’}}}’ > modreqst_ch01_config.json
configtxlator proto_encode –input modreqst_ch01_config.json –type common.Envelope > modreqst_ch01_config.pb

configtxlatorツールを使用した上記のコマンドは似ているように見えるはずです。ここでは、testchainidチャネルの代わりにch01を使用して文字通り同じことを行っています。 Peer APIを使用した次のコマンドで、ノードをチャネルに含めるプロセスが完了します。

Peer channel update -f modreqst_ch01_config.pb -o [Orderer URL here] -c ch01 –tls –cafile /var/hyperledger/admin/msp/tlscacerts/ca.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem

上記のコマンドは、記録される更新トランザクションを作成します。この更新は、Org01がチャンネルch01に組み込まれたことを反映しています。あとは、このPeer組織が所有するノードをネットワークに含めるだけです。

ピアからノード

前回は、Peer Dev PodからAzure Shellにファイルをコピーし、その後Orderer Dev Podにコピーしました。今回は、その逆を行う必要があります。Orderer Dev Podのdevenv:/var/hyperledger/admin/msp/tlscacerts/..data/ca.crtにあるOrdererのTLS証明書を、PeerのDev Podのdevenv:/var/hyperledger/admin/ca_Orderer.crtに必要とします。なぜこのようなことが必要なのかと思われるかもしれません。それは、チャンネルch01に登録したばかりのOrg01のMSPを使用することができますが、チャンネルにしか接続できず、ノード自体は検証されないからです。

OrdererからのTLS証明書がその助けになります。 TLS証明書がピアノードにコピーされていると仮定すると、ジェネシスブロックの構成をOrdererから取得する必要があります。次のコマンドを使用してピアからOrdererノードに接続するときに、ここでこれを指定する必要があります。

Peer channel fetch 0 ch01_config.block -o [Orderer URL Here]-c ch01 –tls –cafile /var/hyperledger/admin/ca_Orderer.crt –clientauth –certfile /var/hyperledger/admin/tls/cert.pem –keyfile /var/hyperledger/admin/tls/key.pem
Peer channel join -b ch01_config.block

そして、ちょうどそのように、ノードはチャネルの一部になりました。最初の行はチャネルのジェネシスブロック構成を取得してch01_config.blockファイルに保存し、2番目の行はこれを使用してノードをチャネルに参加させます。 Org01のMSPはすでに登録されているため、このピアノードはチャネル上でトランザクションを実行できます。

これでデモネットワークの構築は終わりです。この時点で残っているのは、必要なチェーンコードをデプロイし、必要に応じて呼び出すことだけです。次のセクションでは、このデモネットワークでのチェーンコード管理について説明します。

9-チェーンコードの展開と運用

ネットワークが構築され、ノードがチャネルに含まれると、その後のプロセスはクラウドプラットフォームに関係なく同じになります。セクションの最後にいますが、このポッドに注文者のパブリックURLをENV変数として保存すると便利な場合があります。この値はデプロイメントごとに異なる可能性があるため、ポッドの作成後に設定することをお勧めします。

チェーンコードをインストールするタスクは、チェーンコードを操作することになっているピア（ここではOrg01のピアノード）から最初に実行する必要があります。つまり、最初にkubectlがピアのAKSクラスターを指すようにしてから、ピアの開発ポッドのbashシェルにアクセスする必要があります。その後、チェーンコードを操作するプロセスはかなり簡単です。環境変数にパスを設定している場合は、次のようなコマンドを使用し

Peer chaincode install -p [Path to the Chaincode] -n [Name of the Chaincode] -v [Version of the Chaincode (Generally start of 1.0 for every chaincode)] -l [Language the chaincode is written in]

にチェーンコードをピアにインストールしますその後、ライフサイクルを続行します。ここで注意すべき興味深い点は、ほとんどのPeer APIコマンドには、注文者のアドレスを示す-oのグローバルフラグがあることです。これは、チャネルが使用している注文者になります。この場合、このフラグの値はOrdererOrgのURLになります。

概要

これでパート3は終了し、シリーズの記事は終わりです。大まかに言えば、AzureクラウドプラットフォームにFabricをデプロイする方法を学びました。まず、AzureのサービスとしてのBlockchainオファリングについての説明から始め、次に、ファブリック用のAzure MarketplaceAKSオファリングを使用してピアとオーダーのクラスターをデプロイするのがいかに簡単であるかを示すことに移りました。さらに、ネットワークとノードを稼働させた後のchiancodeの使用方法と、初期設定が完了した後にネットワークを拡張してチャネルにメンバーを追加する方法について簡単に説明しました。

リソース

Linux Foundation＆Hyperledgerの無料トレーニングコース
Linux Foundation＆Hyperledgerのeラーニングコース
- Hyperledger Fabric Administration (LFS272)
- Hyperledger Fabric for Developers (LFD272)
Linux Foundation＆Hyperledgerの認定試験
- Certified Hyperledger Fabric Administrator (CHFA)
- Certified Hyperledger Fabric Developer (CHFD)
5つの人気のあるHyperledger DLT（Fabric、Besu、Sawtooth、Iroha、Indy）のレビュー
3つのHyperledgerツール（ Caliper、Cello、Avalon）のレビュー
4つのHyperledgerライブラリ（Aries、Quilt、Ursa、Transact）のレビュー

著者について

マットザンド シリアルアントレプレナーであり、4つのテックスタートアップの創設者です。 DCWebメーカー, ハッシュフロー, Coding Bootcamps と High School Technology Services。彼はの筆頭著者です HyperledgerFabricを使用した実践的なスマートコントラクト開発オライリーメディアの本。彼は、IBM、SAP、Alibaba Cloud、Hyperledger、The Linux Foundationなどのサイトで、Hyperledger、Ethereum、CordaR3プラットフォームのブロックチェーン開発に関する100を超える技術記事とチュートリアルを執筆しています。 Hash Flowで、彼はエンタープライズ分散型アプリケーションのコンサルティングと展開のためのブロックチェーンエキスパートのチームを率いています。チーフアーキテクトとして、彼はコーディングブートキャンプのブロックチェーンコースとトレーニングプログラムを設計および開発してきました。彼はメリーランド大学で経営学の修士号を取得しています。ブロックチェーンの開発とコンサルティングの前は、いくつかのスタートアップ企業でシニアWebおよびモバイルアプリの開発者およびコンサルタント、投資家、ビジネスアドバイザーとして働いていました。あなたはLIで彼とつながることができます： https://www.linkedin.com/in/matt-zand-64047871

Abhik Banerjee 研究者であり、熱心な読者であり、アニメファンでもあります。余暇には、ホワイトペーパーを読んだり、DLTからCloudInfraまでの趣味のプロジェクトを構築したりしています。彼は、Blockchainのいくつかの特許に加えて、InternationalConferencesとBookTitlesに複数の出版物を持っています。彼の興味には、ブロックチェーン、量子情報処理、バイオインフォマティクスが含まれます。あなたはLIで彼とつながることができます： https://in.linkedin.com/in/abhik-banerjee-591081164

Azure Cloud Platform での Hyperledger Fabric の構築とデプロイ - パート 3

要約