Sharing a Blueprint
About
For enabling a fully shareable blueprint or a resource this two abilities were added: importing a catalog blueprint and adding a namespace context to any import available resource. With those two it is possible to share any common blueprint definitions, from a simple data types definitions through an architecture common pattern (like creating an openstack VM with all of its requirements) and up to entire micro-services that are found across in several services.
Namespace
The namespace context is added to all the DSL elements that may be referenced, allowing the blueprint to safely be imported and used in other blueprints, without fear of name collisions. This contributes a great deal for common blueprint patterns that now can be imported several times under different namespaces and be used with no unwanted duplications across deployments. ** Notice: ** Cloudify basic types definition can not receive namespace.
Catalog Blueprint
With the ability to import a catalog blueprint, blueprints are now truly shareable building blocks that can be used across deployments ranging from sharing a basic definition blueprint to sharing DBs, Message brokers blueprints building block and even sharing entire micro-services blueprints as integral pieces. Which will reduce blueprint duplication across deployments and will allow for a better way of consuming shareable building blocks.
Example
In an Openstack cloud environment, a very basic building block could be a blueprint which creates a VM on open stack.
Basic Openstack VM blueprint with a single port opened:
tosca_definitions_version: cloudify_dsl_1_3
imports:
- http://www.getcloudify.org/spec/cloudify/4.5.5/types.yaml
- plugin:cloudify-openstack-plugin
inputs:
port:
description: open port
default: 8080
agent_user:
description: User name used when SSH-ing into the started machine
image:
description: Openstack image name or id to use for the new server
flavor:
description: Openstack flavor name or id to use for the new server
network_name:
description: Openstack network name the new server will be connected to
floating_network_id:
description: The id of the network to use for allocating a floating ip
key_pair_name:
description: Openstack key pair name of the key to associate with the new server
private_key_path:
description: |
Path to the private key which will be used for connecting to the server
on the manager or machine running CLI if running in local mode.
node_templates:
virtual_ip:
type: cloudify.openstack.nodes.FloatingIP
properties:
floatingip:
floating_network_id: { get_input: floating_network_id }
security_group:
type: cloudify.openstack.nodes.SecurityGroup
properties:
rules:
- port: { get_input: port }
remote_ip_prefix: 0.0.0.0/0
- port: 22
remote_ip_prefix: 0.0.0.0/0
keypair:
type: cloudify.openstack.nodes.KeyPair
properties:
use_external_resource: true
resource_id: { get_input: key_pair_name }
private_key_path: { get_input: private_key_path }
vm:
type: cloudify.openstack.nodes.Server
properties:
agent_config:
user: { get_input: agent_user }
key: { get_property: [ keypair, private_key_path ] }
image: { get_input: image }
flavor: { get_input: flavor }
management_network_name: { get_input: network_name }
relationships:
- type: cloudify.openstack.server_connected_to_keypair
target: keypair
- type: cloudify.openstack.server_connected_to_floating_ip
target: virtual_ip
- type: cloudify.openstack.server_connected_to_security_group
target: security_group
interfaces:
cloudify.interfaces.lifecycle:
create:
inputs:
args:
security_groups: [{ get_attribute: [ security_group, external_name ]}]
An application deployed on Openstack using the openstack VM blueprint:
tosca_definitions_version: cloudify_dsl_1_3
imports:
- openstack_infra--blueprint:openstack_vm
node_templates:
http_web_server:
type: openstack_infra--cloudify.nodes.WebServer
properties:
port: { get_input: openstack_infra--port }
relationships:
- type: openstack_infra--cloudify.relationships.contained_in
target: openstack_infra--vm
interfaces:
cloudify.interfaces.lifecycle:
configure: scripts/configure.sh
start: scripts/start.sh
stop: scripts/stop.sh
outputs:
http_endpoint:
description: Web server external endpoint
value: { concat: ['http://', { get_attribute: [openstack_infra--virtual_ip, floating_ip_address] },
':', { get_property: [http_web_server, openstack_infra--port] }] }
And if “hello world” is useful micro service in another service, which need an “hello-world” service in port 8080 and one in port 9090. That blueprint will look like this:
tosca_definitions_version: cloudify_dsl_1_3
imports:
- port_8080--hello.yaml
- port_9090--hello.yaml
Thanks to those two abilities it’s very easy to use shareable building block and distribute them across deployments and across projects.