vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For example, the following command creates registry access to a Docker Hub registry called privatedocker that is at https://index.docker.io/v1/ and uses your username and password.

ibmcloud ce secret create --format registry --name privatedocker --server https://index.docker.io/v1/ --username <Docker_User_Name> --password <Password>

Example output

Creating registry secret 'privatedocker'...
OK
3. Create your job configuration and reference the image in your private Docker Hub registry. For example, create the mytestjob job configuration to reference the docker.io/privaterepo/testjob by using the privatedocker access information.

ibmcloud ce job create --name mytestjob --image docker.io/privaterepo/testjob --registry-secret privatedocker



The format of the name of the image for this job is REGISTRY/NAMESPACE/REPOSITORY:TAG where REGISTRY and TAG are optional. If REGISTRY is not specified, the default is docker.io. If TAG is not specified, the default is latest.





 Next steps 



* After you create your job, submit the job to run it. See [Run a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job). You can run your job multiple times.
* After you [run your job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job), to view details of your job and job runs, see [access job details](https://cloud.ibm.com/docs/codeengine?topic=codeengine-access-job-details).
* Now that your job is created, consider making your jobs event-driven.
* [Buildah](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_buildah)
* [Docker](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_docker)
* [Podman](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_podman)
* [Skopeo](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_skopeo)





 Using Buildah to access your namespace 

Log in to the registry by using the Buildah CLI.

You can use the Buildah CLI to log in to the registry by using a bearer token, replace <registry_domain> with the [domain](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth):

ibmcloud iam oauth-tokens | sed -ne '/IAM token/s/.* //p' | buildah login -u iambearer --password-stdin <registry_domain>





 Using Docker to access your namespace 

Log in to the registry by using the Docker CLI.

You can use the Docker CLI to log in to the registry by using a refresh token in the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started):

ibmcloud cr login --client docker

You can use the Docker CLI to log in to the registry by using a bearer token:



1.
Policies enable access to be granted at different levels. Some options include the following access levels:



* Access to the service in your account
* Access to a specific resource within the service
* Access to all IAM-enabled services in your account
* Access to resources within a resource group



If you want to restrict user access to one or more

namespacesfor an ID that you are using for automation, use an IAM service ID. For more information about service IDs, see [Creating and working with service IDs](https://cloud.ibm.com/docs/account?topic=account-serviceidsserviceids).

You can set permissions so that you can configure access to resources within a namespace at the

resource grouplevel. For more information, see [User permissions for working with namespaces](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_setup_cli_namespace_plan_perm).

For more information about enabling policies for Container Registry, see [Defining IAM access policies](https://cloud.ibm.com/docs/Registry?topic=Registry-useruser).





 Assign roles 

After you define the scope of the IAM access policy, you assign a role.

If a specific role and its actions don't fit the use case that you're looking to address, you can [create a custom role](https://cloud.ibm.com/docs/account?topic=account-custom-rolescustom-access-roles) and pick the actions to include.

Review the following tables that outline the actions that each role allows within the Container Registry service.



* [Platform management roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iam&interface=uiplatform_management_roles) enable users to perform tasks on service resources at the platform level, for example, assign user access to the service, create or delete instances, and bind instances to applications.
Use the API key and [domain](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth) to log in to the registry by running the following Podman command, replace <apikey> with the API key and <registry_domain> with the domain:

podman login -u iamapikey -p <apikey> <registry_domain>





 Using Skopeo to authenticate with the registry 

You can use Skopeo to authenticate with the registry so that you can push and pull images to and from the registry.

For example, you can use the following Skopeo command to pull an image from Docker Hub and push it to your namespace. Replace <registry_domain> with the name of your [domain](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth), <namespace> with your namespace, and <apikey> with your API key:

skopeo --insecure-policy --override-os linux copy docker://busybox:latest docker://<registry_domain>/<namespace>/busybox:latest --dest-creds iamapikey:<apikey>









 Accessing your namespaces interactively 

You can use bearer tokens and refresh tokens to push and pull images to and from your namespaces interactively.

Examples of how to access your namespaces interactively are provided for the following clients:



* [Buildah](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_buildah)
* [Docker](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_docker)
* [Podman](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive_auth_podman)
Policies enable access to be granted at different levels. Some options include the following access levels:



* Access to the service in your account
* Access to a specific resource within the service
* Access to all IAM-enabled services in your account
* Access to resources within a resource group



If you want to restrict user access to one or more

namespacesfor an ID that you are using for automation, use an IAM service ID. For more information about service IDs, see [Creating and working with service IDs](https://cloud.ibm.com/docs/account?topic=account-serviceidsserviceids).

You can set permissions so that you can configure access to resources within a namespace at the

resource grouplevel. For more information, see [User permissions for working with namespaces](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_setup_cli_namespace_plan_perm).

For more information about enabling policies for Container Registry, see [Defining IAM access policies](https://cloud.ibm.com/docs/Registry?topic=Registry-useruser).





 Assign roles 

After you define the scope of the IAM access policy, you assign a role.

If a specific role and its actions don't fit the use case that you're looking to address, you can [create a custom role](https://cloud.ibm.com/docs/account?topic=account-custom-rolescustom-access-roles) and pick the actions to include.

Review the following tables that outline the actions that each role allows within the Container Registry service.



* [Platform management roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iamplatform_management_roles) enable users to perform tasks on service resources at the platform level, for example, assign user access to the service, create or delete instances, and bind instances to applications.
* [Configuring project-wide access to Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-cr)



* [What access permissions are required for Code Engine managed access to IBM Cloud Container Registry?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-cr-access)
* [What's the relationship between the service ID and the registry secret?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-cr-relation)
* [Configuring Container Registry access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-cr-config)
* [Removing Code Engine managed access to Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-cr-remove)









 Deploying applications 

[Working with apps in Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsapplication-workloads)



* [How do I make my code run as a Code Engine application component?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsdeploy-app-containerimage)
* [Considerations for HTTP handling](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsconsiderationshttphandlingapp)
* [Options for visibility for a Code Engine application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsoptionsvisibility)
Debugging images 

Use the troubleshooting tips to learn how to troubleshoot images.



 Working with images 

A build, or image build, is a mechanism that you can use to create a container image from your source code.

A container registry, or registry, is a service that stores container images. For example, IBM Cloud Container Registry and Docker Hub are container registries. A container registry can be public or private. A container registry that is public does not require credentials to access. In contrast, accessing a private registry does require credentials.

Code Engine requires access to container registries to complete the following actions:



* To retrieve (or "pull") a container image to run an app or job
* To store a newly created container image as an output of an image build
* To store and retrieve local files when a build is run from local source



Whether your code exists as source in a local file or in a Git repository, or your code is a container image that exists in a public or private registry, Code Engine provides you a streamlined way to run your code as an app or job.

When you want Code Engine to handle the build process for you, Code Engine can pull your source code and create the container image for you from your source code. Code Engine supports building from a Dockerfile or Cloud Native Buildpacks.

Consider the following points before you build your container image:



* 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).
* 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.
If the container registry does not require authentication, set the -no-auth parameter to prevent prompting. If no environment parameters are required, set the -no-env parameter, for example:

ibmcloud hpvs registration-create --no-env --no-auth

Where: --repository-name REPO-NAME : Is the fully qualified name for the repository.

--cr-username USER-NAME
: Is the username for the login on the container repository. It can be any string of 4 - 30 characters.

--cr-pwd-path FILE-PATH
: Is the path for the file that contains the container repository password.

To ensure there are no trailing spaces in the file path, you can specify it as vi -b file_name , :set noeol, :wq.

--no-auth
: Is the parameter that must be set if the image does not require authorization to download. In this case, you don't need to provide cr-username and cr-pwd-path parameters. If you do, these parameters are ignored.

--allowed-env-keys ENV-KEYS
: Specifies the allowed environment variable keys as a comma-separated list. The keys must be strings of 1 - 64 characters.

--no-env
: This parameter can be set if the image does not require any allowed environment variables. In this case, you don't need to provide the allowed-env-keys parameter. If you do, it is ignored.

--image-key-id IMAGE-KEY-ID
: The ID of the root key that was used to sign the image. It must contain 64 characters long. 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 more information about Code Engine requirements for accessing images in a container registry, see [Accessing container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).





 What's the relationship between the service ID and the registry secret? 

When you configure default registry access for a specific location, you can view details about what Code Engine does for you, including information about the service ID and its access policies, API key, and registry secret.

Code Engine uses a service ID to enable registry access to Container Registry, on behalf of the user, instead of using the identity of the user that is logged in.

The registry secret is a Code Engine generated and managed registry secret that includes an autogenerated API key for it. This secret is used for accessing images in Container Registry.

When default registry access is configured for a location (region), the service ID and registry secret apply to your specific project.





 Configuring Container Registry access 

You can configure registry access such that all users in the project can access and work with images in IBM Cloud Container Registry from the Code Engine console.



1. Go to the Integrations page.



1. Select your project from the [Projects page in the Code Engine console](https://cloud.ibm.com/codeengine/projects).
2. Click Project settings > Integrations.



2. In the Container Registry tile, click the row for the location that you want to configure registry access.
3. From the "Configure default registry access" page, you can optionally expand the What Code Engine does for you section to view information about what Code Engine automatically creates for you when you configure default registry access to a specific location. View information about the service ID and the access policies that are assigned to this service ID, the API key that Code Engine automatically generates for the service ID, and the registry secret that is used for this registry access.
4. Click Configure to configure the default registry access for a specific location.
5. From the table, you can view configuration status by location and the autogenerated registry secret.
6.
If you want to pull images from the shared account to your own account, then you must be [authorized to access IBM Cloud Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).





 Accessing images in a different account 

You can assign IBM Cloud IAM access policies to users or a service ID to restrict permissions to specific registry image namespaces or actions (such as push or pull). Then, create an API key and store these registry credentials in Code Engine.

For example, to access images in other IBM Cloud accounts, [create an API key](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-your-account-api-key) that stores the IBM Cloud Container Registry credentials of a user or service ID in that account. Then, in Code Engine, use that key to [create access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce) in your account.





 Accessing images in a private Docker Hub account 

To access images in a private Docker Hub account, create registry access by providing your password or an access token. By using an access token, you can more easily grant and revoke access to your Docker Hub account without requiring a password change. For more information about access tokens and Docker Hub, see [Managing access tokens](https://docs.docker.com/docker-hub/access-tokens/).

After you decide whether to use your password directly or to create an access token, [create your registry access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce).





 Add registry access to Code Engine
6. Complete your setup by using one of the following options.



* To pull images in Kubernetes namespaces other than default or from other IBM Cloud accounts, [copy or create another image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryother).
* To restrict the image pull secret access to particular registry resources such as namespaces or regions:



1. Make sure that [IBM Cloud IAM policies for IBM Cloud Container Registry are enabled](https://cloud.ibm.com/docs/Registry?topic=Registry-user).
2. [Edit the IBM Cloud IAM policies](https://cloud.ibm.com/docs/account?topic=account-serviceidsupdate_serviceid) for the service ID, or [create another image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryother_registry_accounts).













 Using an image pull secret to access images in other IBM Cloud accounts or external private registries from non-default Kubernetes namespaces 

Set up your own image pull secret in your cluster to deploy containers to Kubernetes namespaces other than default, use images that are stored in other IBM Cloud accounts, or use images that are stored in external private registries. Further, you might create your own image pull secret to apply IAM access policies that restrict permissions to specific registry image namespaces, or actions (such as push or pull).

After you create the image pull secret, your containers must use the secret to be authorized to pull an image from the registry. You can add the image pull secret to the service account for the namespace, or refer to the secret in each deployment. For instructions, see [Using the image pull secret to deploy containers](https://cloud.ibm.com/docs/containers?topic=containers-registryuse_imagePullSecret).

Image pull secrets are valid only for the Kubernetes namespaces that they were created for. Repeat these steps for every namespace where you want to deploy containers.
The global registry stores IBM-provided public images, and regional registries store your own private or public images.
6. Verify your connection by [listing your container registry namespaces](https://cloud.ibm.com/apidocs/container-registrylist-namespaces).







 Running oc commands from behind an allowlist 

If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, to run oc commands, you must allow TCP access for the cluster.

When a cluster is created, the port in the service endpoint URLs is randomly assigned from within 30000-32767. You can either choose to open port range 30000-32767 for any cluster that might get created or you can choose to allow access for a specific existing cluster.

Before you begin, allow access to [run ibmcloud oc commands](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_bx).

To allow access for a specific cluster:



1. Log in to the IBM Cloud CLI. Enter your IBM Cloud credentials when prompted. If you have a federated account, include the --sso option.

ibmcloud login [--sso]
2. If the cluster is in a resource group other than default, target that resource group. To see the resource group that each cluster belongs to, run ibmcloud oc cluster ls. Note: You must have at least the [Viewer role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for the resource group.

ibmcloud target -g <resource_group_name>
3. Get the name of your cluster.

ibmcloud oc cluster ls
4. Retrieve the service endpoint URLs for your cluster.



* If only the Public Service Endpoint URL is populated, get this URL. Your authorized cluster users can access the master through this endpoint on the public network.
* If only the Private Service Endpoint URL is populated, get this URL.
Log in to the registry by using the Docker CLI.

You can use the Docker CLI to log in to the registry by using a refresh token in the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started):

ibmcloud cr login --client docker

You can use the Docker CLI to log in to the registry by using a bearer token:



1. Generate a bearer token by using [ibmcloud iam oauth-tokens](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_oauth_tokens).
2. Log in to the registry by using the docker login command. Replace <bearer_token> with your bearer token and <registry_domain> with the [domain](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth):

docker login -u iambearer --password <bearer_token> <registry_domain>







 Using Podman to access your namespace 

Log in to the registry and pull an image by using the CLI, where <image_name> is the name of the image.

ibmcloud cr login --client podman

podman pull <image_name>





 Using Skopeo to access your namespace 

Log in to the registry by using the Skopeo CLI.

You can use the Skopeo CLI to log in to the registry by using a bearer token, replace <registry_domain> with the [domain](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth):

ibmcloud iam oauth-tokens | sed -ne '/IAM token/s/.* //p' | skopeo login -u iambearer --password-stdin <registry_domain>







 Accessing your namespaces programmatically
For more information about adding an image to Container Registry, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgetting-started).



1. Navigate to your application page. One way to navigate to your application page is to



* Locate the [Code Engine Projects page](https://cloud.ibm.com/codeengine/projects).
* Click the name of your project to open the Overview page.
* Click Applications to open a list of your applications. Click the name of your application to open the application page.



2. Click Configuration to open the configuration details for the selected application revision.
3. Click Edit and create new revision to update the application.
4. From the Code tab, click Configure image to open the configure image dialog. For this example, update the app to reference an existing ibmcregistry registry, select the mynamespace2 namespace, select the helloworld-repo image, and select 1 as the value for tag. From the configure image page,



* If the image you want to use resides in the same Container Registry account, select the access for the registry.
* If the image that you want to use resides in a different container registry account, you can select the registry access for this registry. If the registry access does not exist, you must first [create your IAM API key](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-your-account-api-key) and then [Add registry access to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce).