Overview

Get the latest docs
You are looking at documentation for an older release. Not what you want? Go to the current release documentation.

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

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 cloudify_dsl_1_0, cloudify_dsl_1_1 and cloudify_dsl_1_2.

If you’re just starting to use Cloudify now, you should use the latest version.

More on tosca_definitions_version in the spec.

imports

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).

inputs

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.

node_templates

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_instance.

node_types

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.

outputs

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.

relationships

relationships let you define how nodes relate to one another. For example, a web_server node can be contained_in a vm node or an application node can be connected_to a database node.

intrinsic_functions

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.

More on instrinsic_functions in the spec.

plugins

By declaring 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.

interfaces

Interfaces provide a way to map logical tasks to executable operations.

workflows

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.

groups

groups provide a way of configuring shared behavior for different sets ofnode_templates.

dsl_definitions

The 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.

policy_types

policies provide a way of analyzing a stream of events that correspond to a group of nodes (and their instances).

policy_triggers

policy_triggers provide a way of declaring actions the can be invoked by policies.

data_types

data_types are useful for grouping together and re-using a common set of properties, along with their types and default values.

import_resolver

An import resolver can be used to resolve imports during blueprint parsing.

upload_resources

upload_resources can be used to upload resources to the manager, which could be used by blueprints.