My latest challenge was to develop a process to deploy a predefined infrastructure model, simple network with 3 nodes, in a consistent and repeatable fashion. However, this model needed to be deployed in every flavor type with different disk configurations.
Basically a customer wanted a repeatable mechanism to performance test the different node flavors at scale.
We could simply build on the previous HEAT examples and write a massive YAML template that contains the required infrastructure. However, this is prone to errors, difficult to debug and not very efficient or flexible.
What we need is to separate the static and dynamic infrastructure components – define a template that matches the static components and allows the dynamic components to be passed as parameters. Any coders out there will be familiar with the DRY code principle, Don’t Repeat Yourself – the same applies here.
As we were deploying into a project with existing infrastructure I also passed some of these details into the heat stack as input parameters – e.g. routerId, kpName
The basic infrastructure template looked like this :
Now that we have our Infrastructure as Code, how do we deploy it at scale whilst changing the input parameters? Well, this is where the ‘API Economy’ comes to the forefront. Fujitsu K5 is based on OpenStack which is an API first platform – in English rather than marketing this effectively means that the platform can be driven 100% through API only interaction….still confused? I get to use more code!
I can send the heat template above along with the different sets of parameters to K5’s orchestration engine using a python script which will send the data to the orchestration endpoint.
The advantage that you have here is that the entire process is now defined in code – and this can easily be version controlled which helps to guarantee consistent deployments.
The complete version of this solution can be checked-out here: https://github.com/allthingsclowd/Fujitsu_OpenStack_K5_Heat_Cookie_Cutter