vania-janet/multiturn-rag-retrieval-data huggingface dataset:
From the drop down Application instance, choose an existing application instance or choose Create a new instance. If you choose Create a new instance, the details of the new instance are shown. The new instance is created when the cluster is created. If you disable this integration and want to enable it later, see [Logging for clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-health&interface=ui).
Monitoring

Enable the [monitoring](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-started) option. From the drop down Platform instance menu, choose a platform instance. From the drop down Application instance, choose an existing application instance or choose Create a new instance. If you choose Create a new instance, the details of the new instance are shown. The new instance is created when the cluster is created. If you disable this integration and want to enable it later, see [Monitoring cluster health](https://cloud.ibm.com/docs/openshift?topic=openshift-health-monitor&interface=ui).



19. In the Summary pane, review the order summary and then click Create. A worker pool is created with the number of workers that you specified. You can see the progress of the worker node deployment in the Worker nodes tab.



* Your cluster might take some time to provision the Red Hat OpenShift master and all worker nodes and enter a Normal state. Note that even if the cluster is ready, some parts of the cluster that are used by other services, such as Ingress secrets or registry image pull secrets, might still be in process. Before you continue, wait until the cluster is ready by checking that the Ingress subdomain follows a pattern of <cluster_name>.<region>.containers.appdomain.cloud.
* Every worker node is assigned a unique worker node ID and domain name that must not be changed manually after the cluster is created. Changing the ID or domain name prevents the Red Hat OpenShift master from managing your cluster. Is your cluster not in a Normal state?
Click Save.
11. Click Publish again and select Publish application.
12. Click Publish.
13. In the command line, the API Target URL and API invoke tls-profile is specified for the API. Make a note of this information. The API invoke tls-profile is always client:Loopback-client, but you can retrieve the API Target URL as described in the following step.

Deploying to IBM Cloud
...preparing project
...building package for deploy
...uploading package
Runtime published successfully.
Management URL: https://<domain name>/apps/33e7b062-092b-4227-af97-047499dab2e7
API target urls: apiconnect-33e7b062-092b-4227-af97-047499dab2e7.<IBM_Cloud_org>-<IBM_Cloud_space>.apic.<domain_name>
API invoke tls-profile: client:Loopback-client
Updated newapi_1.0.0.yaml with tls-profile and target-url.
Updated notes.yaml with tls-profile and target-url.
14. In the API Designer UI, complete the following steps:



1. Click APIs.
2. Select your API.
3. Click Assemble.
4. In the Assembly editor, click the Filter policies icon.
5. Select DataPower Gateway policies.
6. Click Save to save the API.



15. Next, you need to publish to the API Manager. Click Publish.



1. Select Publish application then choose one of the following options:



* Replace existing app: If you have a published application, select this option to overwrite the existing app.
* As a brand new app (using the existing route): Select this option to create a new app and provide a name for it in the New app field. The service is not interrupted.



2.
db2 update dbm cfg using SSL_CLNT_STASH /<ssl_directory_name>/ssl/dashclient.sth

e. Catalog the Db2 Warehouse on Cloud node so that client applications can connect to it. Issue the following command:

db2 catalog tcpip node <node_name> remote <Db2_Warehouse_IP_address> server <port_number> security ssl

where:

<node_name> is your name for the node.

<Db2_Warehouse_IP_address> is the IP address of the Db2 Warehouse on Cloud server.

<port_number> is the port that is used to connect to Db2 Warehouse by using an SSL connection. If you are using the default port, specify 50001.

f. Catalog the remote Db2 Warehouse on Cloud database so that client applications can connect to it. Issue the following command:

db2 catalog database bludb as <db_alias> at node <node_name>

where db_alias is your name for the Db2 Warehouse on Cloud database.

g. Test the SSL connection in one of the following ways:



* Test the connection by using CLP by issuing the following command to connect to the Db2 Warehouse on Cloud database:

db2 connect to <db_alias> user <user_id>

where <user_id> is your Db2 Warehouse on Cloud user ID. You are prompted to enter your password.
* Test the connection by using CLI by issuing the following command to connect to the Db2 Warehouse on Cloud database:

db2cli validate -dsn <alias> -connect -user <user_id> -passwd <password>

where <alias> is a DSN alias that you created by using the db2cli writecfg command, <user_id> is your Db2 Warehouse on Cloud user ID, and <password> is your Db2 Warehouse on Cloud database password.



* To create a connection without SSL, complete the following steps:

a. Catalog the Db2 Warehouse on Cloud node so that client applications can connect to it. Issue the following command:
Ensure that $FABRIC_CA_CLIENT_HOME is set to $HOME/fabric-ca-client/ca-admin.
echo $FABRIC_CA_CLIENT_HOME
$HOME/fabric-ca-client/ca-admin
2. Issue the following command to find your affiliation and your organization name.
fabric-ca-client affiliation list --caname <ca_name> --tls.certfiles <ca_tls_cert_path>

Your command might look like the following example:

fabric-ca-client affiliation list --caname ca --tls.certfiles $HOME/fabric-ca-client/catls/tls.pem

You should see information that is similar to the following example:

affiliation: org1
affiliation: org1.department1

Make a note of the second affiliation value, for example, org1.department1. You need to use this value in the command below.

If you created the CA with the IBM Blockchain APIs instead of the console, your CA is deployed without affiliations, unless you created affiliations by using the Fabric CA Client. If your CA does not have affiliations, you can skip this step and leave the --id.affiliation off future commands.
3. Run the following command to register the ordering node or peer.
fabric-ca-client register --caname <ca_name> --id.name <name> --id.affiliation org1.department1 --id.type <component_type> --id.secret <secret> --tls.certfiles <ca_tls_cert_path>

Create a name and password for the component and then use them to replace name and secret. Make a note of this information. Set the --id.type to orderer if you are deploying an ordering node, or set it to peer if you are deploying a peer. The command might look similar to the following example:
If you want to use the community buildpack to overwrite the IBM-created buildpack, you must specify the buildpack by using the -b option with the ibmcloud cf push command.

For example, you can use the community buildpack for Java™ web apps by using the following command.

ibmcloud cf push app_name -b java_buildpack -p app_path

You can also use the community buildpack for Node.js app with the following command.

ibmcloud cf push app_name -b nodejs_buildpack -p app_path

For a runtime or framework that is not supported by IBM-created buildpacks but is supported by built-in community buildpacks, you do not have to use the -b option with the ibmcloud cf push command. For example, for Ruby apps, there are no IBM-created buildpacks. You can use the built-in community buildpack by entering the following command.

ibmcloud cf push app_name -p app_path





 External buildpacks 

You can use external or custom buildpacks in IBM Cloud. You must specify the URL of the buildpack with the -b option, and specify the stack with the -s option on the ibmcloud cf push command. For example, to use an external community buildpack for static files, run the following command.

ibmcloud cf push app_name -p app_path -b https://github.com/cloudfoundry/staticfile-buildpack.git

If you don't want to use the built-in community buildpack for Ruby apps, you can use an external buildpack by entering the following command.

ibmcloud cf push app_name -p app_path -b https://github.com/cloudfoundry/ruby-buildpack.git

You can also use a custom buildpack for your app. For example, you can use an open source PHP buildpack that is provided by the Cloud Foundry community. When you deploy your PHP app to IBM Cloud, enter the following command to specify the Git repository URL of the buildpack.
To build the MSP definition, create a JSON by copying the following text and saving it to a file of type JSON:

{
"name": "<organization_name>",
"display_name": "<organization_name>",
"msp_id": "<organization_id>",
"type": "msp",
"admins": [
"<admins>"
],
"root_certs": [
"<root_certs>"
],
"tls_root_certs": [
"<tls_root_certs>"
],
"fabric_node_ous": {
"enable": true,
"admin_ou_identifier": {
"certificate": "<ou_root_cert>",
"organizational_unit_identifier": "admin"
},
"client_ou_identifier": {
"certificate": "<ou_root_cert>",
"organizational_unit_identifier": "client"
},
"orderer_ou_identifier": {
"certificate": "<ou_root_cert>",
"organizational_unit_identifier": "orderer"
},
"peer_ou_identifier": {
"certificate": "<ou_root_cert>",
"organizational_unit_identifier": "peer"
}
},
"host_url": "<url>",
}
Show more

Replace the following values:



* organization_name: Specify any name to be used to identify this MSP definition in the console.
* organization_id: Specify an ID that is used to represent this MSP internally in the console.
* root_certs: Paste in an array that contains one or more root certificates from the external CA in base64 format. You must provide either a CA root certificate or an intermediate CA certificate.
A good practice is to set up the container image with a defined user and to run as non-root. For example, based on our previous scenario,

FROM node:16-alpine AS builder

COPY . /app
WORKDIR /app
RUN npm install && npm run build

FROM node:16-alpine

RUN npm install -g serve

COPY --from=builder /app/build /app

USER 1100:1100
EXPOSE 8080
ENTRYPOINT [ "serve", "--single", "--no-clipboard", "--listen", "8080", "/app" ]

The Dockerfile uses the USER command to specify that it wants to run as user and group 1100. Note that this command does not implicitly create a named user and group in the container image. Usually, this structure is acceptable, but if your application logic requires the user and also its home directory to exist, then you must create the user and group explicitly:

FROM node:16-alpine AS builder

COPY . /app
WORKDIR /app
RUN npm install && npm run build

FROM node:16-alpine

RUN npm install -g serve && 
addgroup nonroot --gid 1100 && 
adduser nonroot --ingroup nonroot --uid 1100 --home /home/nonroot --disabled-password

COPY --from=builder /app/build /app

USER 1100:1100
EXPOSE 8080
ENTRYPOINT [ "serve", "--single", "--no-clipboard", "--listen", "8080", "/app" ]
Show more

The RUN command in the runtime stage was extended to call the addgroup and adduser commands to create a group and a user with a home directory.
First, check the status of the pods:

kubectl get deployments

You'll receive a response similar to:

NA.M.E READY UP-TO-DATE AVAILABLE AGE
ibp-operator 1/1 1 1 48d
orderer1node1 1/1 1 1 20h
orderer2node1 1/1 1 1 22h
orderer3node1 1/1 1 1 22h
orderer4node1 1/1 1 1 22h
orderer5node1 1/1 1 1 22h
ordererorgca 1/1 1 1 48d
peera 0/0 0 0 20h
peerc 1/1 1 1 20h
peerorg1ca 1/1 1 1 48d

Then scale the peera pod back up by setting the replicas value to 1.

kubectl patch <component> <componentName> --type merge --patch '{"spec":{"replicas":1}}' -n <namespace>

Where <component> is, once again, one of: ibppeer, ibporderer, or ibpca.

In this example, scale up peera:

kubectl patch <ibppeer> peera --type merge --patch '{"spec":{"replicas":1}}' -n n3392fd

Once the pod is back up, the peer is now restored, with the same peer channel membership, installed smart contracts, and ledger height as when the snapshot was taken. Because the peer immediately starts pulling new blocks from the ordering service or other peers once it comes up, the ledger height might increase.





 Restoring an ordering node 

The process for restoring an ordering node is largely similar to the process for restoring a peer. However, there are a few additional things to keep in mind.



1. You must stop all the ordering nodes in the cluster by scaling down each deployment to zero before restoring any of the ordering nodes. Note after the nodes have been scaled down, it is not possible to transact. Client applications must resubmit their transaction requests after the ordering service is restored.
2.
Note: Learn more about [securing your personal information](https://cloud.ibm.com/docs/containers?topic=containers-securitypi) when you work with container images.

Use lowercase alphanumeric characters or underscores (_) only in the image name. Don't forget the period (.) at the end of the command. The period tells Docker to look inside the current directory for the Dockerfile and build artifacts to build the image.

docker build -t us.icr.io/<namespace>/hello-world:1 .

When the build is complete, verify that you see the following success message:

=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:3ca1eb1d0998f738b552d4c435329edf731fe59e427555b78ba2fb54f2017906 0.0s
=> => naming to <region>.icr.io/<namespace>/hello-world:1 0.0s
5. Create a deployment for your app. Deployments are used to manage pods, which include containerized instances of an app. The following command deploys the app in a single pod. For the purposes of this tutorial, the deployment is named hello-world-deployment, but you can give the deployment any name that you want.

kubectl create deployment hello-world-deployment --image=us.icr.io/vpc-gen2/hello-world:1

Example output

deployment.apps/hello-world-deployment created

Learn more about [securing your personal information](https://cloud.ibm.com/docs/containers?topic=containers-securitypi) when you work with Kubernetes resources.
6. Make the app accessible by exposing the deployment as a NodePort service. Because your VPC worker nodes are connected to a private subnet only, the NodePort is assigned only a private IP address and is not exposed on the public network.
Client Version: 4.11.0
Kustomize Version: v4.5.4

 zip
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.

 unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send

 git --version
git version 2.31.1

 curl
curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.6 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.2.0) libssh/0.9.6/openssl/zlib nghttp2/1.33.0

 wget
GNU Wget 1.19.5 built on linux-gnu.

 openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021

 make
GNU Make 4.2.1

 docker
Client:
Version: 20.10.16
API version: 1.41
Go version: go1.17.10
Git commit: aa7e414
Built: Thu May 12 09:14:28 2022
OS/Arch: linux/amd64
Context: default

 dc --version
dc (GNU bc 1.07.1) 1.4.1

 ed --version
GNU ed 1.14.2

 skopeo --version
skopeo version 1.8.0
Show more





 Version 3.9 

To view the contents of version 3.9, from the running image, type default_versions.sh. The 3.x branch provides images with the current tool versions. The current Java™ version is Java™ 17. Node.js no longer uses nvm to manage different node.js versions.
Zoom

![Project View](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/ocp48-project-view.png)

Project View
2. Let's build and deploy the application by selecting Import from Git.
3. Enter the repository https://github.com/IBM-Cloud/patient-health-frontend.git in the Git Repo URL field.



* Note the green check Builder image detected and the Node.js 16 (UBI 8).
* Note that the builder image automatically detected the language Node.js. If not detected, select Node.js from the provided list.
* Builder Image Version leave at the default.
* Application Name delete all of the characters and leave it empty (this will default to the Name)
* Name : patient-health-frontend.
* Click the Resource type link and choose DeploymentConfig.
* Leave defaults for other selections.



4. Click Create at the bottom of the window to build and deploy the application.







 View Application 



1. You should see the app you just deployed. Notice that you are in the Topology view of the example-health project in the Developer perspective. All applications in the project are displayed.
2. Select the nodepatient-health-frontend to bring up the details view of the DeploymentConfig. Note the DC next to patient-health-frontend. The Pods, Builds, Services and Routes are visible.

Zoom

![App Details](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/ocp45-topo-app-details.png)

App Details
This image includes the following tools:

 node --version
v14.17.0

 npm --version
6.14.13

 jq --version
jq-1.6

 yq --version
yq version 2.4.1

 yq3 --version
yq version 3.4.1

 yq4 --version
yq version 4.9.3

 kubectl version --client
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"clean", BuildDate:"2021-03-18T01:10:43Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}

 buildctl --version
buildctl github.com/moby/buildkit v0.8.2 9065b18ba4633c75862befca8188de4338d9f94a

 helm version --client
Client: &version.Version{SemVer:"v2.17.0", GitCommit:"a690bad98af45b015bd3da1a41f6218b1a451dbe", GitTreeState:"clean"}

 helm3 version --client
version.BuildInfo{Version:"v3.6.0", GitCommit:"7f2df6467771a75f5646b7f12afb408590ed1755", GitTreeState:"clean", GoVersion:"go1.16.3"}

 ibmcloud -version
ibmcloud version 1.6.0+59b6322-2021-05-26T20:13:53+00:00

 ibmcloud plugin list
Now that you have the intermediate CA admins registered with the root CA, there is one last piece of information we need: the root CA TLS signed certificate. This certificate is shared with each node in the organization and is used to secure the communications between the nodes. Therefore, in order for the intermediate CA to communicate with the root CA, it has to be included in the intermediate CA configuration. To get the root CA TLS signed certificate, simply export the root CA to a JSON file. Open the root CA and click the Export icon.

Zoom

![Export root CA](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/export-root-ca.png)

Figure 2. Export root CA



tls_cert









 Part Two: Build the intermediate CA JSON override 

Anytime that you deploy a CA, you can override the default CA settings by pasting a JSON that contains the parameters that you want to override. Because we are deploying an intermediate CA, we need to override some of the default settings in order to configure it to be an intermediate CA. For example, you need to configure the intermediate block of the JSON to point to your root CA as the parent server. Therefore, copy the following text to an editor where you can modify the values:

{
"ca": {
"debug": true,
"registry": {
"maxenrollments": -1,
"identities": [{
"name": "<INTERMEDIATE-CA-ADMIN>",
"pass": "<INTERMEDIATE-CA-ADMIN-PW>",
"type": "client",
"attrs": {
"hf.Registrar.Roles": "",
"hf.Registrar.DelegateRoles": "",
"hf.Revoker": true,
"hf.IntermediateCA": true,
Client Version: 4.11.12
Kustomize Version: v4.5.4

 zip
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.

 unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send

 git --version
git version 2.31.1

 curl
curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.6 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.2.0) libssh/0.9.6/openssl/zlib nghttp2/1.33.0

 wget
GNU Wget 1.19.5 built on linux-gnu.

 openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021

 make
GNU Make 4.2.1

 docker
Client:
Version: 20.10.21
API version: 1.41
Go version: go1.18.7
Git commit: baeda1f
Built: Tue Oct 25 17:56:30 2022
OS/Arch: linux/amd64
Context: default

 dc --version
dc (GNU bc 1.07.1) 1.4.1

 ed --version
GNU ed 1.14.2

 skopeo --version
skopeo version 1.9.3
Show more





 Version 3.11 

To view the contents of version 3.11, from the running image, type default_versions.sh. The 3.x branch provides images with the current tool versions. The current Java™ version is Java™ 17. Node.js no longer uses nvm to manage different node.js versions.
Retrieve the list of IP addresses that you need to allow in your WireGuard client configuration so that you can successfully connect to your private Red Hat OpenShift cluster.



1. Get the details of your cluster and note the Ingress Subdomain and the Private Service Endpoint URL.

ibmcloud ks cluster get --cluster <cluster_name_or_ID>
2. Retrieve the IP address that is assigned to the Ingress subdomain and your private service endpoint URL.

nslookup <ingress_subdomain>

nslookup <private_service_endpoint_URL>

To successfully run an nslookup command on your private service endpoint URL, remove https:// and the port from your URL. Alternatively, you can note all IP address CIDRs for the region that your cluster master is in as shown in step 3 of [Opening required ports in a private firewall](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_private).
3. Get the IP address CIDR of all the VPC subnets, private VLANs, or on-prem networks that your cluster worker nodes are connected to. For example, if you created a VPC cluster in IBM Cloud, you can get the subnet CIDR by getting the details for each worker node.

ibmcloud ks worker get --worker <worker_ID> --cluster <cluster_name_or_ID>



10. Install, configure, and activate the WireGuard client.



1. Follow the [instructions](https://www.wireguard.com/install/) to install the WireGuard client on your local machine.
2. Open the client.
3. Click + to create an empty VPN tunnel. A WireGuard private and public key is automatically created for you and displayed in the client configuration.
4. Enter a name for your client configuration.
5. Add the following configuration after the PrivateKey that is displayed in the Interface section.
<br><br> * Navigate to the Nodes tab.<br> * Open the Ordering Org CA and click Associate identity.<br> * Click the Existing CA tab and select the Ordering Org CA Admin.<br> * If you created the endorsing organizations for the peers, repeat these steps for the Org1 CA and Org2 CA nodes, associating the Org1 CA Admin and Org2 CA Admin identities respectively.<br><br><br> 









 Summary 

Congratulations. You have used the Ansible playbooks to configure IBM Blockchain Platform components on your cluster. You know how to run a playbook individually and have some sample shell scripts that show how to run the playbooks together to build a reproducible network and tear it back down. You can explore further by building your own playbooks that call the Ansible [modules](https://ibm-blockchain.github.io/ansible-collection/modules.html) or build your own custom scripts according to your network use case.