Heat Application Stack in OpenContrail

Ales Komarek, Jakub Pavlik- January 12, 2015 -

In this blog we would like to show how to orchestrate with OpenStack using Heat and OpenContrail. We show how to create complex application stack with using existing implementation HAProxy Neutron LbaaS in OpenContrail.

Heat is the main project of the OpenStack orchestration program. It allows users to describe deployments of complex cloud applications in text files called templates. These templates are then parsed and executed by the Heat engine.

Heat is not officially supported by Juniper in Contrail release 1.2, but with OpenStack release IceHouse it works smoothly for standard OpenStack resources. Contrail specific Heat resources can be implemented through contrail-heat repo at following link https://github.com/Juniper/contrail-heat

The contrail heat extensions adds resources for managing:

Network IPAMs – IP Address Management resources, which are available only in OpenContrail.

In the configuration file, specify the location of the database where the Orchestration service stores data. Use same MySQL database as Contrail with a heat user on the controller node. Replace HEAT_DBPASS with the password for the database user. Edit /etc/heat/heat.conf and modify the [database] section:

[database]# The SQLAlchemy connection string used to connect to the databaseconnection = mysql://heat:HEAT_DBPASS@controller/heat

Use the password that you set previously to log in as root and create a heat database user:

# service heat-api restart# service heat-api-cfn restart# service heat-engine restart

Verify heat

# heat list

If there is nothing, it is OK. Otherwise something is wrong. Now we can start with our application stack deployment.

Heat Stack Deployment Process

This part will cover how did we implement the automated deployment process with heat and salt. It actually consist of only 2 phases. In the 1st the heat orchestration client creates the necessary resources. After all resources have been successfully created the 2nd phase is stated. It orchestrates services across the application stack in the right order, ie. the database services are installed before the application services that require them.

Create infrastructure resources

Orchestrate compute services

The following schema illustrates how this deployment process works with the OpenStack IaaS platform. Heat orchestration

The entire process for this test is processed by the Salt orchestration runner [1]. The following code shows simple salt orchestration runner for deploying and configuring our application heat stacks covered in next part.

This functionality can be implemented by bash script or Jenkins job as well. So what does the salt runner do? First it gets the metadata and provisioning services (salt formulas) on the orchestration controller in shape, then it calls heat to create resources. Our script waits for the completion of the stack creation. Then finally the salt master is called to enforce entire service stack (salt highstate) on all newly created compute resources. With our simple stack we can do it in just one configuration step, for more complicated stacks more steps would be required.

Out Testing Application Stack

We tested the capabilities of Heat with OpenContrail resources on multiple application stacks with 2 web services booted from block volumes with load balancer in front. We have several kind of resources that were needed to be created before we could start the configuration orchestration:

Network: Private Neutron network where all instances, load balancers and router are connnected.

Public IP: Neutron Floating IP from public network pool tha is associated with the load balancers.

The following schema shows our the heat stack within one testing tenant. There are multiple web Service infrastructures (A, B), each have the same resource definition in heat, just the metadata (environmental parameters) differs.

Following code shows the complete creation of our testing in heat. It’s in the new HOT format which is our opinion a good leap forward to better readability and usability of these templates.

Graphical User Interface

Along the automated shell guns we can operate the stack using the horizon-based GUI. We have adapted the GUI to see

As the Heat orchestration GUI has limited options it can be used for example by developers without deeper knowledge of underlying service stack to setup their working or staging environments.

The following screen shows application stack with 5 server instance booted from volumes, connected to the same network with router and 2 floating IP’s hidden above and below the graph borders.

Conclusion

Setting up Heat templates can solve previously unsolvable issues in virtual infrastructure life-cycles and that is creation and deletion of not-compute resources that compute resources rely on (network and storage resources mostly). Heat allows to create expandable range of resources that are created exactly in the right order. The compute servers are part of the resource stack and can be created and directed to configuration management of your choice. We have used the Salt configuration tool, but tools like Puppet, Chef or Ansible can be used as well.