Versions Compared

Old Version 6

changes.mady.by.user Tsvetan Georgiev

Saved on

compared with

New Version Current

changes.mady.by.user Tsvetan Georgiev

Saved on

Key

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

...

  • 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:

  • 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>

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“

https://{{console_namespace}}-{{console_name}}-console.{{console_domain}}

...

Step

Details

Notes

Deploy Certificate Authority

Console → Nodes → Create new CAAdd Certificate Authority

Create new CA

  • CA name: <org_id>

  • CA admin enroll id: <org_id>-ca-admin

  • CA enrollment secret: anything that can be remembered (note it down)

Associate (enroll) the CA admin identity registered above during the CA deployment

  • Enroll id: <org_id>-ca-admin (display name <org_id>-ca-admin)


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

  • Enroll id: <org_id>-ca-admin (display name <org_id>-ca-admin)


Register the organization admin identity

Console → Nodes → Endorsing Org CACertificate Authorities

Register the org admin user using the deployed CA above

  • Enroll id: <org_id>-msp-admin

  • Type: admin

  • Enroll secret: should be remembered (note it down)


Create the MSP definition for the organization

Console → Organizations → create Create MSP definitionDefinition

  • MSP name: <org_id>

  • MSP id: <org_id>

  • Enroll ID: <org_id>-msp-admin

  • Identity Name: <org_id>-msp-admin

  • Generate Certificates

  • Next and deploy

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

  • Enroll Id: <org_id>-peer1

  • Enroll Secret: remember it and note it down

  • Type: peer


Deploy the peer node

Console → Nodes → Add Peer


  • Peer enroll id (name): <org_id>-peer1

  • Choose the endorsing org MSP and CA created above

  • Choose the peer-enrolled identity as registered above

  • Enter the enrollment secret of the <org_id>-peer1 as registered above

  • Accosiate the amdin Identity: <org_id>-msp-admin

More peer nodes can be added later to scale and distribute the peers of the endorsing organization

...

Console → Notifications

Trigger commit of the approved chaincode definition. After a successful commit the chaincode deployment is done.

Chaincode:

openidl-cc-analytics-carrier

Step

Actor

Details

Propose openIDL default chaincode definition

Analytics

Console → Channels → defaultchannel → Propose smart contract definition

Chaincode:

openidl-cc-default


  • Organization: the <org_id>; Organization msp admin: <org_id>-msp-admin

  • Install the smart contract by using the package file (add file):

https://github.com/orgs/senofiopenidl-org/packages?repo_name=openidl-main
The latest version of (*.tgz): openidl-chaincode.openidl-cc-default

  • Smart Contract version: v1 (version increases with every chaincode upgrade)

  • Use the default values for the rest of the steps


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:

openidl-cc-default


  • Organization: the <org_id>; Organization msp admin: <org_id>-msp-admin

  • Install the smart contract by using the package file (add file):

https://github.com/orgs/senofiopenidl-org/packages?repo_name=openidl-main
The latest version of (*.tgz): openidl-chaincode.openidl-cc-default

  • Smart Contract version: v1 (version increases with every chaincode upgrade)

  • Use the default values for the rest of the steps


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:

openidl-cc-default

Propose openIDL analytics-carrier private chaincode definition

Analytics

Console → Channels → <analytics org id>-<carrier org id> → Propose smart contract definition

Chaincode:

openidl-cc-analytics-carrier


  • Organization: the <org_id>; Organization msp admin: <org_id>-msp-admin

  • Install the smart contract by using the package file (add file):

https://github.com/orgs/
senofi
openidl-org/packages?repo_name=openidl-main
The latest version of (*.tgz): openidl-cc-analytics-carrier

  • Smart Contract version: v1 (version increases with every chaincode upgrade)

  • If required select the chaincode reqruies init option

    Info

    In case the used public channel has name other than the default one (defaultchannel), the chaincode should be initialized. Therefore it is required to select the chaincode requires init option.

    During initialization (see below) the name of the public channel is passed to the chaincode and stored on the ledger (the carrier/analytics channel).

Use the following template to create a private data collection (PDC))

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.

[
   {
      "name":"<analytics org id>_<carrier org id>_pdc",
      "policy": "OR('<analytics org id>.member', '<carrier org id>.member')",
      "requiredPeerCount":0,
      "maxPeerCount":0,
      "blockToLive":0
   }
]

  • Choose the templated local PDC file to add as PDC definition of the deployment

  • Use the default values for the rest of the steps

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:

openidl-cc-analytics-carrier


  • Organization: the <org_id>; Organization msp admin: <org_id>-msp-admin

  • Install the smart contract by using the package file (add file):

https://github.com/orgs/openidl-org/packages?repo_name=openidl-main
The latest version of (*.tgz): openidl-cc-analytics-carrier

  • Smart Contract version: v1 (version increases with every chaincode upgrade)

)", "requiredPeerCount":0, "maxPeerCount":0, "blockToLive":0 } ]

  • Choose the templated local PDC file to add as PDC definition of the deployment

  • Use the default values for the rest of the steps

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

Commit the chaincode proposal

Analytics

Console → Notifications

Trigger commit of the approved chaincode definition. After a successful commit the chaincode deployment is done.

Console → Notifications

Chaincode:

openidl-cc-analytics-carrier

  • Organization: the <org_id>; Organization msp admin: <org_id>-msp-admin

  • Install the smart contract by using the package file (add file):

https://github.com/orgs/senofi/packages?repo_name=openidl-main
The latest version of (*.tgz): openidl-cc-analytics-carrier

  • Smart Contract version: v1 (version increases with every chaincode upgrade)

  • Use the default values for the rest of the steps

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.