Blueprint Files and Packages
Blueprints are YAML documents written in Studio Conductor’s DSL (Domain Specific Language), which is based on TOSCA. Your blueprints will describe the logical representation, or topology, of an application or infrastructure.
Blueprints are packaged into a blueprint archive, which contains a main blueprint YAML file, and any other resources that you want to include, such as scripts, imports, etc. For more information, click this link.
Blueprint Elements
Blueprints comprise several high-level sections:
Tosca Definitions Version
tosca_definitions_version
is a top-level property of the blueprint that is used to specify the DSL version used.
Always use the latest DSL version unless you know of a good reason not to.
For more information about the tosca_definitions_version
, see the specification.
DSL Definitions
dsl_definitions
are used to define arbitrary data structures that can then be reused in different parts of the blueprint using YAML anchors and aliases.
For more information about dsl_definitions
, see the specification.
Imports
Import other YAML files to be parsed with the current blueprint file.
For more information about imports
, see the specification.
Plugins
The plugins
specification configures the plugin execution method, package information, and distribution information.
Together with node-types, data-types, relationships, and workflows, these are often found in “plugin.yaml"s instead of proper blueprints.
Node Types
Node types define the implementation and base properties for node-templates.
For more information about node_types
see the specification.
Together with data-types, relationships, workflows, and plugins, these are often found in “plugin.yaml"s instead of proper blueprints.
Data Types
data_types
enable grouping and re-use of a common set of properties, together with their types and default values.
For more information about data_types
, see the specification.
Together with node-types, relationships, workflows, and plugins, these are often found in “plugin.yaml"s instead of proper blueprints.
Relationships
Relationships provide implementation maapings for relationship operations.
For more information about relationships
see the specification.
Together with node-types, data-types, workflows, and plugins, these are often found in “plugin.yaml"s instead of proper blueprints.
Workflows
Workflows define a set of tasks that can be executed on a node or a group of nodes, and the execution order of those tasks, serially or in parallel. A task may be an operation implemented by a plugin, but it could also be other actions, including arbitrary code.
For more information about workflows
, see the specification.
Together with node-types, data-types, relationships, and plugins, these are often found in “plugin.yaml"s instead of proper blueprints.
Inputs
Inject blueprint parameters when you create your deployment.
These parameters can be referenced using the get_input intrinsic function.
For more information about inputs
, see the specification.
Node Templates
Node templates are used in a blueprint to indicate when you want to deploy one or more instances of a node-type.
For more information about node_templates
, see the specification.
Outputs
Outputs are special values that you want to make readable to certain authenticated Studio Conductor users via the UI, CLI, or API. For example these may be consumed by another deployment via the Deployment Proxy
For more information about outputs
see the specification.
Intrinsic Functions
You can assign values in a blueprint at runtime via intrinsic functons.
For more information about instrinsic_functions
, see the specification.
Interfaces
Interfaces map logical tasks to executable operations.
For more information about interfaces
, see the specification.
Groups
groups
enable configuration of shared behavior for different node_templates
.
For more information about groups
, see the specification.
Policy Types
policies
enable a stream of events that correspond to a group of nodes and their instances to be analyzed.
For more information about policy_types
, see the specification.
Policy Triggers
policy_triggers
enable actions to be declared that can be invoked by policies.
For more information about policy_triggers
, see the specification.
Import Resolver
An import_resolver
is used to resolve imports during blueprint parsing.
For more information about import_resolver
, see the specification.
Upload Resources
upload_resources
enables resources to be uploaded to the Conductor Manager that could be used by blueprints.
For more information about upload_resources
, see the specification.
Capabilities
capabilities
are special values that are exposed in order to be consumed by
other deployments using the get_capability
intrinsic function.
For more information about capabilities
, see the specification.