Add deployment steps for self-provisioned K8s via AWS and ECR

[arcolife]

Add scripts for deploying chaincode on a self-provisioned K8s cluster on AWS that uses ECR as container image registry.

Fixes #49

Open to suggestions for the ugly hack in tag name conversion.

PS: https://github.com/hyperledger-labs/fabric-operator/blob/main/docs/CONTRIBUTING.md is TODO.

[jkneubuh]

Hi @arcolife - thank you kindly for the PR!

This is a great PR and it's super to see some of the rough edges around working with EKS getting smoothed over. I am going to land this (maybe with a tweak here or there...) as is. But - please be aware that this area (chaincode and the sample network) is undergoing a little bit of change.

Most importantly, please see the new fabric-builder-k8s if you have not already had a chance for review. It is brilliant and makes a "mockery" out of all the parts that used to be hard when working with chaincode and Fabric. In the 08/24 community call we did a quick demo of the new builder - please watch the 20220824 Fabric contributor call, starting about 0:22:00 into the video for a deep dive.

Regarding the launch on EC2, the ./network scripts are really showing some age, and not in a good way. These bash scripts started off modeled after the fabric-samples test-network.sh, and evolved organically into the current state. Originally we had support for KIND clusters and some hack-ish yaml files to deploy a network directly. After fabric-operator, we're now able to deploy to the full gamut of k8s runtimes (kind, rancher, k3s, minikube, EKS, AKS, IKS, OCP, DO, etc...) but the ./network scripts really haven't kept up. Lots of ugly hacks are starting to multiply, as you saw above.

The next iteration of the operator sample-network is actually in the context of working in a "full stack" environment, combining local dev iterations with a Cloud-Native / production pipeline. If you are working around the area of spinning up Fabric networks, chaincode, etc. with EC2, please see the full-stack-asset-transfer-guide as it covers many of the use cases above in a natural format, including build; tag; publish; deploy iterations of chaincode with the kubernetes builder. The new recipes are very good, and we're promoting this lifecycle as THE lifecycle for working with chaincode on k8s, resorting to CCaaS only for cases where a user wants to launch a CC locally in a debugger, adjacent (or via reverse proxy) to a network peer running in k8s.

This is relevant to your PR above, as when working with type=k8s builder packages, the image pull policy for the chaincode must be associated with the service account running the peer. We had quite a few "heated discussions" around how image pull secrets would be communicated through the CC packages, and while I "lost" the argument, am actually quite happy to have settled on the outcome. Some additional background on this thread is over at PR #27 (closed) in the k8s-builder.

So near-term outcomes:

• I'd like to review, approve, and merge this PR.
• Please go through the full-stack-asset-transfer-guide, with a particular focus on the EC2 section, and then let's mull over the "right" way to wire all of this up and document cleanly.

Thanks - great PR!

[jkneubuh]

• notes on EC2 config in the "Full Stack" Cloud-Native Guide: https://github.com/hyperledgendary/full-stack-asset-transfer-guide/blob/main/docs/CloudReady/13-kube-public-cloud.md

• Tangentially related: Use k8s builder NOT CCaaS: Bundle the new "k8s chaincode builder" with fabric-operator #28