Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

https://www.hyperledger.org/blog/2023/04/27/introducing-kubernetes-operators-in-hyperledger-bevel-with-bevel-operator-fabric

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

Bevel-Operator-Fabric is the first of the different sets of Kubernetes operators that Hyperledger Bevel will ultimately support. As the name suggests, it is a Kubernetes operator for managing Hyperledger Fabric networks. Bevel-operator-fabric enables developers to define Hyperledger Fabric components in the form of custom resources and associated controllers to manage the lifecycle of those components. 

Bevel-operator-fabric has two components to it.

  1. Operator
  2. Kubectl-hlf plugin

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:



fabric-ca-client register -d --id.name orderer1-org0 --id.secret ordererPW --id.type orderer -u https://0.0.0.0:6052
fabric-ca-client enroll -d -u https://orderer1-org0:ordererPW@0.0.0.0:6052 --enrollment.profile tls --csr.hosts orderer1-org0
 

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

...

Thanks. 



Candidate Solutions



Hyperledger #Sessions:  Smart BFT dev & deploy w Bevel, Kubernetes 


If you miss any of these but want to see the recording, they'll all be posted to the Hyperledger YouTube channel at: https://www.youtube.com/Hyperledger


Hyperledger Certified Service Providers

...