vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Best practices for securing the Schematics objects 

IBM Cloud® Schematics uses open source projects, including Terraform, Ansible, Red Hat OpenShift on IBM Cloud, Operators, and Helm, delivered to you as a managed service. Rather than installing each open source project on your local system, and learning the API or CLI. You can declare the tasks that you want to run in IBM Cloud® and watch Schematics run these tasks for you.

Take time to review the suggested practices to reduce the security risks for all production, staging, and test servers in your cloud infrastructure. This list is an excellent starting point to increase the security of your cloud infrastructure.



 Best practices for creating Terraform Templates or modules in Git repositories 



 What are the best practices that you must follow in developing the Terraform templates, and publishing the same in the Git repositories? 

Follow these practices in developing and publishing the Terraform template in the Git repositories.



* Create Terraform template by using Terraform version1.0 or higher and current [IBM Cloud provider](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest).
* Create environment variables for all your credentials.
* Check whether pre-commit hooks are run to inspect your code meets Terraform standards, see [sample repository that contains pre-commit hook](https://github.com/terraform-ibm-modules/terraform-ibm-iam/blob/main/.pre-commit-config.yaml).
* Check whether your repository uses Terratest framework to validate your Terraform resources and data source to provision, see [sample validated Terraform repository](https://github.com/terraform-ibm-modules/terraform-ibm-iam/blob/main/.github/workflows/validate_terraform.yml) to run Terratest.
* Check whether your repository contains gitignore for any files that are not tracked by Git remain untracked.
* Add the license file for your template.
* Do not set your sensitive variable as default in the configuration files.
* Check your secured variables or output as sensitive.
Schematics Blueprints is a [beta feature](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-beta-limitations) that are available for evaluation and testing purposes. It is not intended for production usage. Refer to the list of [limitations](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-beta-limitationssc-bp-beta-limitation) for the beta release.



 Understanding blueprint templates and configuration 

IBM Cloud® Schematics Blueprints utilizes the analogy of building a house from a blueprint drawing. Where a blueprint defines the architecture, layout and the major building blocks.



 Blueprint configuration 

Cloud environments are deployed from a blueprint configuration, specifying a blueprint template and customizable input values that define parameters like its region or compute capacity. [Templates](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpb2) determine the infrastructure architecture, specifying the modules (building blocks) to deploy the cloud resources of an environment. The section [using Terraform modules with blueprint templates](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-terraform) illustrates how public modules can be combined with user developed modules to create custom solutions.

Well designed templates are reusable across multiple environments, with the customizable input values maintained separately from the template as [inputs](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpi1). In cookie cutter fashion, several environments can be created from the same blueprint template. Each environment has its own [blueprint configuration](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpb3) and inputs. This separation of template from its deploy time configuration is illustrated in the figure. Here a template is reused many times to deploy a range of environments such as dev, stage, and production.
Schematics Blueprints is a [beta feature](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-beta-limitations) that are available for evaluation and testing purposes. It is not intended for production usage. Refer to the list of [limitations](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-beta-limitationssc-bp-beta-limitation) for the beta release.



 Maintaining blueprints 

Maintaining a cloud environment is about managing continual change. Cloud environments are not static. User infrastructure requirements change and the IBM Cloud® platform is constantly evolving. Without maintenance and updates of the blueprint templates, inputs and automation module code, a deployed environment will lose currency and compliance, and will cease to be manageable through Schematics automation.

Change occurs for many reasons:



* The IBM Cloud® platform is constantly adding features, and depreciating end-of-life services. It also maintains the currency of services, for example IBM Cloud® Kubernetes Service and the databases IBM Cloud® Databases for Redis and IBM Cloud® Databases for MongoDB continually move to new versions.
* Alongside, the open source IaC tools that are used by Schematics evolve, with new versions of Terraform and Helm, and the supporting Terraform providers.
* As the platform evolves, IBM® authored automation modules are refreshed to support new service features, maintain currency and to address evolving security compliance requirements.
* Changes are also expected in the application environment to reflect new user requirements, scaling up or down, rotation of API keys, certificates and more.



Managing a blueprint environment is an iterative cycle of applying changes to the deployed environment to maintain currency and compliance.



 Updating blueprint environments 

After deployment, blueprint environments will continue to evolve through managed change, implemented as updates to the blueprint template, automation modules, and inputs.

Changes to the environment are first prepared as version updates to the blueprint template and input files. The blueprint configuration is updated in Schematics with the updated template and input versions. These changes are then applied to the blueprint environment.
Deploy a Node.js Express app by using IBM Cloud Schematics 

In this tutorial, you learn how to create and deploy a scalable Node.js Express application. This scalable web app offers a one-click option to create an IBM Cloud® Schematics workspace with your choice of preconfigured Terraform templates. The Terraform templates deploy your app to IBM Cloud with options for the deployment target (Kubernetes or Red Hat® OpenShift®) and the DevOps toolchain pipeline structure.

IBM Cloud Schematics delivers Terraform-as-a-Service so that you can use a high-level scripting language to model the resources that you want in your IBM Cloud environment, and enable Infrastructure as Code (IaC). [Terraform](https://www.terraform.io/) is an open source software that is developed by HashiCorp that enables predictable and consistent resource provisioning to rapidly build complex, multitier cloud environments.

In this tutorial, you follow two easy steps to create a Schematics workspace and apply a Terraform execution plan. When you apply the plan, a Kubernetes or OpenShift cluster is created, and a Node.js Express application is deployed to it by using an IBM Cloud DevOps toolchain.

Two types of DevOps toolchain pipeline structures are available with this app:



* Classic pipeline structure
* Tekton "GitSecure" pipeline structure



Both toolchain template options offer a code repository, delivery pipelines, and web IDE.



 Before you begin 



* Set up an [IBM Cloud account](https://cloud.ibm.com/registration). Depending on your IBM Cloud account type, access to certain resources might be limited. Depending on your account plan limits, certain capabilities that are required by some DevOps toolchains might not be available. For more information, see [Setting up your IBM Cloud account](https://cloud.ibm.com/docs/account?topic=account-account-getting-started) and [Upgrading your account](https://cloud.ibm.com/docs/account?topic=account-upgrading-account).







 Step 1: Create a Schematics workspace
Deploy, modify, and remove IBM Cloud resources by using IBM Cloud Schematics.



 ibmcloud schematics apply 

Scan and run the infrastructure code of your Terraform template that your workspace points to. When you apply a Terraform template, your resources are provisioned, modified, [stored](https://cloud.ibm.com/docs/schematics?topic=schematics-general-faqpersist-file), or removed in IBM Cloud. IBM Cloud Schematics supports 50 API requests per minute, per host, and per customer. The host can be us-east, us-south, eu-gb, or eu-de region. You need to wait before calling the command again.

Your workspace must be in an Inactive, Active, Failed, or Stopped state to perform a Schematics apply action. For more information about workspace state, see [workspace state diagram](https://cloud.ibm.com/docs/schematics?topic=schematics-wks-state&interface=uiworkspace-state-diagram).

While your infrastructure code runs in IBM Cloud Schematics, you cannot make any changes to your workspace.

Syntax

ibmcloud schematics apply --id WORKSPACE_ID [--target RESOURCE1] [--target RESOURCE2] [--var-file PATH_TO_VARIABLES_FILE] [--force] [--output OUTPUT]

Command options



Schematics apply flags

 Flag Required / Optional Description 

 --id or -i Required The unique identifier of the workspace that points to the Terraform template in your source control repository that you want to apply in IBM Cloud. To find the ID of your workspace, run ibmcloud schematics workspace list command. 
 --target or -t Optional Target the creation of a specific resource of your Terraform configuration file by entering the Terraform resource address, such as ibm_is_instance.vm1. All other resources that are defined in your configuration file is not created or updated. To target the creation of multiple resources, use the following syntax: --target <resource1> --target <resource2>.
Template files are written to a [YAML schema](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-template-schema-yaml) and specify the Terraform [automation modules](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpb5) to be used, their versions, Git source libraries, and the relationships and dependencies between modules. Template files versioned and sourced from a version control system, GitHub or GitLab.





 Blueprint configuration 

A blueprint configuration is the initial definition that the user provides to create a blueprint. The configuration defines the [blueprint template](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpb2) YAML file to be used, its Git source location. Also any [input files](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpi2) that will be used to customize the template, file version information, and additional dynamic (override) inputs.





 Blueprint environment 

A blueprint environment is the set of IBM Cloud resources that are created from a [blueprint template](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpb2) and the inputs that are specified by a [blueprint configuration](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpb3). It is composed of smaller linked modular environments.





 Blueprint modules 

Blueprint templates are composed from IaC automation modules. Modules perform the work of deploying Cloud resources using open-source IaC tools. Initial support is for modules written in Terraform with additional IaC tools planned. Tools like Redhat Ansible and Helm, may be utilized today as blueprint modules using a Terraform wrapper.
Schematics architecture 

Learn about the IBM Cloud® Schematics service architecture, service dependencies, and how client workloads are isolated from each other in IBM Cloud Schematics?



 Architectural flow 

Schematics is a shared multi-tenant service. On initial use, a new Schematics service instance is automatically provisioned for each user account.

The following Schematics architecture image depicts:



* Main Schematics components.
* The interaction between service components.
* Key Management services used.
* Usage of IBM Cloud® observability services.
* The role of runtime jobs to interact with IBM Cloud APIs, private cloud such as vSphere, Kubernetes, and other public cloud providers such as AWS, Google, so on.



Zoom

![Schematics architecture](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/schematics-enduser-architecture.png)

Figure 1. Schematics architecture





 Workload isolation 

IBM Cloud Schematics implements a robust multi-tenant service architecture on shared infrastructure.



 How are API requests to the service isolated from other API requests? 

All API requests to the Schematics api-server are handled as separate service processes. IAM requests are made to authenticate user access to Schematics, workspaces and operations. Authenticated API requests are processed and queued as Schematics internal messages.

The Schematics job queue manager forwards the requests with the job ID and health check messages. At any particular time, a maximum of n API requests are processed by the Schematics engine. By default, n equals 20, but this number is manually adjusted by the Schematics operator based on the current API workload.

For every queued request from a Schematics user, the Schematics engine creates a dedicated runtime job that runs to completion. The request is removed from the queue when it is fully processed. The Schematics jobs are not shared between tenants or reused later.
IBM Cloud Schematics [IBM Cloud Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-getting-started) is a managed Terraform service where you can use native Terraform capabilities, but you don't have to worry about setting up and maintaining the Terraform CLI and IBM Cloud Provider plug-in. For more information about how to use Terraform to create a cluster, see [Creating single and multizone Kubernetes and Red Hat OpenShift clusters](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-tutorial-tf-clusters). Yes Yes 
 Terraform [Terraform](https://www.terraform.io/docs/) is an open-source software that enables predictable and consistent provisioning of IBM Cloud platform, classic infrastructure, and VPC infrastructure resources by using a high-level scripting language. For more information about how to use native Terraform to create a cluster, see [Creating single and multizone Kubernetes and Red Hat OpenShift clusters](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-tutorial-tf-clusters). Yes Yes 







 Hybrid cloud services 



Table 3. Hybrid cloud services

 Service Description Classic VPC 

 IBM Cloud VPC VPN With the IBM Cloud VPC VPN, you can securely connect your VPC to an on-premises network, other VPCs, or to classic infrastructure through a VPN tunnel. For more information, see [Connecting to your on-premises network](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-onprem-example). Yes 
 Direct Link With [IBM Cloud® Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-dl-about), you can create a direct, private connection between your remote network environments and IBM Cloud Kubernetes Service without routing over the public internet.
Schematics Blueprints is a [beta feature](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-beta-limitations) that are available for evaluation and testing purposes. It is not intended for production usage. Refer to the list of [limitations](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-beta-limitationssc-bp-beta-limitation) for the beta release.



 Using Terraform modules with blueprint templates 

One of the use cases for blueprints is to compose infrastructure architectures directly from [Terraform modules](https://developer.hashicorp.com/terraform/language/modulesmodules).

Blueprint templates can reuse existing Terraform modules from the [Terraform registry](https://registry.terraform.io/namespaces/terraform-ibm-modules), along with IBM and user created modules from public and private libraries. Best practice implementations for IBM Cloud are available as reusable Terraform modules in the [terraform-ibm-modules](https://github.com/terraform-ibm-modules) GitHub repo and the Terraform registry.

The section [Orchestration and modules](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-scalingblueprint-scaling-orchestration) describes the design philosophy of the design and usage of modules within the Blueprints orchestration framework. See the [IBM module authoring guidelines](https://terraform-ibm-modules.github.io/documentation//implementation-guidelines) for creating user modules compliant with Schematics Blueprints.

The combination of IBM and user modules from public and private repos to create a custom template is illustrated in the figure.

Zoom

!
If you are validating a deployable architecture that references modules from the catalog, make sure that the modules were onboarded to the catalog.



1. From the Validate version page, enter the name of your Schematics service, select a resource group, select a Schematics region, and click Next.

In the Tags field, you can enter a name of a specific tag to attach to your template. This tag is put on the IBM Cloud Schematics workspace. Tags provide a way to organize, track usage costs, and manage access to the resources in your account.
2. From the input variables section, review your parameter values, and click Next.
3. In the Validation version section, select I have read and agree to the following license agreements.
4. Click Validate.

To monitor the progress of the validation process, click View logs.







 Validating a test deployment by using the CLI 

To validate a version of your deployable architecture into an existing product, run the [ibmcloud catalog offering version validate](https://cloud.ibm.com/docs/cli?topic=cli-manage-catalogs-pluginvalidate-offering) command:

ibmcloud catalog offering version validate --vl <VERSION_LOCATOR>





 Reviewing cost by using the CLI 

Review the cost of your deployable architecture by using the console. To view the steps, see [Reviewing or defining cost by using the console](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-onboard-custom&interface=uicustom-cost-ui).





 Reviewing or defining cost by using the console 

You can review the estimated starting cost of your product. If you included the resource metadata in your source repository, the information is parsed during validation and pulled into a starting cost per hour (USD) summary table. The table is displayed in the catalog for customers to compare across variations of a deployable architecture or to get a general idea of what a base configuration of your deployable architecture might cost.

The summary table lists the resources that your product uses and their estimated costs. Starting cost is an estimate based on available data.
* UI
* CLI
* API





Schematics Blueprints is a [beta feature](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-beta-limitations) that are available for evaluation and testing purposes. It is not intended for production usage. Refer to the list of [limitations](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-beta-limitationssc-bp-beta-limitation) for the beta release.



 Update a blueprint configuration 

Cloud environments are not static. User infrastructure requirements change and the IBM Cloud® platform is constantly evolving. Without maintenance and updates of the blueprint templates, inputs and modules, a deployed environment loses currency, compliance, and will cease to be manageable through Schematics automation.

After the [deploy](https://cloud.ibm.com/docs/schematics?topic=schematics-deploy-blueprints) lifecycle stage of a cloud environment, an environment will continue to evolve through managed change that is implemented as updates to the blueprint template, automation modules and inputs. Review the section on [updating blueprints](https://cloud.ibm.com/docs/schematics?topic=schematics-update-op-blueprints) to understand more about the process of maintaining blueprint environments and the steps required to run regular updates.



 Update process 

Updating a deployed blueprint environment and cloud resources is a two-step process, Update, and Apply. The first step updates the blueprint configuration in Schematics with the intended changes to the blueprint template, IaC module code, and inputs. The second [blueprint apply](https://cloud.ibm.com/docs/schematics?topic=schematics-apply-blueprint&interface=cli) step runs the automation module code to deploy the changes in the blueprint configuration.

Updating a blueprint environment uses the capabilities of Terraform to update deployed cloud resources. The Terraform config and inputs for a module are updated by the blueprint update operation.
Deploy, modify, and remove IBM Cloud resources by using IBM Cloud Schematics.



 ibmcloud schematics apply 

Scan and run the infrastructure code of your Terraform template that your workspace points to. When you apply a Terraform template, your resources are provisioned, modified, [stored](https://cloud.ibm.com/docs/schematics?topic=schematics-general-faqpersist-file), or removed in IBM Cloud. IBM Cloud Schematics supports 50 API requests per minute, per host, and per customer. The host can be us-east, us-south, eu-gb, or eu-de region. You need to wait before calling the command again.

Your workspace must be in an Inactive, Active, Failed, or Stopped state to perform a Schematics apply action. For more information about workspace state, see [workspace state diagram](https://cloud.ibm.com/docs/schematics?topic=schematics-workspace-setupworkspace-state-diagram).

While your infrastructure code runs in IBM Cloud Schematics, you cannot make any changes to your workspace.

Syntax

ibmcloud schematics apply --id WORKSPACE_ID [--target RESOURCE1] [--target RESOURCE2] [--var-file PATH_TO_VARIABLES_FILE] [--force] [--output OUTPUT]

Command options



Schematics apply flags

 Flag Required / Optional Description 

 --id or -i Required The unique identifier of the workspace that points to the Terraform template in your source control repository that you want to apply in IBM Cloud. To find the ID of your workspace, run ibmcloud schematics workspace list command. 
 --target or -t Optional Target the creation of a specific resource of your Terraform configuration file by entering the Terraform resource address, such as ibm_is_instance.vm1. All other resources that are defined in your configuration file is not created or updated. To target the creation of multiple resources, use the following syntax: --target <resource1> --target <resource2>.