vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To learn more, see [Deploying your app from local source code with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-local-source-code) and [Creating your job from local source code with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-local-source-code).



However, if you want more control over the build of your image, you must first create a build configuration and then run your build. After your build is complete, you can deploy the container image as an application or create a job that references your image.

Use this topic to learn about the information you need to control the build of your container image. In this scenario, IBM Cloud® Code Engine pulls source code from a Git repository or a local directory, builds it, and then pushes (uploads) the container image to a registry. You can choose public or private [repositories](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories) and [registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry). You can also choose to specify registry details with a registry secret for your build output with user-provided access. Or, you can choose to let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry with automatic access.

Before you start building images, review [planning information](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-build). You'll also need to verify that you can access the registry. See [Setting up authorities for container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).

Interested in configuring your project such that all users of the project can store and access images in Container Registry without having to manually create registry secrets?
You can add the IBM Cloud® DevOps Insights tool integration to your toolchain without any additional configuration.

[DevOps Insights](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-di_working) is included in the created toolchain. You do not need to provide any configuration steps for DevOps Insights. The continuous integration pipeline automatically uses the DevOps Insights instance that is included in the toolchain. DevOps Insights aggregates code, test, build, and deployment data to provide visibility into the velocity and quality of all of your teams and releases.

Click Continue.





 Step 4: Complete the toolchain setup 

On the Summary page, click Create toolchain. Several steps run automatically to set up your toolchain.

You can configure the individual toolchain integrations after the pipeline is created.

Zoom

![Code Engine secure app toolchain Summary](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/code_engine_summary.png)

Figure 6. Code Engine secure app toolchain summary





 Step 5: Explore your new toolchain 

After you create your toolchain, it shows each of the tool integrations that are part of the toolchain in a diagram.



 Explore the pipelines 

You can explore the pipelines to understand the toolchain flow and the different operations that run within each pipeline. The toolchain that you created contains the following pipelines:



* Pull request pipeline: Runs when a developer merges changes from their development branch to the master branch, or to any other branch in the repo. The pull request pipeline runs the Unit Test and Static Scans on the Application Source Code.
* Continuous integration pipeline: Runs when you merge a change into the master branch of the Application Source Code repo. The continuous integration pipeline runs the Unit Test, Code Coverage, and Static Scans on the Application Source Code, CIS check, and Bill Of Materials (BOM) check.
roles = ["Supertenant Metrics Publisher"]
description = "Authorization Policy"
transaction_id = "terraformAuthorizationPolicy"
}

The ibm_iam_authorization_policy resource requires the source service, target service, and role. The source service is granted access to the target service, and the role is the level of permission that the access allows. Optionally, you can add a description for the authorization and a transaction ID.



* You may provide target_resource_instance_id to scope a specific IBM Cloud Monitoring instance.
* For more examples, see the [Terraform documentation for authorization resources](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_authorization_policy).



2. After you finish building your configuration file, initialize the Terraform CLI. For more information, see [Initializing Working Directories](https://www.terraform.io/cli/init).

terraform init
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply









 Creating an authorization by using the API 

You must have access to the target service to create an authorization between services. You can grant only the level of access that you have as a user of the target service. The autorization that you define for the IBM Cloud Metrics Routing service requires that you have Administrator role for the IBM Cloud Monitoring service.

To authorize a source service access to a target service, use the [IAM Policy Management API](https://cloud.ibm.com/apidocs/iam-policy-managementcreate-a-policy). See the following API example for Create a policy method with the type=authorization specified.

The supported attributes for creating an authorization policy depend on what each service supports.
Submitting build run 'myapp-run-220999-210706331'...
Creating image 'private.us.icr.io/ce--6ef04-khxrbwa0lci/app-myapp:220418-0207-askql'...
Waiting for build run to complete...
Build run status: 'Running'
Build run completed successfully.
Run 'ibmcloud ce buildrun get -n myapp-run-220000-210706331' to check the build run status.
Waiting for application 'myapp' to become ready.
Configuration 'myapp' is waiting for a Revision to become ready.
Ingress has not yet been reconciled.
Waiting for load balancer to be ready.
Run 'ibmcloud ce application get -n myapp' to check the application status.
OK

https://myapp.abcdbwa0lci.us-south.codeengine.appdomain.cloud

And that's it. You now have an internet-facing application. The code in the application itself is the same as what is used for a Cloud Foundry application, it's just the Code Engine commands that are slightly different.

Let's take a deeper look at the previous app create command. Notice that the output of the app create command provides information about the progression of the build run before the app is created and deployed.



1. Code Engine receives a request to create an application from source code (instead of pulling directly from an image).
2. Code Engine checks for an IAM service ID and API key that is associated with the selected project. 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 local source (--build-source .). 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.
* 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 your job. You can create your job from images in a [public registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job) or [private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job-private) and then access the referenced image from your job run.
* If you are starting with source code that is located in a Git repository, you can choose to point to the location of your source, and Code Engine takes care of building the image from your source and creating the job with a single operation. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry. To learn more, see [Creating a job from repository source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job-source-code). If you want more control over the build of your image, then you can choose to [build the image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image) with Code Engine before you create your job and run the job.
* If you are starting with source code on a local workstation, you can choose to point to the location of your source, and Code Engine takes care of building the image from your source and creating the job with a single CLI command. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry. To learn more, see [Creating your job from local source code with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-local-source-code).
Accessing private code repositories 

A code repository, such as GitHub or GitLab, stores source code. With Code Engine, you can add access to a private code repository and then reference that repository from your build.

After you create access to your private code repository, you can pull code from repo, build it, and deploy an app or job with IBM Cloud® Code Engine.



 Create code repository access 

When you create access to a private code repository, you are saving credentials in Code Engine. In the console, these credentials are called Code repo access. In the CLI, these credentials are called SSH secrets.

Before you begin



* [Set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).
* [Choose an SSH key to use](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositorieschoose-ssh-key).





 Choosing an SSH key for code repository 

For both GitHub and GitLab, you can decide between two kinds of SSH keys to connect to your source repository.



1. An SSH key associated with the source code repository, this key has access to only those repositories where you register the SSH key. This access is read only, by default, which is the level that is required by Code Engine to download the source code. You can select write access, if needed. Consider choosing this option to set an SSH key that is scoped to specific repositories to control access to only the specified repositories.



* [GitHub - Deployment keys](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keysdeploy-keys)
Access for service bindings must be configured before you can bind a service instance to a Code Engine app, job or function workload. [Configure access for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccess) based on whether you want Code Engine to automatically create and manage the service ID for you or whether you want to use a service ID that you manage.

When you work with service bindings, what is the relationship between the service ID, service access secrets, and service credentials?
: In Code Engine, a service binding is the relationship between an app, job, or function workload and another IBM Cloud service. Code Engine uses a service ID to create credentials for a specific IBM Cloud service instance. These credentials are service credentials and are used by your Code Engine project to interact with the service instance. Service credentials are stored in a service access secret. A service access secret can be accessed by an app or job with the service credentials and is used to interact with the service instance.
: When you create your IBM Cloud service instance, you can choose to create the service credential for that service instance. Or, when you create a service binding, you can choose for Code Engine to automatically create the service instance credential for you if you configured [access for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccess).
: Whether you choose for Code Engine to automatically create the service credential for you or you manually create the service credential for a specific service instance, you must specify the Identity and Access Management (IAM) role for the service credential. The role that you specify defines the interaction that is allowed with the specific service instance and the bound Code Engine app or job. For example, if you create a service binding from Code Engine to an IBM Cloudant service instance and you only want the app or job to read from the IBM Cloudant database, select the Reader role.



 Binding a service instance to a Code Engine app or job from the console 

You can create a service binding that binds an existing service instance to a Code Engine app or job by using the console.
Working with the Periodic timer (cron) event producer 

The Periodic timer (cron) event producer generates an event at regular intervals. This interval can be scheduled by minute, hour, day, or month or a combination of several different time intervals. You can subscribe Code Engine apps and jobs to receive cron events.

The Periodic timer (cron) event subscription uses standard crontab syntax to specify interval details, in the format * * * * , where the fields are minute, hour, day of month, month, and day of week. For example, to schedule an event for midnight, specify 0 0 * * . To schedule an event for every Friday at midnight, specify 0 0 * * 5. For more information about crontab, see [CRONTAB](http://crontab.org/).

When you subscribe to a Periodic timer (cron) event producer, you must provide a destination (app or job) and a destination type for the subscription. If you do not provide a schedule, then the default of * * * * * (every minute) is used.

Code Engine has quotas for Periodic timer (cron) subscriptions within a project and subscription limits. For more information about Code Engine limits, see [Limits and quotas for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limits).



 Subscribing to Periodic timer (cron) events for an application 

You can work with Periodic timer (cron) subscriptions from the console or with the CLI.

Events are sent to applications as HTTP POST requests. For more information about the information that is included with the event, see [HTTP headers and body information for events](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribe-cronsub-header-body-cron).



 Subscribing to Periodic timer (cron) events for an application from the console 

You can create and update Periodic timer (cron) event subscriptions for an application from the console.

Before you begin
1. Create your job



1. Open the [Code Engine](https://cloud.ibm.com/codeengine/overview) console.
2. Select Start creating from Run a container image.
3. Select Job.
4. Enter a name for the job; for example, myjob.
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). Note that you must have a selected project to create a job.
6. Choose the code to run. You can create your job from an image in a [public registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job), [private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job-private), or in [IBM Cloud Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job-crimage). You can also create your job from [repository](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job-source-code) or [local](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-local-source-code) source code. For this example, use the Code Engine sample image, icr.io/codeengine/helloworld.
7. In Runtime settings, specify daemon for the mode. When you specify daemon mode, job runs for this job can run indefinitely and they do not time out. There is no retry limit for these job runs. Any job runs for these jobs are automatically restarted without limit.
8. Click Create to create the job.



2. View the list of defined jobs from the Jobs page and click the name of your job to open the configuration.
From the Create config page, complete the following steps:



1. Select the TLS Secret option.
2. Provide a name; for example, myTLSsecret.
3. Add the certificate chain and its private key. Note that you can concatenate the certificates by starting each in a new line. You can provide this information in a file.



5. Click Create to create the TLS secret.
6. Now that your TLS secret is created from the console, go to the Secrets and configmaps page to view a listing of defined secrets and configmaps. For secrets, you can display a list of user-generated secrets or a list of all secrets, which includes secrets that are generated by Code Engine. You can use your TLS secret when working with [custom domain mappings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-domain-mappings) in Code Engine.









 Creating secrets with the CLI 

Learn how to create secrets with the Code Engine CLI that can be consumed by apps or jobs as environment variables.

Before you begin



* Set up your [Code Engine CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli) environment.
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



Beginning with CLI version 1.42.0, defining and working with secrets in the CLI is unified under the secret command group. See [ibmcloud ce secret](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) commands. Use the --format option to specify the category of secret, such as basic_auth, generic, ssh, tls, or registry. The default value for the --format option is generic.

By using the secret create command, you can create and manage various secret formats.
You can deploy your IBM Cloud® Code Engine application across multiple regions to make it resilient to regional failures. Note that this example uses IBM Cloud Internet Services, but you can use alternate providers. This example also uses a custom domain.

Code Engine Cloud Internet Services (CIS)



* 30 minutes
* 2023-04-20



[Running a function from local source](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-tutorial)Running a function from local source

With this tutorial, run a Function with the Code Engine CLI from code on your local system

Code Engine



* 10 minutes
* 2023-06-29



[Securing your application with Guard](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started-with-guard)Securing your application with Guard

Guard is a runtime-security solution that IBM Cloud® Code Engine you can use to govern the incoming requests and outgoing responses of your application. Guard uses a per-application auto learned set of micro-rules to govern the application incoming requests and outgoing responses. As a result, you can use Guard to identify application anomalies and support Situational Awareness. Guard can also block requests or responses that are not in line with expected patterns.

Code Engine



* 10 minutes
* 2022-11-21



[Validating your application code and latency with Iter8](https://cloud.ibm.com/docs/codeengine?topic=codeengine-slovalidationtut)Validating your application code and latency with Iter8

Iter8 is the release engineering tool for Kubernetes that enables service-level objectives (SLO) validation, A/B testing, and progressive updates for Kubernetes applications. Now, you can use Iter8 to verify that your IBM Cloud® Code Engine application is running with low latency and is error-free. Learn more about Iter8 in 5 minutes.

Code Engine



* 5 minutes
* 2023-02-21
Repositories created 

As part of the Veeam service installation and configuration, the following repositories are created:



* For the Veeam configuration backup files - a repository named IC4V Default Config Backup Repository. The path to the folder where the Veeam backups are stored is <Drive>:ConfigBackup\.
* For scale-out, a repository named IC4V Scale-Out Repository. For more information, see [Adding a scale-out repository](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icos_orderingicos_ordering-scale-repo).
* For the VM backups - a repository named IC4V Default VM Backup Repository. The path to the folder where the VM backups are stored is <Drive>:VMBackup\. This repository is added as an extent to IC4V Scale-Out repository.









 Linux hardened repository for immutable storage 

When you order Veeam, you can optionally order a Linux hardened repository (LHR). You can use the repository for immutable storage.



* If you order an LHR, an additional bare metal server with Red Hat Enterprise Linux (RHEL) 8.x installed is deployed. The same bare metal hardware is deployed as the Veeam Backup & Replication (VBR) server.
* The disk options are similar to the VBR server. The size options are 2 TB, 6 TB, and 12 TB.
* You can order an LHR for any of the Veeam deployment types: VM, VSI, or bare metal server.
* There is no charge for LHR beyond the cost of the bare metal infrastructure.



See the following information:



* [Cyber recovery with Veeam architecture](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-veeam-cr-sa-overview), which describes two solution architectures to help you with cyber recovery.
After a "spread" rule is created, you can provision a virtual server into that group and ensure that it won't be on the same host as any of your other virtual servers. The best part? There’s absolutely no charge for using this feature.

You can create your placement group, then assign up to four new virtual server instances. With the "spread" rule, each of your virtual servers are provisioned on different physical hosts. In the following example configurations, the “Power Spread” option is used.

Zoom

![Figure 2. Placement groups host spread](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap/images/sap-terraform-ha-pg-1.png)

Figure 2. Placement groups host spread

Zoom

![Figure 3. Placement groups power spread](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap/images/sap-terraform-ha-pg-2.png)

Figure 3. Placement groups power spread

These are the following SAP instances that are needed for an HA scenario:



* ABAP central services instance (ASCS instance)- contains the ABAP message server and the ABAP enqueue server
* Enqueue replication server instance (ERS instance) for the ASCS instance
* Database instance
* Primary application instance (PAS) on node 1
* Additional application instance (AAS) on node 2



It's recommended that you run both the ASCS instance and the ERS instance in a switchover cluster infrastructure.





 IBM Cloud File Storage for VPC for SAP HA architecture 

[IBM Cloud File Storage for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-vpc-about) technology is used to make the SAP directories available to the SAP system.