An application in Cloudify is described in a
blueprint and its DSL (Domain Specific Language) is based on a standard called TOSCA.
Blueprint files are written in YAML and describe the logical representation of an application, which we call a
topology. In a Blueprint you will describe the application’s components, how they relate to one another, how they are installed and configured and how they’re monitored and maintained.
Other than the YAML itself, a Blueprint can comprise multiple resources such as configuration and installation scripts (or Puppet Manifests, or Chef Recipes, etc..), code, and basically any other resource you require for running your application.
All files in the directory that contains the blueprint’s main file, are also considered part of the blueprint, and paths described in the Blueprint are relative to that directory.
Blueprints comprise several high level sections:
tosca_definitions_version is a top level property of the blueprint which is used to specify the DSL version used.
For Cloudify 3.3, the versions that are currently defined are
If you’re just starting to use Cloudify now, you should use the latest version.
tosca_definitions_version in the spec.
imports allow the author of a blueprint to reuse blueprint files or parts of them and use predefined types (e.g. from the types.yaml file).
imports in the spec.
inputs are parameters injected into the blueprint upon deployment creation. These parameters can be referenced by using the get_input intrinsic function.
Inputs are useful when there’s a need to inject parameters to the blueprint which were unknown when the blueprint was created and can be used for distinction between different deployments of the same blueprint.
inputs in the spec.
node_templates represent the actual instances of node types which would eventually represent a running application/service as described in the blueprint.
node_types are more commonly referred to as
nodes. nodes can comprise more than one instance. For example, you could define a node which contains two vms. Each vm will then be called a
node_templates in the spec.
node_types are used for defining common properties and behaviors for node-templates.
node-templates can then be created based on these types, inheriting their definitions.
node_types in the spec.
outputs provide a way of exposing global aspects of a deployment. When deployed, a blueprint can expose specific outputs of that deployment - for instance, an endpoint of a server or any other runtime or static information of a specific resource.
outputs in the spec.
relationships let you define how nodes relate to one another. For example, a
web_server node can be
vm node or an
application node can be
relationships in the spec.
intrinsic_functions are functions that can be used within blueprints. Depending on the function, evaluation occurs on deployment creation or in runtime. For example, the
get_input intrinsic function is used to retrieve an input defined within the blueprint.
intrinsic_functions make blueprints dymanic, allowing to retrieve and set data structures in different parts of the blueprint.
instrinsic_functions in the spec.
plugins we can install python modules and use the installed or preinstalled modules to perform different operations. We can also decide where a specific plugin’s operations will be executed.
plugins in the spec.
Interfaces provide a way to map logical tasks to executable operations.
interfaces in the spec.
workflows define a set of tasks that can be executed on a node or a group of nodes, and the execution order of these tasks, serially or in parallel. A task may be an operation (implemented by a plugin), but it may also be other actions, including arbitrary code.
workflows in the spec.
groups provide a way of configuring shared behavior for different sets of
groups in the spec.
dsl_definitions section can be used to define arbitrary data structures that can then be reused in different parts of the blueprint using YAML anchors and aliases.
dsl_definitions in the spec.
policies provide a way of analyzing a stream of events that correspond to a group of nodes (and their instances).
policy_types in the spec.
policy_triggers provide a way of declaring actions the can be invoked by policies.
policy_triggers in the spec.
data_types are useful for grouping together and re-using a common set of properties, along with their types and default values.
data_types in the spec.
An import resolver can be used to resolve imports during blueprint parsing.
import_resolver in the spec.
upload_resources can be used to upload resources to the manager, which could be used by blueprints.
upload_resources in the spec.