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

By Matt Zand and Abhik Banerjee

要約

前編記事シリーズのでは、ブロックチェーン開発のための Azure クラウドプラットフォームの提供と、Azure Marketplace テンプレートと手動構成の違いについて説明しました。また、Orderer 組織と Peer 組織をデプロイすることで、Azure での Hyperledger Fabric ブロックチェーンアプリケーションの構築に向けた最初の一歩を踏み出しました。この記事では、開発環境の設定方法、Orderer と Peer の設定方法、Fabric アプリケーションのポッドとボリュームマウントの設定方法について説明することで、旅を続けます。

この次の記事では、次の内容について説明します。

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

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

4- 開発環境のセットアップ

このセクションでは、ノード関連のアクティビティー用に開発環境をセットアップする方法を説明します。このタスクには Azure Shell (Bash) を使用します。 Hyperledger Fabric をインストールする前に、前提条件が整っていることを確認する必要があります。これには、チェーンコード、Docker、および JQ のプログラミング言語が含まれます。 Go (ここでは推奨言語) と JQ をインストールできるように、Azure Shell には Docker が既にインストールされている必要があります。必ず GOPATH、PATH、GOROOT 環境変数を設定してください。そうしないと、Go が正しく機能しません。よくわからない場合は、以下のコマンドに従ってください。

wget https://dl.google.com/go/go1.12.17.linux-amd64.tar.gz -O /tmp/go1.12.17.linux-amd64.tar.gz
tar -C /usr/local -xzf /tmp/go1.12.17.linux-amd64.tar.gz
export PATH=/usr/local/go/bin:$PATH
GOROOT=/usr/local/go をエクスポート
GOPATH=$PWDをエクスポート

最初の 2 つのコマンドは Go を /usr/local ディレクトリにインストールし、そのパスは 3 番目に設定されます。 GOROOT と GOPATH は、Go プログラムをコンパイルして連続した行に設定するために不可欠です。ローカル PC では ~/.bashrc ファイルに格納できますが、Azure Shell は一時ストレージを提供するため、しばらくすると失われます。このセクションで説明するように、Docker コンテナーを使用してこれを永続化する方法があります。次の手順では、GitHub リポジトリから Hyperledger バイナリをダウンロードして Hyperledger Fabric をインストールし、/usr/local に配置します。

mkdir /usr/local/hyperledger
cd /usr/local/hyperledger
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | sudo bash -s — 1.4.4 1.4.4 0.4.18 -d -s
export PATH=/usr/local/hyperledger/bin:$PATH

最後のステップとして、PATH 環境変数が /usr/local/hyperledger ディレクトリも指すように設定して、コマンドのバイナリへのパスを常に設定しなくても、コマンドを簡単に呼び出せるようにします。先に進む前に、Docker イメージを作成することをお勧めします。これは、Orderer および Peer Clusters 内で開発を行う場合、常にゼロから始める必要がなく、開発に非常に役立ちます (Orderer および Peer の構成に追加のファイルを含める理由を理解するには、5.1 および 5.2 を参照してください)。組織）。 Dockerfile を作成してからイメージを作成することをお勧めします。このイメージを dockerhub (または Azure の専門家である場合は Azure Container Registry) に発行して、今後のセクションで使用できます。

5- Orderer と Peer の構成の設定

このセクションでは、クラスターポッドでの開発用の構成をセットアップします。この時点で、「必要な情報を含むクラスターをすでにデプロイしているのに、なぜポッドでの開発が必要なの?」と考えるかもしれません。問題は、前のセクションで述べたように、これらの注文者とピア組織のクラスターが接続されていないことです。さらに、チェーンコード管理に関する次のセクションで説明するように、特定のチェーンコードをピアに展開する必要がある場合があります。これらの理由から、クラスター内に dev env を配置すると便利です。

注文者の設定

この時点で実行する次のステップは、Orderer のカスタムセットアップを行うことです。このセットアップは、Hyperledger Fabric Test Network から入手できるサンプルセットアップから派生したものです。これにより、Orderer の YAML 構成を最初から書き出す必要がなくなります。開発環境にも役立ちます。ここで使用する構成は、デモの目的を果たしていることに注意してください。実稼働環境が必要な場合は、必要に応じて別のより洗練された構成を使用してください。この展開に使用される Orderer Config ファイルは、ホストされたリンクのブックファイル名 Orderer.yaml に関連付けられたコードセクションで提供されています。

ピア設定

ピアを設定するには、本のホストされたコードで提供される core.yaml ファイルを使用できます。構成ファイルには、注文者が Org01 に関連付けられたノードクラスターを見つけて通信できるようにするために必要な構成が含まれています。この YAML ファイルには、他のセクションの中でも特に Peer、Chaincode、Ledger のセクションが含まれていることに気付くかもしれません。これらは、ピア、チェーンコード、および元帳として使用されるデータベースのタイプのプロパティをそれぞれ定義するために使用されます。執筆時点では、3 番目のセクションは「goleveldb」および「CouchDB」オプションをサポートしています。

configtx.yaml、Orderer.yaml、および core.yaml ファイルをシェルで選択したディレクトリにアップロードすることで、Azure Shell にコピーできます。この場所は次のセクションで使用されるため、これは覚えておくべき手順です。

Dev Pod 用の Docker イメージの作成

さらに先に進む前に、これまでに実行した指示から Docker イメージを作成すると便利です。この Docker イメージを使用して、Hyperledger Fabric バイナリが既に含まれている簡単な開発環境を提供するポッドをスピンアップできます。次のセクションで説明するように、このイメージをボリュームマウント関連の構成の基本イメージとして使用します。

ホストされたコードセクションで提供される Dockerfile は、イメージの作成に役立ちます。現時点で HF がサポートしている最新バージョンであるため、イメージは Ubuntu 18.04 に基づいています。行番号 22 までは、Go、JQ、Hyperledger Fabric (リポジトリから) をインストールし、それぞれのパスを設定するので、手順は慣れているように見えるはずです。 24 行目と 25 行目でカスタム設定をコピーし、最後の行で環境変数 FABRIC_CFG_PATH の値を /etc/hyperledger/fabric (ファイルのコピー先のディレクトリ) に設定します。このイメージを Dockerhub に公開します。

6- 開発用のポッドとボリュームマウントの設定

チャネルを作成し、Orderer と Peer の組織を結合させる前に、開発ポッドに適切なボリュームマウントを作成するという、最後の詳細を完了する必要があります。前の手順で、ポッドの作成元となる基本イメージを作成しました。ポッドが実際にクラスターと通信できるようにするには、それぞれのクラスターにセキュリティキーを格納するシークレットボリュームにアクセスする必要があります。これは、クラスタータイプごとに YAML ファイルを導入することで簡単に実行できます。

以下の表は、ポッドが認識して使用する必要がある秘密のマウントボリュームを示しています。ここで、これらのボリュームはピアクラスターとオーダークラスターで分離されるため、異なる値が含まれ、クラスターが AKS で作成されたときに自動的に作成されることに注意してください。ただし、必要なのはこれらをポッドにマウントすることだけです。

秘密の	マウント
hlf-admin-idcert	/var/hyperledger/admin/msp/admincerts /var/hyperledger/admin/msp/signcerts
hlf-ca-idcert	/var/hyperledger/admin/msp/cacerts
hlf-admin-idkey	/var/hyperledger/admin/msp/keystore
hlf-tlsca-idcert	/var/hyperledger/admin/msp/tlscacerts
hlf-admin-tls-idkey	/var/hyperledger/admin/tls
hlf-admin-tls-idcert	/var/hyperledger/admin/tls

この目的で dev_pod.yaml を使用できます。この YAML ファイルは、それぞれのクラスターの Orderer Pod と Peer Pod でほとんど同じであることに注意してください。ポッドが適切に開発するために必要なボリュームマウントと環境変数を設定します。 YAML は、特にチャネルに新しいノードを追加するために必要な環境変数を設定します。

ファイルは、最後にいくつかの変更も必要です。 33 行目と 76 行目から 79 行目まではコメントアウトされています。前者は、前のセクションで作成したイメージの名前を配置する必要がある場所であり、後者のセクションには、組織の名前やクラスターの URL などのポッドタイプ固有の詳細が含まれています。

ポッドは次の手順で作成できます。

1. az aks get-credentials –resource-group -名前–サブスクリプション

kubectl -n hlf-admin apply -f ./dev_pod.yaml

Azure Shell で実行される最初のコマンドは、kubectl に、指定されたクラスターを指すように指示します。次のステップでは、そのクラスターの hlf-admin 名前空間に YAML を提供します。最初のコマンドには、リソースグループとクラスター名の Orderer および Peer 固有の値が含まれます (ここでは、リソースグループと OrdererOrg および Org01 のそれぞれ RG-HLF-AzureOrd および RG-HLF-AzureOrg です)。ポッドがプロビジョニングされると、次の方法でポッドにアクセスできます。

kubectl exec -n hlf-admin -it devenv /bin/bash

これにより、kubectl が現在指しているクラスターの開発ポッド内に bash シェルが提供されます。

概要

開発環境の設定方法、Orderer と Peer の設定方法、Fabric アプリケーションの Pod とボリュームマウントの設定方法について説明した記事シリーズの第 2 部は終了しました。

このシリーズのこのシリーズの次の最終記事、この記事で完成したものの上に構築します。具体的には、チャネルを作成し、ネットワーク、チャネル、およびノードにピアを追加します。最後の最後のステップでは、Azure で Fabric チェーンコードをデプロイして操作する方法を示します。

リソース

著者について

マットザンド シリアルアントレプレナーであり、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 の構築とデプロイ - パート 2

要約