vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Hosted static websites focus on the content your users desire: information and media. By removing the administration of webservers like Apache or Nginx, management of your website focuses directly on content, from generation to deployment.

Static content differs substantially from dynamic web content. However, if you don't need to generate dynamic content on the web or if your workflow results in content saved to a fixed form, then the hosted static solution featured here presents the best choice.





 Capabilities 

Creating static website hosting in IBM Cloud Object Storage can be accomplished with [cURL](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-curlcurl-configure-static-web), as well as libraries for [Java](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-javajava-examples-hosted-static-website-create), [Go](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-using-gogo-guide-hosted-static-website-create), [Python](https://test.cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-pythonpython-examples-hosted-static-website-create), and [NodeJS](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-nodenode-examples-hosted-static-website-create). In addition, S3 compatibility means that the [AWS CLI](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-aws-cliaws-cli-configure-static-web) can also be used to define static website functionality from the command line. Also, creating and configuring a new hosted static website solution can be created using a GUI in the [Console](https://cloud.ibm.com/login) just by adding the option for Static Website when creating a bucket.





 Basic Configuration
cat $jsonFile | jq '.items[] | {family, type, region, name} | join(" ")' | sed 's/"//g'





 Next Steps 

For each custom domain you discovered that you wish to continue using with an IBM Cloud Foundry application, upload the SSL certificates using the instructions below.







 Security Storage 

The new method for securely storing SSL certificates for IBM Cloud Foundry applications uses the IBM Cloud [Secrets Manager](https://www.ibm.com/cloud/secrets-manager). All users who want to continue directing their custom domain to their IBM Cloud Foundry application need to create a Secrets Manager service instance, authorize its use, and upload the required SSL certificates. This is a one time change and can then be used for all the custom domains you wish to forward to IBM Cloud Foundry applications.

There are different levels of [Secrets Manager plans](https://cloud.ibm.com/catalog/services/secrets-manager) - Trial and Standard. You should pick the plan most appropriate for your needs.



 Standard Plan 



* $299.00 / month
* Can store unlimited secrets
* No expiration timeframe



If you intend to use Secrets Manager in other capacities and with other IBM Cloud services, in addition to the need for IBM Cloud Foundry application certificates, then you should choose this plan for continued use.





 Trial Plan 



* Free to use
* Expires after 30 days



If you do not intend to use Secrets Manager after changing your IBM Cloud Foundry custom domain certificates, select this plan. You will create the Secrets Manager service and follow the normal instructions uploading the certificates you need. IBM Cloud Foundry will then retrieve the certificates. After IBM Cloud Foundry retrieves the certificates from Secrets Manager, you no longer need the Secrets Manager instance, unless you need to update your certificates in the future. If you do need to update your custom domain SSL certificate, repeat the procedure with the Trial Secrets Manager instance plan and repeat the custom domain upload procedure. If you don't need to update your certificate again, simply let the Secrets Manager instance Trial plan elapse.







 Timeline
[Code Engine secure app repo](https://cloud.ibm.com/docs-content/v1/content/efbf7b33e3aca029f69f9244bced9dd4d8acb848/apps/includes/ContinuousDelivery/includes/ContinuousDelivery/images/code_engine_secure_app_repository.png)

Figure 2. Code Engine secure app repo

You can change the name of the app repo. The region of the repo remains the same as the region of the toolchain.
2. Optional. The toolchain template provides a [Sample Hello World Application](https://us-south.git.cloud.ibm.com/open-toolchain/hello-helm) app. If you want to link an existing Application repo for the toolchain, select Bring your own app and specify the URL for the repo. The toolchain supports linking only to existing Git Repos and Issue Tracking repos.
3. Click Continue.



By default, the Application repo template is cloned to your Git Repos and Issue Tracking org. To change the org, enable Advanced options and specify the repo owner.





 Securely store secrets 

Several tools within this toolchain require secrets, such as an IBM Cloud API key. You must securely store all secrets in a secrets vault and reference them as required by the toolchain.



1. Using IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secret. In the Secrets step, you can specify which secret vault integrations to add or remove from your toolchain. For more information about adding and removing vault integrations, including prerequisites and by using hints, see [Managing IBM Cloud secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloud).

By using hints within a template, a toolchain is automatically populated with preconfigured secrets; you don't need to manually select secrets from vault integrations that are attached to the toolchain.
[Code Engine secure app repo](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/code_engine_secure_app_repository.png)

Figure 2. Code Engine secure app repo

You can change the name of the app repo. The region of the repo remains the same as the region of the toolchain.
2. Optional. The toolchain template provides a [Sample Hello World Application](https://us-south.git.cloud.ibm.com/open-toolchain/hello-helm) app. If you want to link an existing Application repo for the toolchain, select Bring your own app and specify the URL for the repo. The toolchain supports linking only to existing Git Repos and Issue Tracking repos.
3. Click Continue.



By default, the Application repo template is cloned to your Git Repos and Issue Tracking org. To change the org, enable Advanced options and specify the repo owner.





 Securely store secrets 

Several tools within this toolchain require secrets, such as an IBM Cloud API key. You must securely store all secrets in a secrets vault and reference them as required by the toolchain.



1. Using IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secret. In the Secrets step, you can specify which secret vault integrations to add or remove from your toolchain. For more information about adding and removing vault integrations, including prerequisites and by using hints, see [Managing IBM Cloud secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloud).

By using hints within a template, a toolchain is automatically populated with preconfigured secrets; you don't need to manually select secrets from vault integrations that are attached to the toolchain.
Determine an option for managing encryption for your instance.

You can enhance the security of your secrets at rest by integrating with a key management service. For more information about customer-managed encryption, check out [Protecting your sensitive data in Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-mng-datadata-encryption).
7. From the list of endpoint options, select Public and private or Private only.

By default, Secrets Manager instances accept API requests from both public and private endpoints. To limit access to your instance to take place only through a private network, select the Private only option. Keep in mind that the Secrets Manager service UI is not accessible for Private only instances.
8. Click Create.

Provisioning a Secrets Manager instance can take 5 - 15 minutes to complete.







 Setting up private endpoints for Secrets Manager from the CLI 

After your account is enabled for VRF and service endpoints, you can provision a Secrets Manager service instance to connect over a private service endpoint.



1. In a terminal window, log in to IBM Cloud.

ibmcloud login

If the login fails, run the ibmcloud login --sso command to try again. The --sso parameter is required when you log in with a federated ID. If this option is used, go to the link listed in the CLI output to generate a one-time passcode.
2. Select the account, region, and resource group where you want to create a Secrets Manager service instance.

You can use the following command to set your target region and resource group.

ibmcloud target -r <region_name> -g <resource_group_name>
3. (Optional) Check whether your account is enabled for VRF and service endpoints.

ibmcloud account show

The following CLI output shows the account details of a VRF and service endpoint-enabled account.

Retrieving account John Doe's Account of john.doe@email.com...
OK

Account ID: d154dfbd0bc2edefthyufffc9b5ca318
For this purpose, the application has been customized to include [a test object](https://github.com/IBM-Cloud/cdn-with-cda-todolist/blob/master/views/detection-test-object.html) made available at [/test-dca](https://github.com/IBM-Cloud/cdn-with-cda-todolist/blob/master/main.goL11).

To activate DCA:



1. Select the Settings tab in the CDN configuration.
2. Under the Optimization settings section, click Edit and select Dynamic Content Acceleration from the Optimized for drop-down list.
3. Under the Detection path section, specify the path /test-dca as the detection path, and click Test to verify the path is set correctly. This detection path will be used periodically by IBM® Content Delivery Network to determine the fastest path to the origin.
4. Make sure Prefetching and Image compression are both set to On.

Zoom

![Configure DCA](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution52-cdn-dca/detection_path.png)

Configure DCA
5. Click Save. You have successfully accelerated your application deployed in Kubernetes Service cluster with Dynamic Content Acceleration.







 Step 4: Verify DCA performance 

You can use common website performance tools such as [Web Page Test](https://www.webpagetest.org/) to compare the website response time before and after DCA is turned on.

After enabling DCA for a period, you can view the both static and dynamic traffic bandwidth by clicking on the View CDN report on the [CDN Overview](https://cloud.ibm.com/cdn) page.





 Step 5: Conclusion
[DevSecOps Application Lifecycle Management](https://cloud.ibm.com/docs/deployable-reference-architectures?topic=deployable-reference-architectures-deploy-arch-ibm-devsecops-alm)![IBM Title Image](https://cloud.ibm.com/media/docs/images/homepage/tutorial-default.svg)DevSecOps Application Lifecycle Management Reference architecture

Security and compliance requirements in the Cloud native app development.

[Enterprise account architecture](https://cloud.ibm.com/docs/enterprise-account-architecture)![IBM Title Image](https://cloud.ibm.com/media/docs/images/homepage/tutorial-default.svg)Enterprise account architecture White paper

Recommendations for how large customers should configure and govern IBM Cloud at scale.

[IBM Cloud Framework for Financial Services](https://cloud.ibm.com/docs/framework-financial-services)![IBM Title Image](https://cloud.ibm.com/media/docs/images/homepage/tutorial-default.svg)IBM Cloud Framework for Financial Services Solution guide

Designed to help address the needs of financial services institutions with regulatory compliance, security, and resiliency.

All solution docs[Accelerate a dynamic website using Dynamic Content Acceleration](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-dynamic-content-cdn)Accelerate a dynamic website using Dynamic Content Acceleration Solution tutorial

Web applications are composed of static content like text, images, cascading style sheets, and JavaScript files. The tutorial Accelerate delivery of static files using a CDN shows how to host and serve static assets (images, videos, and documents) of a website from IBM Cloud Object Storage with IBM® Content Delivery Network (CDN).

!
The External Secrets controller fetches the ExternalSecrets objects in the configuration file that you defined by using the Kubernetes API.
4. At application run time, the controller retrieves the secret data from Secrets Manager, and converts the ExternalSecrets objects to Kubernetes secrets for your cluster.



This scenario features a third-party tool that can impact the compliance readiness of workloads that run in your Kubernetes cluster. If you add a community or third-party tool, keep in mind that you are responsible for maintaining the compliance of your apps, and working with the appropriate provider to troubleshoot any issues. For more information, see [Your responsibilities with using IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-responsibilities_iks).



 Before you begin 

Before you get started, be sure that you have [Administrator platform access](https://cloud.ibm.com/docs/account?topic=account-assign-access-resourcesassign-new-access) so that you can create account credentials and provision resources. You also need the following prerequisites:



* [Download and install the IBM Cloud CLI](https://cloud.ibm.com/docs/cli).
* [Install the Secrets Manager CLI plug-in](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-cli).
* [Install the Kubernetes CLI (kubectl)](https://kubernetes.io/docs/tasks/tools/).
* [Download and install jq](https://stedolan.github.io/jq/).

jq helps you slice and filter JSON data. You use jq in this tutorial to grab and use stored environment variables.







 Step 1: Set up your environment 

To work with Secrets Manager and Kubernetes Service, you need to create a cluster and a Secrets Manager instance in your IBM Cloud account. You also need to configure permissions so that you can run operations against both services.
Set a default Secrets Manager instance and regenerate your secrets 

When you set a default Secrets Manager instance, all new Ingress subdomain certificates are stored in that instance.



1. Run the command to set the new default instance. You can optionally specify a [secret group](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-groups) that is allowed access to the secrets in the instance.

ibmcloud ks ingress instance default set --cluster <cluster_name_or_id> --name <instance_name> --secret-group <secret_group_id>
2. Regenerate your secrets. Any secrets that are managed by IBM, such as your default Ingress secrets, are uploaded to the new default instance. These secrets are automatically updated and the CRN is changed to reference the Secrets Manager instance.



1. List the nlb-dns subdomains in your cluster.

ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>
2. For each subdomain in your cluster, run the command to regenerate your IBM-managed secrets. This updates the CRN of these secrets to reference the CRN of the new default Secrets Manager instance.

Regenerating your secrets is rate-limited to five times per week. Follow the steps in this document carefully, as repeating them might cause you to reach the limit. If you do not regenerate your secrets, or if you have reached the limit, your secrets are uploaded to your Secrets Manager instance at the next renewal cycle.

ibmcloud ks nlb-dns secret regenerate --cluster <cluster_name_or_id> --nlb-subdomain <nlb_subdomain>
3. Verify that your default Ingress secrets regenerated. In the output, the CRN of the default Ingress secrets should contain secrets-manager.

It may take several minutes for your secrets to regenerate. During this process, the Status column in the output says regenerating and switches to created when the regeneration is complete.
Set a default Secrets Manager instance and regenerate your secrets 

When you set a default Secrets Manager instance, all new Ingress subdomain certificates are stored in that instance.



1. Run the command to set the new default instance. You can optionally specify a [secret group](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-groups) that is allowed access to the secrets in the instance.

ibmcloud oc ingress instance default set --cluster <cluster_name_or_id> --name <instance_name> --secret-group <secret_group_id>
2. Regenerate your secrets. Any secrets that are managed by IBM, such as your default Ingress secrets, are uploaded to the new default instance. These secrets are automatically updated and the CRN is changed to reference the Secrets Manager instance.



1. List the nlb-dns subdomains in your cluster.

ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
2. For each subdomain in your cluster, run the command to regenerate your IBM-managed secrets. This updates the CRN of these secrets to reference the CRN of the new default Secrets Manager instance.

Regenerating your secrets is rate-limited to five times per week. Follow the steps in this document carefully, as repeating them might cause you to reach the limit. If you do not regenerate your secrets, or if you have reached the limit, your secrets are uploaded to your Secrets Manager instance at the next renewal cycle.

ibmcloud oc nlb-dns secret regenerate --cluster <cluster_name_or_id> --nlb-subdomain <nlb_subdomain>
3. Verify that your default Ingress secrets regenerated. In the output, the CRN of the default Ingress secrets should contain secrets-manager.

It may take several minutes for your secrets to regenerate. During this process, the Status column in the output says regenerating and switches to created when the regeneration is complete.
Using Delivery Pipeline Tekton Pipelines with externalized properties 

You can run pipelines that contain pipeline properties that are not stored with the Delivery Pipeline. By using these externalized properties, you can manage pipeline environment properties in a Git repository (repo) and use version control and tracking.

After a pipeline is externalized, pipeline runs occur in the same way, depending on the triggers that are configured for the pipeline. The values of any properties that are externalized and specified by way of the pipeline UI are overridden by the values in the UI when the property names and property types match.



 Configuring a pipeline to use externalized properties 

The latest private worker agent versions support external properties natively. This support uses [Kustomize](https://kustomize.io/) and [External Secrets](https://external-secrets.io/), and requires a pipeline that is configured to use external properties.

As of Kubernetes version 1.14, Kustomize is included in Kubernetes to provide a declarative means of cluster configuration and Kubernetes object creation by using yaml files. To use externalized properties, your pipelines require a kustomization.yaml file.

By using the External Secrets operator, you can synchronize secrets from external APIs with Kubernetes secrets. Supported providers include [IBM Cloud® Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started). By using the operator, you can represent secrets and providers within yaml files that are stored in a repo, such as Git. To use externalized secure properties, your pipeline definitions must provide yaml files that define both a SecretStore and an ExternalSecret.



 Configuring a cluster 

Pipelines with externalized environment properties are supported on [pipeline private worker installations](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-install-private-workers&interface=ui) at version 0.14.9 or later, or on IBM-provided managed workers.
* If you already have the VPN server certificate from other CAs, make sure that the certificate has the Extended key usage: TLS Web Client Authentication. You can use the following command to check the certificate information based on content of the encoded certificate file: cat YOUR-CERTIFICATE-FILE | openssl x509 -noout -text.
* If the certificate is used as the VPN client certificate to authenticate the client, you must upload the Certificate file and the Intermediate certificate file. For example, if you use different client certificates to authenticate different users, make sure that these certificates are signed by the same CA and that you uploaded one of the client certificates (Certificate file and Intermediate certificate file only) to Secrets Manager.

You can use a CA chain to bundle the certificates (Intermediate CA 1, Intermediate CA 2, and root CA) into a single file and upload to the intermediate certificate file. Also, keep in mind that you can create multiple client certificates offline using the same CA without having to upload the certificates to Secrets Manager.







 Importing VPN server certificates into Secrets Manager 

To import VPN server certificates into Secrets Manager, follow these steps:



1. If you do not have a Secrets Manager instance already, go to the [Secrets Manager](https://cloud.ibm.com/catalog/services/secrets-manager) page. Then, complete the information and click Create to create a Secrets Manager instance.

For more information, see ordering certificates for [Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificates&interface=uiorder-certificates).
2. Go to Resource List > Security and choose a Secrets Manager instance in IBM Cloud.
3. Click Add.
4. Choose the TLS certificate on the Add a secret page, then click Import a certificate.
5. On the Your certificates page, follow these steps to import the certificate:



* Provide a certificate name.
* Click Browse and select ./pki/issued/vpn-server.vpn.ibm.com.crt as the certificate file.