vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Environments deployed from reusable blueprint template](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics//images/new/bp-reuse.svg)

Environments deployed from reusable blueprint template

A common reusable template defines the architecture, with separate input files for the dev, stage and prod for define the customizations. For example, the scale, configuration and region for each environment. All based off the same template.

Each blueprint environment is uniquely defined by its own [blueprint configuration](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-termsbpb3). The configuration defines the template, its location and version, plus the inputs to customize a template for the target environment. The separation of template from its runtime configuration allows a single template to be reused many times to deploy a range of environments such as dev, stage, and production with multiple target regions.

For details on how to configure a blueprint refer to the section [Understanding blueprint templates and configuration](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-templates).



 Deployment pipelines 

Reuse supports the creation of software delivery deployment pipelines. Here the same or similar environment configurations are required to support the stages of a delivery pipeline to ensure that application code is tested in an environment that is as close to production as possible.

The prior figure illustrates the reuse of a template across the stages of a delivery pipeline. A single template provides a common architecture pattern against which application code can be developed and tested in production like environments. The configuration for each environment is provided by the inputs, customizing each stage of the pipeline, adjusting for scaling, region and networking.







 Customization best practice 

Blueprints best practice is to for templates to be reusable across the instances of an application environment, from dev to stage and production.
Can integrate with any cloud service providers or private cloud. 
 Compute time Null resources or [local-exec](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-limitationslocal-remote-exec) executes for a maximum of 30 minutes. There is no compute time restrictions. 
 Latency Runs in Schematics clusters provisioned in us or eu region only. Can be configured to run on edge cluster or Satellite cluster for faster response time. 
 Network configuration Ingress/egress policies are controlled by Schematics. Cannot reach out to any external PORT that are not in allowed list. Can decide on ingress/egress policies, and can allow PORTS accordingly. 
 Software Can use only pre-installed software such as Python / Jquery / IBM Cloud command line cannot install additional software. Client is free to install additional software on need basis. 
 Tenancy Multi tenant. Single tenant. 







 Setting up an Agent 

The [Schematics Agents](https://cloud.ibm.com/docs/schematics?topic=schematics-agents-intro) are deployed in your IBM Cloud® account and configured to connect to your Schematics service instance. The block diagram represents the set up to provision, deploy, connect, and use the required cluster infrastructure.

Zoom

![Schematics Agents set up](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics//images/agents-setup-latest.svg)

Schematics Agents set up

For more information about estimated time to set up an Agent, refer to [Installing Schematics Agent](https://cloud.ibm.com/docs/schematics?topic=schematics-agents-setup).





 Next steps 

Now that you learned about the Schematics Agents architecture and its advantages. The next steps to explore Schematics Agents:
If you provided your Terraform template by uploading a tape archive file (.tar), you must use the [ibmcloud schematics workspace upload](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-cli-referenceschematics-workspace-upload) command to provide a new version of your template.
4. If you added, or removed variables in your Terraform configuration files, or if you want to change the variable values that you set when you created the workspace, enter or change the variable values.
5. Click Generate plan to create a Terraform execution plan. Note that during this time, you cannot make changes to your workspace.
6. Click View log to review the log files of your execution plan. This log file provides a summary of all the resources that IBM Cloud Schematics is about to modify. IBM Cloud Schematics might not be able to modify some of your resources, and suggest removing and re-creating the resource.
7. Click Apply plan to apply the new Terraform template version. Depending on the changes that you made, it might take couple of minutes or up to a few hours for the template to be applied. Note that during this time, you cannot make changes to your workspace.

If you want to stop applying your Terraform template, you can use the Stop button. Note that updates to resources that were already performed are not reverted. If a resource is currently updating, Schematics waits for the update to complete, and then stops the creation, update, or deletion of any other resources in your Terraform template.
8. Review the log files to ensure that no errors occurred during the modification process.
9. From the navigation, select Resources and verify that your resources show the updated configuration.







 Managing drift between your cloud environment and your Terraform configuration 

Use Terraform-native capabilities to determine the differences between the infrastructure and platform services that you provisioned in IBM Cloud and the resources that you specified in your Terraform configuration files.

Managing deviations between the real-world state of your cloud environment and your infrastructure code, also referred to as drift, is a key challenge when implementing infrastructure as code.
Deploying DevSecOps Application Lifecycle Management by using IBM Cloud Schematics 

Customize and deploy an instance of the DevSecOps Application Lifecycle Management deployable architecture by using IBM Cloud Schematics.



 Before you begin 



 Reviewing access requirements 

The DevSecOps Application Lifecycle Management deployable architecture requires an [IBM Cloud® API key](https://cloud.ibm.com/docs/account?topic=account-manapikey) to deploy the toolchains. Cloud API keys are distinct from Service API keys. Service API keys cannot create pipelines in the toolchains. Using a Service API key would cause the deployment process to fail. Create an [API key](https://cloud.ibm.com/iam/apikeys). The deployment process provisions the toolchains into the account that owns the API key.

Two similar ibmcloud api key entries are used. ibmcloud_api_key is used for creating the toolchains by using Schematics. ibmcloud_api_keyis set during the deployment process. The other entry, ibmcloud-api-key is required to run the toolchains and is created in a secrets provider.





 Configuring your workspace 

Your workspace is a IBM Cloud® Schematics workspace that is configured to run the Terraform code that creates the toolchains. Any workspaces that you created previously are listed here.



Table 1. Workspace variables

 Variable Description 

 Name The name of the workspace. 
 Resource Group The resource group where the workspace is created. 
 Location The location where the workspace is created. 



You can find the IBM Cloud Schematics workspaces in [Workspaces](https://cloud.ibm.com/schematics/workspaces). Alternatively, go to [IBM Cloud®](https://cloud.ibm.com) and go to the IBM Cloud Schematics workspaces by clicking Menu!
Or Terraform by using IBM container worker pool zone attachment resource. For more information, see [ibm_container_worker_pool_zone_attachment](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/container_worker_pool_zone_attachment).





 Where can I view the list of public and private allowed IP addresses of us-south, us-east, eu-gb, and eu-de regions? 

You can view the list of public and private allowed IP addresses of us-south, us-east, eu-gb, and eu-de regions in [Schematics allowed IP addresses](https://cloud.ibm.com/docs/schematics?topic=schematics-allowed-ipaddresses).





 Can I manually add, or remove a resource from the service dashboard directly? 

When you provision resources with IBM Cloud Schematics, the state of your resources is stored in a local IBM Cloud Schematics state file. This state file is the single source of truth for IBM Cloud Schematics to determine what resources are provisioned in your IBM Cloud account. If you manually add a resource without IBM Cloud Schematics, this resource is not stored in the IBM Cloud Schematics state file, and as a consequence cannot be managed with IBM Cloud Schematics.

When you manually remove a resource that you provisioned with IBM Cloud Schematics, the state file is not updated automatically and becomes out of sync. When you create your next Terraform execution plan or apply a new template version, Schematics verifies that the IBM Cloud resources in the state file exist in your IBM Cloud account with the state that is captured in your state file. If the resource is not found, the state file is updated, and the Terraform execution plan are changed.

To keep your IBM Cloud Schematics state file and the IBM Cloud resources in your account in sync, use IBM Cloud Schematics to provision, or remove your resources.





 What changes can I make to my resources? 

You can choose to add, modify, or remove infrastructure code in your Terraform template through GitHub, or update variable values from the Schematics Workspaces dashboard.
[CreateWorkspace](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/roks-on-vpc/images/provision/schematics-create-workspace.png)
3. Schematics can automatically pull terraform code from a GitHub repo. Enter https://github.com/IBM-Cloud/cloud-journey/tree/main/ROKS as the repository URL (which represents the VPC architecture depicted above) and select terraform_v1.0. ![CreateWorkspace2](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/roks-on-vpc/images/provision/schematics-create-workspace2.png)
4. Specify the workspace details values based on your preferences. ![CreateWorkspace3](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/roks-on-vpc/images/provision/schematics-create-workspace3.png)

As a best practice, do NOT use the "default" resource group. Create a resource group for this network or project provides more flexibility. For additional details see the [Preparing Your IBM Cloud Account](https://cloud.ibm.com/docs/vpc-journey?topic=vpc-journey-vpc-prep-account) page of this deployment journey guide.
5. Validate the information entered and click on Create to retrieve the Terraform code and create the Schematics workspace.







 Configure Terraform Variables 



1.
See [Managing IBM Cloud resources with Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-manage-lifecycle) to create, update, and delete IBM Cloud resources with Terraform.







 Next steps 



* Looking for more workspace samples to work with? Check out the [IBM Cloud Schematics GitHub repository](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-provider-templatesample). Check the Readme files of the examples for further customization, and usage for each sample.
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.

Schematics Red Hat OpenShift on IBM Cloud

+4

Red Hat OpenShift on IBM Cloud,Kubernetes service,Continuous Delivery,Creating apps



* 45 minutes
* 2023-03-09



[Deploy a Java Spring app by using IBM Cloud Schematics](https://cloud.ibm.com/docs/apps?topic=apps-tutorial-spring-webapp)Deploy a Java Spring app by using IBM Cloud Schematics

In this tutorial, you learn how to create and deploy a scalable Java Spring 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.

Schematics Red Hat OpenShift on IBM Cloud

+4

Red Hat OpenShift on IBM Cloud,Kubernetes service,Continuous Delivery,Creating apps



* 45 minutes
* 2023-03-09



[Creating an IBM Cloud Satellite environment on AWS by using scripts](https://cloud.ibm.com/docs/apps?topic=apps-tutorial-trysat)Creating an IBM Cloud Satellite environment on AWS by using scripts

This tutorial and set of scripts provide a mostly automated way to set up an IBM Cloud Satellite location and Red Hat OpenShift cluster on Amazon Web Services (AWS). This is not a production-ready solution, but it provides a useful tool for proof-of-concepts, learning, and experimenting.

Schematics Red Hat OpenShift on IBM Cloud

+4
This builds on the IaC best practice of [modular architectures](https://cloud.ibm.com/docs/schematics?topic=schematics-infrastructure-as-codeiac-bp-modularity). It [scales the Terraform deployment model](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-scaling), by connecting modular IaC environments, as the layers and components of large infrastructure architectures. The definition of an architecture using modules and deployment as linked environments is illustrated.

Zoom

![Deploying modular large-scale environments with Blueprints](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics//images/new/bp-overview.svg)

Deploying modular large-scale environments with Blueprints

A blueprint template determines the infrastructure architecture, specifying the modules required for the implementation, the infrastructure topology and relationships between modules. Inputs customize the template for the target deployment. Blueprint operations build up the infrastructure by deploying the smaller modular environments defined by the template. Blueprints linking the module environments into the whole, by the sharing and passing of resource dependency data between modules.

Reuse and maintainability are key features to deploy at scale. Publicly available modules designed for IBM Cloud® can be [combined with third-party and user developed modules](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-terraform) to create customized solutions. Separately maintained input configurations, ensure reusable blueprint templates can be configured at deploy time to create customized dev, stage and prod pipelines, or repeatable application deployments.

This modular approach to composition and configuration also eases the task of maintaining and updating large environments. Blueprint operations update environments on request through configuration of module versions, rather than by code change. IBM module libraries are regularly refresh and upgrade version to maintain platform compatibility and meet current compliance requirements.
2022/11/21 08:24:15 Done with the blueprint init flow job

OK







 Policy commands 

Schematics Policy is a beta feature 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.



 ibmcloud schematics policy create 

Create a policy using Schematics to select one or more Schematics objects (such as, Workspaces, Action, Blueprint) to deliver targeted Schematics feature.

Syntax

ibmcloud schematics policy create --name POLICY_NAME --kind POLICY_KIND --location LOCATION --resource-group RESOURCE_GROUP [--description DESCRIPTION] [--target-file TARGET_FILE] [--tags TAGS] [--output OUTPUT] [--no-prompt]

Command options



Schematics policy create flags

 Flag Required / Optional Description 

 --name or -n Required The unique name of the policy. 
 --kind or -K Policy kind for managing and deriving policy decision. Supported is agent_assignment_policy. 
 --location or -l Optional Geographic location of Schematics service where the agent is defined. For example, us-south, us-east, eu-de, eu-gb. Jobs are picked up from this location for processing. 
 --description or -d Optional The description of the Schematics policy. 
 --resource-group or -r Required Resource group name or ID for the policy. 
 --tags or -t Optional Tags can be used multiple times to search for and locate agent policies faster. 
 --target-file or tf Optional Path to the JSON file containing the definition of the policy. 
 --output or -o Optional Specify output format, only JSON is supported. 
 --no-prompt Optional Set this flag to run the command without user prompts. 





 Using the payload file 

You can provide a payload file to specify certain parameters for the policy create command.
In this tutorial, you learn how to create and deploy a scalable Java Spring 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.

Schematics Red Hat OpenShift on IBM Cloud

+4

Red Hat OpenShift on IBM Cloud,Kubernetes service,Continuous Delivery,Creating apps



* 45 minutes
* 2023-03-09



[Creating an IBM Cloud Satellite environment on AWS by using scripts](https://cloud.ibm.com/docs/apps?topic=apps-tutorial-trysat)Creating an IBM Cloud Satellite environment on AWS by using scripts

This tutorial and set of scripts provide a mostly automated way to set up an IBM Cloud Satellite location and Red Hat OpenShift cluster on Amazon Web Services (AWS). This is not a production-ready solution, but it provides a useful tool for proof-of-concepts, learning, and experimenting.

Schematics Red Hat OpenShift on IBM Cloud

+4

Red Hat OpenShift on IBM Cloud,Kubernetes service,Continuous Delivery,Creating apps



* 1.5 hours
* 2022-02-23



[Part 4: Set up a Continuous Compliance (CC) toolchain](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-cc-toolchain)Part 4: Set up a Continuous Compliance (CC) toolchain

This tutorial is part 4 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 4 of this tutorial series, you use the toolchain template for continuous compliance (CC) to ensure that your deployed artifacts and their source repositories are always compliant.

Kubernetes service Continuous Delivery

+1

DevSecOps



* 1 hour
ibmcloud schematics apply --id myworkspace-a1aa1a1a-a11a-11 --json --target ibm_is_instance.vm1 --var-file ./terraform.tfvars





 ibmcloud schematics destroy 

Remove the IBM Cloud resources that you provisioned with your Schematics Workspace, even if these resources are active. 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.

Use this command with caution. After you run the command, you cannot reverse the removal of your IBM Cloud resources. If you use permanent storage, ensure that you create a backup for your data.

Your workspace must be in an Active, Failed, or Stopped state to perform a Schematics destroy action.

Syntax

ibmcloud schematics destroy --id WORKSPACE_ID [--target RESOURCE1] [--target RESOURCE2] [--force] [--output OUTPUT]

Command options



Schematics destroy flags

 Flag Required / Optional Description 

 --id or -i Required The unique identifier of the workspace that points to the Terraform template in your source repository that specifies the IBM Cloud resources that you want to remove. To find the ID of a workspace, run ibmcloud schematics workspace list command. 
 --target or -t Optional Target the deletion of a specific resource by entering the Terraform resource address, such as ibm_is_instance.vm1. All other resources in your workspace remain unchanged. To target the deletion of multiple resources, use the following syntax: --target <resource1> --target <resource2>. If the targeted resource specifies the count attribute and no index is specified in the resource address, such as ibm_is_instance.vm1[1], all instances that share the same resource name are targeted for deletion.
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.

Refer to the section [using Terraform modules with blueprint templates](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-terraform) for details on working with Terraform root and child modules. Examples of IBM authored (child) modules that can be used with Blueprints can be found in the GitHub repository [Terraform IBM Modules](https://github.com/terraform-ibm-modules).

Each module in a template is deployed as an independent environment, managed by Blueprints as part of the overall application architecture.





 Blueprint inputs 

A blueprint template, optionally declares a set of input variables that can be used to customize the blueprint template, while deploying or managing a blueprint environment. The template metadata for the input variables include the following: variable name, variable type, default value, variable description, sensitive, read only, hidden.

Blueprint inputs can be provided as:



* User-defined input, provided via the Schematics API, CLI or UI at config create time. They can be used to pass input values that would be a security exposure if written to a Git repository.