vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Start each instance:

Zoom

![IIDR Configuration Tool](https://cloud.ibm.com/docs-content/v1/content/68e10678b2f8b8694884ecb5442c326c9b60a3fb/Db2whc/connecting/images/IIDR_instances.jpg)

Figure 3. IIDR Configuration Tool
3. Launch the InfoSphere Data Replication management console and use Access Manager to complete the following steps:

a. Create a datastore to connect to your source instance by using the Datastore tab. Because a Db2 database was not originally supported as a source database, you must provide user and password information for the source database by clicking Connection Parameters.

Zoom

![Datastore Properties - Source](https://cloud.ibm.com/docs-content/v1/content/68e10678b2f8b8694884ecb5442c326c9b60a3fb/Db2whc/connecting/images/IIDR_source_datastore.jpg)

Figure 4. View of source datastore properties

b. Create a datastore to connect to your target instance by using the Datastore tab. You must provide user and password information by clicking Connection Parameters.

Zoom

![Datastore Properties - Target](https://cloud.ibm.com/docs-content/v1/content/68e10678b2f8b8694884ecb5442c326c9b60a3fb/Db2whc/connecting/images/IIDR_target_datastore.jpg)

Figure 5. View of target datastore properties

c. If the user (for example, admin) that connects to the Access Server does not exist, create that user:

Zoom

!
* UI
* CLI







 Deploying app workloads from images in a public registry 

Deploy your app with Code Engine. You can create an app from the console or with the CLI.



 Deploying an app from the console 

Deploy an application with an image from a public registry that does not require credentials with the Code Engine console.

This example references the public icr.io/codeengine/helloworld image in [IBM Cloud® Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-crimage). Alternatively, you can also reference an image in a public Docker Hub or an [image in a private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-private).



1. Open the [Code Engine](https://cloud.ibm.com/codeengine/overview) console.
2. Select Start creating from Run a container image.
3. Select Application.
4. Enter a name for the application. Use a name for your application that is unique within the project.
5. Select a project from the list of available projects. You can also [create a new one](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-projectcreate-a-project). You must have a selected project to deploy an app.
6. Specify a container image for your app, for example, icr.io/codeengine/helloworld. If you have your own source code that you want to turn into a container image for the app, see [building a container image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image). For more information about the code that is used for this example, see [helloworld](https://github.com/IBM/CodeEngine/tree/main/helloworld).
7. Modify any default values for endpoint or runtime settings.
Remember that you'll be responsible for managing your certificate if you upload a custom certificate. For example, IBM CIS won't track the certificate expiration dates.





 Alternatively, use a certificate provisioned by CIS 

IBM CIS has partnered with several Certificate Authorities (CAs) to provide domain wildcard certificates for our customers, by default. Manual verification could be required for setting up these certificates, and your support team can help you perform these additional steps.





 Change your TLS setting to End-to-End CA Signed 

Most of our Enterprise customers use the End-to-End CA Signed security setting. An End-to-End CA Signed setting requires a valid, CA-signed certificate installed on your web server. The certificate's expiration date must be in the future, and it must have a matching hostname or Subject Alternative Name (SAN).
Before you can create an Object Storage subscription, you must assign the Notifications Manager role to Code Engine. As a Notifications Manager, Code Engine can view, modify, and delete notifications for an Object Storage bucket.

Only account administrators can assign the Notifications Manager role.

When you assign the Notifications Manager role to your project, you can then create event subscriptions for any regional buckets in your Object Storage instance that are in the same region as your project.



1. Navigate to the Grant a Service Authorization page in the [IAM dashboard](https://cloud.ibm.com/iam/authorizations/grant).
2. From Source service, select Code engine.
3. Select Resources based on selected attributes and Source service instance. Then, select a Code Engine project.
4. In Target service, select Cloud Object Storage.
5. Select Resources based on selected attributes and Service instance. Then, select your IBM Cloud Object Storage instance.
6. Assign the Notifications Manager role and click Authorize.



You can also assign the Notifications Manager role to your project by using the [ibmcloud iam authorization-policy-create](https://cloud.ibm.com/docs/account?topic=account-ibmcloud_commands_iamibmcloud_iam_authorization_policy_create) command.





 Subscribing to IBM Cloud Object Storage events for an application 

You can work with IBM Cloud Object Storage subscriptions from the console or with the CLI so events are sent to a Code Engine application.

By default, events are routed to the root URL of the destination application. You can send events to a different destination within the app by using the --path option. For example, if your subscription specifies --path /event, the event is sent to https://<base application URL>/events.

Events are sent to applications as HTTP POST requests. For more information, see [HTTP headers and body information for events](https://cloud.ibm.com/docs/codeengine?topic=codeengine-eventing-cosevent-producersub-header-body-cos).
Figure 2. IIDR New Instance - Target instance

c. Start each instance:

Zoom

![IIDR Configuration Tool](https://cloud.ibm.com/docs-content/v1/content/2a59ee244ed61eb35ab50e45757b42d22f720132/Db2onCloud/connecting/images/IIDR_instances.jpg)

Figure 3. IIDR Configuration Tool
3. Launch the InfoSphere Data Replication management console and use Access Manager to complete the following steps:

a. Create a datastore to connect to your source instance by using the Datastore tab. Because a Db2 database was not originally supported as a source database, you must provide user and password information for the source database by clicking Connection Parameters.

Zoom

![Datastore Properties - Source](https://cloud.ibm.com/docs-content/v1/content/2a59ee244ed61eb35ab50e45757b42d22f720132/Db2onCloud/connecting/images/IIDR_source_datastore.jpg)

Figure 4. View of source datastore properties

b. Create a datastore to connect to your target instance by using the Datastore tab. You must provide user and password information by clicking Connection Parameters.

Zoom

![Datastore Properties - Target](https://cloud.ibm.com/docs-content/v1/content/2a59ee244ed61eb35ab50e45757b42d22f720132/Db2onCloud/connecting/images/IIDR_target_datastore.jpg)

Figure 5. View of target datastore properties

c. If the user (for example, admin) that connects to the Access Server does not exist, create that user:

Zoom

!
Select the Source Provider and enter the URL of your repo, for example: https://github.com/my-org/my-repo.



3. Click Continue.



If you want to access more advanced source repository settings such as using a custom server and changing the cloning behavior, select Switch to advanced configuration.





 Step 4: Setting up your delivery pipeline 

Name the delivery pipeline for deploying your applications to multiple clusters in your Satellite cluster group.



1. Enter the pipeline name, which is displayed in your toolchain.
2. Click Continue.







 Step 5: Providing an API key 

Provide the IBM Cloud API key info that the toolchain can use to access your Satellite location.

If you have an existing API key or multiple existing API keys, follow these steps.



1. Select the secret provider or providers that you use. You can select one or more.
2. Click Continue.
3. Provide the necessary info for accessing your secret provider.



If you don't have an existing API key, you can ignore the options on this page and click Continue to proceed to the next page, where you can create an IBM Cloud API key and save it to a secret provider.





 Step 6: Setting up Satellite Config 

Specify the settings that the Satellite Config tool can use when deploying resources.



1. Provide IBM Cloud API key. If you did not provide an existing IBM Cloud API key on the previous page, you can create a new IBM Cloud API key by clicking New.

You can save this key to a secret provider of your choice for reuse by selecting that option when you create the new key or by clicking the key icon.
2. Define the namespace that you want your resources to be deployed to. This must be an existing namespace.
3. Specify the branch to deploy the resource to; for example, v1.
4. Provide the path to deploy the resource to; for example, deployments.
5. Select the cluster group to receive the resources that you are deploying.
6. Provide the displayed name of the Satellite configuration.
7. Click Continue.
If REGISTRY is not specified, the default is docker.io. If TAG is not specified, the default is latest.
4. After your app is updated, you can access the app. To obtain the URL of your app, run ibmcloud ce app get --name myhelloapp --output url. When you curl the myhelloapp app, the app returns Hello World from Code Engine, which demonstrates the app is now using the helloworld_repo image.







 Updating an app to reference an image that is built from source code from the console 

Update an application to reference an image that is built from source code by using the Code Engine console.

For this example, let's update the helloapp that you created in [Deploying an application that references an image in a container registry from the console](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-crimagedeploy-app-crimage-console) to reference an image that is built from your source code.

For more information about creating a build configuration from the console, see [create a build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-imagebuild-create-console).



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, you can create an image build, or you can rerun an existing image build that is referenced by your application. To create an image build, click Create image from source to run an image build.
The following is an example using the ibmcloud atracker target rm --target xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx command.

Are you sure you want to remove the target with target ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx? [y/N]>y
OK
Target with target ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx was successfully removed.

The following is an example using the ibmcloud atracker target rm --target xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -force command.

This example shows a failed command where the specified target could not be found.

Are you sure you want to remove the Target bearing Target ID 33333333-3333-3333-3333-333333333333? [y/N]> y
FAILED
Something went wrong. Error:
Status Code: 404
Incident ID: 67a33257-d5a4-46ec-94d9-14eb70e94f3d
Code: not_found
Message: The target id specified in target_id field is not found.







 Validating a target using the CLI 

Use this command to validate that a target is correctly configured for an IBM Cloud Activity Tracker Event Routing region.

ibmcloud atracker target validate --target TARGET [--region REGION] [--output FORMAT]



 Command options 

--target TARGET
: The ID or name of the target.

--region REGION | -r REGION
: Name of the region, for example, us-south or eu-gb. If not specified, the region logged into, or targeted, will be used.

--output FORMAT
: Currently supported format is JSON. If specified, output will be returned in JSON format. If JSON is not specified, output will be returned in a tabular format.

help | --help | -h
: List options available for the command.





 Example
Timeout: 10m0s



When you submit a build that pulls code from a local directory, your source code is packed into an archive file and uploaded to your IBM Cloud Container Registry instance. After the build run is completed, you can see your built image, such as codeengine-build, in the IBM Cloud Container Registry instance. You also see a source image with -source appended to the name of your build, such as codeengine-build-source. You can delete this source image without impact.

For more information about builds, check the [troubleshooting tips](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-build).







 Next steps for builds 

You can now create an application or job from your container image. See [Deploying applications](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloads) and [Running jobs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan).

Looking for more code examples? Check out the [Samples for IBM Cloud Code Engine GitHub repo](https://github.com/IBM/CodeEngine).
9. Click Save and create to save your changes, run the build with your changes, and deploy the app revision.
10. After the application status changes to Ready, you can test the app revision. Click Test application and then click Send request in the Test application pane. To open the application in a web page, click Application URL.







 Updating an app to reference an image that is built from source code with the CLI 

Update an application to reference an image that is built from source code by using the Code Engine CLI.

For this example, let's change the myhelloapp that you updated in [Updating an app to reference a different image in Container Registry with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-update-appupdate-app-crimage-cli) to reference a different image that is built from your source code.

From the previous example, the myhelloapp app references the us.icr.io/mynamespace2/helloworld_repo by using the myregistry access information. Let's create a build configuration, run the build, and update the myhelloapp to reference the image that was built from source code.



1. Create the build configuration. For example, the following build create command creates a build configuration that is called helloworld-build. This configuration builds from the public Git repo https://github.com/IBM/CodeEngine, uses the dockerfile strategy and medium build size, and stores the image to us.icr.io/mynamespace/codeengine-helloworld by using the image registry secret that is defined in myregistry.

ibmcloud ce build create --name helloworld-build --image us.icr.io/mynamespace/codeengine-helloworld --registry-secret myregistry --source https://github.com/IBM/CodeEngine --commit main --context-dir /hello --strategy dockerfile --size medium
2. Run the build.
This service ID must be authorized to read and write to IBM Cloud Container Registry. If no service ID exists, Code Engine creates one for you. Note that this service ID is used for subsequent Code Engine build requests that are run from the same project.
3. This example builds code from a public GitHub repository (--build-source https://github.com/IBM/heroku-to-code-engine). The source code is packed into an archive file and uploaded to a managed namespace within the IBM Cloud Container Registry instance in your account. Note that you can target only IBM Cloud Container Registry for your local builds. For more information about IBM Container Registry, including information about quota limits and access, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started).
4. Code Engine builds your source code into an image. The source image is created in the same namespace as your source archive file.
5. After the build completes, your application is deployed. You can access your application from the provided URL.



With Code Engine, you automatically get many of the same features as Heroku, such as autoscaling and blue-green roll-out of updates, but you'll also enjoy the benefits of newer features such as scaling down-to-zero, ensuring that you are not charged if your application is not active.

Want to learn more about your options for building your source code? See the [application create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-create) and the [job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create) commands.

Want to learn more about applications and jobs?
Working with apps in Code Engine 

An application, or app, runs your code to serve HTTP requests. In addition to traditional HTTP requests, IBM Cloud® Code Engine also supports applications that use WebSockets as their communications protocol. The number of running instances of an app are automatically scaled up or down (to zero) based on incoming requests and your configuration settings. An app contains one or more revisions. A revision represents an immutable version of the configuration properties of the app. Each update of an app configuration property creates a new revision of the app.

Before you begin



* If you want to use the Code Engine console, go to [Code Engine overview](https://cloud.ibm.com/codeengine/overview).
* If you want to use the CLI, [set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* Plan and choose your approach for making your code run as a Code Engine application component.
* Ensure that your app follows the [12-factor app methodology](https://12factor.net/).



For security features provided with Code Engine, see [Code Engine and security](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secure).

Code Engine provides custom resource definition (CRD) methods. For more information, see [Code Engine API reference - Serving CRD methods](https://cloud.ibm.com/docs/codeengine?topic=codeengine-apiapi-crd-serving).



 How do I make my code run as a Code Engine application component? 

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.



* If you have a container image, per the [Open Container Initiative (OCI) standard](https://opencontainers.org/), then you need to provide only a reference to the image, which points to the location of your container registry when you create and deploy your app.
This option supports a comma-separated list of log sources to apply to the configuration. If you don't provide a log source, logging configurations are created for container and ingress log sources. 
 --type syslog The value syslog forwards your logs to an external server. 
 --namespace Optional: The Kubernetes namespace that you want to forward logs from. Log forwarding is not supported for the ibm-system and kube-system Kubernetes namespaces. This value is valid only for the container log source. If you don't specify a namespace, then all namespaces in the cluster use this configuration. 
 --hostname Specify the hostname or IP address of the log collector service. 
 --port The ingestion port. If you don't specify a port, then the standard port 9091 is used. For syslog, specify the port of the log collector server. If you don't specify a port, then the standard port 514 is used. 
 --app-containers Optional: To forward logs from apps, you can specify the name of the container that contains your app. You can specify more than one container by using a comma-separated list. If no containers are specified, logs are forwarded from all the containers that contain the paths that you provided. 
 --app-paths The path on a container that the apps log to. To forward logs with source type application, you must provide a path. To specify more than one path, use a comma-separated list; for example, /var/log/myApp1/,/var/log/myApp2/ 
 --syslog-protocol When the logging type is syslog<, the transport layer protocol. You can use the following protocols: udp, tls, or tcp. When forwarding to a rsyslog server with the udp protocol, logs that are over 1KB are truncated. 
 --ca-cert Required: When the logging type is syslog and the protocol is tls, the Kubernetes secret name that contains the certificate authority certificate.
Setting up your secure software development architecture 

The DevSecOps Application Lifecycle Management deployable architecture streamlines the process to set up your secure software supply chain by using a set of continuous integration (CI), continuous deployment (CD), and continuous compliance (CC) toolchain templates. These templates use a collection of tool integrations and customizable reference Tekton pipelines for build, scan, test, change management, and deploy applications.

The Tekton pipelines provide a framework of custom scripts that you can use to ensure the compliant and automated orchestration of code and configuration changes. The pipelines maintain a GitOps release inventory, while they collect and store evidence that can be used to generate auditable change requests. Additionally, the continuous compliance pipeline periodically scans the deployed artifacts and associated source code repositories for vulnerabilities.

For more information about configuring the deployable architecture to fit your needs, see the [DevSecOps deployment guide](https://cloud.ibm.com/docs/devsecops-alm?topic=devsecops-alm-devsecops-alm-dep). You can use a [project](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-setup-project) to deploy this architecture in all of your application development environments, so that your development team can take a shift-left approach by identifying security risks and exposures early, so that they are addressed before code ever reaches production.





 Ensuring continuous compliance with the CC pipeline 

The [CI](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-ci-pipeline)/[CD](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cd-pipeline) pipelines ensure that the application code that your team develops is secure and free of vulnerabilities before code is pushed to production. Once your code reaches production, you can use the CC pipeline to continuously scan your production code for new vulnerabilities.