github.com/true-sqn/fabric@v2.1.1+incompatible/docs/source/test_network.md (about) 1 # Using the Fabric test network 2 3 After you have downloaded the Hyperledger Fabric Docker images and samples, you 4 can deploy a test network by using scripts that are provided in the 5 `fabric-samples` repository. You can use the test network to learn about Fabric 6 by running nodes on your local machine. More experienced developers can use the 7 network to test their smart contracts and applications. The network is meant to 8 be used only as a tool for education and testing. It should not be used as a 9 template for deploying a production network. The test network is being introduced 10 in Fabric v2.0 as the long term replacement for the `first-network` sample. 11 12 The sample network deploys a Fabric network with Docker Compose. Because the 13 nodes are isolated within a Docker Compose network, the test network is not 14 configured to connect to other running fabric nodes. 15 16 **Note:** These instructions have been verified to work against the 17 latest stable Docker images and the pre-compiled setup utilities within the 18 supplied tar file. If you run these commands with images or tools from the 19 current master branch, it is possible that you will encounter errors. 20 21 ## Before you begin 22 23 Before you can run the test network, you need to clone the `fabric-samples` 24 repository and download the Fabric images. Make sure that that you have installed 25 the [Prerequisites](prereqs.html) and [Installed the Samples, Binaries and Docker Images](install.html). 26 27 ## Bring up the test network 28 29 You can find the scripts to bring up the network in the `test-network` directory 30 of the ``fabric-samples`` repository. Navigate to the test network directory by 31 using the following command: 32 ``` 33 cd fabric-samples/test-network 34 ``` 35 36 In this directory, you can find an annotated script, ``network.sh``, that stands 37 up a Fabric network using the Docker images on your local machine. You can run 38 ``./network.sh -h`` to print the script help text: 39 40 ``` 41 Usage: 42 network.sh <Mode> [Flags] 43 <Mode> 44 - 'up' - bring up fabric orderer and peer nodes. No channel is created 45 - 'up createChannel' - bring up fabric network with one channel 46 - 'createChannel' - create and join a channel after the network is created 47 - 'deployCC' - deploy the fabcar chaincode on the channel 48 - 'down' - clear the network with docker-compose down 49 - 'restart' - restart the network 50 51 Flags: 52 -ca <use CAs> - create Certificate Authorities to generate the crypto material 53 -c <channel name> - channel name to use (defaults to "mychannel") 54 -s <dbtype> - the database backend to use: goleveldb (default) or couchdb 55 -r <max retry> - CLI times out after certain number of attempts (defaults to 5) 56 -d <delay> - delay duration in seconds (defaults to 3) 57 -l <language> - the programming language of the chaincode to deploy: go (default), java, javascript, typescript 58 -v <version> - chaincode version. Must be a round number, 1, 2, 3, etc 59 -i <imagetag> - the tag to be used to launch the network (defaults to "latest") 60 -cai <ca_imagetag> - the image tag to be used for CA (defaults to "1.4.6") 61 -verbose - verbose mode 62 network.sh -h (print this message) 63 64 Possible Mode and flags 65 network.sh up -ca -c -r -d -s -i -verbose 66 network.sh up createChannel -ca -c -r -d -s -i -verbose 67 network.sh createChannel -c -r -d -verbose 68 network.sh deployCC -l -v -r -d -verbose 69 70 Taking all defaults: 71 network.sh up 72 73 Examples: 74 network.sh up createChannel -ca -c mychannel -s couchdb -i 2.0.0 75 network.sh createChannel -c channelName 76 network.sh deployCC -l javascript 77 ``` 78 79 From inside the `test-network` directory, run the following command to remove 80 any containers or artifacts from any previous runs: 81 ``` 82 ./network.sh down 83 ``` 84 85 You can then bring up the network by issuing the following command. You will 86 experience problems if you try to run the script from another directory: 87 ``` 88 ./network.sh up 89 ``` 90 91 This command creates a Fabric network that consists of two peer nodes, one 92 ordering node. No channel is created when you run `./network.sh up`, though we 93 will get there in a [future step](#creating-a-channel). If the command completes 94 successfully, you will see the logs of the nodes being created: 95 ``` 96 Creating network "net_test" with the default driver 97 Creating volume "net_orderer.example.com" with default driver 98 Creating volume "net_peer0.org1.example.com" with default driver 99 Creating volume "net_peer0.org2.example.com" with default driver 100 Creating orderer.example.com ... done 101 Creating peer0.org2.example.com ... done 102 Creating peer0.org1.example.com ... done 103 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 104 8d0c74b9d6af hyperledger/fabric-orderer:latest "orderer" 4 seconds ago Up Less than a second 0.0.0.0:7050->7050/tcp orderer.example.com 105 ea1cf82b5b99 hyperledger/fabric-peer:latest "peer node start" 4 seconds ago Up Less than a second 0.0.0.0:7051->7051/tcp peer0.org1.example.com 106 cd8d9b23cb56 hyperledger/fabric-peer:latest "peer node start" 4 seconds ago Up 1 second 7051/tcp, 0.0.0.0:9051->9051/tcp peer0.org2.example.com 107 ``` 108 109 If you don't get this result, jump down to [Troubleshooting](#troubleshooting) 110 for help on what might have gone wrong. By default, the network uses the 111 cryptogen tool to bring up the network. However, you can also 112 [bring up the network with Certificate Authorities](#bring-up-the-network-with-certificate-authorities). 113 114 ### The components of the test network 115 116 After your test network is deployed, you can take some time to examine its 117 components. Run the following command to list all of Docker containers that 118 are running on your machine. You should see the three nodes that were created by 119 the `network.sh` script: 120 ``` 121 docker ps -a 122 ``` 123 124 Each node and user that interacts with a Fabric network needs to belong to an 125 organization that is a network member. The group of organizations that are 126 members of a Fabric network are often referred to as the consortium. The test 127 network has two consortium members, Org1 and Org2. The network also includes one 128 orderer organization that maintains the ordering service of the network. 129 130 [Peers](peers/peers.html) are the fundamental components of any Fabric network. 131 Peers store the blockchain ledger and validate transactions before they are 132 committed to the ledger. Peers run the smart contracts that contain the business 133 logic that is used to manage the assets on the blockchain ledger. 134 135 Every peer in the network needs to belong to a member of the consortium. In the 136 test network, each organization operates one peer each, `peer0.org1.example.com` 137 and `peer0.org2.example.com`. 138 139 Every Fabric network also includes an [ordering service](orderer/ordering_service.html). 140 While peers validate transactions and add blocks of transactions to the 141 blockchain ledger, they do not decide on the order of transactions or include 142 them into new blocks. On a distributed network, peers may be running far away 143 from each other and not have a common view of when a transaction was created. 144 Coming to consensus on the order of transactions is a costly process that would 145 create overhead for the peers. 146 147 An ordering service allows peers to focus on validating transactions and 148 committing them to the ledger. After ordering nodes receive endorsed transactions 149 from clients, they come to consensus on the order of transactions and then add 150 them to blocks. The blocks are then distributed to peer nodes, which add the 151 blocks the blockchain ledger. Ordering nodes also operate the system channel 152 that defines the capabilities of a Fabric network, such as how blocks are made 153 and which version of Fabric that nodes can use. The system channel defines which 154 organizations are members of the consortium. 155 156 The sample network uses a single node Raft ordering service that is operated by 157 the ordering organization. You can see the ordering node running on your machine 158 as `orderer.example.com`. While the test network only uses a single node ordering 159 service, a real network would have multiple ordering nodes, operated by one or 160 multiple orderer organizations. The different ordering nodes would use the Raft 161 consensus algorithm to come to agreement on the order of transactions across 162 the network. 163 164 ## Creating a channel 165 166 Now that we have peer and orderer nodes running on our machine, we can use the 167 script to create a Fabric channel for transactions between Org1 and Org2. 168 Channels are a private layer of communication between specific network members. 169 Channels can be used only by organizations that are invited to the channel, and 170 are invisible to other members of the network. Each channel has a separate 171 blockchain ledger. Organizations that have been invited "join" their peers to 172 the channel to store the channel ledger and validate the transactions on the 173 channel. 174 175 You can use the `network.sh` script to create a channel between Org1 and Org2 176 and join their peers to the channel. Run the following command to create a 177 channel with the default name of `mychannel`: 178 ``` 179 ./network.sh createChannel 180 ``` 181 If the command was successful, you can see the following message printed in your 182 logs: 183 ``` 184 ========= Channel successfully joined =========== 185 ``` 186 187 You can also use the channel flag to create a channel with custom name. As an 188 example, the following command would create a channel named `channel1`: 189 ``` 190 ./network.sh createChannel -c channel1 191 ``` 192 193 The channel flag also allows you to create multiple channels by specifying 194 different channel names. After you create `mychannel` or `channel1`, you can use 195 the command below to create a second channel named `channel2`: 196 ``` 197 ./network.sh createChannel -c channel2 198 ``` 199 200 If you want to bring up the network and create a channel in a single step, you 201 can use the `up` and `createChannel` modes together: 202 ``` 203 ./network.sh up createChannel 204 ``` 205 206 ## Starting a chaincode on the channel 207 208 After you have created a channel, you can start using [smart contracts](smartcontract/smartcontract.html) to 209 interact with the channel ledger. Smart contracts contain the business logic 210 that governs assets on the blockchain ledger. Applications run by members of the 211 network can invoke smart contracts to create assets on the ledger, as well as 212 change and transfer those assets. Applications also query smart contracts to 213 read data on the ledger. 214 215 To ensure that transactions are valid, transactions created using smart contracts 216 typically need to be signed by multiple organizations to be committed to the 217 channel ledger. Multiple signatures are integral to the trust model of Fabric. 218 Requiring multiple endorsements for a transaction prevents one organization on 219 a channel from tampering with the ledger on their peer or using business logic 220 that was not agreed to. To sign a transaction, each organization needs to invoke 221 and execute the smart contract on their peer, which then signs the output of the 222 transaction. If the output is consistent and has been signed by enough 223 organizations, the transaction can be committed to the ledger. The policy that 224 specifies the set organizations on the channel that need to execute the smart 225 contract is referred to as the endorsement policy, which is set for each 226 chaincode as part of the chaincode definition. 227 228 In Fabric, smart contracts are deployed on the network in packages referred to 229 as chaincode. A Chaincode is installed on the peers of an organization and then 230 deployed to a channel, where it can then be used to endorse transactions and 231 interact with the blockchain ledger. Before a chaincode can be deployed to a 232 channel, the members of the channel need to agree on a chaincode definition that 233 establishes chaincode governance. When the required number of organizations 234 agree, the chaincode definition can be committed to the channel, and the 235 chaincode is ready to be used. 236 237 After you have used the `network.sh` to create a channel, you can start a 238 chaincode on the channel using the following command: 239 ``` 240 ./network.sh deployCC 241 ``` 242 The `deployCC` subcommand will install the **fabcar** chaincode on 243 ``peer0.org1.example.com`` and ``peer0.org2.example.com`` and then deploy 244 the chaincode on the channel specified using the channel flag (or `mychannel` 245 if no channel is specified). If you are deploying a chaincode for the first 246 time, the script will install the chaincode dependencies. By default, The script 247 installs the Go version of the fabcar chaincode. However, you can use the 248 language flag, `-l`, to install the Java or javascript versions of the chaincode. 249 You can find the Fabcar chaincode in the `chaincode` folder of the `fabric-samples` 250 directory. This folder contains sample chaincode that are provided as examples and 251 used by tutorials to highlight Fabric features. 252 253 After the **fabcar** chaincode definition has been committed to the channel, the 254 script initializes the chaincode by invoking the `init` function and then invokes 255 the chaincode to put an initial list of cars on the ledger. The script then 256 queries the chaincode to verify the that the data was added. If the chaincode was 257 installed, deployed, and invoked correctly, you should see the following list of 258 cars printed in your logs: 259 ``` 260 [{"Key":"CAR0", "Record":{"make":"Toyota","model":"Prius","colour":"blue","owner":"Tomoko"}}, 261 {"Key":"CAR1", "Record":{"make":"Ford","model":"Mustang","colour":"red","owner":"Brad"}}, 262 {"Key":"CAR2", "Record":{"make":"Hyundai","model":"Tucson","colour":"green","owner":"Jin Soo"}}, 263 {"Key":"CAR3", "Record":{"make":"Volkswagen","model":"Passat","colour":"yellow","owner":"Max"}}, 264 {"Key":"CAR4", "Record":{"make":"Tesla","model":"S","colour":"black","owner":"Adriana"}}, 265 {"Key":"CAR5", "Record":{"make":"Peugeot","model":"205","colour":"purple","owner":"Michel"}}, 266 {"Key":"CAR6", "Record":{"make":"Chery","model":"S22L","colour":"white","owner":"Aarav"}}, 267 {"Key":"CAR7", "Record":{"make":"Fiat","model":"Punto","colour":"violet","owner":"Pari"}}, 268 {"Key":"CAR8", "Record":{"make":"Tata","model":"Nano","colour":"indigo","owner":"Valeria"}}, 269 {"Key":"CAR9", "Record":{"make":"Holden","model":"Barina","colour":"brown","owner":"Shotaro"}}] 270 ===================== Query successful on peer0.org1 on channel 'mychannel' ===================== 271 ``` 272 273 ## Interacting with the network 274 275 After you bring up the test network, you can use the `peer` CLI to interact 276 with your network. The `peer` CLI allows you to invoke deployed smart contracts, 277 update channels, or install and deploy new smart contracts from the CLI. 278 279 Make sure that you are operating from the `test-network` directory. If you 280 followed the instructions to [install the Samples, Binaries and Docker Images](install.html), 281 You can find the `peer` binaries in the `bin` folder of the `fabric-samples` 282 repository. Use the following command to add those binaries to your CLI Path: 283 ``` 284 export PATH=${PWD}/../bin:$PATH 285 ``` 286 You also need to set the `FABRIC_CFG_PATH` to point to the `core.yaml` file in 287 the `fabric-samples` repository: 288 ``` 289 export FABRIC_CFG_PATH=$PWD/../config/ 290 ``` 291 You can now set the environment variables that allow you to operate the `peer` 292 CLI as Org1: 293 ``` 294 # Environment variables for Org1 295 296 export CORE_PEER_TLS_ENABLED=true 297 export CORE_PEER_LOCALMSPID="Org1MSP" 298 export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt 299 export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp 300 export CORE_PEER_ADDRESS=localhost:7051 301 ``` 302 303 The `CORE_PEER_TLS_ROOTCERT_FILE` and `CORE_PEER_MSPCONFIGPATH` environment 304 variables point to the Org1 crypto material in the `organizations` folder. 305 306 If you used `./network.sh deployCC` to install and start the fabcar chaincode, 307 you can now query the ledger from your CLI. Run the following command to get the 308 list of cars that were added to your channel ledger: 309 ``` 310 peer chaincode query -C mychannel -n fabcar -c '{"Args":["queryAllCars"]}' 311 ``` 312 313 If the command is successful, you can see the same list of cars that were printed 314 in the logs when you ran the script: 315 ``` 316 [{"Key":"CAR0", "Record":{"make":"Toyota","model":"Prius","colour":"blue","owner":"Tomoko"}}, 317 {"Key":"CAR1", "Record":{"make":"Ford","model":"Mustang","colour":"red","owner":"Brad"}}, 318 {"Key":"CAR2", "Record":{"make":"Hyundai","model":"Tucson","colour":"green","owner":"Jin Soo"}}, 319 {"Key":"CAR3", "Record":{"make":"Volkswagen","model":"Passat","colour":"yellow","owner":"Max"}}, 320 {"Key":"CAR4", "Record":{"make":"Tesla","model":"S","colour":"black","owner":"Adriana"}}, 321 {"Key":"CAR5", "Record":{"make":"Peugeot","model":"205","colour":"purple","owner":"Michel"}}, 322 {"Key":"CAR6", "Record":{"make":"Chery","model":"S22L","colour":"white","owner":"Aarav"}}, 323 {"Key":"CAR7", "Record":{"make":"Fiat","model":"Punto","colour":"violet","owner":"Pari"}}, 324 {"Key":"CAR8", "Record":{"make":"Tata","model":"Nano","colour":"indigo","owner":"Valeria"}}, 325 {"Key":"CAR9", "Record":{"make":"Holden","model":"Barina","colour":"brown","owner":"Shotaro"}}] 326 ``` 327 328 Chaincodes are invoked when a network member wants to transfer or change an 329 asset on the ledger. Use the following command to change the owner of a car on 330 the ledger by invoking the fabcar chaincode: 331 ``` 332 peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n fabcar --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"changeCarOwner","Args":["CAR9","Dave"]}' 333 ``` 334 335 If the command is successful, you should see the following response: 336 ``` 337 2019-12-04 17:38:21.048 EST [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 001 Chaincode invoke successful. result: status:200 338 ``` 339 340 **Note:** If you deployed the Java chaincode, run the invoke command with the 341 following arguments instead: `'{"function":"changeCarOwner","Args":["CAR009","Dave"]}'` 342 The Fabcar chaincode written in Java uses a different index than the chaincode 343 written in Javascipt or Go. 344 345 Because the endorsement policy for the fabcar chaincode requires the transaction 346 to be signed by Org1 and Org2, the chaincode invoke command needs to target both 347 `peer0.org1.example.com` and `peer0.org2.example.com` using the `--peerAddresses` 348 flag. Because TLS is enabled for the network, the command also needs to reference 349 the TLS certificate for each peer using the `--tlsRootCertFiles` flag. 350 351 After we invoke the chaincode, we can use another query to see how the invoke 352 changed the assets on the blockchain ledger. Since we already queried the Org1 353 peer, we can take this opportunity to query the chaincode running on the Org2 354 peer. Set the following environment variables to operate as Org2: 355 ``` 356 # Environment variables for Org2 357 358 export CORE_PEER_TLS_ENABLED=true 359 export CORE_PEER_LOCALMSPID="Org2MSP" 360 export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt 361 export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp 362 export CORE_PEER_ADDRESS=localhost:9051 363 ``` 364 365 You can now query the fabcar chaincode running on `peer0.org2.example.com`: 366 ``` 367 peer chaincode query -C mychannel -n fabcar -c '{"Args":["queryCar","CAR9"]}' 368 ``` 369 370 The result will show that `"CAR9"` was transferred to Dave: 371 ``` 372 {"make":"Holden","model":"Barina","colour":"brown","owner":"Dave"} 373 ``` 374 375 ## Bring down the network 376 377 When you are finished using the test network, you can bring down the network 378 with the following command: 379 ``` 380 ./network.sh down 381 ``` 382 383 The command will stop and remove the node and chaincode containers, delete the 384 organization crypto material, and remove the chaincode images from your Docker 385 Registry. The command also removes the channel artifacts and docker volumes from 386 previous runs, allowing you to run `./network.sh up` again if you encountered 387 any problems. 388 389 ## Next steps 390 391 Now that you have used the test network to deploy Hyperledger Fabric on your 392 local machine, you can use the tutorials to start developing your own solution: 393 394 - Learn how to deploy your own smart contracts to the test network using the 395 [Deploying a smart contract to a channel](deploy_chaincode.html) tutorial. 396 - Visit the [Writing Your First Application](write_first_app.html) tutorial 397 to learn how to use the APIs provided by the Fabric SDKs to invoke smart 398 contracts from your client applications. 399 - If you are ready to deploy a more complicated smart contract to the network, follow 400 the [commercial paper tutorial](tutorial/commercial_paper.html) to explore a 401 use case in which two organizations use a blockchain network to trade commercial 402 paper. 403 404 You can find the the complete list of Fabric tutorials on the [tutorials](tutorials.html) 405 page. 406 407 ## Bring up the network with Certificate Authorities 408 409 Hyperledger Fabric uses public key infrastructure (PKI) to verify the actions of 410 all network participants. Every node, network administrator, and user submitting 411 transactions needs to have a public certificate and private key to verify their 412 identity. These identities need to have a valid root of trust, establishing 413 that the certificates were issued by an organization that is a member of the 414 network. The `network.sh` script creates all of the cryptographic material 415 that is required to deploy and operate the network before it creates the peer 416 and ordering nodes. 417 418 By default, the script uses the cryptogen tool to create the certificates 419 and keys. The tool is provided for development and testing, and can quickly 420 create the required crypto material for Fabric organizations with a valid root 421 of trust. When you run `./network.sh up`, you can see the cryptogen tool creating 422 the certificates and keys for Org1, Org2, and the Orderer Org. 423 424 ``` 425 creating Org1, Org2, and ordering service organization with crypto from 'cryptogen' 426 427 /Usr/fabric-samples/test-network/../bin/cryptogen 428 429 ########################################################## 430 ##### Generate certificates using cryptogen tool ######### 431 ########################################################## 432 433 ########################################################## 434 ############ Create Org1 Identities ###################### 435 ########################################################## 436 + cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output=organizations 437 org1.example.com 438 + res=0 439 + set +x 440 ########################################################## 441 ############ Create Org2 Identities ###################### 442 ########################################################## 443 + cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output=organizations 444 org2.example.com 445 + res=0 446 + set +x 447 ########################################################## 448 ############ Create Orderer Org Identities ############### 449 ########################################################## 450 + cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output=organizations 451 + res=0 452 + set +x 453 ``` 454 455 However, the test network script also provides the option to bring up the network using 456 Certificate Authorities (CAs). In a production network, each organization 457 operates a CA (or multiple intermediate CAs) that creates the identities that 458 belong to their organization. All of the identities created by a CA run by the 459 organization share the same root of trust. Although it takes more time than 460 using cryptogen, bringing up the test network using CAs provides an introduction 461 to how a network is deployed in production. Deploying CAs also allows you to enroll 462 client identities with the Fabric SDKs and create a certificate and private key 463 for your applications. 464 465 If you would like to bring up a network using Fabric CAs, first run the following 466 command to bring down any running networks: 467 ``` 468 ./network.sh down 469 ``` 470 471 You can then bring up the network with the CA flag: 472 ``` 473 ./network.sh up -ca 474 ``` 475 476 After you issue the command, you can see the script bringing up three CAs, one 477 for each organization in the network. 478 ``` 479 ########################################################## 480 ##### Generate certificates using Fabric CA's ############ 481 ########################################################## 482 Creating network "net_default" with the default driver 483 Creating ca_org2 ... done 484 Creating ca_org1 ... done 485 Creating ca_orderer ... done 486 ``` 487 488 It is worth taking time to examine the logs generated by the `./network.sh` 489 script after the CAs have been deployed. The test network uses the Fabric CA 490 client to register node and user identities with the CA of each organization. The 491 script then uses the enroll command to generate an MSP folder for each identity. 492 The MSP folder contains the certificate and private key for each identity, and 493 establishes the identity's role and membership in the organization that operated 494 the CA. You can use the following command to examine the MSP folder of the Org1 495 admin user: 496 ``` 497 tree organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/ 498 ``` 499 The command will reveal the MSP folder structure and configuration file: 500 ``` 501 organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/ 502 └── msp 503 ├── IssuerPublicKey 504 ├── IssuerRevocationPublicKey 505 ├── cacerts 506 │ └── localhost-7054-ca-org1.pem 507 ├── config.yaml 508 ├── keystore 509 │ └── 58e81e6f1ee8930df46841bf88c22a08ae53c1332319854608539ee78ed2fd65_sk 510 ├── signcerts 511 │ └── cert.pem 512 └── user 513 ``` 514 You can find the certificate of the admin user in the `signcerts` folder and the 515 private key in the `keystore` folder. To learn more about MSPs, see the [Membership Service Provider](membership/membership.html) 516 concept topic. 517 518 Both cryptogen and the Fabric CAs generate the cryptographic material for each organization 519 in the `organizations` folder. You can find the commands that are used to set up the 520 network in the `registerEnroll.sh` script in the `organizations/fabric-ca` directory. 521 To learn more about how you would use the Fabric CA to deploy a Fabric network, 522 visit the [Fabric CA operations guide](https://hyperledger-fabric-ca.readthedocs.io/en/latest/operations_guide.html). 523 You can learn more about how Fabric uses PKI by visiting the [identity](identity/identity.html) 524 and [membership](membership/membership.html) concept topics. 525 526 ## What's happening behind the scenes? 527 528 If you are interested in learning more about the sample network, you can 529 investigate the files and scripts in the `test-network` directory. The steps 530 below provide a guided tour of what happens when you issue the command of 531 `./network.sh up`. 532 533 - `./network.sh` creates the certificates and keys for two peer organizations 534 and the orderer organization. By default, the script uses the cryptogen tool 535 using the configuration files located in the `organizations/cryptogen` folder. 536 If you use the `-ca` flag to create Certificate Authorities, the script uses 537 Fabric CA server configuration files and `registerEnroll.sh` script located in 538 the `organizations/fabric-ca` folder. Both cryptogen and the Fabric CAs create 539 the crypto material and MSP folders for all three organizations in the 540 `organizations` folder. 541 542 - The script uses configtxgen tool to create the system channel genesis block. 543 Configtxgen consumes the `TwoOrgsOrdererGenesis` channel profile in the 544 `configtx/configtx.yaml` file to create the genesis block. The block is stored 545 in the `system-genesis-block` folder. 546 547 - Once the organization crypto material and the system channel genesis block have 548 been generated, the `network.sh` can bring up the nodes of the network. The 549 script uses the ``docker-compose-test-net.yaml`` file in the `docker` folder 550 to create the peer and orderer nodes. The `docker` folder also contains the 551 ``docker-compose-e2e.yaml`` file that brings up the nodes of the network 552 alongside three Fabric CAs. This file is meant to be used to run end-to-end 553 tests by the Fabric SDK. Refer to the [Node SDK](https://github.com/hyperledger/fabric-sdk-node) 554 repo for details on running these tests. 555 556 - If you use the `createChannel` subcommand, `./network.sh` runs the 557 `createChannel.sh` script in the `scripts` folder to create a channel 558 using the supplied channel name. The script uses the `configtx.yaml` file to 559 create the channel creation transaction, as well as two anchor peer update 560 transactions. The script uses the peer cli to create the channel, join 561 ``peer0.org1.example.com`` and ``peer0.org2.example.com`` to the channel, and 562 make both of the peers anchor peers. 563 564 - If you issue the `deployCC` command, `./network.sh` runs the ``deployCC.sh`` 565 script to install the **fabcar** chaincode on both peers and then define then 566 chaincode on the channel. Once the chaincode definition is committed to the 567 channel, the peer cli initializes the chainocde using the `Init` and invokes 568 the chaincode to put initial data on the ledger. 569 570 ## Troubleshooting 571 572 If you have any problems with the tutorial, review the following: 573 574 - You should always start your network fresh. You can use the following command 575 to remove the artifacts, crypto material, containers, volumes, and chaincode 576 images from previous runs: 577 ``` 578 ./network.sh down 579 ``` 580 You **will** see errors if you do not remove old containers, images, and 581 volumes. 582 583 - If you see Docker errors, first check your Docker version ([Prerequisites](prereqs.html)), 584 and then try restarting your Docker process. Problems with Docker are 585 oftentimes not immediately recognizable. For example, you may see errors 586 that are the result of your node not being able to access the crypto material 587 mounted within a container. 588 589 If problems persist, you can remove your images and start from scratch: 590 ``` 591 docker rm -f $(docker ps -aq) 592 docker rmi -f $(docker images -q) 593 ``` 594 595 - If you see errors on your create, approve, commit, invoke or query commands, 596 make sure you have properly updated the channel name and chaincode name. 597 There are placeholder values in the supplied sample commands. 598 599 - If you see the error below: 600 ``` 601 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) 602 ``` 603 604 You likely have chaincode images (e.g. ``dev-peer1.org2.example.com-fabcar-1.0`` or 605 ``dev-peer0.org1.example.com-fabcar-1.0``) from prior runs. Remove them and try 606 again. 607 ``` 608 docker rmi -f $(docker images | grep dev-peer[0-9] | awk '{print $3}') 609 ``` 610 611 - If you see the below error: 612 613 ``` 614 [configtx/tool/localconfig] Load -> CRIT 002 Error reading configuration: Unsupported Config Type "" 615 panic: Error reading configuration: Unsupported Config Type "" 616 ``` 617 618 Then you did not set the ``FABRIC_CFG_PATH`` environment variable properly. The 619 configtxgen tool needs this variable in order to locate the configtx.yaml. Go 620 back and execute an ``export FABRIC_CFG_PATH=$PWD/configtx/configtx.yaml``, 621 then recreate your channel artifacts. 622 623 - If you see an error stating that you still have "active endpoints", then prune 624 your Docker networks. This will wipe your previous networks and start you with a 625 fresh environment: 626 ``` 627 docker network prune 628 ``` 629 630 You will see the following message: 631 ``` 632 WARNING! This will remove all networks not used by at least one container. 633 Are you sure you want to continue? [y/N] 634 ``` 635 Select ``y``. 636 637 - If you see an error similar to the following: 638 ``` 639 /bin/bash: ./scripts/createChannel.sh: /bin/bash^M: bad interpreter: No such file or directory 640 ``` 641 642 Ensure that the file in question (**createChannel.sh** in this example) is 643 encoded in the Unix format. This was most likely caused by not setting 644 ``core.autocrlf`` to ``false`` in your Git configuration (see 645 [Windows extras](prereqs.html#windows-extras)). There are several ways of fixing this. If you have 646 access to the vim editor for instance, open the file: 647 ``` 648 vim ./fabric-samples/test-network/scripts/createChannel.sh 649 ``` 650 651 Then change its format by executing the following vim command: 652 ``` 653 :set ff=unix 654 ``` 655 656 - If your orderer exits upon creation or if you see that the create channel 657 command fails due to an inability to connect to your ordering service, use 658 the `docker logs` command to read the logs from the ordering node. You may see 659 the following message: 660 ``` 661 PANI 007 [channel system-channel] config requires unsupported orderer capabilities: Orderer capability V2_0 is required but not supported: Orderer capability V2_0 is required but not supported 662 ``` 663 This occurs when you are trying to run the network using Fabric version 1.4.x 664 docker images. The test network needs to run using Fabric version 2.x. 665 666 If you continue to see errors, share your logs on the **fabric-questions** 667 channel on [Hyperledger Rocket Chat](https://chat.hyperledger.org/home) or on 668 [StackOverflow](https://stackoverflow.com/questions/tagged/hyperledger-fabric). 669 670 <!--- Licensed under Creative Commons Attribution 4.0 International License 671 https://creativecommons.org/licenses/by/4.0/ -->