| Table of Contents |
|---|
Key Points
...
https://www.youtube.com/watch?v=UgZWMRiYXMQ
Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use Case Studies: https://www.hyperledger.org/learn/cas... Training & Certification: https://www.hyperledger.org/learn/tra... Tutorials: https://www.hyperledger.org/use/tutor... Webinars: https://www.hyperledger.org/learn/web... Events: https://www.hyperledger.org/events Vendor Directory: https://www.hyperledger.org/use/vendo... Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
...
Fabric Test Network on Kubernetes
For a production network(s) you will have a successful outcome with the combination of Kubernetes and fabric-operator.
The operator can also be supplemented by the fabric-operations-console for cases where you would prefer to administer the networks with a GUI, or automate deployment with Ansible or REST SDKs. For the CLI integration, fabric-operator works directly with the raw Kube APIs and fabric CLI binaries, and can be integrated with your CI/CD/automation infrastructure as necessary. Both the operator and console are designed to support the "remote management" of Fabric networks, in cases where you do not have access to the underlying infrastructure, but can establish network visibility to peers and orderers via gRPCs service URLs.
fabric-operator has been designed for easy integration with the new Gateway Client (> 2.4), Chaincode-as-a-Service (> 2.4.1), and the new fabric-builder-k8s, providing near instantaneous deployments of production images, and interactive step-level debugging in the IDE of your choice. In addition, operator provides some key certificate enrollment and renewal functions which will set your network off to a healthy start and long-term stability.
We have a sample-network available which will "just work" on a local development environment (KIND, Rancher/k3s, minikube), and extends naturally to kube clusters running in the wild at EKS, IKS, and hybrid cloud environments. The sample network uses a combination of kubectl / kustomization to apply a network, and some light shell scripting to illustrate the configuration of Fabric services using the native CLI binaries. In general, we've found the combination of KIND, operator, and Chaincode-as-a-Service to provide a development environment that is superior to the fabric-samples "test-network.sh", providing clear alignment with production operations.
Regarding the network setup, there are good opportunities to align some of the higher-order systems, such as Minifabric, BAF, Cello, K8s operators, and the like, into a community supported "really easy to use" and "really easy to live with" solutions that allow us to just write some chaincode...
Please feel free to reach out, either on the mailing list or Discord #fabric-kubernetes for additional guidance, feedback, and general banter.
Planning Considerations for Fabric Solution
...
Key engineering requirements based on trust engineering - what ledger data needs to be shared and when? why?
Fabric Consensus Method for Ordering Service
Chaincode transactions will be ordered according to the channel configuration setup for the ordering service, meaning there is no way of changing consensus on the fly.
Addressing the three ideas:
- Two orderer organizations in the same channel will share the same ordering rules, as they are part of the same ordering service.
- Not possible for the reasons I outlined above.
- You may have two channels that follow two different ordering protocols (Raft and BFT for v3.0.0-preview) as long as they are served by different orderers. The orderer runtime will run only one of the protocols after initial setup. That would also mean that your chaincode logic would be separate in two channels (two chaincodes) and that information would be registered in separate ledgers.
here are some of the network configuration decisions you need to make before deployment:
...
Adding Bevel-Operator-Fabric is an important milestone for Hyperledger Bevel and a step towards the redesign of Bevel with support for Kubernetes operators to achieve DLT (distributed ledger technology) network deployments and automation.
What is Bevel-Operator-Fabric
...
Operator runs on Kubernetes and tries to bring the current state to the desired state, a process called reconciliation. The kubectl-hlf plugin is used to create the custom resource and send the commands to the operator. It also provides an abstraction to create CRDs.
Users having the need to rapidly and consistently setup production ready DLT networks should consider Hyperledger Bevel, whereas users needing to deploy Hyperledger Fabric components quickly and have operator pattern in place should consider Bevel-Operator-Fabric.
Potential Value Opportunities
...
CA tutoriials work for SOLO, Kafka, NOT Raft
Here is some more background info and some update to this issue.
Background:
I started out this exercise by following the Fabric CA Operations tutorial (https://hyperledger-fabric-ca.readthedocs.io/en/latest/operations_guide.html) so it is a standard 4 CAs 2 Orgs setup. It worked with SOLO or KAFKA without any problem. The Orderer TLS setup is pretty standard too:
Update:
When the orderers first started with genesis block, it first complained that "certificate is valid for orderer[X]-org0, not orderer[Y]-org0". So I tried to put all 5 orderers hostname into csr hosts (which I know is probably not supposed to). It ended up with another complaint that "certificate presented by orderer[X]-org0:7050 doesn't match any authorized certificate" which I have no idea because it was saying that the certificate was valid in the first complaint.
Deploying System Chaincode Debug
...