HYPERLEDGER FABRIC - Developing Applications - Application design elements - Connection Profile
독자 : Architects, application and smart contract developers
connection profile은 Hyperledger Fabric 블록체인 네트워크의 peer, orderer와 인증 기관을 포함한 구성 요소 집합을 설명합니다.
이런 구성 요소와 관련된 채널과 조직 정보도 포함되어 있습니다.
connection profile은 주로 모든 네트워크 상호작용을 처리하는 gateway(Developing Applications » Application design elements » Gateway)를 구성하여 비즈니스 로직에 집중할 수 있도록 applicaion에서 사용됩니다.
connection profile은 일반적으로 네트워크 토폴로지를 이해하는 관리자가 만듭니다.
이번 주제에서 다음을 다룰 것입니다.
- Why connection profiles are important
- How applications use a connection profile
- How to define a connection profile
Scenario (Why connection profiles are important)
connection profile은 게이트웨이를 구성하는데 사용됩니다.
게이트웨이는 많은 이유에서 중요한데, 일차적으로는 네트워크 채널과 application의 상호작용을 단순히 하는 것입니다.
issue, buy 두 어플리케이션은 connection profile로 구성된 1&2 게이트웨이를 사용합니다. 각 profile은 MagnetoCorp와 DigiBank 네트워크 구성요소의 다른 부분집합을 설명합니다. 각 connection profile은 issue와 buy application를 대신하여 네트워크와 상호작용하는 게이트웨이의 충분한 정보를 포함해야합니다. 자세한 설명은 텍스트를 참조하세요.
connection profile은 JSON이나 YAML 기술 문법으로 표현된 네트워크 뷰의 설명을 포함합니다.
이번 주제에서 우리는 읽기 쉽게 YAML 표현을 사용합니다.
connection profile에서 정보를 동적으로 증가시키기 위해 서비스 검색(Architecture Reference » Service Discovery)을 사용하기 때문에 정적 게이트웨이는 다이나믹 게이트웨이보다 더 많은 정보를 필요로 합니다.
connection profile은 네트워크 채널에 대한 완전한 설명이 아니어야합니다.
단지 사용하는 gateway의 충분한 정보만 포함하면 됩니다.
위의 네트워크 connection profile1은 트랜잭션이 원장에 커밋될 때 게이트웨이에 알릴 peer를 식별할뿐만 아니라 issue 트랜잭션을 보증하는 조직과 peer가 적어도 포함해야합니다.
네트워크의 보기를 설명하는 것으로 connection profile은 쉽게 생각할 수 있습니다.
포괄적인 관점이 될 수 있지만, 몇 가지 이유로 비현실적입니다.
- peer, orderer, 인증 기관, 채널, 조직은 수요에 따라 추가되고 삭제됩니다.
- 구성요소는 시작하거나 중지될 수 있고, 예기치않게 실패할 수 있습니다. (예, 정전)
- 게이트웨이는 전체 네트워크를 보는게 필요하지 않으며, 오직 트랜잭션 제출 또는 이벤트 알림을 성공적으로 처리하는 데 필요합니다.
- 서비스 검색은 connection profile의 정보를 보완할 수 있습니다. 특히, 동적 게이트웨이는 최소한의 Fabric 토폴로지 정보로 구성될 수 있습니다. 나머지는 발견될 수 있습니다.
정적 connection profile은 일반적으로 네트워크 토폴로지에 대해 잘 이해하고 있는 관리자가 만듭니다.
정적 profile은 꽤 많은 양의 정보를 포함하고 있으므로, 관리자는 해당 connection profile에서 이를 찾아야합니다.
반대로 동적 profile은 필요한 정의의 양을 최소화하므로 빠르게 찾기 원하는 개발자나 더 응답이 빠른 게이트웨이를 만드려는 관리자에게 더 나은 선택이 될 수 있습니다.
connection profile은 선택한 편집기를 사용하여 YAML 또는 JSON 포맷으로 만들어집니다.
Usage (How applications use a connection profile)
connection profile을 정의하는 방법에 대해서 살펴보겠습니다.
예제 MagnetoCorp issue application에서 어떻게 사용되는지 살펴보겠습니다.
const yaml = require('js-yaml');
const { Gateway } = require('fabric-network');
const connectionProfile = yaml.safeLoad(fs.readFileSync('../gateway/paperNet.yaml', 'utf8'));
const gateway = new Gateway();
await gateway.connect(connectionProfile, connectionOptions);
몇개의 필수 클래스를 로드한 후, paperNet.yaml 게이트웨이 파일이 파일 시스템으로부터 로드되고, yaml.safeLoad() 메소드를 사용하여 JSON 객체로 변환되고, connect() 메소드로 게이트웨이를 구성하는데 사용되는 방법을 살펴보세요.
connection profile로 게이트웨이를 구성함으로써, issue application은 트랜잭션을 처리하는데 사용해야하는 관련 있는 네트워크 토폴로지를 게이트웨이에 제공합니다.
connection profile은 거래가 성공적으로 처리될 수 있도록 PaperNet 채널, 조직, peer, orderer 그리고 CA에 대한 충분한 정보를 포함하고 있어 트랜잭션을 성공적으로 처리할 수 있기 때문입니다.
주어진 조직에 대해 둘 이상의 peer를 정의하는 것은 단일 실패 지점을 방지하여 connection profile에 대한 좋은 방법입니다.
이 방법은 동적 게이트웨이에 서비스 검색의 시작 지점을 둘 이상으로 제공하며 적용할 수 있습니다.
DigiBank buy application은 일반적으로 비슷한 connection profile로 게이트웨이를 구성하지만, 몇가지 중요한 차이점이 있습니다.
일부 요소는 채널처럼 같습니다. 일부 요소는 보증하는 peer처럼 겹칩니다.
알림 peer와 인증기간과 같은 다른 요소들은 완전히 다릅니다.
connectionOptions은 connection profile을 보완하는 게이트웨이로 넘어갑니다.
application은 게이트웨이가 connection profile을 사용하는 방법을 선언할 수 있습니다.
예를 들어 이벤트 알림을 사용하기 위한 peer를 선택하기 위해 네트워크 구성요소와 상호작용 패턴을 제어하기 위해 SDK에서 해석됩니다.
사용가능한 connection options의 목록에 대해 그리고 언제 그들을 사용해야 하는지에 대해 읽어보세요. (hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/connectoptions.html)
Structure (How to define a connection profile)
connection profile의 구조의 이해를 돕기위해, 위의 네트워크 예제를 단계별로 살펴보겠습니다.
그것의 connection profile은 PaperNet 기업 어음 예제에 기초를 두고 있으며, GitHub 레파지토리(github.com/hyperledger/fabric-samples/blob/master/commercial-paper/organization/magnetocorp/gateway/networkConnection.yaml)에 저장됩니다.
편의를 위해 우리는 아래에 재현했습니다.
지금 읽으면서 다른 브라우저 창에 전시하는 것은 도움이 될 것입니다.
- Line 9: name: "papernet.magnetocorp.profile.sample"
- connection profile의 이름입니다. DNS 스타일의 이름을 사용하세요. 의미를 전달하기 매우 쉬운 방법입니다.
- Line 16: x-type: "hlfv1"
- 사용자는 그들의 HTTP 헤더와 마찬가지로 "어플리케이션별" x- 속성을 추가할 수 있습니다. 주로 향후에 사용을 위해 제공됩니다.
- Line 20: description: "Sample connection profile for documentation topic"
- connection profile에 대한 간단한 설명입니다. 처음 보는 독자들에게도 도움이 되도록 하세요.
- Line 25: version: "1.0"
- connection profile의 스키마 버전입니다. 현재 오직 버전 1.0만 지원되며,스키마가 자주 변경되지 않을 것으로 예상됩니다.
- Line 32: channels:
- 이것은 정말 중요한 첫번째 줄입니다. channels:는 connection profile이 설명하는 모든 채널을 식별합니다. 그러나 특히 서로 독립적인 경우 다른 connection profile에는 다른 channel을 유지하는 것이 좋습니다.
- Line 36: papernet:
- papernet의 세부정보, connection profile의 첫번째 채널인 papernet에 대한 자세한 내용은 다음을 참조하세요.
- Line 41: orderers:
- papernet의 모든 orderer의 자세한 내용입니다. 45번째 라인에서 이 채널의 orderer가 orderer1.magnetocorp.example.com임을 알 수 있습니다. 이것은 단지 논리적인 이름입니다. connection profile(lines 134-147), orderer에 연결하는 자세한 방법이 있습니다. orderer2.digibank.example.com는 목록에 없다는 것을 확인하세요. application은 다른 조직의 orderer가 아닌 그들의 조직 orderer를 사용하는 것이 합리적입니다.
- Line 49: peers:
- papernet의 모든 peer의 세부정보가 이어집니다.
- MagnetoCorp에서 three peer를 볼 수 있습니다. (peer1.magnetocorp.example.com, peer2.magnetocorp.example.com, peer3.magnetocorp.example.com) 여기에서 수행 한 것처럼 MagnetoCorp의 모든 peer를 나열 할 필요는 없습니다. DigiBank로부터는 오직 하나의 peer만 확인할 수 있습니다. (peer9.digibank.example.com) 이 peer를 포함하면 보증 정책에 따라 MagnetoCorp와 DigiBank가 트랜잭션을 보증해야 함을 의미하기 시작합니다. 단일 실패 지점을 피하기 위해 여러 peer를 갖는 것이 좋습니다.
- 각 peer 밑에 네개의 비독점적 역할을 볼 수 있습니다. (endorsingPeer, chaincodeQuery, ledgerQuery, eventSource) peer1과 peer2는 papercontract의 host로서 모든 역할을 수행합니다. 알림에 사용되는 peer3 또는 world state대신 원장의 블록체인 구성요소에 접근하는 원장 쿼리와 대조되므로 smart contract 설치할 필요가 없습니다. peer9은 MagnetoCorp peer가 더 낫게 제공하기 때문에, 어떻게 보증대신 다른 용도로 사용할 수 없는지 확인하세요.
- 다시 말하지만, peer가 그들의 논리적인 이름과 역할에 따라 어떻게 설명되는지 확인하세요. 나중에 profile에서 우리는 이 peer들의 물리적인 정보를 볼 수 있습니다.
- Line 97: organizations:
- 모든 채널의 모든 조직의 자세한 정보가 이어집니다. 비록 papernet이 현재 유일한 목록임에도 불구하고 이러한 조직은 모든 채널에 적용된다는 점을 알아두세요. 조직은 여러 채널에 있을 수 있기 때문에 채널은 여러 조직을 가질 수 있습니다. 게다가 일부 application 동작은 채널보단 조직과 관계가 있습니다. 예를 들어, application은 연결 옵션을 사용하여 조직에 있는 하나 또는 모든 peer 혹은 네트워크 안에 있는 모든 조직에 알림을 요청할 수 있습니다. 이를 위해, peer 매핑을 위한 조직이 필요하며 이 섹션에서는 이를 제공합니다.
- Line 101: MagnetoCorp:
- MagnetoCorp의 일부로 간주되는 모든 peer (peer1, peer2, peer3). 인증 기관도 마찬가지 입니다. 다시 말하지만, channels: 섹션같은 논리적인 이름 사용은 유의하세요. 물리적인 정보는 profile 뒷부분에서 나중에 따라올 것입니다.
- Line 121: DigiBank:
- peer9는 DigiBank의 일부로 나열되며, 인증기관은 없습니다. 이러한 다른 peer와 DigiBank CA는 이 connection prifile의 사용자와 관련이 없기 때문입니다.
- Line 134: orderers:
- orderer의 물리적인 정보는 나열됩니다. connection profile은 papernet에 하나의 orderer만 언급한 것과 같이, orderer1.magnetocorp.example.com의 나열된 자세한 사항을 볼 수 있습니다. 여기에는 IP 주소, 포트, orderer과 통신할 때 필요한 경우 기본값을 재정의할 수 있는 gRPC 옵션을 포함합니다. peers: 에서와 마찬가지로 가용성을 위해, 둘 이상의 orderer를 지정하는 것이 좋습니다.
- Line 152: peers:
- 모든 이전 peer의 물리적인 정보는 나열됩니다. 이 connection profile은 MagnotoCorp의 세가지 peer입니다. (peer1, peer2, peer3) DigiBank를 위한 단일 peer9는 그것의 나열된 정보를 가지고 있습니다. orderer와 마찬가지로 각 peer에 대해 그들의 IP주소, 포트 그리고 particular peer과 통신할 때 필요한 경우 기본값을 재정의할 수 있는 gRPC 옵션이 나열됩니다.
- Line 194: certificateAuthorities:
- 인증 기관에 대한 물리적인 정보가 나열됩니다. connection profile은 MagnetoCorp의 단일 CA인 cal-magnetocorp를 가지고 있고, 그것의 물리적인 정보는 다음과 같습니다. IP 세부사항 뿐만 아니라 등록정보를 통해 CA가 인증서 서명 요청(Certificate Signing Requests, CSR)을 사용할 수 있습니다. 로컬에서 생성된 public/private 키 쌍에 대한 새 인증서를 요청하는데 사용됩니다.
MagnetoCorp의 connection profile을 이해했으므로, DigiBank의 해당 profile(github.com/hyperledger/fabric-samples/blob/master/commercial-paper/organization/magnetocorp/gateway/networkConnection.yaml)을 살펴보는 것이 좋습니다.
profile이 MagnetoCorp과 동일한 위치 찾기, 유사한 위치 확인, 마지막으로 profile이 다른 위치 확인합니다.
왜 이러한 차이점이 DigiBank application에 합리적인지 생각해보세요.
이것이 connection profile에 대해 알아야할 모든 것들입니다.
요약하면, connection profile은 게이트웨이를 구성하기 위해 application의 위한 충분한 채널, 조직, peer, orderer 그리고 인증기관을 정의합니다.
이 게이트웨이를 사용하면 application은 네트워크 토폴로지의 자세한 사항보다 비즈니스 로직에 집중할 수 있습니다.
Sample
이 파일은 GitHub 기업 어음 예제에서 가져왔습니다.
1: ---
2: #
3: # [Required]. A connection profile contains information about a set of network
4: # components. It is typically used to configure gateway, allowing applications
5: # interact with a network channel without worrying about the underlying
6: # topology. A connection profile is normally created by an administrator who
7: # understands this topology.
8: #
9: name: "papernet.magnetocorp.profile.sample"
10: #
11: # [Optional]. Analogous to HTTP, properties with an "x-" prefix are deemed
12: # "application-specific", and ignored by the gateway. For example, property
13: # "x-type" with value "hlfv1" was originally used to identify a connection
14: # profile for Fabric 1.x rather than 0.x.
15: #
16: x-type: "hlfv1"
17: #
18: # [Required]. A short description of the connection profile
19: #
20: description: "Sample connection profile for documentation topic"
21: #
22: # [Required]. Connection profile schema version. Used by the gateway to
23: # interpret these data.
24: #
25: version: "1.0"
26: #
27: # [Optional]. A logical description of each network channel; its peer and
28: # orderer names and their roles within the channel. The physical details of
29: # these components (e.g. peer IP addresses) will be specified later in the
30: # profile; we focus first on the logical, and then the physical.
31: #
32: channels:
33: #
34: # [Optional]. papernet is the only channel in this connection profile
35: #
36: papernet:
37: #
38: # [Optional]. Channel orderers for PaperNet. Details of how to connect to
39: # them is specified later, under the physical "orderers:" section
40: #
41: orderers:
42: #
43: # [Required]. Orderer logical name
44: #
45: - orderer1.magnetocorp.example.com
46: #
47: # [Optional]. Peers and their roles
48: #
49: peers:
50: #
51: # [Required]. Peer logical name
52: #
53: peer1.magnetocorp.example.com:
54: #
55: # [Optional]. Is this an endorsing peer? (It must have chaincode
56: # installed.) Default: true
57: #
58: endorsingPeer: true
59: #
60: # [Optional]. Is this peer used for query? (It must have chaincode
61: # installed.) Default: true
62: #
63: chaincodeQuery: true
64: #
65: # [Optional]. Is this peer used for non-chaincode queries? All peers
66: # support these types of queries, which include queryBlock(),
67: # queryTransaction(), etc. Default: true
68: #
69: ledgerQuery: true
70: #
71: # [Optional]. Is this peer used as an event hub? All peers can produce
72: # events. Default: true
73: #
74: eventSource: true
75: #
76: peer2.magnetocorp.example.com:
77: endorsingPeer: true
78: chaincodeQuery: true
79: ledgerQuery: true
80: eventSource: true
81: #
82: peer3.magnetocorp.example.com:
83: endorsingPeer: false
84: chaincodeQuery: false
85: ledgerQuery: true
86: eventSource: true
87: #
88: peer9.digibank.example.com:
89: endorsingPeer: true
90: chaincodeQuery: false
91: ledgerQuery: false
92: eventSource: false
93: #
94: # [Required]. List of organizations for all channels. At least one organization
95: # is required.
96: #
97: organizations:
98: #
99: # [Required]. Organizational information for MagnetoCorp
100: #
101: MagnetoCorp:
102: #
103: # [Required]. The MSPID used to identify MagnetoCorp
104: #
105: mspid: MagnetoCorpMSP
106: #
107: # [Required]. The MagnetoCorp peers
108: #
109: peers:
110: - peer1.magnetocorp.example.com
111: - peer2.magnetocorp.example.com
112: - peer3.magnetocorp.example.com
113: #
114: # [Optional]. Fabric-CA Certificate Authorities.
115: #
116: certificateAuthorities:
117: - ca-magnetocorp
118: #
119: # [Optional]. Organizational information for DigiBank
120: #
121: DigiBank:
122: #
123: # [Required]. The MSPID used to identify DigiBank
124: #
125: mspid: DigiBankMSP
126: #
127: # [Required]. The DigiBank peers
128: #
129: peers:
130: - peer9.digibank.example.com
131: #
132: # [Optional]. Orderer physical information, by orderer name
133: #
134: orderers:
135: #
136: # [Required]. Name of MagnetoCorp orderer
137: #
138: orderer1.magnetocorp.example.com:
139: #
140: # [Required]. This orderer's IP address
141: #
142: url: grpc://localhost:7050
143: #
144: # [Optional]. gRPC connection properties used for communication
145: #
146: grpcOptions:
147: ssl-target-name-override: orderer1.magnetocorp.example.com
148: #
149: # [Required]. Peer physical information, by peer name. At least one peer is
150: # required.
151: #
152: peers:
153: #
154: # [Required]. First MagetoCorp peer physical properties
155: #
156: peer1.magnetocorp.example.com:
157: #
158: # [Required]. Peer's IP address
159: #
160: url: grpc://localhost:7151
161: #
162: # [Optional]. gRPC connection properties used for communication
163: #
164: grpcOptions:
165: ssl-target-name-override: peer1.magnetocorp.example.com
166: request-timeout: 120001
167: #
168: # [Optional]. Other MagnetoCorp peers
169: #
170: peer2.magnetocorp.example.com:
171: url: grpc://localhost:7251
172: grpcOptions:
173: ssl-target-name-override: peer2.magnetocorp.example.com
174: request-timeout: 120001
175: #
176: peer3.magnetocorp.example.com:
177: url: grpc://localhost:7351
178: grpcOptions:
179: ssl-target-name-override: peer3.magnetocorp.example.com
180: request-timeout: 120001
181: #
182: # [Required]. Digibank peer physical properties
183: #
184: peer9.digibank.example.com:
185: url: grpc://localhost:7951
186: grpcOptions:
187: ssl-target-name-override: peer9.digibank.example.com
188: request-timeout: 120001
189: #
190: # [Optional]. Fabric-CA Certificate Authority physical information, by name.
191: # This information can be used to (e.g.) enroll new users. Communication is via
192: # REST, hence options relate to HTTP rather than gRPC.
193: #
194: certificateAuthorities:
195: #
196: # [Required]. MagnetoCorp CA
197: #
198: ca1-magnetocorp:
199: #
200: # [Required]. CA IP address
201: #
202: url: http://localhost:7054
203: #
204: # [Optioanl]. HTTP connection properties used for communication
205: #
206: httpOptions:
207: verify: false
208: #
209: # [Optional]. Fabric-CA supports Certificate Signing Requests (CSRs). A
210: # registrar is needed to enroll new users.
211: #
212: registrar:
213: - enrollId: admin
214: enrollSecret: adminpw
215: #
216: # [Optional]. The name of the CA.
217: #
218: caName: ca-magnetocorp
출처 ]
hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/connectionprofile.html