vania-janet/multiturn-rag-retrieval-data huggingface dataset:
r006-d044af9b-92bf-4047-8f77-a7b86efcb923 kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 Application mysubnet-us-south-3 true active online default
6. If you created a public LoadBalancer service, curl the hostname of the Kubernetes LoadBalancer service that is assigned by the VPC ALB that you found in step 4. Example:

curl 06496f64-us-south.lb.appdomain.cloud:8080

Example output

Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!

If you created a private LoadBalancer service, you must be [connected to your private VPC network](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-onprem-example) to curl the hostname.



Do not delete the subnets that you attached to your cluster during cluster creation or when you add worker nodes in a zone. If you delete a VPC subnet that your cluster used, any load balancers that use IP addresses from the subnet might experience issues, and you might be unable to create new load balancers.





 Registering a DNS record and TLS certificate 

The Application Load Balancer for VPC (VPC ALB) provides a default HTTP hostname in the format 1234abcd-<region>.lb.appdomain.cloud through which you can access your app. However, if you want a TLS certificate for your app domain to support HTTPS, you can create an IBM-provided subdomain or bring your own custom domain for both public and private VPC ALBs.

After you create a DNS subdomain for a VPC ALB hostname, you can't use nlb-dns health-monitor commands to create a custom health check. Instead, the default VPC load balancer health check that is provided for the default VPC ALB hostname is used.
Custom resolvers use cases 

IBM Cloud® DNS Services provides custom resolvers as a service that offers the ability to customize the zone resolving rules for different hostnames. The custom resolver feature offers fine-grained control of name resolution and forwarding of DNS Queries to and from on-premises DNS resolvers.

In this example scenario, financial data is in the on-premises instance and you manage this data access under the DNS zone fin.example.com, which is managed by your on-premises DNS servers. Your applications that are running in the IBM Cloud VPC must access financial data with hostnames under this DNS zone.

In this case, you can create custom resolvers to forward the DNS queries on this DNS zone to your on-premises DNS servers. You can also use the custom resolvers to customize rules to forward DNS queries to DNS Services servers, public resolvers, or even custom resolvers launched in other IBM Cloud VPCs.



 Custom resolver concepts 

A custom resolver is a logical object that is created for an IBM Cloud VPC in a DNS Services instance. Within the custom resolver, you can specify the locations where you want to launch the underlying DNS forwarders for the custom resolver. The custom resolver location is equivalent to the subnet in the IBM Cloud VPC. You can create a custom resolver by specifying only one location, or up to three locations in different subnets in the same VPC. The default configuration is highly available, with two locations.

A custom resolver can have multiple forwarding rules to customize where (and on which DNS zones) the DNS queries should be forwarded to. A default forwarding rule is automatically created along with the custom resolver to forward DNS queries to DNS Services servers.





 Use cases and workflows 

The most common use cases of custom resolvers are:



* Forwarding DNS queries from an IBM Cloud VPC to your on-premises DNS servers, or the reverse.
* Forwarding DNS queries from an IBM Cloud VPC to public resolvers.
* Forwarding DNS queries from one IBM Cloud VPC to another.
After you import your account into an enterprise, you can't remove it.
* Can I move an account within an enterprise?

Yes, you can move your account anywhere within an enterprise. For example, you can move your account directly under the enterprise or from one account group to another. For more information, see [Moving accounts within the enterprise](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-enterprise-organize).
* Can I move an account group?

No, it’s not possible to move an account group within the enterprise.
* Can I edit an account name from within the enterprise?

No, you can't edit the name of an account from within your enterprise. To edit the name of an account, go to Manage > Account in the IBM Cloud console, and select Account settings. In the Account section, click the Edit icon ![Edit icon](https://cloud.ibm.com/icons/edit-tagging.svg), enter your new account name, and click Submit.
* Can I invite users to an enterprise?

To invite users to an enterprise, you must have an IBM Cloud Identity and Access Management (IAM) access policy with the Editor or higher role on the User Management service. For more information, see [Inviting users](https://cloud.ibm.com/docs/account?topic=account-iamuserinvinvitations).
* Can my child account have a different subscription currency than my enterprise account?

No, billing and subscriptions are managed at the enterprise level rather than at the child account level. Your child account cannot have a different subscription. For more information about enterprise billing, see [Billing options](https://cloud.ibm.com/docs/billing-usage?topic=billing-usage-enterprise&interface=uienterprise-billing-options).
* Can I change the domain for my enterprise account?

Yes, domains can be updated. You can use the [Enterprise Management API](https://%7BDomainName%7D/apidocs/enterprise-apis/enterpriseupdate-enterprise) to update your domain.
* UI
* CLI
* API
* Terraform







 Connecting DNS providers 

With IBM Cloud® Secrets Manager, you can connect to a DNS provider by adding a configuration to your instance.

A DNS provider is the service that is used to add and manage domains for apps or services. By adding a DNS configuration, you can specify the DNS service to use for domain validation when you [order certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-public-certificatesorder-public-certificates) through Secrets Manager.

You can define up to 10 DNS configurations per instance. To view a list of configurations that are available for your instance, go to the Secrets engines > Public certificates page in the Secrets Manager UI.

You can define up to 10 DNS configurations per instance. To obtain a list of configurations that are available for your instance, you can use the [List configurations](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2get-secret-config-element) API.



 Before you begin 

Before you get started, be sure that you have the required level of access. To manage engine configurations for your instance, you need the [Manager service role or higher](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam).



 Supported DNS providers 

You can connect the following DNS providers with your Secrets Manager service instance.

Cloud Internet Services

Classic infrastructure

Manual



Table 1. Prerequisites - CIS

 Prerequisites
If your cluster is created on classic infrastructure, or if your cluster is created on VPC infrastructure and you enabled the public cloud service endpoint during cluster creation, your cluster is created with only a public Ingress controller by default. To privately expose your apps, you must first create a private IngressController resource and configure the controller with a subdomain. The Ingress operator automatically creates and configures a new private Ingress controller, which you can use to create private routes for your apps.

Note that even though you create an IngressController resource in the following steps, the IngressController resource is only required to create and configure the necessary Ingress controller for you. After the Ingress controller is created, you use the router directly to create routes.



1. Prepare the domain that you want to use for your Ingress controller.



* Custom domain, classic or VPC clusters: To register a custom domain, work with your Domain Name Service (DNS) provider or [IBM Cloud DNS](https://cloud.ibm.com/docs/dns?topic=dns-getting-started). If you want to use the same subdomain for multiple services in your cluster, you can register a wildcard subdomain, such as .example.com.
* IBM-provided domain, VPC clusters only:



1. List the existing subdomains in your cluster. In the Subdomain column of the output, copy the subdomain that has the highest 000<n> value.

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

In this example output, the mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud subdomain has the highest 000<n> value of 0002.

Subdomain Load Balancer Hostname Health Monitor SSL Cert Status SSL Cert Secret Name
VPE is integrated with DNS Services. If your VMware workloads use IBM Cloud DNS Services, they can resolve your VPE FQDNs to your private IP address instances that are provisioned under IBM Cloud DNS Services. IBM Cloud network can use resource records that are configured through IBM Cloud DNS Services by querying DNS Services resolvers.

Therefore, the first architectural decision you must make is how your VMware Workloads resolve DNS queries. IBM Cloud DNS Services provide custom resolvers as a service that offers the ability to customize the hostname, which resolves rules for different hostnames. If your VMware workloads are attached to VPC subnet, you can use the DNS server IP addresses as defined in [VPC IaaS endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpcinfrastructure-as-a-service-iaas-endpoints).

The custom resolver feature offers fine-grained control of name resolution and forwarding of DNS Queries to and from on-premises DNS resolvers. You can create a custom resolver to run inside your VPC address space, and in a subnet you define. You can then use this custom resolver for your VMware Workloads on NSX-T overlays. For more information, see [Working with custom resolvers](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-custom-resolver&interface=ui).

VPE for VPC IP addresses uses a multizone region, logical endpoint gateway to connect to a service endpoint on the IBM Cloud private backbone. The endpoint gateway is designed to support the best practice of binding a single IP from each zone of the VPC.

You can create an endpoint gateway with zero IP addresses and bind IP addresses as each zone is brought online. When you create an endpoint gateway, a DNS zone and records are created. The VPE service automatically upgrades your virtual server instances to use the private DNS as the default DNS resolver.
Viewer View the enterprise, account groups, and accounts 
 Operator Not applicable 
 Editor View and update the enterprise name and domain, create accounts and account groups, view usage reports, and import accounts. 
 Administrator View and update the enterprise name and domain, create accounts and account groups, move accounts between account groups, import existing accounts, and view usage reports 
 Usage report viewer View the enterprise, accounts, and account groups and view usage reports for all accounts in the enterprise. 







 Global catalog 

You can give users access to view private products in the catalog or change the visibility of private products for other users in the account.



Table 7. Roles and example actions for the Global Catalog service

 Roles Actions 

 Viewer View private services 
 Operator View private services 
 Editor Change object metadata but can't change visibility for private services 
 Administrator Change object metadata or visibility for private services, and restrict visibility of a public service 







 IAM Access Groups 

You can give users access to view, create, edit, and delete access groups in the account by using the IAM Access Groups service.



Table 8. Roles and example actions for the IAM access groups service

 Roles Actions 

 Viewer View access groups and members 
 Operator Not applicable 
 Editor View, create, edit, and delete groups<br><br>Add or remove users from groups 
 Administrator View, create, edit, and delete groups<br><br>Add or remove users including other administators<br><br>Assign access to a group<br><br>Manage access for working with access groups<br><br>Enable or disable public access to resources at the account level 







 IAM Access Management service 

You can give users access to manage access policies and custom roles.



Table 9. Roles and example actions for the IAM Access Management service

 Roles Actions 

 Viewer View access policies and custom roles 
 Operator View access policies and custom roles 
 Editor View and edit custom roles<br><br>View IAM insights, policies, and settings 
 Administrator View, create, edit, and delete custom roles<br><br>View and update IAM settings<br><br>Assign access to a group<br><br>View, create, edit, and delete access policies 





 Role Management
secure-file-storage.example.com-account-info.json secure-file-storage.example.com-private-key.pem
Show more



2. Connect the Let's Encrypt ACME account to the Secrets Manager instance. See [Adding a certificate authority configuration in the UI](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-add-certificate-authority&interface=uiadd-certificate-authority-ui) for more details:



1. Open the Secrets Managerservice instance, you can find it in the [Resource List](https://cloud.ibm.com/resources).
2. Open Secrets engines on the left and click Public certificates.
3. Under Certificate authorities click Add.
4. Name: LetsEncrypt and Certificate authority: Let's Encrypt.
5. For the Private key under Select file click Add file and choose the secure-file-storage.example.com-private-key.pem or your existing .pem file from the chooser.
6. Click Add.



3. Connect the CIS as a DNS provider:



1. Under DNS providers click Add.
2. Name cis and choose Cloud Internet Services from the dropdown.
3. Click Next.
4. In the Authorization tab choose the CIS instance.
5. Click Add.



4. Add the TLS certificate secret to Secrets Manager:



1. Click the Secrets tab on the left.
2. Click Add.
3. Click TLS certificates.
4. Click Order a public certificate.
5. Name secure-file-storage.example.com.
6. Certificate authority: LetsEncrypt created earlier.
7. Key algorithm: RSA2048.
8. DNS provider: cis created earlier.
9. Select domains .
10. Open the cis example.com.
11.
Working with CNAME records 

A Canonical Name record (CNAME), is a record that points to another domain address rather than an IP address. A CNAME record points to another DNS record which, in turn, points to an A record which points to an IP address. Then, if the IP address ever changes, you only have to record the change in one place within the network.



* Valid CNAME record examples:



* ftp.example.com 900 IN CNAME example.com
* sftp.example.com 900 IN CNAME example.com



* Invalid CNAME record examples (MX record should not point to another CNAME record):



* example.com. MX 0 foo.example.com.
* foo.example.com. CNAME host.example.com.







 How CNAME records work 

A CNAME is an alias. It allows one domain to point to another domain which, if you follow the CNAME chain, eventually resolves to an A record and IP address. Pointing a CNAME record to another CNAME record is inefficient (but possible) because it requires multiple DNS lookups before the domain can be loaded, negatively impacting the speed of the user experience.

Each resource record in the CNAME chain is considered as a separate DNS query, which slows down the resolution time.

For example, use CNAME records to point ftp.example.com and sftp.example.com to the DNS entry for example.com, which in turn has an A record that points to the IP address:

ftp.example.com CNAME example.com
example.com A 10.1.1.10

The following is an example of a long CNAME chain that is a combination of private zones and public zones.



* Private zones



* foo.com
* bar.com



* Public zones



* prod.com
* containers.appdomain.cloud





abc.foo.com CNAME abc.bar.com
abc.bar.com CNAME new.prod.com
new.prod.com CNAME 1234.containers.appdomain.cloud
Additional details on LDAP user registry synchronization can be found here: [https://www.ibm.com/docs/en/mas86/8.6.0?topic=access-administering-ldap-user-registry-synchronization](https://www.ibm.com/docs/en/mas86/8.6.0?topic=access-administering-ldap-user-registry-synchronization)





 SMTP Setup 



 MAS SMTP Configuration 

To enable outbound emails from your Maximo Application Suite SaaS environment from the provided SMTP relay, you must raise an IBM Support case to configure SMTP Domain Authentication. Completing this configuration will allow you to send email from hosted Manage environment as your %CUSTOMERNAME% domain email addresses. If you plan to use your own SMTP host, this process will not apply.

In the case, please include:



* Case title: SMTP / outbound email activation
* Case description: Please initiate domain authentication for customerdomain.com. This domain should align with the email addresses used in Manage. Please provide contact details / email address of a person who has access to add DNS records for the domain(s) you specify. With these details the IBM SRE Team can generate the DKIM / Domain Authentication records which will be sent to the contact you specify (which has access to add DNS records). Once said contact adds the DNS records, the IBM SRE team will then need to perform a lookup / validation to ensure these records are intact. Once validated, customer will be able to send email as email addresses from the domain(s) specified.



If SendGrid DKIM records already exist in the DNS server in question, please let the IBM SRE team know so they can generate a unique DKIM selector.





 Customer Managed SMTP Configuration 

If you plan to use your own SMTP server instead of the provided MAS SMTP relay, you must raise an IBM Support case.

In the case, please include:



1. Case title: SMTP / outbound email activation
2. Case description: Please configure our MAS-SaaS environment to use the following SMTP server:





* SMTP hostname
CDN type Akamai CNAME format 

 HTTP-only wildcard.appdomain.mdc.edgekey.net. 
 SAN HTTPS cert-xxxxx-cdnedge-bluemix.akamaized.net.edgekey.net. 
 Wildcard HTTPS N/A 



For the Akamai CNAME, it's important to consider the following:



* The Akamai CNAME is only usable for the HTTP-only and SAN HTTPS mapping. For the Wildcard HTTPS mapping, it's only accessible by the IBM CNAME, so you don't have to set the DNS record for the CDN domain.
* The Akamai CNAME cannot ensure your domain is reachable if you STOPPED your CDN. You must manually set your DNS to point your domain to the origin if your domain is running service.
* For the SAN HTTPS CDN, the Akamai CNAME can only be generated when the CDN status has passed the Domain validation required.
* You can only point your domain to Akamai CNAME after the CDN mapping status is RUNNING. You cannot use Akamai CNAME to set the DNS record during the process of Domain validation.



For more information about Akamai CNAME, see the [FAQ for CDN CNAME](https://cloud.ibm.com/docs/CDN?topic=CDN-next-steps-after-orderingfaq-for-cdn-cname).







 FAQ for CDN CNAME 



 Can I configure my domain without pointing it to a CDN CNAME? 

No, you cannot configure your domain without pointing it to a CDN CNAME. You can point your domain only to a CDN CNAME (IBM CNAME or the Akamai CNAME). This way, you can guarantee that your domain is globally distributed to the closest and most efficient edge server for your clients.

The IP addresses of an Akamai edge server are changed dynamically; therefore, setting a fixed Akamai IP address for your domain might cause your traffic to fail.





 Can I update the IBM CNAME or Akamai CNAME?
no-route With the --cluster-local option, the application is still accessible from other workloads within the project, but does not include an internet-facing accessible URL that associated with the application. 
 path Not currently applicable. 
 processes Not needed in Code Engine. The application can create additional processes at run time. 
 random-route Not needed in Code Engine. Each project has a unique subdomain and since the application name is part of the URL, the URL is guaranteed to be unique. 
 routes Custom routes are not currently supported, but you can use [IBM Cloud Internet Service (CIS) or Cloudflare](https://cloud.ibm.com/docs/codeengine?topic=codeengine-migrate-cf-ce-faqcustomurl) to front end your application with a custom domain. 
 sidecars Not currently supported. 
 stack Implicitly managed by Code Engine. 
 timeout Not needed in Code Engine. 
 Environment variables -env option 
 Services See the [ibmcloud ce app bind](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-bind) command. 



Code Engine supports many options that are not available in Cloud Foundry, such as how autoscaling is managed. See [Working with apps in Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloads) and [Configuring application scaling](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-scale).





 I know how to deploy an app with Cloud Foundry. What do I need to know to deploy an app in Code Engine? 

If you know how to deploy an app with Cloud Foundry, find what you need to know to deploy an app in Code Engine.



 Push code 

With Code Engine, you can build your code that is sourced in a Git repository or from a local system (CLI-only). Additionally, as with Cloud Foundry (cf push), you can build and deploy your app in a single step with both the CLI and the Code Engine console.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
...
myapp-vpc-nlb-jp-tok-3 LoadBalancer 172.21.xxx.xxx 169.xx.xxx.xx 8080:30532/TCP 1d run=webserver
2. Create a custom or IBM-provided DNS subdomain for the IP address.



* Custom domain:



1. 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 IP addresses as A records.



* IBM-provided subdomain: Use nlb-dns commands to generate a subdomain with an SSL certificate for the IP addresses. IBM Cloud takes care of generating and maintaining the wildcard SSL certificate for the subdomain for you.



1. Create a DNS subdomain and SSL certificate.

ibmcloud ks nlb-dns create vpc-gen2 --type public --cluster <cluster_name_or_id> --ip <vpc_nlb1_ip> --ip <vpc_nlb2_ip> --ip <vpc_nlb3_ip>
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 IP(s) Health Monitor SSL Cert Status SSL Cert Secret Name