test-network-k8s: Some minor improvements (#718)

This patch includes some minor improvements, such as:
- Fix typos and broken links
- Correct chaincode type of asset-transfer-basic-debug
  (seems it should be ccaas)

Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>
This commit is contained in:
Tatsuya Sato 2022-04-19 20:29:52 +09:00 committed by GitHub
parent c4886eda11
commit 5f88d951cf
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
9 changed files with 27 additions and 31 deletions

View file

@ -1,4 +1,4 @@
{
"type": "external",
"type": "ccaas",
"label": "basic_1.0"
}

View file

@ -31,7 +31,7 @@
# For example, see "tls.certfile" and "tls.clientauth.certfiles".
# The value of each of these fields can be a simple filename, a
# relative path, or an absolute path. If the value is not an
# absolute path, it is interpretted as being relative to the location
# absolute path, it is interpreted as being relative to the location
# of this configuration file.
#
#############################################################################
@ -341,7 +341,7 @@ idemix:
rhpoolsize: 1000
# The Idemix credential issuance is a two step process. First step is to get a nonce from the issuer
# and second step is send credential request that is constructed using the nonce to the isuser to
# and second step is send credential request that is constructed using the nonce to the issuer to
# request a credential. This configuration property specifies expiration for the nonces. By default is
# nonces expire after 15 seconds. The value is expressed in the time.Duration format (see https://golang.org/pkg/time/#ParseDuration).
nonceexpiration: 15s
@ -498,9 +498,9 @@ metrics:
# statsd server address
address: 127.0.0.1:8125
# the interval at which locally cached counters and gauges are pushsed
# the interval at which locally cached counters and gauges are pushed
# to statsd; timings are pushed immediately
writeInterval: 10s
# prefix is prepended to all emitted statsd merics
# prefix is prepended to all emitted statsd metrics
prefix: server

View file

@ -31,7 +31,7 @@
# For example, see "tls.certfile" and "tls.clientauth.certfiles".
# The value of each of these fields can be a simple filename, a
# relative path, or an absolute path. If the value is not an
# absolute path, it is interpretted as being relative to the location
# absolute path, it is interpreted as being relative to the location
# of this configuration file.
#
#############################################################################
@ -341,7 +341,7 @@ idemix:
rhpoolsize: 1000
# The Idemix credential issuance is a two step process. First step is to get a nonce from the issuer
# and second step is send credential request that is constructed using the nonce to the isuser to
# and second step is send credential request that is constructed using the nonce to the issuer to
# request a credential. This configuration property specifies expiration for the nonces. By default is
# nonces expire after 15 seconds. The value is expressed in the time.Duration format (see https://golang.org/pkg/time/#ParseDuration).
nonceexpiration: 15s
@ -498,9 +498,9 @@ metrics:
# statsd server address
address: 127.0.0.1:8125
# the interval at which locally cached counters and gauges are pushsed
# the interval at which locally cached counters and gauges are pushed
# to statsd; timings are pushed immediately
writeInterval: 10s
# prefix is prepended to all emitted statsd merics
# prefix is prepended to all emitted statsd metrics
prefix: server

View file

@ -31,7 +31,7 @@
# For example, see "tls.certfile" and "tls.clientauth.certfiles".
# The value of each of these fields can be a simple filename, a
# relative path, or an absolute path. If the value is not an
# absolute path, it is interpretted as being relative to the location
# absolute path, it is interpreted as being relative to the location
# of this configuration file.
#
#############################################################################
@ -341,7 +341,7 @@ idemix:
rhpoolsize: 1000
# The Idemix credential issuance is a two step process. First step is to get a nonce from the issuer
# and second step is send credential request that is constructed using the nonce to the isuser to
# and second step is send credential request that is constructed using the nonce to the issuer to
# request a credential. This configuration property specifies expiration for the nonces. By default is
# nonces expire after 15 seconds. The value is expressed in the time.Duration format (see https://golang.org/pkg/time/#ParseDuration).
nonceexpiration: 15s
@ -498,9 +498,9 @@ metrics:
# statsd server address
address: 127.0.0.1:8125
# the interval at which locally cached counters and gauges are pushsed
# the interval at which locally cached counters and gauges are pushed
# to statsd; timings are pushed immediately
writeInterval: 10s
# prefix is prepended to all emitted statsd merics
# prefix is prepended to all emitted statsd metrics
prefix: server

View file

@ -31,8 +31,8 @@ $ ./network chaincode query '{"Args":["ReadAsset","1"]}' | jq
## Running Smart Contracts on Kubernetes
In the Kubernetes Test Network, smart contracts are developed with the [Chaincode as a Service](link)
pattern, relying on an embedded [External Builder](link) to avoid the use of a Docker daemon. With
In the Kubernetes Test Network, smart contracts are developed with the [Chaincode as a Service](https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html)
pattern, relying on an embedded [External Builder](https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html) to avoid the use of a Docker daemon. With
Chaincode-as-a-Service, smart contracts are deployed to Kubernetes as `Services`,
`Deployments`, and `Pods`. When invoking smart contracts, the Peer network connects to the grpc receiver
through the port exposed by the chaincode's Kube `Service` as described in the chaincode
@ -70,34 +70,30 @@ launched in the cluster and the chaincode metadata:
To deploy the chaincode, the network script will:
1. Read the `connection.json` and `metadata.json` files from the `/chaincode/${TEST_NETWORK_CHAINCODE_NAME`
1. Read the `connection.json` and `metadata.json` files from the `/chaincode/${TEST_NETWORK_CHAINCODE_NAME}`
folder, bundling the files into a chaincode tar.gz archive.
2. `kubectl cp` the chaincode archive from the local file system to the organization's persistent volume storage.
3. Install the chaincode archive on a peer in the organization:
2. Install the chaincode archive on a peer in the organization:
```shell
export CORE_PEER_ADDRESS='${org}'-peer1:7051
peer lifecycle chaincode install chaincode/asset-transfer-basic.tgz
```
4. In typical Fabric operations, the output of the `chaincode install` command includes a generated ID of the
3. In typical Fabric operations, the output of the `chaincode install` command includes a generated ID of the
chaincode archive printed to standard out. This ID is manually inspected and transcribed by the
network operator when executing subsequent commands with the network peers. To avoid scraping the
output of the installation command, the test network scripts precompute the chaincode ID
as the `sha256` checksum of the tar.gz archive.
5. The chaincode docker [image is launched](../kube/org1/org1-cc-asset-transfer-basic.yaml) as a Kubernetes
4. The chaincode docker [image is launched using the yaml template](../kube/org1/org1-cc-template.yaml) as a Kubernetes
`Deployment` specifying _CHAINCODE_ID=sha-256(archive)_ in the environment and binding a `Service` port 9999
within the namespace. When the network sends messages to the chaincode process, it will use the host URL as
defined in the `connection.json`, connecting to the kubernetes `Service` URL and `Deployment`.
6. Finally, the Admin CLI issues a series of peer commands to approve and commit the chaincode for the org:
5. Finally, the Admin CLI issues a series of peer commands to approve and commit the chaincode for the org:
```shell
export CORE_PEER_ADDRESS='${org}'-peer1:7051
@ -178,7 +174,7 @@ information to the stdout of this process, bundling into a Docker image, and pus
image to the local development container registry.
1. Add some print statements to assetTransfer.go. E.g.:
```java
```go
fmt.Printf("reading asset %s\n", id)
```

View file

@ -141,7 +141,7 @@ When updating anchor peers, the `./network` script will:
1. Transfer the shell scripts from `/scripts/*.sh` into the remote organization's persistent volume.
2. Issue a `kubectl exec -c "script-name.sh {args}"` on the org's admin CLI pod.
For non-trivial Fabric administative tasks, this approach of uploading a script into the cluster and then
For non-trivial Fabric administrative tasks, this approach of uploading a script into the cluster and then
executing in an admin pod works well.

View file

@ -82,7 +82,7 @@ In k8s terms:
- Blockchain services (nodes, orderers, chaincode, etc.) reside within a single `Namespace`.
- Each organization maintains a distinct, independent `PersistentVolumeClaim` for TLS certificates,
local MSP, private data, and transaction ledgers.
- Smart Contracts rely exclusively on the [Chaincode-as-a-Service](link) and [External Builder](link)
- Smart Contracts rely exclusively on the [Chaincode-as-a-Service](https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html) and [External Builder](https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html)
patterns, running in the cluster as Kube `Deployments` with companion `Services`.
- An HTTP(s) `Ingress` and companion gateway application is required for external access to the blockchain.

View file

@ -37,8 +37,8 @@ _Chaincode-as-a-Service_ running in a shared Kubernetes namespace.
- [Deploy the ECert CAs](CA.md#deploy-the-organization-ca)
- [Launching the Test Network](TEST_NETWORK.md)
- [Registering and Enrolling Identities](CA.md#registering-and-enrolling-identities)
- [Assembling Node MSPs](link)
- [Deploy Orderers and Peers](link)
- [Assembling Node MSPs](TEST_NETWORK.md#fabric-node-msp-context)
- [Deploy Orderers and Peers](TEST_NETWORK.md#starting-peers-and-orderers)
- [Working with Channels](CHANNELS.md)
- [Working with Chaincode](CHAINCODE.md)
- [Working with Applications](APPLICATIONS.md)

View file

@ -130,7 +130,7 @@ To trigger the external builder for a chaincode service, set the metadata.json `
Once the local MSP structures for the network nodes have been created, the orderers and peers may be launched in the
namespace. System nodes will read base configuration files (orderer.yaml and core.yaml) from the organization
config folder, made available in Kubernetes as the `fabric-config${org}` config map.
config folder, made available in Kubernetes as the `${org}-config` config map.
Each orderer and peer creates one `Deployment`, `Pod`, and `Service` in the namespace. In addition, each org
defines an `orgN-peerM-config` `ConfigMap` with environment variable overrides replacing the default settings
@ -148,7 +148,7 @@ export FABRIC_VERSION=2.4.2
cat kube/org0/org0-orderer1.yaml | envsubst | kubectl -n $NS -f -
cat kube/org0/org0-orderer2.yaml | envsubst | kubectl -n $NS -f -
cat kube/org0/org0-orderer3.yaml | envsubts | kubectl -n $NS -f -
cat kube/org0/org0-orderer3.yaml | envsubst | kubectl -n $NS -f -
# Wait for the orderers to completely start before launching the network peer nodes.
kubectl -n $NS rollout status deploy/org0-orderer1