Kubernetes deployment of Super Ledger fabric block chain is the service (2)

Pictured in San Francisco Pier 7:coit Tower

The last time we introduced the Kubernetes deployment Fabric (clickable) of the overall architecture and network, storage planning, this issue is serialized second, detailing the deployment tool design details, including template customization and configuration settings. A PDF version of this method is attached.

3. Description and use of the source code

3.1 Environment Preparation

Assume that the K8s platform has been successfully deployed and that the corresponding Fabric v1.0.0 docker mirrors have been downloaded beforehand at each worker node, as shown in table 3-1. (Pre-download mirror is due to the slow speed of the domestic network, after a machine in advance download, you can use the Docker command to export and import other machines.) ）

IMAGE	TAG	Id
Hyperledger/fabric-tools	x86_64-1.0.0	0403fd1c72c7
Hyperledger/fabric-orderer	x86_64-1.0.0	E317ca5638ba
Hyperledger/fabric-peer	x86_64-1.0.0	6830dcd7b9b5
Hyperledger/fabric-ccenv	x86_64-1.0.0	7182c260a5ca
Hyperledger/fabric-ca	x86_64-1.0.0	a15c59ecda5b
Hyperledger/fabric-baseimage	x86_64-0.3.1	9f2e9ec7c527
Hyperledger/fabric-baseos	x86_64-0.3.1	4b0cab202084

Table 3-1

This article covers the directory structure of the Code and its role as follows:

Fabric-on-k8s

-Readme.md

-Setupcluster

-GENERATEALL.SH//responsible for generating k8s deployment files

-Transform//For launching deployment files

-Templates//Storage template

-CLUSTER-CONFIG.YAML//for configuring fabric clusters

-Configtx.yaml//For configuration channel

3.2 Configuration file Description

When planning fabric cluster deployment, edit the following two fabric cluster definition files as needed:

A. Cluster-config.yaml

The Cryptogen tool generates certificates for Fabric members based on the Cluster-config.yaml, a simple example of the following:

Ordererorgs:

-Name:orderer

Domain:orgorderer1

Template:

count:1

 

Peerorgs:

-Name:org1

Domain:org1

Template:

Count:2

 

-Name:org2

domain:org2

Template:

Count:2

Where the Ordererorgs and Peerorgs keywords differentiate between organization types, the internal structure of the two organizations is as follows:

1) Ordererorgs defines an org whose name is orderer, the domain name is orgorderer1, and it specifies that the value of count in template is 1, then there is only one orderer under that org, and I D is Orderer0.

2 The Peerorgs defines two org, ORG1 and Org2, the corresponding domain name is ORG1, ORG2 is similar to orderer, and each org generates two peers, although ORG1 and org The ID of the PEER0 in 2 repeats, but he does not belong to the same org, and it's easy to tell by domain name.

It should be noted that because the namespace in k8s does not support '. ' and uppercase letters, so the domain names of each organization cannot contain these characters.

For more information on how to configure Cluster-config.yaml, please refer to the Cryptogen description in the Fabric source code (FABRIC/COMMON/TOOLS/CRYPTOGEN/MAIN.GO)

As defined above, the Cryptogen tool generates the Crypto-config directory, which is structured as follows: Cluster-config.yaml

Crypto-config

---ordererorganizations

---orgorderer1

---MSP

---CA

---Tlsca

---users

---orderers

---orderer0.orgorderer1

---MSP

---TLS

---peerorganizations

---org1

---MSP

---CA

---Tlsca

---users

---peers

---peer0.org1

---MSP

---TLS

---peer1.org1

---MSP

---TLS

---org2

---MSP

---CA

---Tlsca

---users

---peers

---peer0.org2

---MSP

---TLS

---peer1.org2

---MSP

---TLS

As you can see, each org contains the MSP, CA, Tlsca, and users directories, and then, depending on the org type, there are peers and orderers directories that contain the MSP and TLS files for each member of Org.

B. Configtx.yaml

The Configtxgen tool uses the Genesis.block to generate Orderer initialization when the file is generated, knowing the various information about organization, and therefore the user is based on the Cluster-config.yaml Organization is defined to modify Configtx.yaml to generate the appropriate genesis.block. For example, if a user adds a Org3 to the Cluster-config.yaml and wants to create a cluster that contains ORG1, ORG2, and ORG3, you should modify the Configtx.yaml in the following two steps:

1. Add Org3 to profile, as shown in Figure 3-1.

Figure 3-1

2. Increase the mspdir of ORG3 in organization, as shown in Figure 3-2:

Figure 3-2

Note that the value of the Mspdir in each organization must be this form:

Crypto-config/{orgtype}/{orgname}/mps

3.3 Template Files

When you deploy Fabric in kubernetes, you need to write the appropriate configuration file for each node. Because the number of nodes may be many, this is a complex and error-prone repetitive work. To improve efficiency, you can automatically generate profiles from templates. This article uses 5 template files, which can be replaced with a script, in the templates directory that the author gives to the sample code, which functions as follows:

A. Fabric_1_0_tmeplate_namespace.yaml

Defines the namespace of the fabric cluster in k8s, which corresponds to the organization domain name. NFS servers are used as storage for files such as multiple-node sharing certificates. Through the corresponding PV and PVC in the k8s, the Pod under namespace can obtain the corresponding file through the PVC.

B. Fabric_1_0_template_cli.yaml

The CLI pod template, each organization with a CLI pod, is designed to provide a command-line interface to unify all peer within the organization, including channel creation, Chaincode installation, and so on. The default value of the CORE_PEER_ADDRESS environment variable for the CLI Pod is the first PEER in Org, which can be connected to different PEER by modifying the environment variable.

The command in the Yaml file is to prevent the CLI pod from automatically exiting, and the default working directory for the CLI is/opt/gopath/src/github.com/hyperledger/fabric/peer. Because the channel-artifacts in this directory is mounted on NFS/opt/share/channel-artifacts, the Xxx.block file returned when the channel was created is placed in the directory for all CLI pod shares.

c. Fabric_1_0_template_ca.yaml

The pod-defined template for Fabric's CA services is used for certificate management in organization, and its YAML file defines a service in addition to deployment. The service is bound to the deployment through selector, where the label in deployment is the basis of the selector and its binding.

d. Fabcric_1_0_template_orderer.yaml

Orderer pod definition template, it should be noted that Cryptogen does not generate Genesis.block, however, when the file is missing, Orderer will fail to start, so you need to generate orderer before starting Genesis.block, and place it in the appropriate org directory.