fabric-docs-i18n
fabric-docs-i18n copied to clipboard
[ja_JP] Tutorials / Adding an Org to a Channel
Original HTML: https://hyperledger-fabric.readthedocs.io/en/release-2.5/channel_update_tutorial.html Original Source: https://github.com/hyperledger/fabric/blob/e1e8e2e52aa4fc543360d245fe6554a0eaf81183/docs/source/channel_update_tutorial.rst
diff --git a/docs/source/channel_update_tutorial.rst b/docs/source/channel_update_tutorial.rst
index d79ec8c6e..3a3dca20b 100644
--- a/docs/source/channel_update_tutorial.rst
+++ b/docs/source/channel_update_tutorial.rst
@@ -156,25 +156,27 @@ Bring up Org3 components
~~~~~~~~~~~~~~~~~~~~~~~~
After we have created the Org3 certificate material, we can now bring up the
-Org3 peer. From the ``addOrg3`` directory, issue the following command:
+Org3 peer. From the ``addOrg3`` directory, issue the following command if you are using docker:
.. code:: bash
- docker-compose -f docker/docker-compose-org3.yaml up -d
+ docker-compose -f compose/compose-org3.yaml -f compose/docker/docker-compose-org3.yaml up -d
+
+If you are using podman change the second file argument to `compose/podman/docker-compose-org3.yaml`
If the command is successful, you will see the creation of the Org3 peer:
-.. code:: bash
+.. code::
Creating peer0.org3.example.com ... done
This Docker Compose file has been configured to bridge across our initial network,
so that the Org3 peer resolves with the existing peers and ordering
-node of the test network.
+node of the test network.
-.. note:: the `./addOrg3.sh up` command uses a `fabric-tools` CLI container to perform
- the channel configuration update process demonstrated below. This is to avoid the
- `jq` dependency requirement for first-time users. However, it is recommended to
+.. note:: the `./addOrg3.sh up` command uses a `fabric-tools` CLI container to perform
+ the channel configuration update process demonstrated below. This is to avoid the
+ `jq` dependency requirement for first-time users. However, it is recommended to
follow the process below directly on your local machine instead of using the unnecessary
CLI container.
@@ -194,6 +196,7 @@ to remove).
Navigate back to the ``test-network`` directory.
.. code:: bash
+
cd ..
Because Org3 is not yet a member of the channel, we need to operate as the admin
@@ -217,7 +220,7 @@ We can now issue the command to fetch the latest config block:
.. code:: bash
- peer channel fetch config channel-artifacts/config_block.pb -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c channel1 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ peer channel fetch config channel-artifacts/config_block.pb -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c channel1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"
This command saves the binary protobuf channel configuration block to
@@ -228,7 +231,7 @@ represented and its encoding (protobuf or JSON) is recommended.
When you issued the ``peer channel fetch`` command, the following output is
displayed in your logs:
-.. code:: bash
+.. code::
2021-01-07 18:46:33.687 UTC [cli.common] readBlock -> INFO 004 Received block: 2
@@ -251,7 +254,8 @@ the update process separate from other artifacts. Change into the ``channel-art
folder to complete the next steps:
.. code:: bash
- cd channel-artifacts
+
+ cd channel-artifacts
Now we will make use of the ``configtxlator`` tool to decode this channel
configuration block into JSON format (which can be read and modified by humans).
@@ -262,7 +266,7 @@ means of the ``jq`` tool (you will need to install the `jq tool <https://stedola
.. code:: bash
configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
- jq .data.data[0].payload.data.config config_block.json > config.json
+ jq ".data.data[0].payload.data.config" config_block.json > config.json
This command leaves us with a trimmed down JSON object -- ``config.json`` -- which
will serve as the baseline for our config update.
@@ -288,9 +292,9 @@ We'll use the ``jq`` tool once more to append the Org3 configuration definition
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ../organizations/peerOrganizations/org3.example.com/org3.json > modified_config.json
-Now we have two JSON files of interest -- ``config.json`` and
-``modified_config.json``. The initial file contains only Org1 and Org2
-material, whereas the "modified" file contains all three Orgs. At this
+Now we have two JSON files of interest -- ``config.json`` and
+``modified_config.json``. The initial file contains only Org1 and Org2
+material, whereas the "modified" file contains all three Orgs. At this
point it's simply a matter of re-encoding these two JSON files and calculating
the delta.
@@ -354,7 +358,8 @@ First, let's sign this update proto as Org1. Navigate back to the ``test-network
directory:
.. code:: bash
- cd ..
+
+ cd ..
Remember that we exported the necessary environment variables to operate as the Org1 admin.
As a result, the following ``peer channel signconfigtx`` command will sign the update as Org1.
@@ -397,7 +402,7 @@ Send the update call:
.. code:: bash
- peer channel update -f channel-artifacts/org3_update_in_envelope.pb -c channel1 -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ peer channel update -f channel-artifacts/org3_update_in_envelope.pb -c channel1 -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"
You should see a message similar to the following if your update has been submitted successfully:
@@ -435,8 +440,12 @@ Export the following environment variables to operate as the Org3 Admin:
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org3.example.com/users/[email protected]/msp
export CORE_PEER_ADDRESS=localhost:11051
-As a result of the successful channel update, the ordering service will verify
-that Org3 can pull the genesis block and join the channel. If Org3 had not
+Org3 peers can join ``channel1`` by either the genesis block or a snapshot that is created
+after Org3 has joined the channel.
+
+To join by the genesis block, send a call to the ordering service asking for the genesis block of
+``channel1``. As a result of the successful channel update, the ordering service
+will verify that Org3 can pull the genesis block and join the channel. If Org3 had not
been successfully appended to the channel config, the ordering service would
reject this request.
@@ -447,7 +456,7 @@ Use the ``peer channel fetch`` command to retrieve this block:
.. code:: bash
- peer channel fetch 0 channel-artifacts/channel1.block -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c channel1 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ peer channel fetch 0 channel-artifacts/channel1.block -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c channel1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"
Notice, that we are passing a ``0`` to indicate that we want the first block on
the channel's ledger; the genesis block. If we simply passed the
@@ -464,6 +473,16 @@ peer to the channel:
peer channel join -b channel-artifacts/channel1.block
+To join by a snapshot, follow the instruction in `Taking a snapshot <peer_ledger_snapshot.html#taking-a-snapshot>`__
+to take a snapshot on an existing peer. The snapshot should be taken after Org3 has been added to ``channel1``
+to ensure that the snapshot contains the updated channel configuration including Org3.
+Locate the snapshot directory, copy it to the filesystem of the new Org3 peer, and issue the
+``peer channel joinbysnapshot`` command using the path to the snapshot on your file system.
+
+.. code:: bash
+
+ peer channel joinbysnapshot --snapshotpath <path to snapshot>
+
Configuring Leader Election
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -542,7 +561,7 @@ on the ledger. The commands below assume that we are still using the channel
``channel1``.
After the chaincode has been to deployed we can use the following steps to use
-invoke Basic chaincode as Org3. Copy and paste the following environment
+invoke Basic chaincode as Org3. Copy and paste the following environment
variables in your terminal in order to interact with the network as the Org3
admin:
@@ -605,8 +624,8 @@ for Org3:
.. code:: bash
# use the --package-id flag to provide the package identifier
- # use the --init-required flag to request the ``Init`` function be invoked to initialize the chaincode
- peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID channel1 --name basic --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1
+ # use the --init-required flag to require the execution of an initialization function before other chaincode functions can be called.
+ peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" --channelID channel1 --name basic --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1
You can use the ``peer lifecycle chaincode querycommitted`` command to check if
@@ -616,7 +635,7 @@ channel.
.. code:: bash
# use the --name flag to select the chaincode whose definition you want to query
- peer lifecycle chaincode querycommitted --channelID channel1 --name basic --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ peer lifecycle chaincode querycommitted --channelID channel1 --name basic --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"
A successful command will return information about the committed definition:
@@ -638,7 +657,7 @@ and the new Org3 peer so that the endorsement policy is satisfied.
.. code:: bash
- peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C channel1 -n basic --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt --peerAddresses localhost:11051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org3.example.com/peers/peer0.org3.example.com/tls/ca.crt -c '{"function":"InitLedger","Args":[]}'
+ peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" -C channel1 -n basic --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt" --peerAddresses localhost:11051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org3.example.com/peers/peer0.org3.example.com/tls/ca.crt" -c '{"function":"InitLedger","Args":[]}'
You can query the chaincode to ensure that the Org3 peer committed the data.
@@ -678,14 +697,15 @@ Fetch the most recent config block for the channel, using the ``peer channel fet
.. code:: bash
- peer channel fetch config channel-artifacts/config_block.pb -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c channel1 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ peer channel fetch config channel-artifacts/config_block.pb -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c channel1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"
After fetching the config block we will want to convert it into JSON format. To do
this we will use the configtxlator tool, as done previously when adding Org3 to the
channel. First, change into the ``channel-artifacts`` folder:
.. code:: bash
- cd channel-artifacts
+
+ cd channel-artifacts
When converting it we need to remove all the headers, metadata, and signatures
that are not required to update Org3 to include an anchor peer by using the ``jq``
@@ -695,7 +715,7 @@ channel configuration.
.. code:: bash
configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
- jq .data.data[0].payload.data.config config_block.json > config.json
+ jq ".data.data[0].payload.data.config" config_block.json > config.json
The ``config.json`` is the now trimmed JSON representing the latest channel configuration
that we will update.
@@ -758,7 +778,8 @@ Now that the update has been properly formatted it is time to sign off and submi
Navigate back to the ``test-network`` directory:
.. code:: bash
- cd ..
+
+ cd ..
Since this is only an update to Org3 we only need to have Org3 sign off on the update. Run the following
@@ -778,7 +799,7 @@ Org3 admin before submitting it to the orderer.
.. code:: bash
- peer channel update -f channel-artifacts/anchor_update_in_envelope.pb -c channel1 -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ peer channel update -f channel-artifacts/anchor_update_in_envelope.pb -c channel1 -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"
The orderer receives the config update request and cuts a block with the updated configuration.
As peers receive the block, they will process the configuration updates.