[하이퍼레저 공식문서]Tutorials - Building Your First Network

알 수 없는 사용자 2018. 6. 4. 11:58

2018. 6. 4. 11:58

Building Your First Network(첫 번째 네트워크 구축)

[Note]
이 지침은 제공된 tar 파일 내의 최신 안정된 Docker 이미지와 사전 컴파일된 설치 유틸리티에 대해 작동하는 것으로 확인되었습니다. 현재 마스터 브랜치의 이미지나 도구로 이 명령을 실행하면 구성 및 패닉에러(panic errors) 가 표시될 수 있습니다.

첫 번째 네트워크 (BYFN) 시나리오를 구축하면 2개의 피어 노드(peer nodes)를 유지 관리하는 두 개의 조직과 "solo" ordering service로 구성된 샘플 Hyperbelger 패브릭 네트워크가 프로비저닝됩니다.

Install prerequisites(필수 구성요소 설치)

시작하기 전에 아직 수행하지 않은 경우, 블록 체인 응용 프로그램을 개발하거나 Hyperledger Fabric을 운영 할 플랫폼에 모든 필수 구성 요소가 설치되어 있는지 확인하십시오.

또한 Hyperledger Fabric Samples를 다운로드하여 설치해야합니다. fabric-samples 레파지토리에는 많은 샘플이 포함되어 있습니다. first-network 샘플을 사용할 것입니다. 이제 그 하위 디렉토리를 열어 봅시다.

cd fabric-samples/first-network

Want to run it now?

우리는 2개의 다른 조직(organizations)을 대표하는 4명의 peer와 orderer node로 구성된 Hyperledger Fabric network 를 신속하게 bootstrap하기 위해 이러한 Docker 이미지를 활용하는 완전히 주석한 스크립트 (byfn.sh)를 제공합니다. 또한 피어를 채널에 참여시키고 체인코드(chaincode)를 배포 및 인스턴스화(instantiate)하며 배포된 체인 코드(the deployed chaincode)에 대한 트랜잭션하는 스크립트를 실행할 수 있는 컨테이너를 시작합니다.

byfn.sh 스크립트의 도움말 텍스트는 다음과 같습니다.

./byfn.sh --help
Usage:
byfn.sh up|down|restart|generate [-c <channel name>] [-t <timeout>] [-d <delay>] [-f <docker-compose-file>] [-s <dbtype>]
byfn.sh -h|--help (print this message)
# docker compose의 모드를 선택합니다.
  -m <mode> - one of 'up', 'down', 'restart' or 'generate'
    - 'up' - bring up the network with docker-compose up
    - 'down' - clear the network with docker-compose down
    - 'restart' - restart the network
    - 'generate' - generate required certificates and genesis block
# 채널이름을 사용합니다
  -c <channel name> - channel name to use (defaults to "mychannel")
# cli의 타임아웃 시간을 설정합니다. 
  -t <timeout> - CLI timeout duration in seconds (defaults to 10)
# delay 시간을 설정합니다.
  -d <delay> - delay duration in seconds (defaults to 3)
# 특정 docker compose file을 사용합니다.
  -f <docker-compose-file> - specify which docker-compose file use (defaults to docker-compose-cli.yaml)
# 데이터베이스 백앤드를 사용합니다. goleveldb(디폴트) 또는 couchdb
  -s <dbtype> - the database backend to use: goleveldb (기본) or couchdb
# 체인코드 언어를 선택합니다. golang(기본) 또는 node 
  -l <language> - the chaincode language: golang (default) or node
# 진행전에 확인을 하지 않는 옵션
  -a - don't ask for confirmation before proceeding

  Typically, one would first generate the required certificates and
  genesis block, then bring up the network. e.g.:
# 일반적으로, 먼저 필요한 인증서와 생성 블록을 생성 한 다음 네트워크를 시작합니다. 예 :

      byfn.sh -m generate -c mychannel
      byfn.sh -m up -c mychannel -s couchdb

채널 이름을 제공하지 않기로 선택하면 스크립트는 기본 이름인 mychannel을 사용합니다. CLI 시간 초과 매개 변수 (-t 플래그로 지정)는 선택적 값입니다. 설정하지 않으려는 경우 CLI는 기본 설정 인 10초 후에 수행된 쿼리 요청을 하지않습니다.

Generate Network Artifacts(네트워크 아키팩트 생성)

준비사항이 끝났으면 다음 명령을 실행하십시오.

./byfn.sh -m generate

yes/no 커맨드 라인(command line) 프롬프트와 함께 일어날 일에 대한 간단한 설명을 볼 수 있습니다. 설명된 사항을 실행하려면 y로 응답하거나 리턴 키(return key)를 누르십시오.

# 채널 'mychannel'및 CLI 시간 초과 '10'을 사용하여 certs 및 genesis block 생성 계속 하시겠습니까? [Y / n] y
Generating certs and genesis block for with channel 'mychannel' and CLI timeout of '10'
Continue? [Y/n] y
proceeding ...
/Users/xxx/dev/fabric-samples/bin/cryptogen

##########################################################
##### Generate certificates using cryptogen tool #########
##########################################################
org1.example.com
2017-06-12 21:01:37.334 EDT [bccsp] GetDefault -> WARN 001 Before using BCCSP, please call InitFactories(). Falling back to bootBCCSP.
...

/Users/xxx/dev/fabric-samples/bin/configtxgen
##########################################################
#########  Generating Orderer Genesis block ##############
##########################################################
2017-06-12 21:01:37.558 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-12 21:01:37.562 EDT [msp] getMspConfig -> INFO 002 intermediate certs folder not found at [/Users/xxx/dev/byfn/crypto-config/ordererOrganizations/example.com/msp/intermediatecerts]. Skipping.: [stat /Users/xxx/dev/byfn/crypto-config/ordererOrganizations/example.com/msp/intermediatecerts: no such file or directory]
...
2017-06-12 21:01:37.588 EDT [common/configtx/tool] doOutputBlock -> INFO 00b Generating genesis block
2017-06-12 21:01:37.590 EDT [common/configtx/tool] doOutputBlock -> INFO 00c Writing genesis block

#################################################################
### Generating channel configuration transaction 'channel.tx' ###
#################################################################
2017-06-12 21:01:37.634 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-12 21:01:37.644 EDT [common/configtx/tool] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2017-06-12 21:01:37.645 EDT [common/configtx/tool] doOutputChannelCreateTx -> INFO 003 Writing new channel tx

#################################################################
#######    Generating anchor peer update for Org1MSP   ##########
#################################################################
2017-06-12 21:01:37.674 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-12 21:01:37.678 EDT [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2017-06-12 21:01:37.679 EDT [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update

#################################################################
#######    Generating anchor peer update for Org2MSP   ##########
#################################################################
2017-06-12 21:01:37.700 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-12 21:01:37.704 EDT [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2017-06-12 21:01:37.704 EDT [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update

이 첫 번째 단계는 다양한 네트워크 엔티티에 대한 모든 인증서와 키, 오더링 서비스(the ordering service)를 부트스트랩 하는 데 사용되는 genesis block 및 채널을 구성하는 데 필요한 구성 트랜잭션 모음을 생성합니다.

Bring Up the Network(네트워크 가동)

다음 명령어를 수행시켜 네트워크를 가동합니다.

./byfn.sh -m up

위의 명령은 Golang 체인 코드 이미지를 컴파일하고 해당 컨테이너를 실행시킵니다. Go는 기본 체인 코드 언어이지만 Node.js 체인 코드도 지원됩니다. 노드 체인 코드를 사용하여이 자습서를 실행하려면 다음 명령을 대신 전달하십시오.

# 우리는 chaincode 언어를 지정하기 위해 -l 플래그를 사용합니다.
# -l 플래그를 지정하면 Golang이 기본값이 됩니다.

./byfn.sh -m up -l node

다시 한 번, 계속하거나 중단 할 것인지 묻는 메시지가 나타납니다. y로 응답하거나 return 키를 누르십시오.

Starting with channel 'mychannel' and CLI timeout of '10'
Continue? [Y/n]
proceeding ...
Creating network "net_byfn" with the default driver
Creating peer0.org1.example.com
Creating peer1.org1.example.com
Creating peer0.org2.example.com
Creating orderer.example.com
Creating peer1.org2.example.com
Creating cli


 ____    _____      _      ____    _____
/ ___|  |_   _|    / \    |  _ \  |_   _|
\___ \    | |     / _ \   | |_) |   | |
 ___) |   | |    / ___ \  |  _ <    | |
|____/    |_|   /_/   \_\ |_| \_\   |_|

Channel name : mychannel
Creating channel...

여기에서 로그가 계속됩니다. 이렇게 하면 모든 컨테이너가 시작되고 완전한 종단 간 응용 프로그램(end-to-end application) 시나리오가 시작됩니다. 성공적으로 완료되면 터미널 창에서 다음을 보고해야 합니다.

Query Result: 90
2017-05-16 17:08:15.158 UTC [main] main -> INFO 008 Exiting.....
===================== Query on peer1.org2 on channel 'mychannel' is successful =====================

===================== All GOOD, BYFN execution completed =====================


 _____   _   _   ____
| ____| | \ | | |  _ \
|  _|   |  \| | | | | |
| |___  | |\  | | |_| |
|_____| |_| \_| |____/

이러한 로그를 스크롤하여 다양한 트랜잭션을 볼 수 있습니다. 이 결과를 얻지 못하면 문제 해결 섹션으로 넘어가 무엇이 잘못되었는지 발견 할 수 있는지 알아 보겠습니다.

Bring Down the Network(가동중인 네트워크 중단)

마지막으로 한 번에 명령어로 설정되어 있던 네트워크를 중단할 수 있습니다. 다음은 컨테이너를 죽이고( kill your containers), 암호 자료( crypto material)와 4가지 아티팩트(artifacts)를 제거하고, Docker 레지스트리에서 chaincode 이미지를 삭제합니다.

./byfn.sh -m down

다시 한 번 계속하기를 원하면 y로 응답하거나 return 키를 누르십시오.

Stopping with channel 'mychannel' and CLI timeout of '10'
Continue? [Y/n] y
proceeding ...
WARNING: The CHANNEL_NAME variable is not set. Defaulting to a blank string.
WARNING: The TIMEOUT variable is not set. Defaulting to a blank string.
Removing network net_byfn
468aaa6201ed
...
Untagged: dev-peer1.org2.example.com-mycc-1.0:latest
Deleted: sha256:ed3230614e64e1c83e510c0c282e982d2b06d148b1c498bbdcc429e2b2531e91
...

기본 툴링 및 부트 스트랩 메커니즘에 대해 더 자세히 알고 싶으면 계속 읽으십시오. 다음 섹션에서는 완전한 기능의 Hyperledger 패브릭 네트워크를 구축하기위한 다양한 단계와 요구 사항을 살펴 보겠습니다.

[Note]
아래에 설명된 수동 단계에서는 cli 컨테이너의 CORE_LOGGING_LEVEL이 DEBUG로 설정되어 있다고 가정합니다. 첫 번째 네트워크 디렉토리의 docker-compose-cli.yaml 파일을 수정하여 이를 설정할 수 있습니다. 예 :

cli:
  container_name: cli
  image: hyperledger/fabric-tools:$IMAGE_TAG
  tty: true
  stdin_open: true
  environment:
    - GOPATH=/opt/gopath
    - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
    - CORE_LOGGING_LEVEL=DEBUG
    #- CORE_LOGGING_LEVEL=INFO

Crypto Generator(암호 생성기)

cryptogen 도구를 사용하여 다양한 네트워크 엔터티에 대한 암호 자료 (x509^[1] 인증서 및 서명 키)를 생성합니다. 이 인증서는 신원을 나타내며 당사 엔티티가 통신하고 트랜잭션 할 때 서명/확인(sign/verify ) 인증을 수행할 수 있습니다.

How does it work?(어떻게 작동합니까?)

Cryptogen은 네트워크 토폴로지를 포함하고 있는 - crypto-config.yaml - 파일을 사용하며 조직(Organizations)과 해당 조직(Organizations)에 속한 구성 요소 모두에 대한 인증서 및 키 세트를 생성 할 수 있습니다. 각 조직(Organizations)에는 특정 구성 요소(peers and orderers)를 해당 조직에 바인딩하는 고유 루트 인증서(ca-cert)가 제공됩니다. 각 조직에 고유 한 CA 인증서를 할당하여 참여하는 회원(Memeber)이 자체 인증 기관을 사용하는 일반적인 네트워크를 모방합니다. Hyperledger Fabric 내의 트랜잭션 및 통신은 엔티티의 개인 키 (keystore)에 의해 서명 된 다음 공개 키(signcerts)를 통해 검증됩니다.

이 파일 내에 count변수가 있음을 알 수 있습니다. 우리는 이를 사용하여 조직 당 피어의 수를 지정합니다. 우리의 경우 Org 당 2명의 피어(peers)가 있습니다. 우리는 지금 x.509 인증서 및 공개 키 인프라의 세부 사항을 조사하지 않을 것입니다. 관심이 있다면, 다음 링크를 읽어보세요.

이 도구를 실행하기 전에crypto-config.yaml의 스니펫(snippet)을 간단히 살펴 보겠습니다. OrdererOrgs 헤더 아래의 "Name", "Domain"및 "Specs"매개 변수에 특히 주의하십시오.

OrdererOrgs:
#---------------------------------------------------------
# Orderer
# --------------------------------------------------------
- Name: Orderer
  Domain: example.com
  CA:
      Country: US
      Province: California
      Locality: San Francisco
  #   OrganizationalUnit: Hyperledger Fabric
  #   StreetAddress: address for org # default nil
  #   PostalCode: postalCode for org # default nil
  # ------------------------------------------------------
  # "Specs" - See PeerOrgs below for complete description
# -----------------------------------------------------
  Specs:
    - Hostname: orderer
# -------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
 # ------------------------------------------------------
PeerOrgs:
# -----------------------------------------------------
# Org1
# ----------------------------------------------------
- Name: Org1
  Domain: org1.example.com
  EnableNodeOUs: true

네트워크 엔터티의 명명 규칙은 "{{.Hostname}}.{{.Domain}}" 입니다. 따라서 ordering node를 참조점으로 사용하여 Orderer의 MSP ID에 연결된 orderer.example.com 이라는 ordering node가 남습니다. 이 파일에는 정의 및 구문에 대한 광범위한 설명서가 들어 있습니다. MSP에 관한보다 자세한 정보는 Membership Service Providers (MSP) 문서를 참조하십시오. cryptogen도구를 실행하면 생성 된 인증서와 키가 crypto-config 라는 폴더에 저장됩니다.

Configuration Transaction Generator(트랜잭션 생성기 구성)

configtxgen tool는 4가지 구성 아티팩트(Artifact)^[2]를 만드는 데 사용됩니다.

orderer genesis block,
channel configuration transaction,
and two anchor peer transactions - one for each Peer Org.

이 도구의 기능에 대한 자세한 내용은 configtxgen 을 참조하십시오.

Orderer 블록은 ordering service를 위한 Genesis Block이며 채널 구성 트랜잭션 파일은 채널(Channel) 생성시 orderer에게 브로드캐스트(broadcast)됩니다. 앵커 피어(The anchor peer) 트랜잭션은 이름에서 알 수 있듯이 이 채널에서 각 조직의 앵커 피어(anchor peer)를 지정합니다.

How does it work?(어떻게 작동합니까?)

Configtxgen은 샘플 네트워크의 정의가 들어있는 파일 ( - configtx.yaml -)을 사용합니다. 각 피어 노드를 관리하고 유지 관리하는 Orderer Org (OrdererOrg) 와 Peer Org (Org1 & Org2)의 세 멤버가 있습니다. 이 파일은 또한 2개의 Peer Orgs로 구성된 컨소시엄 - SampleConsortium -을 지정합니다. 이 파일 맨 위에있는 "프로필"섹션에 특히 주의하십시오. 2개의 고유한 헤더가 있음을 알 수 있습니다. 고유한 2개의 헤더는 orderer genesis block 인 - TwoOrgsOrdererGenesis -과 채널의 - TwoOrgsChannel - 입니다.

이러한 헤더는 중요합니다. 우리가 아티팩트를 생성 할 때 인수로 전달합니다.

[Note]
SampleConsortium은 시스템 레벨 프로필에 정의된 다음 채널 레벨 프로필에서 참조됩니다. 컨소시엄의 범위 내에 채널이 존재하며, 모든 컨소시엄은 네트워크 범위 전체에 정의되어야합니다.

이 파일에는 주목할 가치가 있는 두 가지 추가 사양이 포함되어 있습니다.

첫 번째, 각 피어 조직 (peer0.org1.example.com & peer0.org2.example.com)에 대한 앵커 피어(the anchor peers)를 지정합니다.

두 번째, 우리는 각 구성원에 대한 MSP 디렉토리의 위치를 가리키며 차례로 Orderer genesis block에 각 Org에 대한 루트 인증서를 저장할 수 있습니다. 이것은 중요한 개념입니다.

이제 Ordering service와 통신하는 모든 네트워크 엔터티는 디지털 서명을 확인할 수 있습니다.

Run the tools(툴즈 실행)

configtxgen 및 cryptogen 명령을 사용하여 인증서/키(certificates/keys) 및 다양한 구성 아티팩트를 수동으로 생성 할 수 있습니다. 또는, 목표를 달성하기 위해 byfn.sh 스크립트를 적용 할 수도 있습니다.

Manually generate the artifacts(수동으로 아티팩트 생성하기)

byfn.sh 스크립트의 generateCerts 함수를 참조하여 crypto-config.yaml파일에 정의 된대로 네트워크 구성에 사용될 인증서를 생성하는 데 필요한 명령을 참조 할 수 있습니다. 그러나 편의를 위해 여기서도 참조 할 것입니다.

우선 cryptogen 도구를 실행 해 봅시다. 우리의 바이너리는 bin 디렉토리에 있으므로 도구(tool)가 있는 상대 경로를 제공해야합니다.

../bin/cryptogen generate --config=./crypto-config.yaml

터미널에서 다음을 보아야합니다.

org1.example.com
org2.example.com

인증서 및 키 (즉, MSP 자료)는 first-network 디렉토리의 루트에 있는- crypto-config -디렉토리로 출력됩니다.

다음으로, configtxgen 도구를 사용하기 위해 configtx.yaml 파일의 위치를 알려줄 필요가 있습니다. 우리는 현재의 작업 디렉토리를 살펴볼 것입니다 :

export FABRIC_CFG_PATH=$PWD

그런 다음 configtxgen 도구를 호출하여 orderer genesis block 을 만듭니다.

../bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block

터미널에서 다음과 비슷한 출력이 표시되어야합니다.

2017-10-26 19:21:56.301 EDT [common/tools/configtxgen] main -> INFO 001 Loading configuration
2017-10-26 19:21:56.309 EDT [common/tools/configtxgen] doOutputBlock -> INFO 002 Generating genesis block
2017-10-26 19:21:56.309 EDT [common/tools/configtxgen] doOutputBlock -> INFO 003 Writing genesis block

Create a Channel Configuration Transaction(채널 구성 트랜잭션 생성하기)

다음에는 채널 트랜잭션 아티팩트( the channel transaction artifact)를 생성해야 합니다. 다음에 따라 사용할 수있는 환경 변수로 $CHANNEL_NAME을 (를) 바꾸거나 CHANNEL_NAME을 (를) 설정( set CHANNEL_NAME)하십시오.

# The channel.tx artifact contains the definitions for our sample channel
# channel.tx artifact에는 샘플 채널에 대한 정의가 포함되어 있습니다.

export CHANNEL_NAME=mychannel  && ../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME

터미널에서 다음과 유사한 출력을 볼 수 있습니다.

2017-10-26 19:24:05.324 EDT [common/tools/configtxgen] main -> INFO 001 Loading configuration
2017-10-26 19:24:05.329 EDT [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2017-10-26 19:24:05.329 EDT [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 003 Writing new channel tx

다음으로 우리가 구성 할 채널에서 Org1의 앵커 피어를 정의합니다. 다시 말하지만 $CHANNEL_NAME을 바꾸거나 다음 명령에 대한 환경 변수를 설정하십시오. 터미널 출력은 채널 트랜잭션 아티팩트의 출력을 모방합니다.

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP

이제 Org2에 대한 앵커 피어를 동일한 채널에서 정의합니다.

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP

Start the network(네트워크 시작하기)

script를 활용하여 네트워크를 시작할 것입니다. docker-compose 파일은 이전에 다운로드 한 이미지를 참조하고 이전에 생성 된 genesis.block으로 orderer를 부트스트랩(bootstraps)합니다.

우리는 각 호출을 통해 사용구문과 기능을 보이기 위해 명령을 수동으로 수행하려고 합니다.

먼저 네트워크를 시작하십시오.

docker-compose -f docker-compose-cli.yaml up -d

네트워크의 실시간 로그를 보려면 -d플래그를 제공하지 마십시오. 로그 스트림을 보내려면 CLI 호출을 실행하기 위해 두 번째 터미널을 열어야 합니다.

CLI 컨테이너는 1000 초 동안 유휴 State를 유지합니다. 필요가 있을 때 사라졌다면 간단한 명령으로 다시 시작할 수 있습니다:

docker start cli

Environment variables(환경 변수)

peer0.org1.example.com에 대한 다음 CLI 명령이 작동하려면 아래에 제시된 4개의 환경 변수를 사용하여 명령을 시작해야합니다. peer0.org1.example.com에 대한 이러한 변수는 CLI 컨테이너에 저장되므로 그것을 전달하지 않고 운영할 수 있습니다. 그러나 다른 peer 또는 Orderer에게 보내려면 해당 값을 적절하게 제공해야합니다. docker-compose-base.yaml 에서 특정 경로를 검사합니다.

# Environment variables for PEER0

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
CORE_PEER_LOCALMSPID="Org1MSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

Create & Join Channel(채널 생성 및 조인)

위의 <채널 구성 트랜잭션 만들기> 절의 configtxgen 도구를 사용하여 채널 구성 트랜잭션을 만들었습니다. 이 프로세스를 반복하여 configtxgen 도구에 전달한configtx.yaml 의 동일하거나 다른 프로필을 사용하여 추가 채널 구성 트랜잭션을 만들 수 있습니다. 그런 다음이 섹션에서 정의한 프로세스를 반복하여 네트워크에 다른 채널을 설정할 수 있습니다.

docker exec 명령을 사용하여 CLI 컨테이너에 들어갑니다.

docker exec -it cli bash

성공하면 다음이 표시됩니다.

root@0d78bb69300d:/opt/gopath/src/github.com/hyperledger/fabric/peer#

다음으로 생성 된 채널 구성 트랜잭션 아티팩트를 전달합니다. 채널 생성 요청의 일환으로 Orderer에게 채널 구성 트랜잭션 생성 섹션 ( channel.tx라고 함)에서 생성 한 내용을 확인하십시오.

채널 이름을 -c 플래그로 지정하고 채널 구성 트랜잭션을 -f 플래그로 지정합니다. 이 경우에는 channel.tx이지만 다른 이름으로 구성 트랜잭션을 마운트 할 수 있습니다. 이 인수를 명시적으로 전달할 필요가 없도록 CLI 컨테이너 내에 CHANNEL_NAME환경 변수를 설정합니다.

export CHANNEL_NAME=mychannel

# the channel.tx file is mounted in the channel-artifacts directory within your CLI container
# as a result, we pass the full path for the file
# we also pass the path for the orderer ca-cert in order to verify the TLS handshake
# be sure to export or replace the $CHANNEL_NAME variable appropriately

peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

이 명령은 채널에 참여하는 데 사용하는 genesis block - <channel-ID.block> - 을 반환합니다. channel.tx에 지정된 구성 정보가 들어 있습니다. 기본 채널 이름을 수정하지 않은 경우 mychannel.block이라는 제목의 프로토 타입이 반환됩니다.

[Note]
이러한 나머지 수동 명령은 CLI 컨테이너에 남아 있습니다. peer0.org1.example.com 이외의 다른 피어를 대상으로 할 때는 모든 명령 앞에 해당 환경 변수를 사용하는 것을 기억해야합니다.

이제 peer0.org1.example.com을 채널에 가입시켜 보겠습니다.

# 디폴트로, 이것은``peer0.org1.example.com``에만 합류합니다
# 이전 명령에서 <channel-ID.block>을 반환했습니다.
# 채널 이름을 수정하지 않으면 mychannel.block과 함께 참여하게됩니다.
# 다른 채널 이름을 만든 경우 적절하게 명명된 블록을 전달하십시오.

peer channel join -b mychannel.block

위의 환경 변수 섹션에서 사용한 4가지 환경 변수를 적절히 변경하여 다른 피어가 필요에 따라 채널에 참여하도록 만들 수 있습니다.

모든 피어에 가입하는 대신 peer0.org2.example.com 에 간단히 가입하여 채널의 앵커 피어 정의를 올바르게 업데이트 할 수 있습니다. CLI 컨테이너에 구워진 기본 환경 변수를 무시하므로이 전체 명령은 다음과 같습니다.

Update the anchor peers(앵커 피어 업데이트)

다음 명령은 채널 업데이트이며 채널의 정의로 전파됩니다. 본질적으로 채널의 기원 블록(the channel’s genesis block) 상단에 추가 구성 정보를 추가합니다.genesis block을 수정하는 것이 아니라 단순히 앵커 피어를 정의하는 체인에 델타(deltas)를 추가하는 것입니다.

channel 정의를 업데이트하여 Org1의 앵커 피어를 peer0.org1.example.com 으로 정의합니다.

peer channel update -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/Org1MSPanchors.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

이제 채널 정의를 업데이트하여 Org2의 앵커 피어를 peer0.org2.example.com 으로 정의합니다. Org2 피어의 피어 채널 조인 명령과 동일하게 이 호출을 적절한 환경 변수로 시작해야 합니다.

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp 
CORE_PEER_ADDRESS=peer0.org2.example.com:7051 
CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt 
peer channel update -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/Org2MSPanchors.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

Install & Instantiate Chaincode(체인코드 설치 & 인스턴스화)

[Note]
우리는 단순한 기존 chaincode를 활용할 것입니다. 독자적인 체인 코드를 작성하는 방법을 배우려면, 개발자 용 Chaincode 자습서(http://hyperledger-fabric.readthedocs.io/en/release-1.1/chaincode4ade.html)를 참조하십시오.

응용 프로그램은 chaincode를 통해 블록 체인 원장과 상호 작용합니다. 따라서 트랜잭션을 실행하고 Endorse할 모든 피어에 체인 코드를 설치 한 다음 채널에서 체인 코드를 인스턴스화해야합니다.

먼저 샘플 Go 또는 Node.js 체인 코드를 4개의 피어 노드 중 하나에 설치하십시오. 이 명령은 지정된 소스 코드를 피어의 파일 시스템에 배치합니다.

[Note]
체인 코드 이름 및 버전 당 한 버전의 소스 코드 만 설치할 수 있습니다. 소스 코드는 체인 코드 이름과 버전의 컨텍스트에서 피어의 파일 시스템에 존재합니다. 그것은 언어에 상관없습니다. 마찬가지로 인스턴스화 된 chaincode 컨테이너는 피어에 설치된 언어를 반영합니다.

Golang

# this installs the Go chaincode
peer chaincode install -n mycc -v 1.0 -p github.com/chaincode/chaincode_example02/go/

Node.js

# this installs the Node.js chaincode
# make note of the -l flag; we use this to specify the language
peer chaincode install -n mycc -v 1.0 -l node -p /opt/gopath/src/github.com/chaincode/chaincode_example02/node/

그런 다음 채널에서 체인 코드를 인스턴스화합니다. 그러면 채널의 체인 코드가 초기화되고 체인 코드에 대한 Endorsement Policy가 설정되며 대상 피어에 대해 체인 코드 컨테이너가 시작됩니다. -P 인수에 유의하십시오 . 이것은 우리의 정책으로,이 체인 코드에 대한 트랜잭션의 유효성을 검증하는 데 필요한 Endorsement Level을 지정합니다.

아래 명령에서 정책을 -P "OR ('Org0MSP.peer','Org1MSP.peer')" 로 지정한다는 것을 알 수 있습니다. 즉, Org1 OR Org2에 속한 피어 (즉, 단 하나의 Endorsement)로부터 "Endorsement"해야합니다. 구문을 AND 로 변경하면 2가지 Endorsement가 필요합니다.

Golang

# $CHANNEL_NAME 환경 변수를 내보내지 않은 경우 이를 바꿔야 합니다.
# mycc라는 이름의 체인 코드를 설치하지 않았다면 그 인수도 수정하십시오.

peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"

Node.js

[Note]
Node.js 체인 코드의 인스턴스 생성은 대략 1분 정도 소요됩니다. 이 명령은 걸려 있지 않습니다. 이미지가 편집 될 때  fabric-shim을 설치하고 있습니다.
The instantiation of the Node.js chaincode will take roughly a minute. The command is not hanging; rather it is installing the fabric-shim layer as the image is being compiled.

정책 구현에 대한 자세한 내용은 Endorsement Policy 문서를 참조하십시오.

추가 피어가 원장과 상호 작용하게 하려면 해당 피어를 원장과 연결해야 하며 체인 코드 소스의 이름, 버전 및 언어를 해당 피어의 파일 시스템에 설치해야합니다. 체인 코드 컨테이너는 특정 체인 코드와 상호 작용하는 즉시 각 피어에 대해 실행됩니다. 다시 말하지만, Node.js 이미지가 더 느리게 컴파일된다는 사실을 인식하십시오.

체인 코드가 채널에서 인스턴스화되면 l 플래그를 무시할 수 있습니다. 채널 식별자와 체인 코드 이름 만 전달하면됩니다.

Query(쿼리)

체인 코드가 올바르게 인스턴스화되고 State DB가 채워 졌는지 확인하기 위해 a 의 값을 쿼리(query)합니다. 쿼리(query)의 구문은 다음과 같습니다.

# -C와 -n 플래그를 적절하게 설정해야한다.
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

Invoke(호출, 업데이트)

이제 10을 a에서 b로 이동합시다. 이 트랜잭션은 새 블록을 잘라내어 State DB를 업데이트합니다. 호출(invoke) 구문은 다음과 같습니다.

# -C와 -n 플래그를 적절하게 설정해야한다.
peer chaincode invoke -o orderer.example.com:7050  --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem  -C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}'

Query(쿼리)

우리의 이전 호출(invocation )이 제대로 실행되었는지 확인합시다. 키 a를 100으로 초기화하고 이전 호출을 사용하여 10 을 제거했습니다. 따라서 a에 대한 쿼리는 90 을 나타내야합니다. 쿼리 구문은 다음과 같습니다.

# -C와 -n 플래그를 적절하게 설정해야한다.
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

결과는 다음과 같습니다.

Query Result: 90

처음부터 다시 시작하여 키 값 쌍 및 후속 호출을 수정하여 실습해보세요.

What’s happening behind the scenes?(그 뒤에서 무슨 일이 일어나나요?)

[Note]
이 단계에서는 script.sh가 './byfn.sh up'에 의해 실행되는 시나리오를 설명합니다. ./byfn.sh를 사용하여 네트워크를 정리하고 이 명령이 활성 State인지 확인하십시오. 그런 다음 동일한 도커 작성 프롬프트를 사용하여 네트워크를 다시 시작하십시오.

스크립트 - script.sh - 는 CLI 컨테이너에서 실행됩니다. 스크립트는 제공된 채널 이름에 대해 createChannel명령을 실행하고 채널 구성에 channel.tx 파일을 사용합니다.
createChannel의 출력은 피어들의 파일 시스템에 저장되고 channel.tx에서 지정된 채널 구성을 포함하는 genesis block 인 - <your_channel_name>.block - 입니다.
joinChannel 명령은 이전에 생성된 genesis block을 입력으로 사용하는 4개의 모든 피어에 대해 실행됩니다. 이 명령은 피어가 <your_channel_name> 에 가입하고 <your_channel_name>.block으로 시작하는 체인을 만들도록 지시합니다.
이제 우리에게는 4 명의 피어와 2 개의 조직으로 구성된 채널이 있습니다. 이것은 TwoOrgsChannel 프로필입니다.
peer0.org1.example.com 및 peer1.org1.example.com 은 Org1에 속합니다. peer0.org2.example.com 및 peer1.org2.example.com은 Org2에 속합니다.
이러한 관계는 crypto-config.yaml을 통해 정의되며 MSP 경로는 docker compose에서 지정됩니다.
Org1MSP (peer0.org1.example.com) 및 Org2MSP (peer0.org2.example.com)의 앵커 피어(anchor peers)가 업데이트됩니다. Org1MSPanchors.tx 및 Org2MSPanchors.tx 아티팩트를 채널 이름과 함께 Ordering service에 전달하여 이 작업을 수행합니다.
체인코드- chaincode_example02 -는 peer0.org1.example.com 및 peer0.org2.example.com에 설치됩니다.
그런 다음 chaincode는 peer0.org2.example.com 에서 "인스턴스화(instantiated)"됩니다. 인스턴스화(Instantiation )는 채널에 체인 코드를 추가하고 대상 피어에 대한 컨테이너를 시작하며 체인 코드와 연관된 키 값 쌍을 초기화합니다( initializes the key value pairs associated with the chaincode). 이 예제의 초기 값은 [ "a", "100" "b", "200"]입니다. 이 "인스턴스화"는 dev-peer0.org2.example.com-mycc-1.0 이라는 이름으로 컨테이너를 시작합니다.
이 인스턴스화는 Endorsement Policy에 대한 인수도 전달합니다. 이 정책은 -P "OR ('Org1MSP.peer','Org2MSP.peer')" 로 정의됩니다. 이는 모든 트랜잭션이 Org1 또는 Org2에 연결된 피어에 의해 Endorse되어야 함을 의미합니다.
peer0.org1.example.com에 "a"값에 대한 쿼리가 발행됩니다. chaincode는 이전에 peer0.org1.example.com 에 설치되었으므로 Org1 peer0의 컨테이너가 dev-peer0.org1.example.com-mycc-1.0이라는 이름으로 시작됩니다. 쿼리의 결과도 반환됩니다. 쓰기 작업이 발생하지 않으므로 "a"에 대한 쿼리는 여전히 "100"값을 반환합니다.
"a"에서 "b"로 "10"을 이동하기 위해 호출이 peer0.org1.example.com 으로 전송됩니다.
chaincode는 peer1.org2.example.com에 설치됩니다.
"a"값에 대한 쿼리가 peer1.org2.example.com 으로 전송됩니다. 그러면 dev-peer1.org2.example.com-mycc-1.0이라는 이름으로 세 번째 chaincode 컨테이너가 시작됩니다. 키 "a"의 값이 10으로 수정 된 이전 트랜잭션을 정확하게 반영하여 값 90이 리턴됩니다.

What does this demonstrate?(이것은 무엇을 보여줍니까?)

원장(ledger)에 대한 읽기/쓰기 작업을 성공적으로 수행하려면 피어에 체인 코드를 설치해야 합니다. 또한 체인 코드 컨테이너는 해당 체인 코드 (예 : "a"값에 대한 쿼리)에 대해 초기화 또는 기존 트랜잭션 (읽기/쓰기)이 수행 될 때까지 피어에 대해 시작되지 않습니다. 트랜잭션은 컨테이너를 시작하게 합니다. 또한 채널의 모든 피어는 불변의 시퀀스 된 레코드를 블록으로 저장하는 블록 체인과 현재 State의 스냅 샷을 유지 관리하는 State 데이터베이스를 포함하는 원장의 정확한 사본을 유지 관리합니다. 여기에는 위의 예에서 peer1.org1.example.com 과 같이 chaincode가 설치되지 않은 피어가 포함됩니다. 마지막으로 체인 코드는 이미 인스턴스화되었으므로 위의 예에서 peer1.org2.example.com과 같이 설치 한 후에 액세스 할 수 있습니다.

How do I see these transactions?(트랜잭션은 어떻게 볼 수 있습니까?)

CLI Docker 컨테이너의 로그를 확인하십시오.

docker logs -f cli

다음과 같은 결과가 나옵니다.

2017-05-16 17:08:01.366 UTC [msp] GetLocalMSP -> DEBU 004 Returning existing local MSP
2017-05-16 17:08:01.366 UTC [msp] GetDefaultSigningIdentity -> DEBU 005 Obtaining default signing identity
2017-05-16 17:08:01.366 UTC [msp/identity] Sign -> DEBU 006 Sign: plaintext: 0AB1070A6708031A0C08F1E3ECC80510...6D7963631A0A0A0571756572790A0161
2017-05-16 17:08:01.367 UTC [msp/identity] Sign -> DEBU 007 Sign: digest: E61DB37F4E8B0D32C9FE10E3936BA9B8CD278FAA1F3320B08712164248285C54
Query Result: 90
2017-05-16 17:08:15.158 UTC [main] main -> INFO 008 Exiting.....
===================== Query on peer1.org2 on channel 'mychannel' is successful =====================

===================== All GOOD, BYFN execution completed =====================


 _____   _   _   ____
| ____| | \ | | |  _ \
|  _|   |  \| | | | | |
| |___  | |\  | | |_| |
|_____| |_| \_| |____/

How can I see the chaincode logs?(체인 코드 로그는 어떻게 볼 수 있습니까?)

개별 체인 코드 컨테이너를 검사하여 각 컨테이너에 대해 실행 된 개별 트랜잭션을 확인합니다. 다음은 각 컨테이너에서 결합 된 출력입니다.

$ docker logs dev-peer0.org2.example.com-mycc-1.0
04:30:45.947 [BCCSP_FACTORY] DEBU : Initialize BCCSP [SW]
ex02 Init
Aval = 100, Bval = 200

$ docker logs dev-peer0.org1.example.com-mycc-1.0
04:31:10.569 [BCCSP_FACTORY] DEBU : Initialize BCCSP [SW]
ex02 Invoke
Query Response:{"Name":"a","Amount":"100"}
ex02 Invoke
Aval = 90, Bval = 210

$ docker logs dev-peer1.org2.example.com-mycc-1.0
04:31:30.420 [BCCSP_FACTORY] DEBU : Initialize BCCSP [SW]
ex02 Invoke
Query Response:{"Name":"a","Amount":"90"}

Understanding the Docker Compose topology(Docker Compose 토폴로지 이해)

BYFN 샘플은 docker-compose-base.yaml( base폴더에 있음)에서 확장 된 두 가지 Docker Compose 파일을 제공합니다. 첫 번째는, docker-compose-cli.yaml 은 CLI 컨테이너와 함께 4 명의 피어와 함께 orderer 를 제공합니다. 이 파일은 이 페이지의 지침 전체에 사용됩니다.

[Note]
이 절의 나머지 부분에서는 SDK 용으로 설계된 도커 작성 파일에 대해 설명합니다. 이러한 테스트 실행에 대한 자세한 내용은 노드 SDK 레포를 참조하십시오.

두 번째인 docker-compose-e2e.yaml 은 Node.js SDK를 사용하여 end-to-end 테스트를 실행하도록 구성됩니다. SDK의 기능 외에도 fabric-ca 서버를 위한 컨테이너가 있다는 것이 주요 차이점입니다. 결과적으로 사용자 등록 및 등록을 위해 REST 호출을 조직 CA에 보낼 수 있습니다.

byfn.sh 스크립트를 먼저 실행하지 않고 docker-compose-e2e.yaml을 사용하려면 4 단계를 약간 수정해야 합니다. 조직의 CA의 개인 키를 가리켜야 합니다. crypto-config 폴더에서 이 값을 찾을 수 있습니다. 예를 들어, Org1의 개인 키를 찾으려면이 경로 (crypto-config/peerOrganizations/org1.example.com/ca/)를 따라야합니다. 개인 키는_sk뒤에 오는 긴 해시 값입니다. Org2의 경로는 - crypto-config/peerOrganizations/org2.example.com/ca/ 입니다.

docker-compose-e2e.yaml에서 ca0 및 ca1에 대한 FABRIC_CA_SERVER_TLS_KEYFILE 변수를 업데이트하십시오. 또한 ca 서버를 시작하기 위해 명령에 제공된 경로를 편집해야합니다. 각 CA 컨테이너에 동일한 개인 키를 2번 제공합니다.

Using CouchDB(CouchDB 사용)

State 데이터베이스는 기본값 (goleveldb)에서 CouchDB로 전환 할 수 있습니다. 동일한 체인 코드 기능을 CouchDB에서 사용할 수 있지만 체인 코드 데이터를 JSON으로 모델링 할 때 State 데이터베이스 데이터 내용에 대해 풍부하고 복잡한 쿼리를 수행 할 수있는 추가 기능이 있습니다.

기본 데이터베이스 (goleveldb) 대신 CouchDB를 사용하려면 네트워크 시작 docker-compose-couch.yaml 을 제외하고 아티팩트 생성을 위해 앞에서 설명한 것과 동일한 절차를 따르십시오.

docker-compose -f docker-compose-cli.yaml -f docker-compose-couch.yaml up -d

chaincode_example02 는 이제 CouchDB를 사용하여 작동합니다.

[Note]
fabric-couchdb 컨테이너 포트를 호스트 포트에 매핑하는 방법을 선택하는 경우 보안 관련 사항을 알고 있는지 확인하십시오. 개발 환경에서 포트를 매핑하면 CouchDB REST API를 사용할 수 있으며 CouchDB 웹 인터페이스 (Fauxton)를 통해 데이터베이스를 시각화 할 수 있습니다. 프로덕션 환경에서는 CouchDB 컨테이너에 대한 외부 액세스를 제한하기 위해 포트 매핑을 구현하지 않을 가능성이 높습니다.

위에서 설명한 단계를 사용하여 CouchDB State 데이터베이스에 chaincode_example02 chaincode를 사용할 수 있지만 CouchDB 쿼리 기능을 사용하려면 JSON으로 모델링 된 데이터가있는 체인 코드 (예 : marbles02)를 사용해야합니다. marbles02 chaincode는 fabric/examples/chaincode/go 디렉토리에서 찾을 수 있습니다.

위의 Create & Join 채널 섹션에서 설명한대로 동일한 프로세스를 따라 채널을 만들고 가입하십시오. 피어(들)를 채널에 가입시킨 후 다음 단계를 사용하여 marbles02 체인 코드와 상호 작용하십시오.

peer0.org1.example.com 에 체인 코드를 설치하고 인스턴스화하십시오.

# 인스턴스화 명령에 따라 $CHANNEL_NAME 변수를 수정해야합니다.

peer chaincode install -n marbles -v 1.0 -p github.com/chaincode/marbles02/go
peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -v 1.0 -c '{"Args":["init"]}' -P "OR ('Org0MSP.peer','Org1MSP.peer')"

몇개의 구슬을 만들어 이동시켜 보세요.

# $CHANNEL_NAME 변수를 적절히 수정해야합니다.

peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["initMarble","marble1","blue","35","tom"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["initMarble","marble2","red","50","tom"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["initMarble","marble3","blue","70","tom"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["transferMarble","marble2","jerry"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["transferMarblesBasedOnColor","blue","jerry"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["delete","marble1"]}'

docker-compose에서 CouchDB 포트를 매핑하도록 선택한 경우 브라우저를 열고 다음 URL로 이동하여 CouchDB 웹 인터페이스 (Fauxton)를 통해 State 데이터베이스를 볼 수 있습니다.

http://localhost:5984/_utils

mychannel(또는 고유한 채널 이름)이라는 데이터베이스와 그 안에있는 문서를 볼 수 있습니다.

[Note]
아래 명령에 대해서는 $CHANNEL_NAME 변수를 적절하게 업데이트해야합니다.

CLI에서 정기적으로 쿼리를 실행할 수 있습니다. (예 : marble2)

peer chaincode query -C $CHANNEL_NAME -n marbles -c '{"Args":["readMarble","marble2"]}'

결과물에는 marble2의 세부 정보가 표시되어야합니다.

Query Result: {"color":"red","docType":"marble","name":"marble2","owner":"jerry","size":50}

특정 구술의 기록을 검색 할 수 있습니다 (예 : marble1)

peer chaincode query -C $CHANNEL_NAME -n marbles -c '{"Args":["getHistoryForMarble","marble1"]}'

결과물은 marble1에 트랜잭션을 표시해야합니다.

Query Result: [{"TxId":"1c3d3caf124c89f91a4c0f353723ac736c58155325f02890adebaa15e16e6464", "Value":{"docType":"marble","name":"marble1","color":"blue","size":35,"owner":"tom"}},{"TxId":"755d55c281889eaeebf405586f9e25d71d36eb3d35420af833a20a2f53a3eefd", "Value":{"docType":"marble","name":"marble1","color":"blue","size":35,"owner":"jerry"}},{"TxId":"819451032d813dde6247f85e56a89262555e04f14788ee33e28b232eef36d98f", "Value":}]

소유자 jerry 에 의한 marble 필드 쿼리와 같은 데이터 컨텐츠에 대한 풍부한 쿼리를 수행 할 수도 있습니다. :

peer chaincode query -C $CHANNEL_NAME -n marbles -c '{"Args":["queryMarblesByOwner","jerry"]}'

결과물에는 jerry 소유의 두 marbles구술이 표시되어야합니다.

Query Result: [{"Key":"marble2", "Record":{"color":"red","docType":"marble","name":"marble2","owner":"jerry","size":50}},{"Key":"marble3", "Record":{"color":"blue","docType":"marble","name":"marble3","owner":"jerry","size":70}}]

Why CouchDB(왜 CouchDB인가?)

CouchDB는 일종의 NoSQL 솔루션이다. 문서 필드가 키-값 맵으로 저장되는 문서 지향 데이터베이스입니다. 필드는 간단한 키-값 쌍, 목록 또는 맵이 될 수 있습니다. LevelDB에서 지원하는 키/복합 키/키 범위 쿼리 외에도 CouchDB는 전체 블록 체인 데이터에 대한 키가 아닌 쿼리와 같은 전체 데이터 리치 쿼리 기능을 지원합니다. 데이터 내용은 JSON 형식으로 저장되므로 완전히 쿼리 가능합니다. 따라서 CouchDB는 Levelcode에서 지원하지 않는 많은 유스 케이스에 대한 체인 코드, 감사,보고 요구 사항을 충족시킬 수 있습니다.

또한 CouchDB는 블록 체인에서 준수 및 데이터 보호를 위한 보안을 향상시킬 수 있습니다. 트랜잭션 내에서 개별 속성의 필터링 및 마스킹을 통해 필드 수준의 보안을 구현할 수 있으므로 필요에 따라 읽기 전용 권한 만 인증합니다.

또한 CouchDB는 CAP 정리의 AP 유형 (가용성 및 파티션 허용 오차)에 해당합니다. Eventual Consistency을 갖춘 master-master 복제 모델을 사용합니다. 더 많은 정보는 CouchDB 문서의 최종 일관성 페이지에서 찾을 수 있습니다. 그러나 각 패브릭 피어마다 데이터베이스 복제본이 없으며 데이터베이스에 대한 쓰기가 일관되고 내구성이 보장됩니다 ( Eventual Consistency이 아님).

CouchDB는 Fabric을위한 최초의 외부 플러그 가능 State 데이터베이스이며, 다른 외부 데이터베이스 옵션이있을 수 있고 있어야합니다. 예를 들어, IBM은 블록 체인에 관계형 데이터베이스를 사용 가능하게 합니다. 또한 응용 프로그램 수준의 Endorsement없이 데이터 일관성을 유지할 수 있도록 CP 유형 (일관성 및 파티션 허용 오차) 데이터베이스가 필요할 수 있습니다.

A Note on Data Persistence(데이터 지속성에 대한 참고사항)

피어 컨테이너 또는 CouchDB 컨테이너에서 데이터 지속성이 필요한 경우, 한 가지 옵션은 docker-host의 디렉토리를 컨테이너의 관련 디렉토리에 마운트하는 것입니다. 예를 들어, docker-compose-base.yaml파일의 피어 컨테이너 스펙에 다음 두 행을 추가 할 수 있습니다.

volumes:
 - /var/hyperledger/peer0:/var/hyperledger/production

CouchDB 컨테이너의 경우 CouchDB 컨테이너 사양에 다음 두 줄을 추가 할 수있다.

volumes:
 - /var/hyperledger/couchdb0:/opt/couchdb/data

Troubleshooting(문제해결)

항상 네트워크를 새로 시작하십시오. 아티팩트, 암호, 컨테이너 및 체인 코드 이미지를 제거하려면 다음 명령을 사용하십시오.

./byfn.sh -m down

Docker 오류가 표시되면 먼저 도커 버전 (선행 조건)을 확인한 다음 Docker 프로세스를 다시 시작하십시오. Docker의 문제점은 종종 즉시 인식되지 않습니다. 예를 들어, 컨테이너에 마운트된 암호 자료에 액세스 할 수 없으므로 오류가 발생할 수 있습니다. 그들이 지속되면 이미지를 제거하고 처음부터 시작하십시오.

docker rm -f $(docker ps -aq)
docker rmi -f $(docker images -q)

작성, 인스턴스 작성, 호출 또는 조회 명령에 오류가 있는 경우, 채널 이름 및 체인 코드 이름을 올바르게 갱신했는지 확인하십시오. 제공된 샘플 명령에는 자리 표시 자 값이 있습니다.

아래 오류가 표시되면 :

Error: Error endorsing chaincode: rpc error: code = 2 desc = Error installing chaincode code mycc:1.0(chaincode /var/hyperledger/production/chaincodes/mycc.1.0 exits)

이전 실행에서 체인 코드 이미지 (예 : dev-peer1.org2.example.com-mycc-1.0 또는 dev-peer0.org1.example.com-mycc-1.0)가 있을 가능성이 큽니다. 그들을 제거하고 다시 시도하십시오.

docker rmi -f $(docker images | grep peer[0-9]-peer[0-9] | awk '{print $3}')

다음과 유사한 내용이 표시되는 경우

Error connecting: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
Error: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure

"latest"으로 태그가 다시 지정된 "1.0.0"이미지에 대해 네트워크를 실행하고 있는지 확인하십시오.

아래 오류가 표시되면 :

[configtx/tool/localconfig] Load -> CRIT 002 Error reading configuration: Unsupported Config Type ""
panic: Error reading configuration: Unsupported Config Type ""
# [configtx / tool / localconfig]로드 -> CRIT 002 구성 읽기 오류 : 지원되지 않는 구성 유형 "" 패닉 : 구성 읽기 오류 : 지원되지 않는 구성 유형 ""

그런 다음 FABRIC_CFG_PATH 환경 변수를 올바르게 설정하지 않았습니다. configtxgen 도구는 configtx.yaml을 찾으려면 이 변수가 필요합니다. 돌아가서 export FABRIC_CFG_PATH=$PWD를 실행 한 다음 채널 아티팩트를 다시 만드십시오.

네트워크를 정리하려면 다음 down옵션을 사용하십시오.

./byfn.sh -m down

"active endpoints"가 있음을 나타내는 오류가 표시되면 Docker 네트워크를 정리하십시오. 이렇게 하면 이전 네트워크를 지우고 새로운 환경에서 시작할 수 있습니다.

docker network prune

다음 메시지가 표시가 되면 y 를 선택하세요.

WARNING! This will remove all networks not used by at least one container.
Are you sure you want to continue? [y/N]
# 경고! 이렇게하면 하나 이상의 컨테이너에서 사용하지 않는 모든 네트워크가 제거됩니다. 정말 계속하고 싶습니까? [y/N]

↑ X.509는 암호학에서 공개키 인증서와 인증알고리즘의 표준 가운데에서 공개 키 기반(PKI)의 ITU-T 표준이다.
↑ 아티팩트의 의미는 운영체제나 애플리케이션을 사용하면서 생성되는 흔적을 말한다. 보통 시스템에 생성되는 증거를 다음과 같이 2가지로 분류하는데 생성 증거에 해당하는 것이 아티팩트다. 생성 증거 : 시스템이나 애플리케이션이 자동으로 생성한 데이터 보관 증거 : 사람의 사상이나 감정을 표현하기 위해 작성한 데이터 예를 들어, 윈도우 시스템의 생성 증거(아티팩트)로는 레지스트리, 프리/슈퍼패치, 이벤트 로그 등이 있다. 보관 증거로는 직접 작성한 메일 내용, 블로그 및 소셜 네트워크 작성 내용, 직접 작성한 문서 등이 있다.

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/build_network.html

'[블록체인] 하이퍼레저 > [하이퍼레저 패브릭] ' 카테고리의 다른 글

[하이퍼레저 공식문서]Tutorials - Adding an Org to a Channel (0)	2018.06.04
[하이퍼레저 공식문서]Tutorials - Writing Your First Application (0)	2018.06.04
[하이퍼레저 공식문서]Key Concepts - Identity (0)	2018.06.04
[하이퍼레저 공식문서]Key Concepts - Hyperledger Fabric model (0)	2018.06.04
[하이퍼레저 공식문서]Key Concepts - Hyperledger Fabric Functionalities (0)	2018.06.04

월간, 블록체인

[하이퍼레저 공식문서]Tutorials - Building Your First Network

Building Your First Network(첫 번째 네트워크 구축)

Install prerequisites(필수 구성요소 설치)

Want to run it now?

Generate Network Artifacts(네트워크 아키팩트 생성)

Bring Up the Network(네트워크 가동)

Bring Down the Network(가동중인 네트워크 중단)

Crypto Generator(암호 생성기)

How does it work?(어떻게 작동합니까?)

Configuration Transaction Generator(트랜잭션 생성기 구성)

How does it work?(어떻게 작동합니까?)

Run the tools(툴즈 실행)

Manually generate the artifacts(수동으로 아티팩트 생성하기)

Create a Channel Configuration Transaction(채널 구성 트랜잭션 생성하기)

Start the network(네트워크 시작하기)

Environment variables(환경 변수)

Create & Join Channel(채널 생성 및 조인)

Update the anchor peers(앵커 피어 업데이트)

Install & Instantiate Chaincode(체인코드 설치 & 인스턴스화)

Query(쿼리)

Invoke(호출, 업데이트)

Query(쿼리)

What’s happening behind the scenes?(그 뒤에서 무슨 일이 일어나나요?)

What does this demonstrate?(이것은 무엇을 보여줍니까?)

How do I see these transactions?(트랜잭션은 어떻게 볼 수 있습니까?)

How can I see the chaincode logs?(체인 코드 로그는 어떻게 볼 수 있습니까?)

Understanding the Docker Compose topology(Docker Compose 토폴로지 이해)

Using CouchDB(CouchDB 사용)

Why CouchDB(왜 CouchDB인가?)

A Note on Data Persistence(데이터 지속성에 대한 참고사항)

Troubleshooting(문제해결)

'[블록체인] 하이퍼레저 > [하이퍼레저 패브릭] ' 카테고리의 다른 글

+ Recent posts

티스토리툴바