| layout | title | category | publish | abstract | pageord | tosca_link | arch_link |
|---|---|---|---|---|---|---|---|
bt_wiki |
Terminology |
Reference |
true |
Cloudify Terms and Concepts (In a nutshell) |
100 |
overview-architecture.html |
{% linklist h3 %}
Cloudify users will come across several concepts and terms that might have different meanings in other products or systems. For your benefit we define these below:
Agents are task executors.
They may be located on either the application VM, on the manager, or elsewhere - depending on the tools and API’s they need to interface with (see Plugins).
Agents read tasks from a tasks broker and delegate them to a worker subprocess (a Plugin based Python process).
Each deployement has a dedicated agent on the manager known as Deployment Agent
An Application in Cloudify means a software based business service with all of its IT components at the infrastructure, middleware and business logic levels.
A Blueprint is an orchestration plan of an Application.
Cloudify blueprints are inspired by the OASIS TOSCA evolving standard. Essentially it is a YAML file that describes the following:
- Application topology as nodes and their relationships(#relationship) / dependencies.
- Implementation of each lifecycle event of each node (the YAML holds a mapping to plugins(#plugin) that implement the events).
- Configuration for each node.
- [Optional] Workflows that describe the automation of different processes like installation, upgrade etc. By default the blueprint will use the workflows provided with the product.
See the definition here.
The context object is an object passed to plugin operations as an argument named ctx which contains the context of the operation invocation.
For example, the context contains the following information:
- Node id.
- Deployment id.
- Plugin name.
- Operation name.
and more...
In addition, the context object exposes an API for interacting with Cloudify. For example, getting a node's properties.
A deployment is the plan and the state of a single application environment and is a direct derivative of a blueprint.
Deployments are model-representations of node instances (which form applications) and their runtime state.
An Event is a JSON representation of an occurance in Cloudify's environment.
Events are emitted from one of Cloudify's nodes and are generated as a result of an execution of a specific workflow or any other Cloudify process.
Events are generated (from plugins or Cloudify's core code) by using the ctx.logger context object(#context-object).
An Execution is a running instance of a workflow and is based on a particular deployment.
An Execution (unlike a deployment or a blueprint has logs and events associated with it.
A node in the blueprint that represents a type of host whether it's a virtual or physical server.
Interfaces set the protocol between the Topology and the Workflow that uses it.
More elaborately, An Interface is a set of hooks (dabbed Operations) that a Type must map to an implementation function in a plugin. Cloudify Types following the aforementioned TOSCA standard, implement, at the very least, the lifecycle interfaces with the following operations:
- create
- configure
- start
- stop
- delete
A node instance(#node-instance) which is not in either the uninitialized or deleted states(#node-instance-state).
See the definition here.
A Node is one type of component in a topology.
It is an instance of a type with particular properties and dependencies on other components' (relationships).
For example, a node can be one type of a VM with a particular image ID, HW flavor and bound to a specific security group. Each node can be materialized to any number of runtime components, depending on the number of instances to deploy sepcified in the node settings.
A node instance is a runtime representation of a node.
Node instances carry runtime properties and a state. The number of instances is derived from the property set in a node's configuration in the blueprint.
Every node instance(#node-instance) can have one of the following states:
uninitialized- The node instance hasn't been initialized.created- The node instance has been created.started- The node instance has been started.stopped- The node instance has been stopped.deleted- The node instance has been deleted.
An operation is a node or a relationship lifecycle event that is triggered by the workflow.
The operation's names are defined by an interface and a type that implements this interface maps these operations into plugin functions with the implementation logic.
Plugins are extensions to the agents.
Plugins interface with an API or a CLI in order to execute lifecycle events of a node. Plugins are written in Python.
See the definition here.
Properties are a node's design-time configuration details.
Properties are expressed as a YAML dictionary in the blueprint.
Providers are python modules that augment the Cloudify CLI and implement the bootstrapping process for a specific cloud environment.
A YAML file with the configurations for creating a Cloudify manager on a specific Cloud.
The provider configuration file has configuration properties for the some of the following items:
- Cloud credentials and API endpoint
- Network settings
- Manager virtual machine OS and hardware
- SSH credentials for the manager VM
- Cloudify packages to use in oreder to install the manager
Details of the provider's manager environment such as the name of the management network.
The provider context is available in any plugin function in case the plugin code needs such information in order to perform tasks such as agent configuration or VM configuration (as Cloudify needs each VM to be connected also to the management network ifplugin it has an agent installed on it.)
Relationships are types that describe the nature of dependency between nodes and the logic, if required, to glue nodes together.
For example, a relationship can be of type cloudify.types.contained_in. That means that node X is hosted within node Y and therefore can't be created until node Y is created and running.
Another example is an Apache server that's connected to MySQL. In this case, Apache needs to be configured at runtime to connect to MySQL. Waiting for MySQL to be up and running won't suffice in this case. The relationship needs to map relationship operations to plugin functions that execute the connection's configuration.
An instance of a relationship between 2 concerte node instances.
A relationship type describes the nature of dependency between 2 nodes and the logic to materialize it (through operations mapping to implementation).
A relationship is always between a source node and a target node and do it can have implementation logic to run on either or both.
There are 3 basic relationship types:
- depends_on - a base type for all relationships. It means the orchestrator must wait for the target node
- contained_in - the source node is installed within the target node
- connected_to - the source node has a connection to configure to the target node
The data model of the deployements stored in Cloudify's database.
Cloudify holds a data model per application deployment. This data model contains the node instances, with each instance storing its unique instance id as well as copy of the blueprint's original configuration for this node and runtime properties for this node instance.
Runtime Properties are execution-time details of node instances.
Runtime Properties are saved to the database so that they can be consumed by plugins or by users. Unlike node properties, which are explicitly specified in the blueprint, runtime properties are only set during runtime by Cloudify or its plugins.
A Task is the execution of one operation in a plugin with a given set of arguments.
The arguments describe the context of the execution including node properties and node instance runtime properties.
See the definition here.
See the definition here.
A Topology is an application's graph of nodes and their relationships.
A Topology also describes the lifecycle events or other operations that each node and relationship exposes for the use in workflows.
A Topology is denoted in YAML.
A Type is a class of an application's node.
For example a db_server type represents a database server.
The basic types provided with Cloudify are abstract and only serve as markers. Derived types have their operations mapped to a particular plugin that enables their materialization using some API or tool.
For example, cloudify.types.openstack.server is using the nova_plugin to communicate with OpenStack's Nova API (compute API) to spawn virtual machines on OpenStack clouds.
The inheritence chain of a type or a relationship.
Cloudify blueprints use Object Oriented methaphore of inheritence so any concrete Type or relationship is derived from more basic type either with implementation that needs to be refined or without any operation implmentation.
A workflow is an automation process algorithm.
Workflows are described in Python and use dedicated API's for reading and writing a node's state, reading a node's configuration and sending tasks for execution. Workflows are executed via Cloudify's workflow engine.
See the definition here.