Re: how core peer address works


jkneubuh@...
 

Hi Nikos,

Gateway applications can run either locally on the host OS or within the K8s as a container.  In development cycles you can build/edit/test your application locally (e.g. in a debugger) on the host OS, and then over time migrate your application to run within Kubernetes as a container.   Both cases are supported, and encouraged!  When running a gateway application "locally" you will need to either open a port forward to the target Gateway peer Service, or set up an Ingress to tunnel over the Nginx controller into the peers.  When running within Kubernetes, the application can reach the gateway peers via the Kube internal network. 

Depending on your preference both the port forward and Ingress routes work really well.  We haven't done a good job of documenting this, but our team frequently uses the *.vcap.me and *.<ip-address-with-dash>.nip.io DNS wildcard aliases to access the nginx ingress controller for access into the test network.   For instance, you can add the host alias "my-gateway-service.vcap.me" to the peer Certificate requests (see the SAN sections in the kube/../orgX-peerY.yaml), then set up a k8s Ingress to route traffic to the Gateway peer Service.   When you open a TCP connection from your host OS, you can open a connection to grpcs://my-gateway-service.vcap.me, which in turn resolves to 127.0.0.1 and routes through the Ingress.    This is too "fiddly" for inclusion in the CI test suite, so on that path we use a temporary port forward and accesse the gateways via a localhost URL. 

Once in production (or at least in a container), your application can be set up via Deployment and then reference the gateway service directly within Kubernetes.  E.g. grpcs://my-gateway-service. 

Regarding the shell scripting and administration, I agree that the preferred approach is to set up the network without any scripting.  For kube test network we tried to keep this as simple as possible, and map to the existing patterns based on the Docker Compose test network.  If you are looking for a more "production-ready" deployment for working with Fabric, it is highly recommended to use a software-based approach such as the Fabric Operations Console, Hyperledger Ansible Playbooks, Blockchain Automation Framework, IBM Hyperledger Support, etc. to reduce complexity for your network installation and administration tasks.

-josh

Join fabric@lists.hyperledger.org to automatically receive all group messages.