Support for FCO in Cloudify

This article was originally published on the DICE blog. Matej and Tadej Borovšak work at XLAB. The article is being re-published with the consent of the authors.
Cloudify is an important component of the DICE deployment tool. It enables that the users can describe their applications in a human-readable text format YAML, using a TOSCA dialect to describe the application’s topology. The blueprint containing the topology normally includes specification of nodes (virtual machines), services needed by the application (e.g., Kafka, Spark, Zookeeper etc.), which service runs on which node, and what are the relationships between services. Cloudify then takes care of provisinoning resources and installing the components in a public and private Cloud provider of choice. The original list includes the Amazon’s EC2, OpenStack, vSphere and others. In DICE, we extended support to the Flexiant Cloud Orchestrator (FCO) as well.

Cloudify – Intelligent Cloud Orchestration Done Better. Download Free.  Go

With the added support to the FCO, this cloud platform now has a great alternative way of being used, taking advantage of the TOSCA, the growing industry standard. In this post we will show how to use the FCO plug-in in a simple web service topology.
At this time, using the Cloudify in the FCO requires that the Cloudify Manager is installed in a manually created Virtual Machine in the FCO. Simply deploy a new CentOS 7 instance in the FCO with at least 4 GB RAM and 2 CPUs. Then make sure you can connect to the instance using ssh.
Next, follow the instructions for installing Cloudify. We use the simple plug-in to bootstrap the Cloudify manager, so edit the simple-manager-blueprint-inputs.yaml with inputs looking something like:

public_ip: '109.231.122.110'
private_ip: '127.0.0.1'
ssh_user: 'centos'
ssh_key_filename: '/path/to/id_rsa' # path on your local machine to your ssh key
agents_user: 'centos'

The Cloudify Manager bootstrapping process takes several minutes. Once it finishes, the Cloudify Manager can accept bluprints, similar to the following one.
At the top of the document, we first need to specify the language version. Then we define the “libraries” imported from the ready-made node type and relationship type definitions. In this case we import the basic Cloudify’s types and the DICE provided plug-in with the definitions for the FCO.

tosca_definitions_version: cloudify_dsl_1_2
imports:
 - http://www.getcloudify.org/spec/cloudify/3.3.1/types.yaml
 - https://github.com/dice-project/DICE-FCO-Plugin-Cloudify/raw/master/plugin.yaml

Then we need to define the input parameters required by the FCO plug-in. These inputs need to then appear in the inputs file with the corresponding valid values.

inputs:
 # General inputs
 agent_user:
 description: >
 User that is used to ssh to new server (you'll want ubuntu for ubuntu
 based images and centos for centos based images here)
 # Flexiant inputs
 fco_username:
 description: >
 User name of the FCO account.
 fco_password:
 description: >
 The password for the FCO account.
 fco_customer:
 description: >
 The UUID of the FCO customer.
 fco_image_uuid:
 description: >
 FCO OS image UUID to be used as the base image.
 fco_server_offer:
 description: >
 Name of the server offer for the hosts
 fco_disk_offer:
 description: >
 Name of the disk offer
 fco_vdc_uuid:
 description: >
 FCO Virtual Data Center UUID.
 fco_network_uuid:
 description: >
 FCO network UUID.
 fco_agent_key:
 description: >
 SSH key that is used for Cloudify to connect to server

This gives us all the necessary data to place a host to represent a virtual machine in the FCO:

node_templates:
 fco_host:
 type: cloudify.flexiant.nodes.Server
 properties:
 image: { get_input: fco_image_uuid }
 server_type: { get_input: fco_server_offer }
 disk: { get_input: fco_disk_offer }
 vdc: { get_input: fco_vdc_uuid }
 network: { get_input: fco_network_uuid }
 agent_key: { get_input: fco_agent_key }
 auth:
 username: { get_input: fco_username }
 password: { get_input: fco_password }
 customer: { get_input: fco_customer }
 url: "https://cp.diceproject.flexiant.net"
 verify_ca_cert: False
 cloudify_agent:
 user: { get_input: agent_user }

If we want to place a web server to be located in this host, we can do it in a standard TOSCA way by adding an appropriate node template. Assuming that our blueprint source includes the scripts for configuring, starting and stopping, then we can write:

 http_web_server:
 type: cloudify.nodes.WebServer
 properties:
 port: 8080
 interfaces:
 cloudify.interfaces.lifecycle:
 configure: scripts/configure.sh
 start: scripts/start.sh
 stop: scripts/stop.sh
 relationships:
 - type: cloudify.relationships.contained_in
 target: fco_host

Finally, we can supply the outputs of the blueprint:

outputs:
 webserver_ip:
 description: Web server's external host address
 value:
 - get_attribute: [ fco_host, ip ]
 url:
 description: The URL to the web application
 value:
 concat:
 - 'http://'
 - { get_attribute: [ fco_host, ip ] }
 - ':'
 - { get_attribute: [ http_web_server, port ] }
 - '/'

Successfully deploying and running an application in a cloud platform normally requires specification of the elements that are auxiliary to any physical entities or software installations. For instance, certain nodes need to permit network traffic to and from certain ports of a publically accessible network, while blocking any other traffic. The blueprint needs to provide the means to specify the related properties, and the orchestrator needs to configure the cloud environment accordingly. Our FCO plug in does not explicitly support this yet, but this is a planned functionality for the near future updates, which will also be the topic upcoming blog posts.
Matej Artač (XLAB), Tadej Borovšak (XLAB)