prefacio
Un complemento del capítulo anterior: ¿Qué pasa si no quiero probar la estructura en el entorno raíz?
De hecho, solo necesita usar la cuenta raíz al crear e iniciar la ventana acoplable. Por supuesto, debido a que algunos archivos se crearán cuando esté activo, estos archivos deben delegarse. Primero, transfiera los archivos a los usuarios normales, o, de chown
lo chmod -R 775
contrario , las operaciones de seguimiento de usuarios no root tendrán permiso denegado.
Además, el capítulo anterior se refiere principalmente al ejemplo oficial de Hyperledger para intentar poner en marcha la red. Aquí investigué un poco e intenté operar entre pares y canales a través de la API de NodeJS y el cliente de tela, pero al final lo encontré muy inconveniente. Incluso si uso esta API, todavía necesito usar los comandos oficiales debajo del contenedor, como Necesita usar cryptogen para crear un archivo de configuración de clave de nodo. Entonces, después de una consideración exhaustiva, decidí entregar la implementación de la red y la construcción del entorno al shell. Solo el contrato en sí y la lógica para operar el contrato se desarrollan usando mecanografiado o javascript a través de nodejs.
pasos generales
Echemos un vistazo a los pasos necesarios desde el inicio de la ventana acoplable hasta la implementación del contrato en una red Fabric regular:
comenzar
Crear organización y orden
Utilice cryptogen o ca para crear organizaciones. Si usa cryptogen es como sigue:
Cree una organización primero, el nodo de organización
se usa aquí crypto-config-orgX.yaml
para crear un archivo de organización, yaml, vaya a la muestra oficial para encontrar la plantilla de archivo
int=1
cryptogen generate --config=./organizations/cryptogen/crypto-config-org$int.yaml --output="organizations"
Esto puede ser flexible, int puede ser cualquier número entero, usado para representar organizaciones 1, 2, 3, 4... puede crear innumerables organizaciones
Crear un nodo de orden
cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output="organizations"
El nodo de organización y el nodo de orden tienen diferentes responsabilidades
- El ordenador se denomina nodo de clasificación, un nodo de red que proporciona servicios de consenso, por ejemplo, utilizando Kafka o PBFT.
- El par mantiene el nodo de red del libro mayor y, por lo general, actúa como un respaldo o una función de contabilidad en Hyperledger Fabric.
- Además, hay un comitter, que verifica la legalidad de la transacción y finalmente envía la transacción a la cadena de bloques.
nodo de inicio
docker-compose docker-compose-test-net.yaml up -d
La configuración y el inicio de Docker deben ser manejados por usted mismo. Aquí hay una referencia de plantilla de docker-compose. fabric-sample/test-network/docker
Hay archivos de configuración más detallados bajo el oficial
version: '2.4'
volumes:
orderer.example.com:
peer0.org1.example.com:
networks:
test:
name: fabric_test
services:
orderer.example.com:
container_name: orderer.example.com
image: hyperledger/fabric-orderer:latest
labels:
service: hyperledger-fabric
environment:
- FABRIC_LOGGING_SPEC=INFO
- ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
- ORDERER_GENERAL_LISTENPORT=7050
- ORDERER_GENERAL_LOCALMSPID=OrdererMSP
- ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp
# enabled TLS
- ORDERER_GENERAL_TLS_ENABLED=true
- ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
- ORDERER_KAFKA_TOPIC_REPLICATIONFACTOR=1
- ORDERER_KAFKA_VERBOSE=true
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
- ORDERER_GENERAL_BOOTSTRAPMETHOD=none
- ORDERER_CHANNELPARTICIPATION_ENABLED=true
- ORDERER_ADMIN_TLS_ENABLED=true
- ORDERER_ADMIN_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_ADMIN_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_ADMIN_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
- ORDERER_ADMIN_TLS_CLIENTROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
- ORDERER_ADMIN_LISTENADDRESS=0.0.0.0:16050
- ORDERER_OPERATIONS_LISTENADDRESS=0.0.0.0:17050
working_dir: /opt/gopath/src/github.com/hyperledger/fabric
command: orderer
volumes:
- ../system-genesis-block/genesis.block:/var/hyperledger/orderer/orderer.genesis.block
- ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp:/var/hyperledger/orderer/msp
- ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/:/var/hyperledger/orderer/tls
- orderer.example.com:/var/hyperledger/production/orderer
ports:
- 7050:7050
- 16050:16050
- 17050:17050
networks:
- test
peer0.org1.example.com:
container_name: peer0.org1.example.com
image: hyperledger/fabric-peer:latest
labels:
service: hyperledger-fabric
environment:
#Generic peer variables
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=fabric_test
- FABRIC_LOGGING_SPEC=INFO
#- FABRIC_LOGGING_SPEC=DEBUG
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_PROFILE_ENABLED=false
- CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
- CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
- CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
# Peer specific variables
- CORE_PEER_ID=peer0.org1.example.com
- CORE_PEER_ADDRESS=peer0.org1.example.com:7051
- CORE_PEER_LISTENADDRESS=0.0.0.0:7051
- CORE_PEER_CHAINCODEADDRESS=peer0.org1.example.com:7052
- CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052
- CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051
- CORE_PEER_LOCALMSPID=Org1MSP
- CORE_OPERATIONS_LISTENADDRESS=0.0.0.0:17051
volumes:
- ${
DOCKER_SOCK}:/host/var/run/docker.sock
- ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp
- ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls
- peer0.org1.example.com:/var/hyperledger/production
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
command: peer node start
ports:
- 7051:7051
- 17051:17051
networks:
- test
Tenga en cuenta aquí que el archivo cifrado de la organización que acaba cryptogen
de crear se asigna a los volúmenes de cada nodo por docker, que es el archivo de identidad de cada nodo. Aquí hay dos ejemplos, uno es order y el otro es org.
Crear canales
Para crear un canal, primero cree el bloque de génesis del canal. De hecho, un canal del tejido es una cadena. Sin embargo, sigo sintiendo que este paso es demasiado engorroso ¿Puede IBM proporcionar la función de crear automáticamente el bloque de creación?
Muy bien, vamos a crear el bloque de génesis:
CHANNEL_NAME=mychannel
configtxgen -profile ApplicationGenesis -outputBlock ./channel-artifacts/${CHANNEL_NAME}.block -channelID $CHANNEL_NAME
Luego, vamos a crear el canal:
export ORDERER_CA=${
PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
export ORDERER_ADMIN_TLS_SIGN_CERT=${
PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
export ORDERER_ADMIN_TLS_PRIVATE_KEY=${
PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.key
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/${CHANNEL_NAME}.block -o localhost:16050 --ca-file "$ORDERER_CA" --client-cert "$ORDERER_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER_ADMIN_TLS_PRIVATE_KEY"
Crear un canal es en realidad agregar primero el nodo de pedido al canal, de acuerdo con el bloque de creación de canales que se acaba de crear. Este paso es más interesante. ¿Por qué se agrega primero el orden al canal y por qué se usa el comando osnadmin
? El funcionario no encontró una explicación razonable, así que lo dejamos de lado por ahora.
únete al canal
ORG=1
export CORE_PEER_LOCALMSPID="Org${ORG}MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${
PWD}/organizations/peerOrganizations/org${ORG}.example.com/peers/peer0.org${ORG}.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${
PWD}/organizations/peerOrganizations/org${ORG}.example.com/users/Admin@org${ORG}.example.com/msp
P0PORT=`expr 7049 + $ORG \* 2`
export CORE_PEER_ADDRESS=localhost:$P0PORT
BLOCKFILE="./channel-artifacts/${CHANNEL_NAME}.block"
peer channel join -b $BLOCKFILE
El shell anterior es para agregar org1 al canal. Unirse es la última línea del script, pero antes de eso, debe configurar la variable de anillo para verificar la identidad del nodo, que en realidad está "firmando" para unirse.
establecer nodo de anclaje
Dado que los nodos en sí mismos no se comunican entre sí, para establecer otros nodos anclados al nodo, se usa oficialmente una función llamada setAnchorPeer para establecer el nodo de anclaje. No entraré en detalles aquí, y el código es relativamente largo. Por favor consulte el directorio de scripts de la muestra oficial setAnchorPeer.sh
.
Personalmente, creo que este paso es muy engorroso. ¿Por qué necesita configurar manualmente el nodo de anclaje después de configurar el canal? ¿El canal no puede proporcionar una forma para que cada nodo se comunique? No entiendo muy bien el funcionamiento de hyperledg.
Lo anterior es la red fabric mínima construida, y el próximo capítulo hablará sobre el contrato de implementación.