vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Register a custom domain by working with your Domain Name Service (DNS) provider or [IBM Cloud DNS](https://cloud.ibm.com/docs/dns?topic=dns-getting-started).
2. Define an alias for your custom domain by specifying the load balancer external IP as a Canonical Name record (CNAME). In the following example, the load balancer with the external IP of 1234abcd-us-south.lb.appdomain.cloud is reachable at www.your-custom-domain.com.



Host/Service
: The prefix where you want to reach your app such as, www.

Resource Type
: Select CNAME.

TTL
: Select a time to live.

Value/Target
: The LoadBalancer external IP that you retrieved earlier. For example 1234abcd-us-south.lb.appdomain.cloud.. Note that when using IBM Cloud DNS, make sure to enter a trailing period.
* IBM-provided subdomain: Use nlb-dns commands to generate a subdomain with a TLS certificate for the VPC ALB hostname. IBM Cloud takes care of generating and maintaining the wildcard TLS certificate for the subdomain for you.



1. Create a DNS subdomain and TLS certificate.

ibmcloud ks nlb-dns create vpc-gen2 --cluster <cluster_name_or_id> --lb-host <vpc_lb_hostname> --type (public|private)
2. Verify that the subdomain is created. For more information, see [Understanding the subdomain format](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostnameloadbalancer_hostname_format).

ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>

Example output

Subdomain Load Balancer Hostname Health Monitor SSL Cert Status SSL Cert Secret Name
Get caching settings for a given DNS domain.

ibmcloud cis cache-settings DNS_DOMAIN_ID [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

DNS_DOMAIN_ID
: The ID of DNS domain. Required.

-i, --instance
: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set is used.

--output
: Specify output format, only JSON is supported.





 Examples 

Get caching settings for domain 31984fea73a15b45779fa0df4ef62f9b.

ibmcloud cis cache-settings 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"







 ibmcloud cis cache-settings-update 

Update cache settings for a give DNS domain.

ibmcloud cis cache-settings-update DNS_DOMAIN_ID [--caching-level LEVEL] [--development-mode (on | off)] [--serve-stale-content (on | off)] [--query-string-sort (on | off)] [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

DNS_DOMAIN_ID
: The ID of DNS domain. Required.

--caching-level
: Specify under what URL conditions you want to deliver cached assets to the user. Valid values: no-query-string, query-string-independent, query-string-dependent.



* no-query-string: Only delivers resources from cache when there is no query string.
* query-string-independent: Delivers the same resource to everyone independent of the query string.
* query-string-dependent: Delivers a different resource each time the query string changes.



--browser-expiration
: Specify how long you want the user's browser to store cached assets.
(https://cloud.ibm.com/docs/codeengine?topic=codeengine-domain-mappingsprepare-custom-domain-cert) and [Can I use Cloud Internet Services (CIS) for domain management when I am using custom domain mapping with Code Engine?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-domain-mappingsprepare-use-cis)

Updated versions for buildpacks
: See [Choosing a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).





 10 November 2022 

CLI version 1.40.1 released
: See [CLI version history](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli_versions).





 03 November 2022 

Added support for custom domain mappings
: Code Engine adds support for mapping your own custom domain to a Code Engine application to route requests from your custom URL to your application from the Code Engine console. See [Configuring custom domain mappings for your app](https://cloud.ibm.com/docs/codeengine?topic=codeengine-domain-mappings).







 October 2022 

Review the release notes for October 2022.



 27 October 2022 

CLI version 1.40.0 released
: See [CLI version history](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli_versions).

Updated support of ephemeral storage for apps and jobs
: Code Engine adds support for setting ephemeral storage for apps and jobs in the console. Added validation checks for ephemeral storage to clarify the relationship between ephemeral storage and memory. Ephemeral storage is bounded by the configured memory.



* See [Limits and quotas for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limits).
Set up a domain for your app.



* IBM-provided domain: If you don't need to use a custom domain, a route hostname is generated for you in the format <service_name>-<project>.<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud. Continue to the next step.
* Custom domain: Work with your DNS provider to create a custom domain. Note that if you previously set up a third-party load balancer in front of your Ingress controller, work with your DNS provider to create a custom domain for the load balancer instead.



3. Get the IP addresses for the Ingress controller service in the EXTERNAL-IP column.

oc get svc router-external-default -n openshift-ingress
4. Create a custom domain with your DNS provider. If you want to use the same subdomain for multiple services in your cluster, you can register a wildcard subdomain, such as .example.com.
5. Map your custom domain to the Ingress controller's IP addresses by adding the IP addresses as A records.
6. Set up a route that is based on the [type of TLS termination that your app requires](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroute-types). If you don't have a custom domain, don't include the --hostname option so that a route hostname is generated for you. If you registered a wildcard subdomain, specify a unique subdomain in each route that you create. For example, you might specify --hostname svc1.example.com in this route, and --hostname svc2.example.com in another route.



* Simple:

oc expose service <app_service_name> [--hostname <subdomain>]
* Passthrough:

oc create route passthrough --service <app_service_name> [--hostname <subdomain>]

Need to handle HTTP/2 connections?
Assign the Manager role.





 Create a domain 

Create a new domain, or specify an existing domain that you want to add to your cluster. To specify an existing domain, include the full domain name with the external provider zone, such as exampledomain.externalzone.com. To create a new domain, you must still include the external provider zone, but you can customize the subdomain portion, such as custom.exampledomain.externalzone.com. Note that the domain name must be unique in the zone it is registered in.

If you delete a domain that is registered with the IBM internal provider, you cannot reuse the domain name.

ibmcloud oc ingress domain create --cluster CLUSTER [--crn CRN] [--is-default] [--domain DOMAIN] [--hostname HOSTNAME] [--ip IP] [--output OUTPUT] [--domain-provider PROVIDER] [-q] [--secret-namespace NAMESPACE] [--zone ZONE]

-c, --cluster CLUSTER
: Required. The name or ID of the cluster where you want to create the domain.

--crn CRN
: Required for IBM Cloud Internet Services domains. The CRN for the IBM Cloud Internet Services instance.

--is-default
: Optional. Include this option to set the relevant domain as the default domain for the cluster.

--domain DOMAIN
: The domain to create or add to your cluster. This can be a domain that exists in your provider account, or a new domain.

--hostname HOSTNAME
: For VPC clusters. The hostname to register for the domain.

--ip IP
: The IP addresses to register for the domain.

--output OUTPUT
: Optional: Prints the command output in JSON format.

--domain-provider PROVIDER
: Required. The external DNS provider type. Specify --cis-ext.

--secret-namespace NAMESPACE
: Optional. The namespace that the domain TLS secret is created in. If no namespace is specified, the secret is created in the default namespace.
To use a DNS subdomain in a domain that you control:



* Fill in the hostname as the DNS subdomain. For example if you control example.com then static.example.com would be a valid choice.
* Choose HTTP port if required by your application.
* Choose HTTPS port if required by your application and chose the SSL certificate DV SAN certificate.
* CDN Content will be available at your subdomain, static.example.com, for example.
* CDN Content is also available on the generated CNAME.



2. Use the IBM generated DNS subdomain:



* Fill in a unique hostname to identify the DNS instance, this will not be used in the URL for the CDN content.
* Choose HTTP port if required by your application.
* Choose HTTPS port - this is required.
* Choose SSL certificate Wildcard - this is required.
* CDN Content will be available in the generated CNAME.





2. On the next dialog, set the Hostname to a DNS subdomain like static.example.com (option a) or simply a unique name (option b).
3. Leave the Custom CNAME prefix blank, it will default to a unique name.
4. Next, under Configure your origin, leave Host header and Path empty.
5. Select Object Storage to configure the CDN for COS.
6. Set the Endpoint to your bucket public endpoint ($PUBLIC_ENDPOINT). Above this was: s3.us-south.cloud-object-storage.appdomain.cloud.
7. Set Bucket name to the bucket name from above.
8. Enable HTTP (80).
9. Enable HTTPS (443) for https access.



* If using a subdomain that you control (option a):



* HTTPS is optional.
* If HTTPS is selected it is required to select DV SAN Certificate for the SSL certificate.



* If not using a subdomain (option b):



* Select HTTPS. It is required.
If you choose classic infrastructure, enter the [username and API key](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificatesauthorize-classic-infrastructure) that is associated with your account.



7. Click Add.







 Adding a DNS provider configuration from the CLI 

You can add DNS provider configurations to your service instance by using the Secrets Manager CLI. Manual DNS providers can be configured only by using the API.

To configure a secrets engine from the IBM Cloud CLI, run the [ibmcloud secrets-manager configuration-create](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-cli-configuration-create-command) command.

ibmcloud secrets-manager configuration-create {
"cloud_internet_services_apikey": "MY_APIKEY_WITH_MANAGER_ACCESS_TO_CIS",
"cloud_internet_services_crn": "MY_CIS_CRN",
"config_type": "public_cert_configuration_dns_cloud_internet_services",
"name": "my-cloud-internet-services-config"}'





 Adding a DNS provider configuration with the API 

You can add DNS provider configurations to your service instance by using the Secrets Manager API.



 Configuring Cloud Internet Services (CIS) 

The following example shows a query that you can use to add a Cloud Internet Services (CIS) DNS configuration to your Secrets Manager instance. When you call the API, replace the cis_crn value with the CRN of the CIS instance that contains your domains.

If you need to access a CIS instance that is located in another account, provide a cis_apikey value that contains an API key with Manager service access on the Internet Services (internet-svs) service.
Madrid eu-es-2 10.251.64.0/18 
 Madrid eu-es-3 10.251.128.0/18 
 Tokyo jp-tok-1 10.244.0.0/18 
 Tokyo jp-tok-2 10.244.64.0/18 
 Tokyo jp-tok-3 10.244.128.0/18 
 Sydney au-syd-1 10.245.0.0/18 
 Sydney au-syd-2 10.245.64.0/18 
 Sydney au-syd-3 10.245.128.0/18 
 Osaka jp-osa-1 10.248.0.0/18 
 Osaka jp-osa-2 10.248.64.0/18 
 Osaka jp-osa-3 10.248.128.0/18 
 Toronto ca-tor-1 10.249.0.0/18 
 Toronto ca-tor-2 10.249.64.0/18 
 Toronto ca-tor-3 10.249.128.0/18 
 Sao Paulo br-sao-1 10.250.0.0/18 
 Sao Paulo br-sao-2 10.250.64.0/18 
 Sao Paulo br-sao-3 10.250.128.0/18 



The Madrid region only supports dedicated host profiles with instance storage. For more information, see [Dedicated host profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-dh-profiles&interface=ui).

If you don't want these default address prefixes, you can choose to not assign them when you create your VPC. For example, add the "address_prefix_management": "manual" parameter when you create the VPC by using the API.

To bring your own subnets:



1. Create a VPC.
2. For each zone in which you plan to create subnets, create one or more address prefixes.
3. When you create subnets in each zone, specify IP ranges that are within one of the address prefixes that you created for that zone.
For example, if you use a wildcard domain, you can append a wildcard subdomain to the beginning of the domain, such as subdomain1.custom_domain.net. Do not use * for your host or leave the host property empty to avoid failures during Ingress creation.

path
: Replace <app_path> with the path that your app is listening on. The path is appended to the IBM-provided or your custom domain to create a unique route to your app. When you enter this route into a web browser, network traffic is routed to the Ingress controller. The Ingress controller looks up the associated service, and sends network traffic to the service. The service then forwards the traffic to the pods where the app runs. Many apps don't listen on a specific path, but use the root path and a specific port. In this case, define the root path as / and don't specify an individual path for your app.
: For example, to use http://domain/, enter / as the path. For http://domain/app1_path, enter /app1_path as the path.

name
: Replace <app1_service> and <app2_service>, and so on, with the name of the services you created to expose your apps. If your apps are exposed by services in different projects in the cluster, include only app services that are in the same project. You must create one Ingress resource for each project where you have apps that you want to expose.

port
: The port that your service listens to. Use the same port that you defined when you created the Kubernetes service for your app.
2. Create the Ingress resource for your cluster. Ensure that the resource deploys into the same project as the app services that you specified in the resource.

oc apply -f myingressresource.yaml -n <project>
3. Verify that the Ingress resource was created successfully. If messages in the events describe an error in your resource configuration, fix the values in your resource file and reapply the file for the resource.

oc describe ingress myingressresource
Enter your domain name and click Next.
6. Setup your DNS records is an optional step and can be skipped for this tutorial. click on Next
7. When the name servers are assigned, configure your registrar or domain name provider to use the name servers listed.
8. After you've configured your registrar or the DNS provider, it may require up to 24 hours for the changes to take effect.

When the domain's status on the Overview page changes from Pending to Active, you can use the dig <your_domain_name> ns command to verify that the new name servers have taken effect.







 Configure Health Check for the Global Load Balancer 

Health Checks monitor responses to HTTP/HTTPS requests from origin pools on a set interval. They are used with origin pools to determine if the pools are still running properly.



1. In the IBM Cloud Internet Services dashboard, use the left navigation menu to select Reliability > Global Load Balancers.
2. Select the Health checks tab and click Create.



1. Set Name to hello-world-service
2. Set Monitor Type to HTTP.
3. Set Port to 80.
4. Set Path to /.
5. In the Configure request headers (optional) add Header name: Host and Value: <glb_name>.<your_domain_name>
6. Click Create.



When building your own applications, you could define a dedicated health endpoint such as /heathz where you would report the application state.







 Define Origin Pools 

A pool is a group of origin servers that traffic is intelligently routed to when attached to a GLB. With clusters in the United Kingdom and United States, you can define location-based pools and configure CIS to redirect users to the closest clusters based on the geographical location of the user requests.



 One pool for the cluster in Dallas 



1. Select the Origin pools tab and click Create.
2. Set Name to US
3. Set Origin Name to us-cluster
4.
[Actions icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/actions-icon-vertical.svg)> Rotate.
4. Optional: Add a name and description to easily identify your certificate.
5. Optional: Click Update.
6. Click Challenges to access the TXT record name and value that are associated with each of your domains. You need them to complete the challenges.
7. To validate the ownership of your domains, manually add the TXT records that are provided for each of your domains to your DNS provider account. You must address only the challenges that are not validated, before the expiration date.

If you order a certificate for subdomains, for example, sub1.sub2.domain.com, you need to add the TXT records to your registered domain domain.com.
8. Verify that the TXT records that you added to your domains are propagated. Depending on your DNS provider, it can take some time to complete.
9. After you confirm that the records are propagated, click Validate to request Let's Encrypt to validate the challenges to your domains and create a public certificate.

If the order fails, for example, if the TXT records were not successfully propagated, you must start a new order to proceed.
10. When your certificate is issued, clean up and remove the TXT records from the domains in your DNS provider account.







 Creating new versions of private certificates 

If your Secrets Manager service instance is enabled for [private certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-private-certificatescreate-private-certificates), you can manually renew a certificate that was previously issued by a certificate authority that is configured for your service instance.



1. In the console, click the Menu icon !
The following example shows a query that you can use to add a Cloud Internet Services (CIS) DNS configuration to your Secrets Manager instance. When you call the API, replace the cis_crn value with the CRN of the CIS instance that contains your domains.

If you need to access a CIS instance that is located in another account, provide a cis_apikey value that contains an API key with Manager service access on the Internet Services (internet-svs) service. For more information, see [Granting service access to CIS](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificatesauthorize-cis-another-account).

curl -X POST
--H "Authorization: Bearer {iam_token}" --H "Accept: application/json" --H "Content-Type: application/json" --d '{
"cloud_internet_services_apikey": "5ipu_ykv0PMp2MhxQnDMn7VzrkSlBwi3BOI8uthi_EXZ",
"cloud_internet_services_crn": "crn:v1:bluemix:public:internet-svcs:global:a/128e84fcca45c1224aae525d31ef2b52:009a0357-1460-42b4-b903-10580aba7dd8::",
"config_type": "public_cert_configuration_dns_cloud_internet_services",
"name": "cloud-internet-services-config"
}' 
"https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/configurations"

A successful response adds the configuration to your service instance. For more information about the required and optional request parameters, see [Add a configuration](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2create-config-element).





 Configuring classic infrastructure
To enable a domain that is managed by CIS to point to a Code Engine application, set the TLS encryption mode to [End-to-End CA signed](https://cloud.ibm.com/docs/cis?topic=cis-cis-tls-optionstls-encryption-modes-end-to-end-ca-signed) within CIS. This mode requires that you obtain a certificate that is generated and signed by a public and trusted CA, outside of CIS.

Because origin certificates ordered in CIS are not signed by a public and trusted CA, those certificates cannot be used for a domain mapping in Code Engine. You must obtain a CA signed certificated, outside of CIS.

For more information, see [How can I use Cloud Internet Services (CIS) with custom domain mapping](https://cloud.ibm.com/docs/codeengine?topic=codeengine-domain-mappingscompleting-custom-domain-cis)?







 Configuring custom domain mappings 

When your domain name is registered, you have a signed TLS certificate and its matching private key for this domain, and you have an existing Code Engine application, you are ready to add a custom domain mapping to your application.

The transport layer security (TLS) secret that Code Engine creates contains the signed TLS certificate and its matching private key. A TLS secret can also contain a signed TLS certificate and its matching private key for specified multiple domains, or it can contain a wildcard domain, such as for .example.com. Note that you cannot use the wildcard domain more than one time within a region.



 Configuring custom domain mappings from the console 

You can create a custom domain mapping with your Code Engine application to your registered domain name with the Code Engine console.

In this scenario, let's create a custom domain mapping to an application with a TLS secret. For example, create a custom domain mapping to map the www.example.com domain to the myapp application.

Before you begin



* [Create a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).
Why isn't my custom domain mapping ready? 

  What’s happening 

You created a custom domain mapping for your application, but it never shows a Ready state.

  Why it’s happening 

This state can have multiple reasons.



*  When you create a custom domain mapping in Code Engine, the domain name that you use in the mapping must be unique in the region.
*  If you use a wildcard certificate, you can use it only one time per region.
*  If your certificate lists multiple domain names, you can use it only one time per region.



  How to fix it 

To resolve this issue, verify that your custom domain mapping is unique in the region.

If you use a wildcard certificate or your certificate lists multiple domain names, create a single TLS secret and then reuse this secret when you create your domain mappings. Note that the applications that use this TLS secret must be in the same project. To use your domain mappings across projects that are in the same region, create separate certificates. To use the same wildcard certificate across staging environments (for example, DEV, TEST, PROD), consider distributing the project for each of these environments across different Code Engine regions. For example, create the project for DEV in eu-de, the project for TEST in eu-gb and the project for PROD in au-syd. Each of these projects can use the same wildcard certificate by creating a separate secret in each project.