OpenStack Heat is the orchestration project of OpenStack, which allows to describe and provision OpenStack resources based on Heat templates, similar to Amazon CloudFormation. For a research project, I recently had the requirement to assign a floating IP address to every instance of a Heat autoscaling group (ASG). Given the fact that such setup is contradictory to the common practice having a load balancer in front of an ASG, this costed me some time to figure out.
Creating a Single Instance Using Heat
Setting up a single instance using a Heat template (HOT) is pretty easy, straightforward and also covered in the Heat templates repository:
As we can see, the
server1_floating_ip (of type
OS::Neutron::FloatingIP) is NAT’ed to the
server1_port which in turn is assigned to the server instance (type
OS::Nova::Server) that we instantiate.
Creating an Autoscaling Group
In order to create an ASG of multiple instances, each only with a private IP, we also find help in the Heat templates repository:
We see the
AutoScalingGroup defined with the Nova server instance being scaled up and down (between 1 and 10 instances).
Using the scale up and down URLs provided, one can test the functionality of auto scaling.
Recalling our goal, namely to assign a floating IP address to every instance of the ASG (and also to the ones created during scale-out), it looks intuitively right to extend the
resource block of the previous template. However, only one
resource can be given to the
AutoScalingGroup. For our use case, we also need the floating IP resources to be added and destroyed on demand.
Scaling a Complete Stack
The solution to my problem was finally hidden in one of the other examples, the ASG of stacks.
Essentially, Heat can also scale a complete stack (defined by its own template file).
So what we now do is essentially to treat the server with its floating IP as defined in the first listing (
single_server_with_floating_ip.yaml) as entity of scale and pass through all parameters:
type of of resource, we can also supply a file name. That’s.. let me think.. not obvious?
After long search, was able to find this behavior documented under Template composition.
public_net parameter defining the public network ID, from which floating IPs are assigned.
Once we trigger a scale-out, we can see antoehr instance including a floating IP being added after some seconds:
I am not aware of a way to launch such stack using the Horizon dashboard, except when the inner template is referenced via an HTTP(S) URL. Instead, one can launch it using the command line client:
All definition of the required parameters, i.e., image and network IDs, are happening in the
While my use case was a little academic (why in the world should something scale inside an OpenStack cloud and be directly reachable from the outside world), I think this (to me still unknown) concept of template composition helps solving many more problems.
The complete code can be found in this gist.
(cover image by sipa on pixabay.com)