diff --git a/test-network-k8s/chaincode/asset-transfer-basic-debug/metadata.json b/test-network-k8s/chaincode/asset-transfer-basic-debug/metadata.json index bb7056c0..ce13665f 100644 --- a/test-network-k8s/chaincode/asset-transfer-basic-debug/metadata.json +++ b/test-network-k8s/chaincode/asset-transfer-basic-debug/metadata.json @@ -1,4 +1,4 @@ { - "type": "external", + "type": "ccaas", "label": "basic_1.0" } \ No newline at end of file diff --git a/test-network-k8s/config/org0/fabric-ca-server-config.yaml b/test-network-k8s/config/org0/fabric-ca-server-config.yaml index d2c5fd9b..b73d96af 100644 --- a/test-network-k8s/config/org0/fabric-ca-server-config.yaml +++ b/test-network-k8s/config/org0/fabric-ca-server-config.yaml @@ -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 diff --git a/test-network-k8s/config/org1/fabric-ca-server-config.yaml b/test-network-k8s/config/org1/fabric-ca-server-config.yaml index ccce6f91..e14943b9 100644 --- a/test-network-k8s/config/org1/fabric-ca-server-config.yaml +++ b/test-network-k8s/config/org1/fabric-ca-server-config.yaml @@ -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 diff --git a/test-network-k8s/config/org2/fabric-ca-server-config.yaml b/test-network-k8s/config/org2/fabric-ca-server-config.yaml index 992315f0..5d18e4a5 100644 --- a/test-network-k8s/config/org2/fabric-ca-server-config.yaml +++ b/test-network-k8s/config/org2/fabric-ca-server-config.yaml @@ -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 diff --git a/test-network-k8s/docs/CHAINCODE.md b/test-network-k8s/docs/CHAINCODE.md index e967d882..5047f3d6 100644 --- a/test-network-k8s/docs/CHAINCODE.md +++ b/test-network-k8s/docs/CHAINCODE.md @@ -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) ``` diff --git a/test-network-k8s/docs/CHANNELS.md b/test-network-k8s/docs/CHANNELS.md index cfc23980..768e6ae4 100644 --- a/test-network-k8s/docs/CHANNELS.md +++ b/test-network-k8s/docs/CHANNELS.md @@ -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. diff --git a/test-network-k8s/docs/KUBERNETES.md b/test-network-k8s/docs/KUBERNETES.md index ce5f8035..e30db248 100644 --- a/test-network-k8s/docs/KUBERNETES.md +++ b/test-network-k8s/docs/KUBERNETES.md @@ -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. diff --git a/test-network-k8s/docs/README.md b/test-network-k8s/docs/README.md index 8a146f0e..8c3abd17 100644 --- a/test-network-k8s/docs/README.md +++ b/test-network-k8s/docs/README.md @@ -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) diff --git a/test-network-k8s/docs/TEST_NETWORK.md b/test-network-k8s/docs/TEST_NETWORK.md index ef64cee1..3eb4a207 100644 --- a/test-network-k8s/docs/TEST_NETWORK.md +++ b/test-network-k8s/docs/TEST_NETWORK.md @@ -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