| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2022-11-05 |
glossary, IBM Cloud schematics glossary, terms, definitions, schematics glossary |
schematics |
{{site.data.keyword.attribute-definition-list}}
{: #glossary}
This glossary provides terms and definitions for {{site.data.keyword.bpshort}} objects, such as action, Agent, Blueprint, Catalog, Inventory, Job, Template or Modules, and workspace.
{: shortdesc}
The following cross-references are used in this glossary:
Seerefers you from a non-preferred term to the preferred term or from an abbreviation to the spelled-out form.See alsorefers you to a related or contrasting term.
{: #glossary-actions}
Automate resource and application management with Ansible playbook. {: shortdesc}
{: #glossary-agents}
Extends {{site.data.keyword.bpshort}} ability to reach user infrastructure. {: shortdesc}
{: #agentsa1}
Method or service to bind {{site.data.keyword.bpshort}} Agents with {{site.data.keyword.bpshort}} Workspaces. {: shortdesc}
{: #agentsa2}
A collection of Agent related microservices deployed on the Agent infrastructure. It is composed of the following microservices.
JobrunnermicroserviceSandboxmicroserviceRuntimeworkspaceJob {: shortdesc}
{: #agentsa3}
A Kubernetes cluster used to deploy and run the Agent services. It is composed of the following resources.
- VPC infrastructure as
public_gateways, subnets - Kubernetes Service as vpc_kubernetes_cluster
- IBM LogDNA instance {: shortdesc}
{: #glossary-blueprint}
{{site.data.keyword.bplong}} Blueprints is an Infrastructure as Code{: external} (IaC) deployment and lifecycle management service for large-scale cloud environments. It utilizes the analogy of building a house from a blueprint drawing. Where a blueprint defines the architecture, layout and the major building blocks. A craftsman builts the house from well defined components using the blueprint for guidance.
It builds on the {{site.data.keyword.bpshort}} Workspace support for Infrastructure as Code (IaC) and Hashicorp Terraform. See Working with blueprints for details of how to use blueprints and Terraform to create large-scale environments from solution architectures. When using the service, {{site.data.keyword.bpshort}} users create a blueprint to deploy and manage the cloud resources that are specified by a blueprint template.
{: shortdesc}
{: #bpb1}
A blueprint is the resource in {{site.data.keyword.bpshort}} a user works with to manage the environment and cloud resources created from a blueprint template and config. The blueprint resource in {{site.data.keyword.bpshort}} records the details of the template and the specific configuration details. All operations against the deployed cloud resources are performed using the blueprint resource or ID.
The blueprint (resource) maintains the record of operations run, job status, the cloud resources deployed, and the blueprint template. It defines the infrastructure architecture and the unique input values that are used to configure the environment.
A blueprint is created with a blueprint configuration. The set of cloud resources deployed by a blueprint is referred to as a blueprint environment. {: shortdesc}
{: #bpb2}
A blueprint template defines the infrastructure architecture, topology, and cloud resources for a solution architecture. The template implements the desired architecture from reusable modules that are written in Terraform. Template files are written to a YAML schema and specify the Terraform automation modules 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.
{: shortdesc}
{: #bpb3}
A blueprint configuration is the initial settings that the user provides to create a blueprint in {{site.data.keyword.bpshort}}. The configuration defines the blueprint template YAML file to be used, its Git source location, input files, file version information, and additional inputs.
{: shortdesc}
{: #bpb4}
A blueprint environment is the set of {{site.data.keyword.cloud_notm}} resources that are created from a blueprint template and inputs that are specified by a blueprint configuration.
{: shortdesc}
{: #bpb5}
Blueprint templates are composed from IaC automation modules that are implemented in HashiCorp Terraform. Refer to the section using Terraform modules with blueprint templates for details on working with Terraform root and child modules. Examples of {{site.data.keyword.IBM_notm}} authored (child) modules can be found in the GitHub repository Terraform IBM Modules{: external}. {: shortdesc}
{: #bpi1}
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, readonly, 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.
- Version-controlled blueprint input file (from a Git repository) {: shortdesc}
{: #bpi2}
Version-controlled input file (from a Git repository) to pass inputs to customize the blueprint template for a specific environment. The type of an input variable is defined meta data in the template file. {: shortdesc}
{: #bpj1}
Blueprint operations (commands) are run as jobs by {{site.data.keyword.bpshort}}. A blueprint job keeps a record of the status, inputs, outputs, and files of every blueprint config, plan & run command execution. {: shortdesc}
{: #bpl1}
Blueprints follow a lifecycle approach to deploying and managing {{site.data.keyword.cloud_notm}} environments. The tasks of working with a blueprint over its lifecycle can be grouped under four headings, defining blueprints, deploying blueprints, updating and operating blueprints, and deleting blueprints. See the section working with blueprints for more details. {: shortdesc}
{: #glossa-catalog}
An enterprise platform for the built-in Terraform, Ansible, Helm, CloudPak, and Operator capabilities in {{site.data.keyword.bpshort}} to set up an IaC. {: shortdesc}
{: #glossa-inventory}
The collection of hosts that you can run your Ansible playbook. {: shortdesc}
{: #rir1}
A resource inventory defines a single {{site.data.keyword.cloud_notm}} resource or a group of resources against which you want to run Ansible playbooks, modules, or roles when the {{site.data.keyword.bpshort}} Actions are used. {: shortdesc}
{: #glossary-job}
A job maintains a record of the execution of tasks or operations for {{site.data.keyword.bpshort}} Workspaces, Actions, Blueprints, Agents and resources.
{: shortdesc}
{: #glossary-template}
Contains the list of ansible playbooks to set cloud operations on target hosts. {: shortdesc}
The template displays the data sources to use the templates to generate strings for other Terraform resources in IaC.
Modules are a container for multiple resources or templates that are used together in IaC.
{: #glossary-workspace}
A platform to build the infrastructure, provision resources, and deploy applications with the support to multiple environments. It has feasibility, or privilege to access by using Git private or public repositories with a secured access token. {: shortdesc}
{: #wkss1}
A platform to build the infrastructure, provision resources and deploy applications with support to multiple environments. It has feasibility, or privilege to access by using Git private or public repositories with a secured access token. {: shortdesc}
{: #wksj1}
The status of the provisioned resource is in inactive, progress, active, or failed results of the {{site.data.keyword.bpshort}} object by running create, plan, or apply commands.
{: shortdesc}
{: #wksr1}
Maps to the provisioned Terraform resources within the infrastructure. {: shortdesc}
{: #wksr2}
Refers to the demonstration of an example template with steps to prerequisites, provision resources with limitations, and steps to run the Terraform template with support of {{site.data.keyword.bplong_notm}}. {: shortdesc}
{: #wkss2}
Common area to edit values of the variables so that new Terraform template can be generated or re-imply with new changes. {: shortdesc}
{: #wksw1}
A platform to build the infrastructure by using open source tools such as Terraform, Ansible, Helm, Open Shift cloud to manage various cloud infrastructure resources.
{: shortdesc}