You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Nginx Ingress can be replaced with any other K8S ingress that supports ```SNI based routing```. The ingress service should be exposed by two ```Nodeports for Ports: 80/TCP, 443/TCP```. Eg; NodePort 30000 => 443/TCP (Ingress service).
14
+
* Nginx Ingress OR any other K8S ingress that supports ```SNI based routing```. The ingress service should be exposed by two ```Nodeports for Ports: 80/TCP, 443/TCP```. Eg; NodePort 30000 => 443/TCP (Ingress service).
15
15
*```--enable-ssl-passthrough``` Should be enabled on the Nginx Ingress pod. All of the Hyperledger Fabric related TLS requests should be terminated on the Pod level as long as we're keeping the certs in the POD itself. If Nginx, then a similar ssl passthrough annotation ```"nginx.ingress.kubernetes.io/ssl-passthrough: "true"``` must be added to all the HLF Ingress resources we create. This annotation can be handled from the values file for every helm chart. In case if you're not using Nginx Ingress, kindly add the proper annotations accordingly.
16
-
*```Configurable DNS```. You should have the ability to add custom DNS zones that are resolvable from the pods. If you're using CoreDNS, follow this guide to add custom zones on your Kubernetes cluster https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/. If deploying to GKE, you can make use of CloudDNS private zones.
17
-
* Once added the zone, then you need to add A record(s) point to the server(s) where the Ingress is listening. It must be a wildcard DNS entry.
16
+
*```Configurable DNS```. You should have the ability to add custom DNS zones that are resolvable from the pods. If you're using CoreDNS, follow this guide to add custom zones on your Kubernetes cluster https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/. If deploying to GKE on GCP, you can make use of CloudDNS private zones.
17
+
* Once added the zone, then you need to add A record(s) that points to the server(s) where the Ingress is listening. It must be a wildcard DNS entry.
18
18
Eg, If your domain name is ```my-hlf-domain.com``` and you have 3 worker nodes ```10.10.10.10``````10.10.10.11``````10.10.10.12```. Then you need to create a DNS entry ```*.my-hlf-domain.com``` to point to above IPs. This is a must have configuration and make sure that wildcard DNS queries are resolving properly. If this fails, the deployment will fail. Kindly make sure this DNS is resolving and the tcp connections are reaching the ingress. You can verify it by simple telnet command.
19
19
```telnet anyname.my-hlf-domain.com 30000 ``` assuming that 30000 is the Nodeport on Nginx Ingress that maps to Ingress 443.
20
+
If you're in any public cloud platform, then hard coding the worker node IP in the DNS is not a reliable approach since the worker node can be changed at any time. In that case, you can deploy an Internal Cloud LB.
20
21
*```StorageClass``` that supports dynamic volume provisioning.
21
22
* We're using the docker hub upstream HyperLedger Fabric images for Fabric CA, Peers, Orderers and a custom builder tool which is hosted on NPCI docker hub registry. Make sure that your worker nodes can pull these images from docker hub. If not, upload them to your internal registry and the registry/repository can be managed over values.
22
23
23
24
24
25
25
26
##### Keep in mind the following things throughout this example deployment;
26
27
27
-
1. We'll be using the domain `my-hlf-domain.com`. If you have created a different domain as specified in the pre-req section, then update the `my-hlf-domain.com` to your domain name whereever there is a mention.
28
+
1. We'll be using the domain `my-hlf-domain.com`. If you have created a different domain as specified in the pre-req section, then update the `my-hlf-domain.com` to your domain name wherever there is a mention.
28
29
2. The Ingress classname is `nginx`. You need to change it to the appropriate value on your environment if you have a different one.
29
30
3. Nginx ingress services are exposed on `30000` and `30001` for `https` and `http` nodeports respectively.
30
31
4. StorageClass we use `standard-rwo`. Feel free to to change it to your storageclass.
@@ -58,16 +59,17 @@ Clone this repository and change your directory to the root directory. First you
58
59
59
60
2.**Deploy ROOT CA**
60
61
61
-
Create a kubernetes secret with ```user``` and ```password``` as keys for this ROOTCA server. We kept this secret out of the helm charts/values to get more security. All CA/ICA/TLSCA server username/password are handled in this way. Change the ```namespace``` & ```secret``` name if you need a different one and update the secret name at `ca_server.admin_secret`
62
+
Create a kubernetes secret with ```user``` and ```password``` as keys for this `ROOTCA` server. We kept this secret out of the helm charts/values to get more security. All CA/ICA/TLSCA server username/password are handled in this way. Change the ```namespace``` & ```secret``` name if you need a different one and update the secret name at `ca_server.admin_secret`
Apply the `fabric-ca` chart with our values file. If you change the ```tls_domain, docker images, secret & storageClass``` then update the [examples/fabric-ca/root-ca.yaml](./fabric-ca/root-ca.yaml) accordingly.
his will deploy the `root-ca` server for you and the server will be available at `https://root-ca.my-hlf-domain.com`. To verify the server, you can get into any running pod in the cluster and send a curl request as below;
72
+
This will deploy the `root-ca` server for you and the server will be available at `https://root-ca.my-hlf-domain.com`. To verify the server, you can get into any running pod in the cluster and send a curl request as below;
@@ -77,7 +79,7 @@ You will get the CA response like below.
77
79
78
80
3.**Deploy TLSCA**
79
81
80
-
Create an another kubernetes secret for your `TLSCA` server just like we did it for `ROOTCA` and update the secret name in the values file `examples/fabric-ca/tls-ca.yaml`. If you change the ```tls_domain, docker images, secret & storageClass``` then update the [examples/fabric-ca/root-ca.yaml](./fabric-ca/root-ca.yaml) accordingly.
82
+
Create an another kubernetes secret for your `TLSCA` server just like we did it for `ROOTCA` and update the secret name in the values file `examples/fabric-ca/tls-ca.yaml`. If you change the ```tls_domain, docker images, secret & storageClass``` then update the [examples/fabric-ca/tls-ca.yaml](./fabric-ca/tls-ca.yaml) accordingly.
@@ -94,29 +96,29 @@ You can verify it with the similar way we verified the root-ca end-point above.
94
96
```
95
97
6.**Deploy Orderer ICA**
96
98
97
-
You need to create an admin secret like we did for ROOTCA and update [examples/fabric-ca/ica-orderer.yaml](./fabric-ca/ica-orderer.yaml) with your secret. Or create the secret mentioned in this file if you do not want to change it. Once done, apply the following.
99
+
Here, we're deplyoing the same Fabric-ca charts for this CA but this will be in ICA mode. This time you need to create the kubernetes secret with the username and password that you registered at ROOTCA identities job. If you have changed that identities then, create the secret with those values and update the secret name here [examples/fabric-ca/ica-orderer.yaml](./fabric-ca/ica-orderer.yaml) with your secret. If you have not touched anything, then simply apply the following.
You need to create an admin secret like we did for ROOTCA and update [examples/fabric-ca/ica-initialpeerorg.yaml](./fabric-ca/ica-initialpeerorg.yaml) with your secret. Or create the secret mentioned in this file if you do not want to change it. Once done, apply the following.
105
+
Follow the same ICA Orderer deployment steps here and update [examples/fabric-ca/ica-initialpeerorg.yaml](./fabric-ca/ica-initialpeerorg.yaml) with your secret if you have created the secret with a different name. If you have not touched anything, then simply apply the following.
After successful completion of this `cryptogen Job`, you'll see the Genesisblock file and channel transaction file in your filestore under your project directory. If your project name is `yourproject`, then your project directory will be created as `/usr/share/nginx/html/yourproject`.
121
+
After successful completion of this `cryptogen Job`, you'll see the `Genesisblock` file and `Channel transaction` file in your filestore under your project directory. If your project name is `yourproject`, then your project directory will be created as `/usr/share/nginx/html/yourproject`.
120
122
121
123
11.**Deploy Orderers**
122
124
```
@@ -126,7 +128,7 @@ After successful completion of this `cryptogen Job`, you'll see the Genesisblock
After successful deployment of the Peers, you will get 3 peers in initialpeerorg namespace. Each of these peers will have 1 Init container and 3 app containers `(Fabric Peer, Dind & CouchDB)`. If everything went fine, then you'll see similar logs in the `peer0-initialpeerorg-0`.
131
+
After successful deployment of the Peers, you will get 3 peers in initialpeerorg namespace. Each of these peers will have 1 Init container and 3 app containers `(Fabric Peer, Dind & CouchDB)`. If everything went fine, then you'll see some successful connectivity logs in the `peer0-initialpeerorg-0`.
130
132
131
133
13.**Create channel**
132
134
```
@@ -152,7 +154,7 @@ If you have your own chaincode, then package it and upload the same to filestore
152
154
153
155
1.**Deploy Org1 ICA**
154
156
155
-
You need to create an admin secret like we did for ROOTCA and update [examples/fabric-ca/ica-org1.yaml](./fabric-ca/ica-org1.yaml)with your secret. Or create the secret mentioned in this file if you do not want to change it. Once done, apply the following.
157
+
You need to create a kubernetes secret with the one registered with rootca identities registration job and update [examples/fabric-ca/ica-org1.yaml](./fabric-ca/ica-org1.yaml)if you're creating a different secret name. Or create the secret mentioned in this file if you do not want to change it. Once done, apply the following.
@@ -183,17 +185,17 @@ Once the `Org1` ICA started successfully, you would need to add this `Org1` to t
183
185
184
186
1.**Deploy Org2 ICA**
185
187
186
-
You need to create an admin secret like we did for ROOTCA and update [examples/fabric-ca/ica-org2.yaml](./fabric-ca/ica-org2.yaml)with your secret. Or create the secret mentioned in this file if you do not want to change it. Once done, apply the following.
188
+
You need to create a kubernetes secret with the one registered with rootca identities registration job and update [examples/fabric-ca/ica-org2.yaml](./fabric-ca/ica-org2.yaml)if you're creating a different secret name. Or create the secret mentioned in this file if you do not want to change it. Once done, apply the following.
Once the `Org2` ICA started successfully, you would need to add this `Org2` to the network. For that, you need to upgrade the following `configorgchannel` Job in `initialpeerorg`. This time, uncomment the `org2` section in the `Values.organizatons` array in the values file [examples/fabric-ops/initialpeerorg/configure-org-channel.yaml](./fabric-ops/initialpeerorg/configure-org-channel.yaml).
Ensure that you have updated the Chaincode package ID in [examples/fabric-ops/initialpeerorg/approve-chaincode.yaml](./fabric-ops/initialpeerorg/approve-chaincode.yaml), below are the required fields for updating with your own chaincode details.
223
+
Ensure that you have updated the Chaincode package ID in [examples/fabric-ops/initialpeerorg/approve-chaincode.yaml](./fabric-ops/initialpeerorg/approve-chaincode.yaml), below are the required fields for updating with your own chaincode details. (This Chaincode package ID update is only required if you use your own chaincode package. If not, simply apply the following helm approval jobs)
Ensure that you have updated the Chaincode package ID in [examples/fabric-ops/org1/approve-chaincode.yaml](./fabric-ops/org1/approve-chaincode.yaml), below are the required fields for updating with your own chaincode details.
233
+
Ensure that you have updated the Chaincode package ID in [examples/fabric-ops/org1/approve-chaincode.yaml](./fabric-ops/org1/approve-chaincode.yaml), below are the required fields for updating with your own chaincode details. (This Chaincode package ID update is only required if you use your own chaincode package. If not, simply apply the following helm approval jobs)
Ensure that you have updated the Chaincode package ID in [examples/fabric-ops/org2/approve-chaincode.yaml](./fabric-ops/org2/approve-chaincode.yaml), below are the required fields for updating with your own chaincode details.
243
+
Ensure that you have updated the Chaincode package ID in [examples/fabric-ops/org2/approve-chaincode.yaml](./fabric-ops/org2/approve-chaincode.yaml), below are the required fields for updating with your own chaincode details. (This Chaincode package ID update is only required if you use your own chaincode package. If not, simply apply the following helm approval jobs)
Ensure that you have updated the Chaincode package ID in [examples/fabric-ops/initialpeerorg/approve-chaincode.yaml](./fabric-ops/initialpeerorg/approve-chaincode.yaml), below are the required fields for updating with your own chaincode details.
253
+
Ensure that you have updated the Chaincode package ID in [examples/fabric-ops/initialpeerorg/approve-chaincode.yaml](./fabric-ops/initialpeerorg/approve-chaincode.yaml), below are the required fields for updating with your own chaincode details. (This Chaincode package ID update is only required if you use your own chaincode package. If not, simply apply the following helm commit job)
0 commit comments