vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Setting up an image registry 

Red Hat® OpenShift® on IBM Cloud® clusters include an internal registry to build, deploy, and manage container images locally. For a private registry to manage and control access to images across your enterprise, you can also set up your cluster to use IBM Cloud® Container Registry.



 Choosing an image registry solution 

Your container images must be stored in a container registry that your cluster can access to deploy apps into your cluster. You can choose to use the built-in registry of your Red Hat OpenShift cluster, a private registry with access restricted to select users, or a public registry. Review the following table to choose the best option for your use case.

Internal Red Hat OpenShift Container Registry (OCR)
: Your cluster is set up with the internal Red Hat OpenShift Container Registry so that Red Hat OpenShift can automatically build, deploy, and manage your application lifecycle from within the cluster. Images are stored in a backing IBM Cloud classic file storage device that is provisioned at cluster creation time. If you need more storage, you can resize the device. Use cases:



* Red Hat OpenShift-native image stream, build, and app deployment process on a per cluster basis.
* Images can be shared across all projects in the cluster, with access that is controlled through RBAC roles.
* Integrating the internal registry with other Red Hat products like CloudForms for extended features such as vulnerability scanning.
* Option to expose the internal registry with a route so that users can pull images from the registry over the public network.
* Option to set up the internal registry to [pull images](https://cloud.ibm.com/docs/openshift?topic=openshift-registryimagestream_registry) from or [push images](https://cloud.ibm.com/docs/openshift?topic=openshift-registrybuilds_registry) to a private registry such as IBM Cloud Container Registry.



: For more information, see [Using the internal registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_internal_registry).

Private registry
: Private registries are a good choice to protect your images from unauthorized users.
Define an environment variable named MYNAMESPACE pointing to the registry namespace:

export MYNAMESPACE=<REGISTRY_NAMESPACE>
5. Define an environment variable name API_KEY pointing to an IBM Cloud IAM API key.

To create an API key, refer to this [link](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_user_apikey_create).
6. To automate access to your registry namespaces and to push the generated builder container image to Container Registry, create a secret:

oc create secret docker-registry push-secret --docker-username=iamapikey --docker-password=$API_KEY --docker-server=$MYREGISTRY
7. Also, you need to copy and patch the image-pull secret from the default project to your project:

oc get secret all-icr-io -n default -o yaml | sed 's/default/'$MYPROJECT'/g' | oc -n $MYPROJECT create -f -
8. For the image pull secret to take effect, you need to add it in the default service account

oc secrets link serviceaccount/default secrets/all-icr-io --for=pull





 Clone a sample application 

In this section, you will clone a GitHub repo with yaml template files and a shell script to generate yaml file with updated environment variables. The generated file is used to build a container image, push the image to the private container registry and deploy a new app using the private container image.



1. On a terminal, run the below command to clone the GitHub repository to your machine:

git clone https://github.com/IBM-Cloud/openshift-node-app
2. Change to the application directory,

cd openshift-node-app







 Update the BuildConfig and Push the builder image to Container Registry
[Public Docker Hub](https://hub.docker.com/) Use this type of registry to pull existing public images from Docker Hub directly in your Code Engine applications or jobs.<br><br>Important<br><br><br><br> * This registry type might not meet your organization's security requirements such as access management, vulnerability scanning, or app privacy.<br> * When you pull an image from Docker Hub to use with apps or jobs in Code Engine, be aware of [Docker rate limits](https://docs.docker.com/docker-hub/download-rate-limit) for free plan (anonymous) users. You might experience pull limits if you receive a 429 error which indicates that you have reached your pull rate limit. To [increase rate limits](https://www.docker.com/increase-rate-limits), you can upgrade your account to a Docker Pro or Team subscription.<br><br><br><br>With public Docker Hub, you can:<br><br><br><br> * These images can be referred to directly when you create an app or job, no additional setup is required.<br> * Includes various open source applications.<br><br><br> 







 Types of registry secrets 

To access images in a registry, Code Engine uses one of the following types of registry secrets.



* Code Engine managed secret - If your registry uses an IBM Cloud Container Registry namespace that is in your account, then you can let Code Engine create and manage the registry secret for you. In the console, this automatically created registry access secret is called a Code Engine managed secret. In the CLI, the name of an automatically created registry secret is of the format, ce-auto-icr-private-<region>.
* User managed secret - This is a secret that you create and manage. You can [access images from your account with an API key](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-your-account-api-key) or use an access token for the container registry of your choice; for example, Docker Hub.
* [Assigning existing namespaces to resource groups](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_namespace_assign)
* [Removing namespaces](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_remove)







 Setting up Container Registry as a private registry on Red Hat OpenShift 

[Setting up Container Registry as a private registry on Red Hat OpenShift](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_rhosregistry_rhos)



* [Set up Red Hat OpenShift on IBM Cloud to use Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_rhosregistry_rhos_rhoks)
* [Set up Red Hat OpenShift Container Platform to use Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_rhosregistry_rhos_os)



* [Set up the Red Hat OpenShift Container Platform internal registry to pull from Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_rhosregistry_rhos_os_pull)
* [Set up the Red Hat OpenShift Container Platform build to push images to Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_rhosregistry_rhos_os_push)









 Adding images to your namespace 

[Adding images to your namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_)



* [Pulling images from another registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_pulling_reg)
You must use the path to a file that contains the password for the --cr-pwd-path parameter and the path to a file that contains the pass phrase for the --gpg-passphrase-path parameter. The sample command contains placeholders for those paths.

$ ibmcloud hpvs registration-create --registration-key-public-path abcdefg.public --registration-key-private-path abcdefg.private --isv-secrets key1:value1,key2:value2
Repository name> docker.io/containers/your-image
Container registry user name> username
Container registry password>
Allowed environment variables as comma separated list> ENV_PARAM
Allowed Linux capabilities to be enabled as comma separated list> AUDIT_CONTROL,AUDIT_WRITE
Gpg pass phrase for the private part of the registration key>
OK
The registration file was successfully created in the current working directory: registration.json.asc
Complete command executed:
ibmcloud hpvs registration-create --repository-name=docker.io/containers/your-image --cr-username=username --cr-pwd-path=<PATH> --allowed-env-keys="ENV_PARAM" --registration-key-public-path=abcdefg.public --cap-add=AUDIT_CONTROL,AUDIT_WRITE --registration-key-private-path=abcdefg.private --gpg-passphrase-path=<PATH>
As you work with your cluster, refer to the [IBM Cloud Kubernetes Service API reference](https://containers.cloud.ibm.com/global/swagger-global-api//) and [Community Kubernetes API reference](https://kubernetes.io/docs/reference/).



3. Cluster deployment:



1. [Create the cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters).
2. After the cluster is ready, [access your cluster](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster).
3. Spread your cluster across availability zones by [adding worker nodes and zones to your cluster](https://cloud.ibm.com/docs/containers?topic=containers-add_workers).



4. User access:



1. Make sure that your authorized cluster users can now also access the cluster by planning your user access strategy.
2. [Pick the correct access policy and role for your users](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewaccess_roles).
3. [Understand access roles for individual or groups of users in IBM Cloud IAM](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewiam_individuals_groups).
4. [Choose the scope of user access to cluster instances, Kubernetes namespace, or resource groups](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewresource_groups).
5. Allow users to create apps or audit your cluster activity by [assigning cluster access](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms). To see specific permissions and actions that you can grant users, see the [user access permissions reference](https://cloud.ibm.com/docs/containers?topic=containers-access_reference).





Need help?
Because this example uses an image in a Container Registry namespace in your account, Code Engine can automatically create and manage the registry access secret for you.
9. Select an existing namespace and name of the image in the registry for the Code Engine app to reference. For example, select mynamespace and select the image hello_repo in that namespace.
10. Select a value for Tag; for example, latest.
11. Click Done.
12. 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).
13. Click Create to create the application.
14. 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 to a Container Registry instance that is not in your account, see [Adding access to a Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).





 Deploying an app with an image in Container Registry with the CLI 

Deploy an application that uses an image in IBM Cloud® Container Registry with the CLI with the ibmcloud ce app create command. For a complete listing of options, see the [ibmcloud ce app create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-create) command.

Before you begin
You have two options for assigning access:



* Use the Permission sets drop-down list to assign one of the following predefined roles. After selecting a role, click Set.



* View Only gives the user permissions to view infrastructure details only.
* Basic User gives the user some, but not all, infrastructure permissions.
* Super User gives the user all infrastructure permissions.



* Select individual permissions for each category. To review permissions that are needed to perform common tasks in IBM Cloud Kubernetes Service, see [User access permissions](https://cloud.ibm.com/docs/containers?topic=containers-classic-roles).



5. Click Save.
6. In the Device tab, select the devices to grant access to.



* In the Select type group, you can grant access to all bare metal, dedicated, and virtual servers so that users can work with all [flavors for worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesplanning_worker_nodes).
* In the Enable future access group, you can grant the user access to all future bare metal, dedicated, and virtual servers.
* In the table of devices, make sure that the appropriate devices are selected.



7. To save your changes, click Set.
8. Important: If you are assigning permissions so that a user can manage clusters and worker nodes, you must assign the user access for working with support cases.



1. Click the Access policies tab, and then click Assign access.
2. Click the Account management card.
3. Select Support Center.
4. To allow the user to view, add, and edit support cases, select Administrator.
5. Click Assign.





Downgrading permissions? The action can take a few minutes to complete.





 Assigning infrastructure access through the CLI 

Classic infrastructure permissions apply only to classic clusters.
Otherwise, ask the account owner to [set up the API key and assign you the minimum user permissions in IBM Cloud IAM](https://cloud.ibm.com/docs/openshift?topic=openshift-access_referencecluster_create_permissions).

Command-line tools
: For quick access to your resources from the command line, try the [IBM Cloud Shell](https://cloud.ibm.com/shell). Otherwise, set up your local command-line environment by completing the following steps.



1. [Install the IBM Cloud CLI (ibmcloud), Kubernetes Service plug-in (ibmcloud ks), and IBM Cloud Container Registry plug-in (ibmcloud cr)](https://cloud.ibm.com/docs/containers?topic=containers-cli-install).
2. [Install the Red Hat OpenShift (oc) and Kubernetes (kubectl) CLIs](https://cloud.ibm.com/docs/containers?topic=containers-cli-install).
3. To work with VPC, install the infrastructure-service plug-in. The prefix for running commands is ibmcloud is.

ibmcloud plugin install infrastructure-service
4. Update your Kubernetes Service plug-in to the latest version.

ibmcloud plugin update kubernetes-service
5. Make sure that the [kubectl version](https://cloud.ibm.com/docs/containers?topic=containers-cli-install) matches the Kubernetes version of your VPC cluster. This tutorial creates a cluster that runs version 1.26.







 Step 1: Create a cluster in VPC 

Create an IBM Cloud Kubernetes Service cluster in your IBM Cloud Virtual Private Cloud (VPC) environment. For more information about VPC, see [Getting Started with Virtual Private Cloud](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).



1.
name: containerd-dockerhub-registry-config
command:
- /bin/sh
- -c
- 
!/bin/sh
set -uo pipefail
cat << EOF > /etc/containerd/certs.d/docker.io/hosts.toml
server = "https://docker.io"
[host."https://registry-1.docker.io"]
capabilities = ["pull", "resolve"]
EOF
volumeMounts:
- mountPath: /etc/containerd/certs.d/docker.io/
name: dockerhub-registry-config
containers:
- name: pause
image: "us.icr.io/armada-master/pause:3.5"
imagePullPolicy: IfNotPresent
volumes:
- name: dockerhub-registry-config
hostPath:
path: /etc/containerd/certs.d/docker.io/
Show more

For more information on updating a containerd registry host configuration, see the [containerd documentation](https://github.com/containerd/containerd/blob/v1.5.6/docs/hosts.md).
* [Using Podman to access your namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_podman)
* [Using Skopeo to access your namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_skopeo)



* [Accessing your namespaces programmatically](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_programmatic)



[Managing IAM access](https://cloud.ibm.com/docs/Registry?topic=Registry-iamiam)



* [Access policies](https://cloud.ibm.com/docs/Registry?topic=Registry-iamiam_access_policies)
* [Assign roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iamiam_assign_roles)
* [Context-based restrictions](https://cloud.ibm.com/docs/Registry?topic=Registry-iamiam_cbr)
* [Platform management roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iamplatform_management_roles)
* [Service access roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iamservice_access_roles)



* [Access roles for configuring Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_configure)
* [Access roles for using Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_using)



* [Assigning access to Container Registry in the console](https://cloud.ibm.com/docs/Registry?topic=Registry-iamregistry_iam_assign-access-console)
To log in by using other clients, see [Accessing your namespaces interactively](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive).

To upload (push) an image, complete the following steps:



1. Log in to the CLI by running the [ibmcloud cr login](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_login) command.

ibmcloud cr login

You must log in if you pull an image from your private IBM Cloud Container Registry.

If you have a problem when you try to log in, see [Why can't I log in to Container Registry?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-login) for assistance.
2. To view all namespaces that are available in your account, run the ibmcloud cr namespace-list command.
3. [Upload the image to your namespace.](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgs_registry_images_pushing)

If you get an unauthorized: authentication required or a denied: requested access to the resource is denied message, run the ibmcloud cr login command.



After you push your image to IBM Cloud Container Registry, you can do one of the following tasks.



* [Manage security with Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=ui) to find information about potential security issues and vulnerabilities.
* [Create a cluster and use this image to deploy a container](https://cloud.ibm.com/docs/containers?topic=containers-getting-startedgetting-started) to the cluster in IBM Cloud Kubernetes Service.







 Copying images between registries 

You can pull an image from a registry in one region and push it to a registry in another region so that you can share the image with users in both regions.

Zoom

![Copying images between registries.]
Before you start building images, review [planning information](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-build). You'll also need to verify that you can access the registry. See [Setting up authorities for container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).

Interested in configuring your project such that all users of the project can store and access images in Container Registry without having to manually create registry secrets? With sufficient permissions, you can configure this default registry access on a per location (region) basis. If you don't have sufficient permissions to perform these actions, you can use this page to help you understand the required permissions. See [Configuring project-wide settings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrations).

To learn about how to build your container image with a single Code Engine CLI command and create the container image without creating a reusable build configuration, see [Building a container image with stand-alone build commands (CLI)](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-standalone).

If you build multiple versions of the same container image, the latest version of the container image is downloaded and used when you run your job or deploy your application, unless a tag is specified for the image. If a tag is specified for the image, then the tagged image is used for the app or job.



 Create a build configuration that pulls source from public repository 

If your source is located in a public repository, create a build configuration with settings that include information about where to pull source from a public repository. For the build output, you can choose to specify registry details along with a registry secret to access your built image in the registry. Or, you can choose to let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry. For this case, you do not need to specify a registry secret or the location of the image registry.
Defining IAM access policies for Container Registry 

As an administrator, you can define IBM Cloud® Identity and Access Management (IAM) access policies to create different levels of access for different users in IBM Cloud® Container Registry. For example, you can authorize some users to view quotas and other users to set quotas.

You must define IAM

access policiesfor every user that works with IBM Cloud Container Registry. The scope of an IAM access policy is based on the user's role or roles that determine the actions that they are allowed to do. Some roles are predefined, but custom roles can be defined.

To find out more about IAM access policies, see [IBM Cloud IAM roles](https://cloud.ibm.com/docs/account?topic=account-userroles).

You can assign Container Registry namespaces to a [resource group](https://cloud.ibm.com/docs/account?topic=account-rgs) and scope access policies to that group, see [Planning namespaces](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_setup_cli_namespace_plan). However, you can still define access policies that are scoped to individual Container Registry namespaces or to all namespaces that are owned by the account.



 Creating policies 

Before you begin, complete the following tasks:



* Decide on the roles that each user needs and on which resources in IBM Cloud Container Registry, see [IAM roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iamiam). You can create multiple policies, for example, you can grant write access on a resource but grant read access only on another resource. Policies are additive, which means that a global read policy and a resource-scoped write policy grants both read and write access on that resource.
* [Invite users to an account](https://cloud.ibm.com/docs/account?topic=account-iamuserinviamuserinv).