Blueprint Authoring for Cloudify 4.0
In Cloudify 4.0 two main changes were introduced.
- The usage of provider context or implicit Iaas data was deprecated.
- A secret store was added to hold all sensitive data (usernames, passwords…).
If we take a snippet from a blueprint used in Cloudify 3.x it may look like that:
node_types:
elk.nodes.MonitoredServer:
derived_from: cloudify.openstack.nodes.Server
properties:
cloudify_agent:
default:
user: { get_input: agent_user }
server:
default:
image: { get_input: image }
flavor: { get_input: flavor }
interfaces:
...
node_templates:
elasticsearch_host:
type: elk.nodes.MonitoredServer
instances:
deploy: 1
relationships:
- target: elasticsearch_floatingip
type: cloudify.openstack.server_connected_to_floating_ip
- target: elasticsearch_security_group
type: cloudify.openstack.server_connected_to_security_group
elasticsearch_security_group:
type: cloudify.openstack.nodes.SecurityGroup
properties:
security_group:
name: elasticsearch_security_group
...
elasticsearch_floatingip:
type: cloudify.openstack.nodes.FloatingIP
The same blueprint in Cloudify 4.x will look like this:
dsl_definitions:
openstack_config: &openstack_config
username: { get_secret: keystone_username }
password: { get_secret: keystone_password }
tenant_name: { get_secret: keystone_tenant_name }
auth_url: { get_secret: keystone_url }
region: { get_input: region }
node_types:
elk.nodes.MonitoredServer:
derived_from: cloudify.openstack.nodes.Server
properties:
openstack_config:
default:
*openstack_config
agent_config:
default:
user: { get_input: agent_user }
key: { get_property: [ key, private_key_path ] }
install_method: remote
port: 22
server:
default:
image: { get_input: image }
flavor: { get_input: flavor }
management_network_name:
default:
{ get_property: [ public_network, resource_id ] }
interfaces:
node_templates:
elasticsearch_host:
type: elk.nodes.MonitoredServer
capabilities:
scalable:
properties:
default_instances: 1
relationships:
# Attaching a floating ip to elasticsearch host
- target: key
type: cloudify.openstack.server_connected_to_keypair
- target: elasticsearch_host_port
type: cloudify.openstack.server_connected_to_port
key:
type: cloudify.openstack.nodes.KeyPair
properties:
openstack_config: *openstack_config
resource_id: { get_input: key_name }
private_key_path: { get_input: private_key_path }
elasticsearch_floatingip:
type: cloudify.openstack.nodes.FloatingIP
properties:
openstack_config: *openstack_config
floatingip:
floating_network_name: { get_property: [ external_network, resource_id ] }
elasticsearch_security_group:
type: cloudify.openstack.nodes.SecurityGroup
properties:
openstack_config: *openstack_config
security_group:
name: elasticsearch_security_group
...
public_subnet:
type: cloudify.openstack.nodes.Subnet
properties:
openstack_config: *openstack_config
use_external_resource: true
resource_id: { get_input: public_subnet_name }
relationships:
- target: public_network
type: cloudify.relationships.contained_in
- target: router
type: cloudify.openstack.subnet_connected_to_router
public_network:
type: cloudify.openstack.nodes.Network
properties:
openstack_config: *openstack_config
use_external_resource: true
resource_id: { get_input: public_network_name }
router:
type: cloudify.openstack.nodes.Router
properties:
openstack_config: *openstack_config
use_external_resource: true
resource_id: { get_input: router_name }
relationships:
- target: external_network
type: cloudify.relationships.connected_to
external_network:
type: cloudify.openstack.nodes.Network
properties:
openstack_config: *openstack_config
use_external_resource: true
resource_id: { get_input: external_network_name }
You can see that resources like network and router used in Cloudify 3.x are implicit and part of the manager provider context, while in Cloudify 4.x all resources are explicit and must be part of the blueprint as there is no provider context.
You can also note that the Openstack configuration is not part of the Cloudify 3.x snippet, while in the 4.x we define a dsl_definition of the openstack_config and use it in every node that needs it.
You can find the full blueprint at:
https://github.com/cloudify-examples/elk-blueprint/blob/master/openstack-blueprint.yaml
If you want to make your blueprint more readable and have only nodes relevant to your application you can put all Iaas relevant resources like networks and subnets in separate blueprint and import it like this:
imports:
- http://www.getcloudify.org/spec/cloudify/4.0/types.yaml
- http://www.getcloudify.org/spec/openstack-plugin/2.0.1/plugin.yaml
- imports/iaas-resources-blueprint.yaml
To make your blueprint even more readable and since the YAML language has a limitation that it can’t import dsl_definition you could create a node_type that will hold the Openstack configuration data structure, with it you can create a node_template for this specific blueprint and use it in all importing blueprints.
Like this:
We will define in our types.yaml file the following type:
node_types:
my.openstack.nodes.OpenStackConfig:
derived_from: cloudify.nodes.Root
properties:
configuration:
default: {}
…
Next, we will define a node_template from this type
node_templates:
my.openstack.config:
type: td.openstack.nodes.OpenStackConfig
properties:
configuration:
auth_url: http://openstack-api-endpoint
...
Then, we will import the node_template and use it for all other nodes:
my_server:
type: cloudify.openstack.nodes.Server
properties:
openstack_config: { get_property: [td.openstack.config, configuration] }
Using the secret store and the get_secret intrinsic function
To add secrets to your manager please see follow the documentation:
http://docs.getcloudify.org/4.0.0/cli/secrets/
If you want to use it via the rest-api:
http://docs.getcloudify.org/api/v3/#secrets
Documentation about get_secret intrinsic function can be found here:
http://docs.getcloudify.org/4.0.0/blueprints/spec-intrinsic-functions/#get-secret
Comments
0 comments
Please sign in to leave a comment.