vania-janet/multiturn-rag-retrieval-data huggingface dataset:
ibmcloud cr image-inspect [--format FORMAT] IMAGE [IMAGE...]



 Prerequisites 

To find out about the required permissions, see [Access roles for using Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_using).





 Command options 

--format FORMAT
: (Optional) Format the output elements by using a Go template. For more information, see [Formatting and filtering the Container Registry CLI output](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_cli_list).

IMAGE
: The name of the image for which you want to get a report. You can inspect multiple images by listing each image in the command with a space between each name.

You can identify images by using either the digest <dns>/<namespace>/<repo>@<digest> or by tag <dns>/<namespace>/<repo>:<tag>. Where <dns> is the domain name, <namespace> is the namespace, <repo> is the repository, <digest> is the digest, and <tag> is the tag.

To find the names of your images, run one of the following commands:



* To identify your image by digest, run the ibmcloud cr image-digests command. Combine the content of the Repository column (repository) and the Digest column (digest) separated by an at (@) symbol to create the image name in the format repository@digest.
* To identify your image by tag, run the ibmcloud cr image-list command. Combine the content of the Repository column (repository) and Tag column (tag) separated by a colon (:) to create the image name in the format repository:tag. If a tag is not specified in the image name, the image that is tagged latest is deleted by default.







 Example 

Display details about the exposed ports for the image us.icr.io/birds/bluebird:1 by using the following formatting directive.
* If you want to configure settings to control Code Engine managed registry access to IBM Cloud Container Registry, see [Configuring project-wide access to Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-cr).







 Configuring project-wide service binding operations 

Use the Integrations page in the console to configure settings for service binding operations so that all users of a specific project can create and delete bindings without having to assign all necessary privileges to their personal user IDs.

In Code Engine, service binding operations, which include creating, and deleting service bindings, are not performed with the identity of the user that is logged in. Instead, Code Engine automatically creates a service ID that is used specifically for service binding operations. With sufficient permissions, you can configure service binding operations to automatically set up this service ID for service binding operations from the Integrations page. Or, you can choose to use your own custom service ID that you manage for service binding operations.



 What access permissions are required to configure service binding operations? 

The user of this Integrations page must have the following Cloud Identity and Access Management (IAM) access policies that are assigned to your user account to successfully configure service binding operations. If you don't have sufficient permissions to perform these actions, you can use this page to help you understand the required permissions.



* Service: All Identity and Access enabled services



* Resources: Select from resource group, region, or access management tags.
* Resource group access:Viewer
* Roles and actions:Administrator platform access (no service access required)



* Service: Code Engine



* Resources: The resource group of this Code Engine project
* Resource group access:Viewer
* Roles and actions:Writer service access and Operator platform access





For Code Engine to automatically generate a service ID for service binding operations, Code Engine checks and automatically sets up a service ID with Operator platform access and Manager service access for all services in the resource group of the Code Engine project. Code Engine uses this service ID to access IBM Cloud services with service bindings.
Enter the following command to log in to the Docker registry where your Discovery images are available. Include your entitlement key in the following command:

docker login cp.icr.io -u cp -p {entitlement_key}
3. Enter the following command to pull the custom-crawler-sdk image:

docker pull cp.icr.io/cp/watson-discovery/custom-crawler-sdk:2.1.3
4. Enter the following command to run the custom-crawler-sdk image:

docker run cp.icr.io/cp/watson-discovery/custom-crawler-sdk:2.1.3
5. Enter the following command to copy custom-crawler-docs.zip from the container where the image is running:

docker cp {container_name}:/crawler/custom-crawler-docs.zip .

To find the image, enter docker ps -a | grep custom-crawler-sdk.
6. Expand the custom-crawler-docs.zip file:

cd {local_directory}

where {local_directory} is the directory on your local machine to which you downloaded the custom-crawler-docs.zip file.

unzip custom-crawler-docs.zip

If your local machine does not have the unzip utility, try using the gunzip command instead, or see the documentation of the operating system of your local machine for other alternatives to expand compressed files.

If you are using a version of Discovery that is earlier than 2.1.2 and you want to access the custom-crawler-docs.zip file, enter the following command: scp root@{instance_name}:/root/bob/sdk/custom-crawler-docs.zip {local_directory}.
You can edit the configuration file from the Red Hat OpenShift Application Console or in your command line by running the following command.

oc edit route image-registry -n openshift-image-registry

Add the annotation.

apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
haproxy.router.openshift.io/balance: source
...
5. If corporate network policies prevent access from your local system to public endpoints via proxies or firewalls, [allow access to the route subdomain](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-firewallopenshift-registry) that you create for the internal registry in the following steps.
6. Log in to the internal registry by using the route as the hostname.

docker login -u $(oc whoami) -p $(oc whoami -t) image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud
7. Now that you are logged in, try pushing a sample hello-world app to the internal registry.



1. Pull the hello-world image from DockerHub, or build an image on your local machine.

docker pull hello-world
2. Tag the local image with the hostname of your internal registry, the project that you want to deploy the image to, and the image name and tag.

docker tag hello-world:latest image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud/<project>/<image_name>:<tag>
3. Push the image to your cluster's internal registry.

docker push image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud/<project>/<image_name>:<tag>
4.
COPY --from=builder /usr/lib/libCryptoki2_64.so.6.3.0 /usr/lib/libCryptoki2_64.so.6.3.0
Show more

Now, run the following command to build the Docker image:

docker build -t hsm-client:v1 -f Dockerfile .





 Step three: Push the Docker image to your container registry 

After the image is built, the next step is to push the image to your Docker registry (for example, Docker Hub). The commands look similar to:

docker login -u <DOCKER_HUB_ID> -p <DOCKER_HUB_PWD>
docker tag hsm-client:v1 <DOCKER_HUB_ID>/hsm-client:v1
docker push <DOCKER_HUB_ID>/hsm-client:v1



* Replace <DOCKER_HUB_ID> with your Docker Hub id.
* Replace <DOCKER_HUB_PWD> with your Docker Hub password.



Create a Kubernetes image pull secret

If the HSM client image that you published is not public, then the operator requires an image pull secret that contains a valid username and password (or access token) for the container registry. If the image is public, the imagepullsecret is not required and you can skip this command. To build the image pull secret named hsm-docker-secret, run the following command in the namespace or project where you deployed the service:

kubectl create secret docker-registry hsm-docker-secret --docker-server=<DOCKER_REGISTRY_SERVER> --docker-username=<DOCKER_USER> --docker-password=<DOCKER_PASSWORD> --docker-email=<DOCKER_EMAIL> -n <NAMESPACE>

Replace:



* DOCKER_REGISTRY_SERVER - Registry server url where the HSM client image is hosted.
* DOCKER_USER - Valid username with access to HSM client image in the container registry.
If the image-key-id is not specified, the command first tries to determine the ID automatically by requesting the container registry notary service. You are prompted for this parameter for Docker Hub images.

--fingerprint FINGERPRINT
: If the image is in ICR, the fingerprint of the gpg key that is used to sign the image must be provided. You can get the fingerprint by using the gpg --list-keys name_of_the_key command. For example, when you run the gpg --list-keys latestnewkey command, the following snippet is an example of the output:

pub rsa4096 2023-01-12 [SCEA] [expires: 2024-04-28]
E8C9E...........61A927D9F3
uid [ultimate] latestnewkey
<latestnewkey@example.com>
sub rsa4096 2023-01-1--fingerprint FINGERPRINT2 [SEA] [expires: 2024-04-28]

In this example, "E8C9E...........61A927D9F3" is the fingerprint.

--image-key-public-path PUBLIC-KEY
: The path for the file that contains the public part of the key that was used to sign the image. The public part of the key must be a minimum of 20 characters and base64 encoded. If the image is present in ICR, path to the gpg public key that is used to sign the image and push to ICR should be mandatorily provided.

--registration-key-public-path PRIVATE-KEY-PATH
: The path for the public key from the registration key pair. Ensure that you use the same key that you had used when you created the virtual instance the first time. You must save these keys in a safe and secure location for future use.

--registration-key-private-path PUBLIC-KEY-PATH
: The path for the private key from the registration key pair.
Select the namespace and name of the image in Docker Hub for the Code Engine app to reference. For example, select mynamespace and select the image hello_repo in that namespace.
15. Select a value for Tag; for example, latest.
16. Click Done. You selected your image in the registry to reference from your app.
17. Modify any runtime settings or environment variables for your app. For more information about these options, see [Options for endpoint visibility of apps](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsoptionsdeploy) and [Options for deploying an app](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsoptionsdeploy).
18. From the Create application page, click Create.
19. After the application status changes to Ready, you can test the application. Click Test application and then click Send request in the Test application pane. To open the application in a web page, click Application URL.



Now that you have deployed your application, you can view information about application revisions and any running instances, and configuration details.

If you want to add registry access before you create an app, see [Adding access to a private container registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).





 Deploying an app with an image from a private registry with CLI 

Deploy an application that uses an image in a container registry with the CLI with the ibmcloud ce app create command.

Before you begin



* Set up your [Code Engine CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli) environment.
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).
* [Create new IAM API key credentials and store them in an image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother_registry_accounts) to access images in other IBM Cloud accounts or to apply IAM policies that restrict access to certain registry domains or namespaces.
* [Create an image pull secret to access images in external private registries](https://cloud.ibm.com/docs/openshift?topic=openshift-registryprivate_images).



If you already created an image pull secret in your project that you want to use in your deployment, see [Deploying containers by using the created imagePullSecret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret).



 Copying an existing image pull secret 

You can copy an image pull secret, such as the one that is automatically created for the default Red Hat OpenShift project, to other projects in your cluster. If you want to use different IBM Cloud IAM API key credentials for this project such as to restrict access to specific projects, or to pull images from other IBM Cloud accounts, [create an image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother_registry_accounts) instead.



1. List available Red Hat OpenShift projects in your cluster, or create a project to use.

oc get projects

Example output

default Active
ibm-cert-store Active
ibm-system Active
kube-public Active
kube-system Active

To create a project

oc new-project <project_name>
2. List the existing image pull secrets in the default Red Hat OpenShift project for IBM Cloud Container Registry.

oc get secrets -n default | grep icr-io

Example output

all-icr-io          kubernetes.io/dockerconfigjson        1         16d
3. Copy the all-icr-io image pull secret from the default project to the project of your choice.
{"auths":{"<region>.icr.io":{"username":"iamapikey","password":"<password_string>","email":"<name@abc.com>","auth":"<auth_string>"}}}
4. Compare the image pull secret regional registry domain name with the domain name that you specified in the container image. By default, new clusters have image pull secrets for each regional registry domain name for containers that run in the default Red Hat OpenShift project. However, if you modified the default settings or are using a different Red Hat OpenShift project, you might not have an image pull secret for the regional registry. [Copy an image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycopy_imagePullSecret) for the regional registry domain name.
5. Log in to the registry from your local machine by using the username and password from your image pull secret. If you can't log in, you might need to fix the service ID.

docker login -u iamapikey -p <password_string> <region>.icr.io



1. Re-create the cluster service ID, IBM Cloud IAM policies, API key, and image pull secrets for containers that run in the default Red Hat OpenShift project.

ibmcloud oc cluster pull-secret apply --cluster <cluster_name_or_ID>
2. Re-create your deployment in the default Red Hat OpenShift project. If you still see an authorization error message, repeat Steps 1-5 with the new image pull secrets. If you still can't log in, [open an IBM Cloud Support case](https://cloud.ibm.com/docs/openshift?topic=openshift-get-help).



6. If the login succeeds, pull an image locally. If the command fails with an access denied error, the registry account is in a different IBM Cloud account than the one your cluster is in.
When you include an [init container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) in your deployment, you can give a non-root user that is specified in your Dockerfile write permissions for the volume mount path inside the container.

The init container starts before your app container starts. The init container creates the volume mount path inside the container, changes the mount path to be owned by the correct (non-root) user, and closes. Then, your app container starts with the non-root user that must write to the mount path. Because the path is already owned by the non-root user, writing to the mount path is successful. If you don't want to use an init container, you can modify the Dockerfile to add non-root user access to NFS file storage.

Before you begin: [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1. Open the Dockerfile for your app and get the user ID (UID) and group ID (GID) from the user that you want to give writer permission on the volume mount path. In the example from a Jenkins Dockerfile, the information is:



* UID: 1000
* GID: 1000



Example Dockerfile

FROM openjdk:8-jdk

RUN apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/

ARG user=jenkins
ARG group=jenkins
ARG uid=1000
ARG gid=1000
ARG http_port=8080
ARG agent_port=50000

ENV JENKINS_HOME /var/jenkins_home
ENV JENKINS_SLAVE_AGENT_PORT ${agent_port}
...
2. Add persistent storage to your app by creating a persistent volume claim (PVC).
* The property DOCKER_REPO identifies the namespace (which you created in step 1) and the container image name to be used. Specify a value that is not used or allocated in your container registry.
* Specify the value of the API key that is created in step 1 for both properties DOCKER_PASSWORD and DOCKER_RO_PASSWORD.
* Specify the value of your personal access token for the property ACCESS_TOKEN. The build process uses a personal access token for github.com to avoid a build failure due to its access rate limit. For more information, see [Creating a personal access token](https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-personal-access-token).



For a list of properties, see [here](https://github.com/ibm-hyper-protect/secure-build-clipreparing-the-configuration).





 5. Create the client certificate and client CA by running the following command: 

./build.py create-client-cert --env sbs-config.json

The following snippet shows example output:

INFO:__main__:parameter file sbs-config.json renamed to sbs-config.json.2021-02-10_14-55-19.806993
INFO:root:client_certificate: generating client CA and certificate

The client certificate and CA are used for secure communication between the Secure Build Server CLI on your workstation and the Secure Build Server instance.

This command does the following:



* It updates the file sbs-config.json by adding two properties: UUID and SECRET.
* It creates a directory that is named .SBContainer-<uuid>.d. This directory contains the created certificates and keys.



If the file sbs-config.json is open in an editor when you run this command, reload the updated file. Do not modify the new properties UUID and SECRET.





 6. Create the server certificate and server KEY by running the following command:
apiVersion: v1
kind: ConfigMap
metadata:
name: tcp-services
namespace: kube-system
data:
9000: "<namespace>/<service>:8080"
2. Create the ConfigMap in the kube-system namespace.

kubectl apply -f tcp-services.yaml -n kube-system
3. Specify the tcp-services ConfigMap as a field in the [ibm-ingress-deploy-config ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationscomm-customize-deploy).

"tcpServicesConfig":"kube-system/tcp-services"
4. [Modify each ALB service](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationscomm-customize-deploy) to add the ports.







 Setting a maximum number of upstream keepalive requests 

To set the maximum number of requests that can be served through one keepalive connection, use the following Kubernetes ibm-k8s-controller-config ConfigMap [field](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/upstream-keepalive-requests).

upstream-keepalive-requests: 32





 Setting the maximum upstream keepalive timeout 

To set the maximum time that a keepalive connection stays open between the ALB proxy server and your app's upstream server, use the following Kubernetes ibm-k8s-controller-config configmap [field](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/upstream-keepalive-timeout).

upstream-keepalive-timeout: 32





 Customizing the ALB deployment
However, if the ibm-entitlement-keyimage pull secret is missing from the ibp namespace, manually copy the secret to the ibp namespace and reference it in your YAML file, as described below.



1. In the left navigation, click Workloads > Secrets.
2. In the search box next to the Name drop down, type pull-secret.
3. From the listing page, select pull-secret.
4. Click the YAML tab.
5. In the YAML tab, you see the YAML code as follows. Right-click to copy only the last two sets of codes. Those are the secret data and the secret data handling type.

Zoom

![Pull-secret YAML](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/pull-secret.png)

Figure 4. Pull-secret YAML Sample
6. After you copied the two sets of codes, go to the left navigation, click Secrets. Then, use the Create drop down from the upper right of the page to switch to From YAML.
7. Paste your two sets of codes under the existing YAML code.
8. Replace the existing YAML code by copying the following:

kind: Secret
apiVersion: v1
metadata:
name: regcred
namespace: <Your Blockchain Platform namespace>





1. Your complete set of pull-secret YAML code is now as follows:

kind: Secret
apiVersion: v1
metadata:
name: regcred
namespace: <Your IBM Blockchain Platform namespace>
data: <Your secret data here>
type: kubernetes.io/dockerconfigjson





1. Click Create to finish your setup.







 Step three: Deploy the IBM Blockchain Platform console 

There are four instances available listed under "Provided APIs":

Zoom

!
workspace_name Optional Enter a name for your workspace. The maximum length of character limit is set to less than 1 MB. For more information, see [Designing your workspace structure](https://cloud.ibm.com/docs/schematics?topic=schematics-workspaces-planstructure-workspace). 
 terraform_version Optional The Terraform version that you want to use to run your Terraform code. Enter terraform_v1.1 to use Terraform version 1.1,terraform_v1.0 to use Terraform version 1.0, and similarly, terraform_v0.15, terraform_v0.14, terraform_v0.13, terraform_v0.12. For example, when you specify terraform_v1.1 means users can have template that are of Terraform v1.1.0, v1.1.1, or v1.1.2, so on. Make sure that your Terraform config files are compatible with the Terraform version that you specify. This is a required variable. If the Terraform version is not specified, By default, Schematics selects the version from your template. Schematics supports Terraform_v1.x and also plans to make releases available after 30 to 45 days of HashiCorp Configuration Language (HCL) release. 
 location Optional Enter the location where you want to create your workspace. The location determines where your Schematics Actions run and where your workspace data is stored. If you do not enter a location, Schematics determines the location based on the IBM Cloud region that you targeted. To view the region that you targeted, run ibmcloud target --output json and look at the region field. To target a different region, run ibmcloud target -r <region>. If you enter a location, make sure that the location matches the IBM Cloud region that you targeted. 
 resource_group Optional Name of the resource group the workspace will be associated with. Defaults to the 'Default' resource group. 
 description Optional Enter a description for your workspace.