...
- AWX is configured (see the AWX Setup and Configuration chapter)
- Access to AWX with the organization user
Configuration is done and available at a private git repository
Deploy Fabric Operator/Setup Environment Context
Run the following ansible jobs in the order below:
...
AWX Job Template
...
Notes
...
<env_id>-<org_id>-environment-setup
...
Installs the required software on the bastion host, and setups AWS CLI access.
...
- DNS entries are correct and maintained in Route53. The DNS node config ansible playbook expects to have an entry (hosted zone) in Route53. The hosted zone name should match the configured main_domain value in the node config file. The Name Servers should be correctly configured and maintained on the root domain level.
- The configured main domain DNS can be resolved on internet. The node communicates (using TLS) to other nodes on the network over internet.
Deploy Fabric Operator/Setup Environment Context
Run the following ansible jobs in the order below:
AWX Job Template | Notes |
---|---|
<env_id>-<org_id>-environment-setup | Installs the required software on the bastion host, and setups AWS CLI access. |
<env_id>-<org_id>-deploy-fabric-ingress | Deploy k8s ingress controller for the HLF k8s cluster |
<env_id>-<org_id>-dns-config-blk | After the ingress is deployed, DNS entries must be setup in order to route the traffic from the configured domain to the k8s cluster load balancers. Make sure the DNS entries are setup properly before proceeding with the configured domain in the configuration file |
<env_id>-<org_id>-deploy-vault | Deploy vault cluster in HLF k8s cluster. The access credential to the vault instance are stored in AWS secrets manager |
<env_id>-<org_id>-deploy-fabric-operator | Deploy fabric operator k8s controller |
<env_id>-<org_id>-deploy-fabric-console | Deploy operator console. The access to the console is at the address. Note that the address is not configurable as it is assembled by convention. The user and password to access the console are those defined in the credential “fabric-console“
|
...
Step | Details | Notes |
---|---|---|
Deploy Certificate Authority | Console → Nodes → Create new CAAdd Certificate Authority Create new CA
Associate (enroll) the CA admin identity registered above during the CA deployment
| |
Accosiate CA admin user identity | Console → Nodes → Endorsing Org CACertificate Authorities Navigate to the details page of the endorsing org CA create created above. Make sure the CA is up and running (green light). Associate (enroll) the CA admin identity registered above during the CA deployment
| |
Register the organization admin identity | Console → Nodes → Endorsing Org CACertificate Authorities Register the org admin user using the deployed CA above
| |
Create the MSP definition for the organization | Console → Organizations → create Create MSP definitionDefinition
| The same step as for the ordering organization |
Register the peer node identity | Console → Nodes → Endorsing Org CACertificate Authorities On the endorsing org CA node register the peer node identity
| |
Deploy the peer node | Console → Nodes → Add Peer
| More peer nodes can be added later to scale and distribute the peers of the endorsing organization |
...
Step | Actor | Details | ||
---|---|---|---|---|
Propose openIDL default chaincode definition | Analytics | Console → Channels → defaultchannel → Propose smart contract definition Chaincode:
The default chaincode is deployed on the defaultchannel and is used to record the data calls issued by the analytics node. | ||
Approve the proposed chaincode definition | Carrier | Console → Notifications Chaincode:
The default chaincode is deployed on the defaultchannel and is used to record the data calls issued by the analytics node. | ||
Commit the chaincode proposal | Analytics | Console → Notifications Trigger commit of the approved chaincode definition. After a successful commit the chaincode deployment is done. Chaincode:
| ||
Propose openIDL analytics-carrier private chaincode definition | Analytics | Console → Channels → <analytics org id>-<carrier org id> → Propose smart contract definition Chaincode:
Use the following template to create a private data collection (PDC)) definition file on your local file system (replace the values with the analytics and carrier specifics.
Repeat the above step for each analytics-carrier channel The analytics-carrier chaincode is deployed on each of the analytics-carrier channels. It is used to record the extraction of carrier data on the private data collection shared between the carrier and the analytics nodes. | ||
Approve openIDL analytics-carrier private chaincode definition | Carrier | Console → Notifications Chaincode:
Repeat the above step for each analytics-carrier channel The analytics-carrier chaincode is deployed on each of the analytics-carrier channels. It is used to record the extraction of carrier data on the private data collection shared between the carrier and the analytics nodes. | Approve openIDL analytics-carrier private chaincode definition | Carrier |
Console → Notifications Commit the chaincode proposal | Analytics | Console → Notifications Trigger commit of the approved chaincode definition. After a successful commit the chaincode deployment is done. Chaincode:
Repeat the above step for each analytics-carrier channel The analytics-carrier chaincode is deployed on each of the analytics-carrier channels. It is used to record the extraction of carrier data on the private data collection shared between the carrier and the analytics nodes. | Commit the chaincode proposal | Analytics |
Initialize the chaincode | Carrier or Analytics | In case the public channel name is other than "defaultchannel", the private carrier/analytics chaincode must be initialized with the name of the public channel. This step should be performed by the carrier node admin or the analytics node admin. @Carrier admin: The admin of the carrier can login to the AWX instance and launch the template "<env_id>-<org_id>-chaincode-init". @Analytics admin: The analytics node admin can login to the AWX instance and navigate to the template "<env_id>-<org_id>-chaincode-init". The admin should launch the template with additional variable "init_on_channel_id". The variable should define the name of the private (carrier/analytics) channel where the chaincode is deployed and should be initialized. The admin user can repeat that step for every specific carrier/analytics channel. |