Building your first Helion Development Platform app

In this post, i’m going to walk through building and deploying a very simple application.

If you have been following along on my previous posts – you might have a running Helion Development Platform (HDP) cluster running in HP public cloud. If you don’t, you can follow along and build a micro-cloud.

First task is to build an application.

Since the application actually doesn’t matter, lets start with a very simple PHP application. 


      <title>My First CF App</title>
      <?php phpinfo(); ?>

We could try to push this straight into our cluster, but ideally we want to create an application manifest. The manifest will capture important metadata about our application, such as resource requirements, dependent services etc.


– name: helion-phpinfo
  mem: 32M
  disk: 1024M
  instances: 3

There are a couple of interesting things about to talk about:

  1. The file format follows a very strict format. 3 -‘s, followed by the applications: tag, then -{space}name: Other tags are inline with name:
  2. The buildpack is a hint (a very strong one) about what frameworks/runtimes our application needs to run. HDP can figure this out for some applications, but its good practice to specify the one you want – including the version!
  3. Instances are 3 – this means there will be 3 copies of the application running behind router (think load balancer for now).

Now we have our app – we can push this out to our HDP cluster. You will need to download and install the helion client – a link to which is on the portal.

helion push -n

Will publish the application and start it. You can view the running apps using:

helion apps

And to navigate to your application, try:

helion open helion-phpinfo

Even though this is a very simple application, we can use it to learn a lot more about deploying and managing applications on the Helion Development Platform. I’ll tackle some of these in the next few posts!


Adding DEA’s to your microcloud

In a previous post, I showed how you can create a Helion Development Platform microcloud in the HP Public Cloud. In this post, I will show you how to add DEA’s to this in preparation to deploy your applications.

There are 2 types of DEA you can add, Windows or Linux. This post will cover Linux. I will cover Windows in a later post.

There are also 2 ways you can add a node, using the cf-mgmt tool, or by creating a nova instance and performing a manual configuration. Either works, but we will use cf-mgmt. Why? Well a DEA doesn’t need much configuration, so there is little value/flexibility in creating a nova instance and performing the steps manually (although a side project on my side project is to use Ansible to do all of this).

So lets get started. I’m attached to my jump box, and creating a couple of new scripts – and add-dea.yml.

The first script is basically the cf-mgmt command wrapped in a script. This allows me to pop it into source control.

~/linux-amd64/cf-mgmt add-role dea –load add-dea.yml

The add-dea.yml file is the configuration file used by the script:

version: 1.2
constructor-image-name: HP Helion Development Platform – Application Lifecycle Service Installer
seed-node-image-name: HP Helion Development Platform – Application Lifecycle Service Seed Node
cluster-prefix: cluster1
count: “2”
az: az1
constructor-flavor: standard.xsmall
flavor: standard.large
network-id: d190d9ca-6f3c-4fff-9034-f1fc070a3b6b
external-network-id: 122c72de-0924-4b9f-8cf3-b18d5d3d292c
keypair: ookkey
stack: lucid64

Most of the above should be pretty straight forward however:

  • Version: yes its the version
  • constructor-image-name & seed-node-image-name: these are the image names from OpenStack to use to create the cluster. You can use nova image-list | grep Application to view the available images.
  • cluster-prefix: is the prefix you previously used when creating the cluster.
  • count: this is how many instances to create. I recommend only doing a couple at a time otherwise you could hit authentication token timeout issues.
  • az: this is the AZ you wish to create the instances in. See my note below for more.
  • constructor-flavor: this is the constructor image size
  • flavor: this is the DEA node size
  • network-id: this is the internal network id. You can grab this using neutron net-list.
  • external-network-id: this is the network id of the network that contains the floating ips – it’s probably called Ext-Net. See above for the command to list the networks.
  • keypair: the keypair you used to create the cluster in the first place.
  • stack: lucid64 is the ubuntu stack we will use.

AZ’s and high availability of DEA’s

To increase your HA capability, I’d advise you to deploy multiple DEA’s in each AZ. There are 3 AZ’s in public cloud, so i created DEA instances in each. Simply change the az: tag in the configuration file to change the target az. I ended up creating a total of 12 DEAs, which is a good size to give the platform a run for its money.

Once you have the AZ’s defined in OpenStack – you have to do the same in ALS. To do this you need to connect to each DEA and run the following:

kato node availabilityzone AZ1
kato process restart

You can view your Availability Zones from the web console by hitting Settings/DEA then Availability Zones.

Now when an application is deployed with more than one instance (which is always a good idea) ALS will deploy the instances across availability zones.

Although we now have DEA’s across multiple AZ’s there are other parts of the cluster that we will also need to make highly available. I’ll be covering that in later posts.