이 가이드는 패브릭 CA를 패브릭 네트워크 설정을 위해 사용하는 방법을 설명한다. 하이퍼레저 패브릭 블록체인 네트워크의 모든 참여 아이덴티티는 승인을 받아야 한다. 이 승인은 신뢰로운 기관이 검증한 암호화 자료의 형태로 제공된다.
이 가이드에서는 두 피어와 한 오더러로 구성된 두 조직을 포함한 블록체인 네트워크를 설정하는 과정을 볼 수 있을 것이다. 어떻게 오더러, 피어, 관리자, 그리고 최종 사용자를 위한 암호화 자료를 생성해 개인키가 그들이 생성된 호스트나 컨테이너를 떠나지 않게 만드는지 볼 수 있을 것이다.
이 예에서 세 조직의 오더러, 피어, CA들을 설정하는 방법을 살펴본다. 이 배포의 토폴로지는 아래 이미지에서 볼 수 있다 :

이 예는 도커 컨테이너를 사용한 배포를 시뮬레이션할 것이다. 컨테이너는 서로 다른 호스트 머신에서 구동되는 것처럼 여겨질 것이다. 그리하여 어떤 자산에 네트워크에 참여한 조직 간 대역 외(out-of-band) 교환이 필요한지를 알 수 있다.
이 도커 네트워크 구성은 모든 컨테이너가 동일 네트워크에서 구동되고 있음을 가정한다. 배포가 서로 다른 네트워크에서 이루어지고 있는 경우 이 예가 해당 네트워크 구성에서 작동할 수 있도록 조정해야 한다.
아래 문서는 각 구성요소를 분석하기 위해 docker-compose 파일을 분해한다. 전체 docker-compose를 보고 싶다면 여기를 클릭해라
암호화 자료를 요구하는 각 호스트에 대해, 호스트 머신에서 작동할 수 있는 클라이언트 바이너리가 필요하다. 클라이언트는 패브릭 CA 서버 컨테이너에 연결할 때 사용된다.
fabric-ca-client binary를 다운로드하기 위해 이 레포지토리를 탐색해 최신 바이너리를 선택해라
주의
이 예시는 fabric-ca-client 1.4.0 버전을 사용한다.
TLS CA는 TLS 인증서 발행을 위해 사용된다. 이 인증서는 여러 프로세스 간 통신 보안을 위해 요구된다.
예시를 단순화하기 위해, 모든 조직은 같은 TLS CA를 사용하며 TLS 상호 승인(TLS mutual authentication)은 비활성화된다.
주의
프로덕션 환경에서는 TLS 인증서를 얻기 위해 조직 CA를 활용할 것이다. TLS 인증서 유효성을 검증할 조직에 해당 CA 인증서를 대역 외 전송해야 할 것이다. 즉, 이 예시와 달리, 각 조직은 자신만의 TLS CA를 가진다.
아래와 같은 도커 서비스는 패브릭 TLS CA 컨테이너를 런칭하는데에 사용된다.
ca-tls:
container_name: ca-tls
image: hyperledger/fabric-ca
command: sh -c 'fabric-ca-server start -d -b tls-ca-admin:tls-ca-adminpw --port 7052'
environment:
- FABRIC_CA_SERVER_HOME=/tmp/hyperledger/fabric-ca/crypto
- FABRIC_CA_SERVER_TLS_ENABLED=true
- FABRIC_CA_SERVER_CSR_CN=ca-tls
- FABRIC_CA_SERVER_CSR_HOSTS=0.0.0.0
- FABRIC_CA_SERVER_DEBUG=true
volumes:
- /tmp/hyperledger/tls/ca:/tmp/hyperledger/fabric-ca
networks:
- fabric-ca
ports:
- 7052:7052
이 컨테이너는 아래 도커 커맨드를 사용해 시작될 수 있다.
docker-compose up ca-tls
컨테이너가 성공적으로 런칭하면 아래와 같은 CA 컨테이너 로그를 볼 수 있다.
[INFO] Listening on https://0.0.0.0:7052
이 시점에서 TLS CA 서버는 보안 소켓을 수신 대기하고 있고 TLS 인증서 발급을 시작할 수 있다.
CA 클라이언트를 사용하려면 반드시 CA의 TLS 인증서를 위한 서명 인증서를 획득해야 한다. 이것은 TLS를 사용해 커넥팅하기 전에 필수적으로 요구되는 단계이다.
이 예시에서는 TLS CA 서버를 구동중인 머신의 /tmp/hyperledger/tls-ca/crypto/ca-cert.pem에 위치한 파일을 습득하고, 해당 파일을 CA 클라이언트 바이너리를 구동할 호스트로 복사해 전달해야 한다. TLS CA의 서명 인증서라고도 불리는 이 인증서는 CA의 TLS 인증서를 검증하기 위해 사용된다. 이 인증서가 CA 클라이언트의 호스트 머신으로 복사되고 나면, CA를 사용한 발행 커맨드를 시작할 수 있다.
TLS CA의 서명 인증서는 TLS CA에 대해 커맨드를 실행할 모든 호스트에서 접근가능해야 한다.
TLS CA 서버는 서버에 대한 전체 관리자(admin) 권한을 가진 부트스트랩 아이덴티티를 사용해 시작되었다. 이 관리자(admin)의 핵심 기능 중 하나는 새 아이덴티티를 기재(register)하는 것이다. 이 CA에 대한 관리자는 CA로 새 아이덴티티를 기재하기 위해 fabric ca client를 사용할 것이다 (각 피어에 대한 아이덴티티 하나씩과 오더러를 위한 아이덴티티 하나를 기재한다). 이 아이덴티티들은 피어들과 오더러들의 TLS 인증서를 얻기 위해 사용된다.
TLS CA 관리자를 등록하고 아이덴티티들을 기재하기 위해 아래 명령어를 사용할 수 있다. 여기서는 TLS CA의 신뢰로운 루트 인증서가 fabric-ca-client를 통해 CA와 통신할 모든 호스트 머신의 /tmp/hyperledger/tls-ca/crypto/tls-ca-cert.pem로 복제되었다고 가정한다.
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/tls-ca/crypto/tls-ca-cert.pem
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/tls-ca/admin
fabric-ca-client enroll -d -u https://tls-ca-admin:tls-ca-adminpw@0.0.0.0:7052
fabric-ca-client register -d --id.name peer1-org1 --id.secret peer1PW --id.type peer -u https://0.0.0.0:7052
fabric-ca-client register -d --id.name peer2-org1 --id.secret peer2PW --id.type peer -u https://0.0.0.0:7052
fabric-ca-client register -d --id.name peer1-org2 --id.secret peer1PW --id.type peer -u https://0.0.0.0:7052
fabric-ca-client register -d --id.name peer2-org2 --id.secret peer2PW --id.type peer -u https://0.0.0.0:7052
fabric-ca-client register -d --id.name orderer1-org0 --id.secret ordererPW --id.type orderer -u https://0.0.0.0:7052
주의
FABRIC_CA_CLIENT_TLS_CERTFILES 환경 변수 경로가 절대경로가 아닐 경우, 클라이언트의 홈 디렉토리에 대한 상대경로로 파싱된다.
TLS CA에 기재된 아이덴티티들을 가지고 각 조직의 네트워크 설정으로 이동할 수 있다. 한 조직에서 노드의 TLS 인증서를 얻을 필요가 있을 때면 언제나 이 CA인증서를 참조할 수 있다.
각 조직은 반드시 등록 인증서 발행을 위해 고유한 인증 기관(CA)를 가져야 한다. CA는 조직의 각 피어와 클라이언트를 위해 인증서를 발행할 것이다.
CA는 조직에 속한 아이덴티티들을 생성하고 각 아이덴티티들에 대한 공개키 및 개인키를 발행한다. 이 키들을 사용하면 당신의 모든 노드들과 어플리케이션들이 자신의 행위에 서명하고 검증할 수 있다. 당신의 CA에 의해 서명된 아이덴티티는 네트워크에 속한 다른 멤버들에게 당신의 조직에 속한 것으로 식별될 것이다.
Org0의 관리자는 패브릭 CA 도커 컨테이너를 런칭할 것이다. 이것은 Org0이 Org0의 아이덴티티를 위해 암호 자료(cryptographic material)를 발행할 때 사용된다.
아래와 같은 도커 서비스는 패브릭 CA 컨테이너 런칭을 위해 사용될 수 있다.
rca-org0:
container_name: rca-org0
image: hyperledger/fabric-ca
command: /bin/bash -c 'fabric-ca-server start -d -b rca-org0-admin:rca-org0-adminpw --port 7053'
environment:
- FABRIC_CA_SERVER_HOME=/tmp/hyperledger/fabric-ca/crypto
- FABRIC_CA_SERVER_TLS_ENABLED=true
- FABRIC_CA_SERVER_CSR_CN=rca-org0
- FABRIC_CA_SERVER_CSR_HOSTS=0.0.0.0
- FABRIC_CA_SERVER_DEBUG=true
volumes:
- /tmp/hyperledger/org0/ca:/tmp/hyperledger/fabric-ca
networks:
- fabric-ca
ports:
- 7053:7053
컨테이너 런칭에 성공할 경우 아래와 같은 CA 컨테이너의 로그를 볼 수 있다.
[INFO] Listening on https://0.0.0.0:7053
이 시점에서 CA서버는 보안 소켓을 수신 대기하고 있고, 암호 자료 발행을 시작할 수 있다.
CA 관리자를 등록하기 위해 아래 명령어를 입력하고, 그 후에 Org0 아이덴티티들을 기재할 것이다.
아래 명령어에서 우리는 CA의 TLS 인증서를 위해 신뢰받는 루트 인증서를 fabric-ca-client 바이너리가 존재하는 호스트 머신의 /tmp/hyperledger/org0/ca/crypto/ca-cert.pem로 복사했다고 가정할 것이다. 클라이언트 바이너리가 다른 호스트에 위치할 경우, out-of-band 프로세스를 퐁해 서명 인증서를 얻어야 한다.
아래 아이덴티티들이 기재될것이다:
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org0/ca/crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org0/ca/admin
fabric-ca-client enroll -d -u https://rca-org0-admin:rca-org0-adminpw@0.0.0.0:7053
fabric-ca-client register -d --id.name orderer1-org0 --id.secret ordererpw --id.type orderer -u https://0.0.0.0:7053
fabric-ca-client register -d --id.name admin-org0 --id.secret org0adminpw --id.type admin --id.attrs "hf.Registrar.Roles=client,hf.Registrar.Attributes=*,hf.Revoker=true,hf.GenCRL=true,admin=true:ecert,abac.init=true:ecert" -u https://0.0.0.0:7053
위에서 실행한 enroll 명령어는 /tmp/hyperledger/org0/ca/admin 디렉토리를 CA로부터 발행된 암호자료로 채울 것이다. 아래와 같은 파일들을 확인할 수 있다:
admin
├── fabric-ca-client-config.yaml
└── msp
├── IssuerPublicKey
├── IssuerRevocationPublicKey
├── cacerts
│ └── 0-0-0-0-7053.pem
├── keystore
│ └── 60b6a16b8b5ba3fc3113c522cce86a724d7eb92d6c3961cfd9afbd27bf11c37f_sk
├── signcerts
│ └── cert.pem
└── user
fabric-ca-client-config.yaml은 CA 인증서로부터 생성된 파일이고, 이 파일은 CA 클라이언트 구성을 포함한다. 여기에는 중요한 세 파일이 더 있다. 처음 하나는 0-0-0-0-7053.pem이다. 이것은 이 아이덴티티를 위해 발행된 CA의 공개 인증서이다. 두 번째는 60b6a16b8b5ba3fc3113c522cce86a724d7eb92d6c3961cfd9afbd27bf11c37f_sk이다. 이것은 클라이언트에 의해 생성된 개인키이다. 이 파일의 이름은 변할 수 있고, 키가 생성될 때 마다 달라진다. 마지막은 cert.pem이다. 이것은 CA에 의해 서명되고 발행된 관리자의 인증서이다.
Org0을 위해 수행했던 설정 단계들을 Org1 CA에 적용할 수 있다.
Org1의 관리자는 Fabric CA 도커 컨테이너를 런칭한다. 이 컨테이너는 Org1이 Org1에 속한 아이덴티티들을 위한 암호 자료를 발행할 때 사용된다.
아래와 같은 도커 서비스는 Fabric CA 컨테이너를 런칭하기 위해 사용할 수 있다.
rca-org1:
container_name: rca-org1
image: hyperledger/fabric-ca
command: /bin/bash -c 'fabric-ca-server start -d -b rca-org1-admin:rca-org1-adminpw'
environment:
- FABRIC_CA_SERVER_HOME=/tmp/hyperledger/fabric-ca/crypto
- FABRIC_CA_SERVER_TLS_ENABLED=true
- FABRIC_CA_SERVER_CSR_CN=rca-org1
- FABRIC_CA_SERVER_CSR_HOSTS=0.0.0.0
- FABRIC_CA_SERVER_DEBUG=true
volumes:
- /tmp/hyperledger/org1/ca:/tmp/hyperledger/fabric-ca
networks:
- fabric-ca
ports:
- 7054:7054
컨테이너가 성공적으로 런칭할 경우 아래 CA 컨테이너 로그를 볼 수 있다.
[INFO] Listening on https://0.0.0.0:7054
이 단계에서 CA는 보안 소켓을 수신 대기하고 있고, 암호 자료 발급을 시작할 수 있다.
CA 관리자를 등록하고 Org1의 아이덴티티들을 기재하기 위해 아래 명령어를 입력할 것이다.
아래 아이덴티티들이 기재될 것이다:
아래 명령어에서, CA의 TLS 인증서를 위해 fabric-ca-client 바이너리가 존재하는 호스트 머신의 /tmp/hyperledger/org1/ca/crypto/ca-cert.pem 로 신뢰로운 루트 인증서가 복사되었음을 가정한다. 클라이언트의 바이너리가 다른 호스트에 위치할 경우, out-of-band 프로세스를 통해 서명 인증서를 얻어야 한다.
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org1/ca/crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org1/ca/admin
fabric-ca-client enroll -d -u https://rca-org1-admin:rca-org1-adminpw@0.0.0.0:7054
fabric-ca-client register -d --id.name peer1-org1 --id.secret peer1PW --id.type peer -u https://0.0.0.0:7054
fabric-ca-client register -d --id.name peer2-org1 --id.secret peer2PW --id.type peer -u https://0.0.0.0:7054
fabric-ca-client register -d --id.name admin-org1 --id.secret org1AdminPW --id.type user -u https://0.0.0.0:7054
fabric-ca-client register -d --id.name user-org1 --id.secret org1UserPW --id.type user -u https://0.0.0.0:7054
Org1을 위해 적용한 것과 같은 설정 단계를 Org2를 위해 적용할 수 있다. 그러므로, 빠르게 Org2의 관리자가 수행할 설정 단계로 넘어가도록 한다.
아래와 같은 도커 서비스는 Org2를 위한 Fabric CA를 런칭하는 데에 사용될 수 있다.
rca-org2:
container_name: rca-org2
image: hyperledger/fabric-ca
command: /bin/bash -c 'fabric-ca-server start -d -b rca-org2-admin:rca-org2-adminpw --port 7055'
environment:
- FABRIC_CA_SERVER_HOME=/tmp/hyperledger/fabric-ca/crypto
- FABRIC_CA_SERVER_TLS_ENABLED=true
- FABRIC_CA_SERVER_CSR_CN=rca-org2
- FABRIC_CA_SERVER_CSR_HOSTS=0.0.0.0
- FABRIC_CA_SERVER_DEBUG=true
volumes:
- /tmp/hyperledger/org2/ca:/tmp/hyperledger/fabric-ca
networks:
- fabric-ca
ports:
- 7055:7055
컨테이너가 성공적으로 런칭되면 아래와 같은 CA 컨테이너의 로그를 볼 수 있다.
[INFO] Listening on https://0.0.0.0:7055
이 단계에서 CA 서버는 보안 통신을 수신 대기하고 있고, 암호 자료 발행을 시작할 수 있다.
CA 관리자를 등록하고 피어와 관련된 모든 아이덴티티를 기재하기 위해 아래 명령어를 입력할 것이다. 아래 명령어에서, CA의 TLS 인정서의 신뢰받는 루트 인증서가 tmp/hyperledger/org2/ca/crypto/ca-cert.pem로 복사되었음을 가정한다.
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org2/ca/crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org2/ca/admin
fabric-ca-client enroll -d -u https://rca-org2-admin:rca-org2-adminpw@0.0.0.0:7055
fabric-ca-client register -d --id.name peer1-org2 --id.secret peer1PW --id.type peer -u https://0.0.0.0:7055
fabric-ca-client register -d --id.name peer2-org2 --id.secret peer2PW --id.type peer -u https://0.0.0.0:7055
fabric-ca-client register -d --id.name admin-org2 --id.secret org2AdminPW --id.type user -u https://0.0.0.0:7055
fabric-ca-client register -d --id.name user-org2 --id.secret org2UserPW --id.type user -u https://0.0.0.0:7055
CA가 구동되면 피어 등록을 시작할 수 있다.
Org1의 관리자는 피어를 자신의 CA를 사용해 등록할 것이고, 피어 도커 컨테이너를 런칭할 것이다. 피어를 시작하기 전에, 피어가 사용할 MSP를 얻기 위해 CA로 피어 아이덴티티를 등록해야 한다. 이것은 로컬 피어 MSP로 알려져 있다.
피어 1이 구동되는 호스트 머신이 fabric-ca-client 바이너리를 가지고 있지 않을 경우, 바이너리 다운로드를 위해 위 지침을 참조해라.
아래 명령어에서는 Org1의 신뢰로운 루트 인증서가 peer1의 호스트 머신의 /tmp/hyperledger/org1/peer1/assets/ca/org1-ca-cert.pem로 복사되었다고 가정한다. 서명 인증서 획득은 out-of-band 프로세스이다.
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org1/peer1
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org1/peer1/assets/ca/org1-ca-cert.pem
export FABRIC_CA_CLIENT_MSPDIR=msp
fabric-ca-client enroll -d -u https://peer1-org1:peer1PW@0.0.0.0:7054
다음 단계는 피어를 위한 TLS 암호 자료를 가져오는 것이다. 여기에는 또 다른 등록이 필요하지만, 이번에는 TLS CA의 tls 프로필에 대해 등록한다. 또한 등록 요청 시 피어 1의 호스트 머신 주소를 csr.hosts 플래그의 입력값으로써 제공해야 한다. 아래 명령어에서는 TLS CA의 인증서가 피어1 호스트 머신의 /tmp/hyperledger/org1/peer1/assets/tls-ca/tls-ca-cert.pem로 복사되었다고 가정한다.
export FABRIC_CA_CLIENT_MSPDIR=tls-msp
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org1/peer1/assets/tls-ca/tls-ca-cert.pem
fabric-ca-client enroll -d -u https://peer1-org1:peer1PW@0.0.0.0:7052 --enrollment.profile tls --csr.hosts peer1-org1
/tmp/hyperledger/org1/peer1/tls-msp/keystore 경로로 이동하고, 키 이름을 key.pem으로 변경한다. 다음 단계에서 참조하기 더 쉬워진다.
이 시점에서 두 MSP 디렉토리를 가지게 된다. 한 MSP는 피어의 등록 인증서를 포함하고 있고, 다른 것은 피어의 TLS 인증서를 가지고 있다. 하지만 등록 MSP 디렉토리에 admincerts 폴더를 추가해야 한다. 이 폴더는 Org1 관리자 인증서를 가지게 된다. Org1 관리자를 등록할 때 이에 대해 조금 더 자세히 이야기할 것이다.
피어 2를 위해 유사한 명령어를 수행할 것이다. 아래 명령어에서, Org1의 신뢰로운 ㄹ프 인증서가 피어 2 호스트 머신의 /tmp/hyperledger/org1/peer2/assets/ca/org1-ca-cert.pem로 복사되었다고 가정할 것이다.
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org1/peer2
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org1/peer2/assets/ca/org1-ca-cert.pem
export FABRIC_CA_CLIENT_MSPDIR=msp
fabric-ca-client enroll -d -u https://peer2-org1:peer2PW@0.0.0.0:7054
다음 단계는 피어를 위한 TLS 암호화 자료를 얻기 위한 것이다. 이는 추가 등록을 필요로 하지만, 여기서는 TLS CA의 tls 프로필에 대해 등록하기로 한다. 피어 2 호스트 머신 주소를 등록 요청에서 csr.hosts 플래그 입력값으로 제공해야 한다. 아래 명령어는 피어 2 호스트 머신의 /tmp/hyperledger/org1/peer2/assets/tls-ca/tls-ca-cert.pem로 TLS CA 인증서를 복사했다고 가정한다.
export FABRIC_CA_CLIENT_MSPDIR=tls-msp
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org1/peer2/assets/tls-ca/tls-ca-cert.pem
fabric-ca-client enroll -d -u https://peer2-org1:peer2PW@0.0.0.0:7052 --enrollment.profile tls --csr.hosts peer2-org1
/tmp/hyperledger/org1/peer2/tls-msp/keystore 경로로 이동해서 키 이름을 key.pem로 변경한다. 이는 나중 단계에서 참조하기 쉽도록 만들어준다.
이 시점에서 두 MSP 디렉토리를 갖게 된다. 하나는 피어의 등록 인증서를 가지고 있고, 다른 하나는 피어의 TLS 인증서를 갖게 된다. 관리자가 등록되면 등록 MSP를 위해 admincerts 폴더를 추가해야 한다.
이 시점에서 피어들이 등록되었다. 이제 Org1의 관리자 아이덴티티를 등록할 것이다. 관리자 아이덴티티는 체인코드 설치 및 인스턴스화와 같은 역할을 가진다. 아래 단계는 관리자를 등록할 것이다. 아래 명령어는 피어 1의 호스트 머신에서 실행되었다고 가정한다.
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org1/admin
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org1/peer1/assets/ca/org1-ca-cert.pem
export FABRIC_CA_CLIENT_MSPDIR=msp
fabric-ca-client enroll -d -u https://admin-org1:org1AdminPW@0.0.0.0:7054
등록 이후에는 관리자 MSP를 가지고 있어야 한다. 이 MSP에서 인증서를 복사하고 피어 1 MSP admincerts 폴더로 옮겨야 한다. 조직의 다른 피어들로 이 관리자 인증서를 퍼트려야 한다. 그리고 이 인증서들은 각 피어 MSP의 admincerts 폴더로 가야 한다.
아래의 명령어는 피어1만을 위한 것이다. 피어2로의 관리자 인증서 교환은 out-of-band로 이루어진다.
mkdir /tmp/hyperledger/org1/peer1/msp/admincerts
cp /tmp/hyperledger/org1/admin/msp/signcerts/cert.pem /tmp/hyperledger/org1/peer1/msp/admincerts/org1-admin-cert.pem
피어 로컬 MSP의 admincerts 폴더가 없을 경우 피어는 시작되지 않는다.
모든 피어와 조직 관리자가 등록되면, 피어를 시작하기 위한 필수 MSP는 모두 가지게 된다.
아래와 같은 도커 서비스는 피어 1 컨테이너 런칭에 사용될 수 있다.
peer1-org1:
container_name: peer1-org1
image: hyperledger/fabric-peer
environment:
- CORE_PEER_ID=peer1-org1
- CORE_PEER_ADDRESS=peer1-org1:7051
- CORE_PEER_LOCALMSPID=org1MSP
- CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org1/peer1/msp
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=guide_fabric-ca
- FABRIC_LOGGING_SPEC=debug
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_TLS_CERT_FILE=/tmp/hyperledger/org1/peer1/tls-msp/signcerts/cert.pem
- CORE_PEER_TLS_KEY_FILE=/tmp/hyperledger/org1/peer1/tls-msp/keystore/key.pem
- CORE_PEER_TLS_ROOTCERT_FILE=/tmp/hyperledger/org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1-org1:7051
- CORE_PEER_GOSSIP_SKIPHANDSHAKE=true
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/org1/peer1
volumes:
- /var/run:/host/var/run
- /tmp/hyperledger/org1/peer1:/tmp/hyperledger/org1/peer1
networks:
- fabric-ca
피어 서비스가 런칭되면 피어 컨테이너가 나타나고, 로그에서 아래를 볼 수 있다.
serve -> INFO 020 Started peer with ID=[name:"peer1-org1" ], network ID=[dev], address=[peer1-org1:7051]
아래와 같은 도커 서비스는 피어 2 컨테이너 런칭에 사용될 수 있다.
peer2-org1:
container_name: peer2-org1
image: hyperledger/fabric-peer
environment:
- CORE_PEER_ID=peer2-org1
- CORE_PEER_ADDRESS=peer2-org1:7051
- CORE_PEER_LOCALMSPID=org1MSP
- CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org1/peer2/msp
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=guide_fabric-ca
- FABRIC_LOGGING_SPEC=grpc=debug:info
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_TLS_CERT_FILE=/tmp/hyperledger/org1/peer2/tls-msp/signcerts/cert.pem
- CORE_PEER_TLS_KEY_FILE=/tmp/hyperledger/org1/peer2/tls-msp/keystore/key.pem
- CORE_PEER_TLS_ROOTCERT_FILE=/tmp/hyperledger/org1/peer2/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer2-org1:7051
- CORE_PEER_GOSSIP_SKIPHANDSHAKE=true
- CORE_PEER_GOSSIP_BOOTSTRAP=peer1-org1:7051
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/org1/peer2
volumes:
- /var/run:/host/var/run
- /tmp/hyperledger/org1/peer2:/tmp/hyperledger/org1/peer2
networks:
- fabric-ca
피어 서비스 런칭은 피어 컨테이너를 나타나게 하고, 로그에서 다음을 확인할 수 있다.
serve -> INFO 020 Started peer with ID=[name:"peer2-org1" ], network ID=[dev], address=[peer2-org1:7051]
Org2 관리자는 CA로 피어를 등록하기 위해 CA의 부트스트랩 아이덴티티를 사용하고 피어 도커 컨테이너를 런칭할 것이다.
피어 1 등록을 위해 아래 커맨드를 실행할 것이다. 아래 커맨드에서는 피어 1 호스트 머신 /tmp/hyperledger/org2/peer1/assets/ca/org2-ca-cert.pem에서 Org2의 신뢰로운 루트 인증서에 접근가능하다고 가정한다.
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org2/peer1
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org2/peer1/assets/ca/org2-ca-cert.pem
export FABRIC_CA_CLIENT_MSPDIR=msp
fabric-ca-client enroll -d -u https://peer1-org2:peer1PW@0.0.0.0:7055
다음으로, TLS 인증서를 획득할 것이다. 아래 명령어에서는 피어 1의 /tmp/hyperledger/org2/peer1/assets/tls-ca/tls-ca-cert.pem에 TLS CA 인증서가 복사되었다고 가정한다.
/tmp/hyperledger/org2/peer1/tls-msp/keystore 경로로 이동해서 키 이름을 key.pem로 변경해라.
피어 2를 등록하기 위해 아래 명령어를 입럭한다. 아래 명령어에서는 피어 1 호스트 머신의 /tmp/hyperledger/org2/peer2/tls/org2-ca-cert.pem에서 Org2의 신뢰로운 루트 인증서에 접근가능하다고 가정한다.
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org2/peer2
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org2/peer2/assets/ca/org2-ca-cert.pem
export FABRIC_CA_CLIENT_MSPDIR=msp
fabric-ca-client enroll -d -u https://peer2-org2:peer2PW@0.0.0.0:7055
다음으로 TLS 인증서를 획득할 것이다. 아래 명령어에서, TLS CA 인증서는 피어 2 호스트 머신의 /tmp/hyperledger/org2/peer2/assets/tls-ca/tls-ca-cert.pem로 이미 복사되었다고 가정한다.
export FABRIC_CA_CLIENT_MSPDIR=tls-msp
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org2/peer2/assets/tls-ca/tls-ca-cert.pem
fabric-ca-client enroll -d -u https://peer2-org2:peer2PW@0.0.0.0:7052 --enrollment.profile tls --csr.hosts peer2-org2
/tmp/hyperledger/org2/peer2/tls-msp/keystore 경로로 이동해서 키 이름을 key.pem으로 변경해라.
이 시점에서는 두 MSP 디렉토리를 가지게 된다. 한 MSP는 등록 인증서를 포함하고 있고 다른 하나는 TLS 인증서를 가지고 있다. 하지만 admincerts 폴더라는 추가 폴더 하나를 등록 MSP 디렉토리에 추가해야 한다. 이 폴더는 Org2의 관리자 인증서를 가지게 될 것이다. 아래 단계는 관리자를 등록할 것이다. 아래 명령어는 피어 1 호스트 머신에서 실행된다고 가정한다.
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org2/admin
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org2/peer1/assets/ca/org2-ca-cert.pem
export FABRIC_CA_CLIENT_MSPDIR=msp
fabric-ca-client enroll -d -u https://admin-org2:org2AdminPW@0.0.0.0:7055
등록 이후 관리자 MSP를 갖게된다. 이 MSP로부터 인증서를 복사해서 admincerts 폴더 아래로 이동시킬 것이다. 아래 명령어는 피어 1만을 위한 것이고, 관리자 인증서를 피어 2로 교환하는 것은 out-of-band로 일어난다.
mkdir /tmp/hyperledger/org2/peer1/msp/admincerts
cp /tmp/hyperledger/org2/admin/msp/signcerts/cert.pem /tmp/hyperledger/org2/peer1/msp/admincerts/org2-admin-cert.pem
admincerts 폴더가 없을 경우 피어는 시작되지 못한다.
모든 피어들과 관리자들을 등록한 후에는 피어를 시작하기 위해 필수적인 MSP들을 가지게 된다.
아래와 같은 도커 서비스는 피어 1을 위한 컨테이너 런칭에 사용된다.
peer1-org2:
container_name: peer1-org2
image: hyperledger/fabric-peer
environment:
- CORE_PEER_ID=peer1-org2
- CORE_PEER_ADDRESS=peer1-org2:7051
- CORE_PEER_LOCALMSPID=org2MSP
- CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org2/peer1/msp
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=guide_fabric-ca
- FABRIC_LOGGING_SPEC=debug
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_TLS_CERT_FILE=/tmp/hyperledger/org2/peer1/tls-msp/signcerts/cert.pem
- CORE_PEER_TLS_KEY_FILE=/tmp/hyperledger/org2/peer1/tls-msp/keystore/key.pem
- CORE_PEER_TLS_ROOTCERT_FILE=/tmp/hyperledger/org2/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1-org2:7051
- CORE_PEER_GOSSIP_SKIPHANDSHAKE=true
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/org2/peer1
volumes:
- /var/run:/host/var/run
- /tmp/hyperledger/org2/peer1:/tmp/hyperledger/org2/peer1
networks:
- fabric-ca
피어 서비스 런칭은 피어 컨테이너를 나타나게 하고, 로그에서는 아래를 확인할 수 있다.
serve -> INFO 020 Started peer with ID=[name:"peer1-org2" ], network ID=[dev], address=[peer1-org2:7051]
아래와 같은 도커 서비스는 피어 2를 위한 컨테이너 런칭에 사용된다.
peer2-org2:
container_name: peer2-org2
image: hyperledger/fabric-peer
environment:
- CORE_PEER_ID=peer2-org2
- CORE_PEER_ADDRESS=peer2-org2:7051
- CORE_PEER_LOCALMSPID=org2MSP
- CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org2/peer2/msp
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=guide_fabric-ca
- FABRIC_LOGGING_SPEC=debug
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_TLS_CERT_FILE=/tmp/hyperledger/org2/peer2/tls-msp/signcerts/cert.pem
- CORE_PEER_TLS_KEY_FILE=/tmp/hyperledger/org2/peer2/tls-msp/keystore/key.pem
- CORE_PEER_TLS_ROOTCERT_FILE=/tmp/hyperledger/org2/peer2/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer2-org2:7051
- CORE_PEER_GOSSIP_SKIPHANDSHAKE=true
- CORE_PEER_GOSSIP_BOOTSTRAP=peer1-org2:7051
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/org2/peer2
volumes:
- /var/run:/host/var/run
- /tmp/hyperledger/org2/peer2:/tmp/hyperledger/org2/peer2
networks:
- fabric-ca
피어 서비스 런칭은 피어 컨테이너를 나타나게 하고, 로그에서는 다음을 볼 수 있다:
serve -> INFO 020 Started peer with ID=[name:"peer2-org2" ], network ID=[dev], address=[peer2-org2:7052]
설정해야 할 마지막 대상은 오더러이다. 오더러를 시작하기 전에 해야 할 몇 가지 작업이 있다.
오더러를 시작하기 전에, 오더러가 사용할 MSP를 얻기 위해 CA로 오더러 아이덴티티를 등록해야 한다. 이것은 로컬 오더러 MSP로도 알려져있다.
호스트 머신이 fabric-ca-client 바이너리를 가지고 있지 않을 경우, 위 지침을 참조해 바이너리를 다운로드받아야 한다.
오더러를 등록하기 위해 아래 명령어를 실행할 것이다.아래 명령어에서 Org0의 신뢰로운 루트 인증서는 오더러 호스트 머신의 /tmp/hyperledger/org0/orderer/assets/ca/org0-ca-cert.pem 에서 접근가능한 것으로 가정한다.
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org0/orderer
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org0/orderer/assets/ca/org0-ca-cert.pem
fabric-ca-client enroll -d -u https://orderer1-org0:ordererpw@0.0.0.0:7053
다음으로 TLS 인증서를 얻을 것이다. 아래 명령어에서 TLS CA 인증서는 오더러 호스트 머신의 /tmp/hyperledger/org0/orderer/assets/tls-ca/tls-ca-cert.pem로 복사되었다고 가정한다.
export FABRIC_CA_CLIENT_MSPDIR=tls-msp
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org0/orderer/assets/tls-ca/tls-ca-cert.pem
fabric-ca-client enroll -d -u https://orderer1-org0:ordererPW@0.0.0.0:7052 --enrollment.profile tls --csr.hosts orderer1-org0
/tmp/hyperledger/org0/orderer/tls-msp/keystore 경로로 가서 키 이름을 key.pem로 바꾼다.
이 시점에서 두 MSP 디렉토리를 갖게 된다. 하나는 등록 인증서를 가지고 있고, 다른 하나는 TLS 인증서를 가지고 있다. 여기에 admincerts 폴더를 추가해야 한다. 이 폴더는 피어 1 관리자의 인증서를 가질 것이다. 이제 아래 명령어를 실행함으로써 Org0의 관리자 아이덴티티를 등록한다.
아래 명령어는 오더러의 호스트 머신에서 실행된다고 가정한다.
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org0/admin
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org0/orderer/assets/ca/org0-ca-cert.pem
export FABRIC_CA_CLIENT_MSPDIR=msp
fabric-ca-client enroll -d -u https://admin-org0:org0adminpw@0.0.0.0:7053
등록 이후 /tmp/hyperledger/org0/admin에 msp 폴더를 갖게 된다. 이 msp의 인증서를 복사해서 오더러 msp의 admincerts 폴더로 이동시켜라.
mkdir /tmp/hyperledger/org0/orderer/msp/admincerts
cp /tmp/hyperledger/org0/admin/msp/signcerts/cert.pem /tmp/hyperledger/org0/orderer/msp/admincerts/orderer-admin-cert.pem
오더러는 자기 자신을 부트스트랩하기 위해 제네시스 블록을 필요로 한다. 더 많은 정보는 하이퍼레저 패브릭 문서에서 얻을 수 있다.
아래 문서에서 특별한 배포를 위해 쓰여진 configtx.yaml 파일의 스니펫을 볼 수 있다. 전체 configtx.yaml는 여기를 클릭해라.
오더러의 호스트 머신에서 모든 조직의 MSP를 모아야 한다. configtx.yaml의 organization 섹션은 아래와 같이 생겼다:
Organizations:
- &org0
Name: org0
ID: org0MSP
MSPDir: /tmp/hyperledger/org0/msp
- &org1
Name: org1
ID: org1MSP
MSPDir: /tmp/hyperledger/org1/msp
AnchorPeers:
- Host: peer1-org1
Port: 7051
- &org2
Name: org2
ID: org2MSP
MSPDir: /tmp/hyperledger/org2/msp
AnchorPeers:
- Host: peer1-org2
Port: 7051
Org0의 MSP는 Org0의 신뢰로운 루트 인증서와 Org0의 관리자 아이덴티티, 그리고 TLS CA의 신뢰로운 루트 인증서를 가지고 있다. 이 MSP 폴더 구조는 아래와 같다.
/tmp/hyperledger/org0/msp
├── admincerts
│ └── admin-org0-cert.pem
├── cacerts
│ └── org0-ca-cert.pem
├── tlscacerts
│ └── tls-ca-cert.pem
└── users
모든 조직의 패턴이 같다. Org1의 MSP 폴더 구조는 다음과 같다:
/tmp/hyperledger/org1/msp
├── admincerts
│ └── admin-org1-cert.pem
├── cacerts
│ └── org1-ca-cert.pem
├── tlscacerts
│ └── tls-ca-cert.pem
└── users
Org2의 MSP 폴더 구조는 다음과 같다:
/tmp/hyperledger/org2/msp
├── admincerts
│ └── admin-org2-cert.pem
├── cacerts
│ └── org2-ca-cert.pem
├── tlscacerts
│ └── tls-ca-cert.pem
└── users
모든 MSP가 오더러 호스트 머신에 존재하면 configtx.yaml이 위치한 디렉토리에서 아래 명령어를 실행할 수 있다:
configtxgen -profile OrgsOrdererGenesis -outputBlock /tmp/hyperledger/org0/orderer/genesis.block -channelID syschannel
configtxgen -profile OrgsChannel -outputCreateChannelTx /tmp/hyperledger/org0/orderer/channel.tx -channelID mychannel
이것은 두 아티팩트, genesis.block 과 channel.tx를 생성하고 이것들은 나중 단계에서 사용된다.
fabric CA client는 오더러 제네시스와 피어 MSP 설정을 위해 필요한 인증서를 얻는 유용한 명령어를 다수 가지고 있다.
첫 명령어는 abric-ca-client certificate 명령어이다. 이 명령어는 admincerts 폴더로부터 인증서를 가져오기 위해 쓰인다. 더 많은 정보는 인증서 정보 목록화를 확인하자.
다음 명령어는 fabric-ca-client getcainfo 명령어이다. 이 명령어는 cacert와 tlscacerts 폴더로부터 인증서를 얻는 데에 사용할 수 있다. 이 명령어는 CA의 인증서를 반환한다.
엔드포인트는 상호 TLS를 사용해 보안될 수 있다. CA, 피어, 또는 오더러가 상호 TLS를 사용하는 경우 클라이언트는 반드시 서버에 의해 검증되는 TLS 인증서를 가지고 있어야 한다.
상호 TLS는 클라이언트가 서버에 제시하는 TLS 인증서를 얻도록 요구한다. TLS 인증서 습득은 상호 TLS가 가능한 TLS 인증 기관을 통해 가능하다. 클라이언트가 TLS 인증서를 획득하면 서버의 신뢰로운 TLS 기관이 클라이언트 TLS 인증서의 발급 기관과
동일한 한 상호 TLS 활성화 서버와 통신할 수 있다.
제네시스 블록과 채널 트랜잭션을 생성하면 위에서 생성된 genesis.block를 가리키는 오더러 서비스를 정의할 수 있다.
orderer1-org0:
container_name: orderer1-org0
image: hyperledger/fabric-orderer
environment:
- ORDERER_HOME=/tmp/hyperledger/orderer
- ORDERER_HOST=orderer1-org0
- ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
- ORDERER_GENERAL_GENESISMETHOD=file
- ORDERER_GENERAL_GENESISFILE=/tmp/hyperledger/org0/orderer/genesis.block
- ORDERER_GENERAL_LOCALMSPID=org0MSP
- ORDERER_GENERAL_LOCALMSPDIR=/tmp/hyperledger/org0/orderer/msp
- ORDERER_GENERAL_TLS_ENABLED=true
- ORDERER_GENERAL_TLS_CERTIFICATE=/tmp/hyperledger/org0/orderer/tls-msp/signcerts/cert.pem
- ORDERER_GENERAL_TLS_PRIVATEKEY=/tmp/hyperledger/org0/orderer/tls-msp/keystore/key.pem
- ORDERER_GENERAL_TLS_ROOTCAS=[/tmp/hyperledger/org0/orderer/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem]
- ORDERER_GENERAL_LOGLEVEL=debug
- ORDERER_DEBUG_BROADCASTTRACEDIR=data/logs
volumes:
- /tmp/hyperledger/org0/orderer:/tmp/hyperledger/org0/orderer/
networks:
- fabric-ca
오더러 서비스 런칭은 오더러 컨테이너를 나타나게 하고, 로그에서 아래를 볼 수 있다.
UTC [orderer/common/server] Start -> INFO 0b8 Beginning to serve requests
피어와의 통신은 CLI 컨테이너를 필요로 한다. 이 컨테이너는 피어와 관련된 커맨드를 실행할 수 있도록 해 주는 적절한 바이너리들을 가지고 있다. 각 조직을 위한 CLI 컨테이너를 만들 수 있다. 예를 들어, 각 조직을 위한 CLI 컨테이너를 피어 1과 동일한 호스트 머신에 런칭할 수 있다.
cli-org1:
container_name: cli-org1
image: hyperledger/fabric-tools
tty: true
stdin_open: true
environment:
- GOPATH=/opt/gopath
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- FABRIC_LOGGING_SPEC=DEBUG
- CORE_PEER_ID=cli-org1
- CORE_PEER_ADDRESS=peer1-org1:7051
- CORE_PEER_LOCALMSPID=org1MSP
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_TLS_ROOTCERT_FILE=/tmp/hyperledger/org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
- CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org1/peer1/msp
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/org1
command: sh
volumes:
- /tmp/hyperledger/org1/peer1:/tmp/hyperledger/org1/peer1
- /tmp/hyperledger/org1/peer1/assets/chaincode:/opt/gopath/src/github.com/hyperledger/fabric-samples/chaincode
- /tmp/hyperledger/org1/admin:/tmp/hyperledger/org1/admin
networks:
- fabric-ca
cli-org2:
container_name: cli-org2
image: hyperledger/fabric-tools
tty: true
stdin_open: true
environment:
- GOPATH=/opt/gopath
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- FABRIC_LOGGING_SPEC=DEBUG
- CORE_PEER_ID=cli-org2
- CORE_PEER_ADDRESS=peer1-org2:7051
- CORE_PEER_LOCALMSPID=org2MSP
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_TLS_ROOTCERT_FILE=/tmp/hyperledger/org2/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
- CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org2/peer1/msp
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/org2
command: sh
volumes:
- /tmp/hyperledger/org2/peer1:/tmp/hyperledger/org2/peer1
- /tmp/hyperledger/org1/peer1/assets/chaincode:/opt/gopath/src/github.com/hyperledger/fabric-samples/chaincode
- /tmp/hyperledger/org2/admin:/tmp/hyperledger/org2/admin
networks:
- fabric-ca
CLI 컨테이너가 구동되면 채널 생성 및 가입을 위한 명령어를 실행할 수 있다. 채널 생성을 위해 피어 1을 사용할 것이다. 피어 1의 호스트 머신에서 아래를 실행한다.
docker exec -it cli-org1 sh
이 명령어는 CLI 컨테이너 안으로 당신을 옮겨주고 터미널을 열어줄 것이다. 여기서 관리자 msp를 사용해 아래 커맨드를 실행한다:
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org1/admin/msp
peer channel create -c mychannel -f /tmp/hyperledger/org1/peer1/assets/channel.tx -o orderer1-org0:7050 --outputBlock /tmp/hyperledger/org1/peer1/assets/mychannel.block --tls --cafile /tmp/hyperledger/org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
이 channel.tx는 오더러의 configtxgen 명령어를 실행함으로써 생성된 아티팩트이다. 이 아티팩트는 오더러로부터 피어 1로 out-of-band로 전송되어야 한다. 위 커맨드는 피어 1의 특별한 출력 경로 tmp/hyperledger/org1/peer1/assets/mychannel.block에 mychannel.block 를 생성할 것이다. 이것은 채널에 가입하길 원하는 네트워크의 모든 피어에게 사용된다. 이 mychannel.block 은 Org1과 Org2의 모든 피어들에게 out-of-band로 전송되어야 한다.
다음 명령어로 피어 1과 피어 2를 채널에 가입시킨다.
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org1/admin/msp
export CORE_PEER_ADDRESS=peer1-org1:7051
peer channel join -b /tmp/hyperledger/org1/peer1/assets/mychannel.block
export CORE_PEER_ADDRESS=peer2-org1:7051
peer channel join -b /tmp/hyperledger/org1/peer1/assets/mychannel.block
CLI 도커 컨테이너에 진입하기 위해 다음 명령어를 실행한다:
docker exec -it cli-org2 sh
Org2에서는 피어를 채널에 가입시키기만 하면 된다. Org2의 피어들은 채널을 생성할 필요가 없다. 그것은 Org1에서 이미 마쳤다. Org2 CLI 컨테이너에서 관리자 msp를 이용해 아래 명령어를 실행한다:
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org2/admin/msp
export CORE_PEER_ADDRESS=peer1-org2:7051
peer channel join -b /tmp/hyperledger/org2/peer1/assets/mychannel.block
export CORE_PEER_ADDRESS=peer2-org2:7051
peer channel join -b /tmp/hyperledger/org2/peer1/assets/mychannel.block
깃헙에서 각 조직의 피어 1 로컬 파일 시스템에 체인코드를 다운받아라.
피어 1에서 체인코드를 설치한다. 아래 명령어는 체인코드가 GOPATH내에서 사용가능하다고 가정한다. 이 예시에서 체인코드는 /opt/gopath/src/github.com/hyperledger/fabric-samples/chaincode/abac/go에 위치해 있고 GOPATH는 /opt/gopath라고 가정한다. Org1의 CLI 컨테이너로부터 아래 명령어를 실행한다:
export CORE_PEER_ADDRESS=peer1-org1:7051
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org1/admin/msp
peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric-samples/chaincode/abac/go
아래 명령어를 피어 2에서 실행한다:
export CORE_PEER_ADDRESS=peer2-org1:7051
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org1/admin/msp
peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric-samples/chaincode/abac/go
피어 1에서 Org1에서 한 것과 동일한 절차를 밟는다. 이 명령어는 체인코드가 /opt/gopath/src/github.com/hyperledger/org2/peer1/assets/chaincode/abac/go에 설치되었고 이용가능하다고 가정한다. Org2의 CLI 컨테이너에서 아래 명령어를 실행한다:
export CORE_PEER_ADDRESS=peer1-org2:7051
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org2/admin/msp
peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric-samples/chaincode/abac/go
동일한 절차를 피어 2에서 실시한다:
export CORE_PEER_ADDRESS=peer2-org2:7051
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org2/admin/msp
peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric-samples/chaincode/abac/go
다음 단계는 체인코드를 인스턴스화하는 것이다. 이는 다음 명령어 실행을 통해 가능하다:
peer chaincode instantiate -C mychannel -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -o orderer1-org0:7050 --tls --cafile /tmp/hyperledger/org2/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
Org1의 CLI 컨테이너에서 아래를 실행한다:
export CORE_PEER_ADDRESS=peer1-org1:7051
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org1/admin/msp
peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'
이것은 100 값을 리턴해야 한다.
Org2의 CLI 컨테이너에서 아래를 실행한다:
export CORE_PEER_ADDRESS=peer1-org2:7051
export CORE_PEER_MSPCONFIGPATH=/tmp/hyperledger/org2/admin/msp
peer chaincode invoke -C mychannel -n mycc -c '{"Args":["invoke","a","b","10"]}' --tls --cafile /tmp/hyperledger/org2/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
이것은 a 값에서 10을 빼서 b로 옮긴다, 이제 다음 쿼리를 실행한다:
peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'
이것은 90을 리턴해야 한다.
이것으로 Fabric CA 운영 가이드를 마친다.