Embedded Multi Paradigm Per Instance Interpolative Provisioning

... also known as EC2Pro or just interpolative provisioning - it gives you extreme one shot Terraform setup powers for multi-instance architecture creation. You keep Terraform as the central infrastructure codification tool, but select from the best of everything for tools and programming languages to provision your cloud system. If you only understand one thing from reading this, understand it's a brilliant DevOps super power to have. Ok, read on ...

There’s a very non-technical driver behind the need for such a technique and that’s down to the fact that DevOps engineers have just as widely varying tastes and preferences in tooling and programming languages as software engineers have, if not more so.

The meaning behind the words:

Provisioning - well you should know what that is, but if you're not sure, think of it like setting things up. You've probably spent time setting things up on a Linux box, looked at your watch and said "ah look, it's my birthday again!" .  You may also have heard the phrase, “with Linux all you do is set it up!”.  Before the advent of CM tools things were actually like that, and though the situation is a lot better today, someone still has to spend the time to codify the steps to perform in an automation. If you'd like to find out more on the subject of provisioning in practice, Vagrant is the best tool to learn.

Interpolative - in programming language expressions, interpolation refers to the concept of variable substitution and expansion. In this context, to use one Terraform invocation to set up say three EC2 instances each for a different purpose, the internal index that Terraform uses to keep track of the number of resources it’s creating, is interpolated  within your configuration allowing you to perform differentiated conditional provisioning, instead of otherwise only being able to set up all three instances the same way.

Per Instance - you have individual instance provisioning granularity, though can also achieve the opposite if required and set up all instances or a subset of instances identically.

Multi Paradigm - you don’t have to use just conventional interpreted programming languages, as you can use CM tool DSLs (domain specific languages) as well, such as Ansible playbooks.

Embedded - you require only one text file that embeds  all the different programming language source code you want to use for the architecture you're setting up. Each area of source code is preceded by an index integer value that indicates which instance or instances to provision with that code. For example, the file's indexes and code areas could be arranged to provision instance 1 with Bash, instance 2 with Python, instances 3 and 4 with Ruby and instance 5 with Lua. You don't have to arrange indexes for code areas contiguously, you can use multiple non contiguous indexes for a code area, range indexes and also a catch all code area for instances not indentified by any index - essentially it's a switch statement. It's a dream DevOps provisioning facility to be able to do this.

There are innumerable approaches to provisioning; there’s Packer, there are many more CM tools around than just Chef, Puppet, Ansible and Salt, there are lots of programming languages with libraries and frameworks for the purpose, and if that’s not enough there are combination approaches which have greatly proliferated the available options. Terraform and Ansible are a popular combination, though some prefer to call that 'Ansible and Terraform', emphasizing Ansible invoking Terraform and not the other way round. Rather than look for an objectively best practice that covers all scenarios, it’s better to have a solid understanding of how everything works, then select for a given situation or common set of situations, based on available skills and requirements (cloud provider costs usually being an important one).

Interpolative provisioning can be enabled as indicated in this excerpt from  vars.tf  below:


.
.
.

variable "interpolative_provisioning" {

  # This allows the user to provision all launched instances at once via a
  # single provisioning template file using any or all of Perl, Python, Ruby,
  # Bash / other shells or other interpreted programming language systems
  # supported by the target instance(s). Additionally, Ansible and Salt
  # configuration management tools may be used. Provisioning can be performed
  # on a per instance basis, supporting unique provisioning requirements for
  # each instance (including supporting unique programming language and CM
  # tooling requirements for each instance). The standard interpolations
  # accessible by the provisioning template include the zero indexed launch
  # number assigned to each launched instance by Terraform, the number of
  # instances requested to be launched and your own arbitrary data supplied
  # in the interpolative_provisioning_user_data variable below. The template
  # can be supplied by REVVOPS or can be implemented yourself, contact us for
  # more information. This variable should only be set to true if you have
  # access to a REVVOPS EL2 EC2Pro compatible provisioning template.

  description = "Embedded multi paradigm per instance interpolative provisioning"
  default = "false"
}


variable "interpolative_provisioning_user_data" {

  description = "Augments the supported EL2 interpolations with your own data"
  default = "My arbitrary data"
}

.
.
.
So you just have to set  -var 'interpolative_provisioning=true',  putting all your provisioning source code in one file, and that's it, you can set up a whole architecture comprising any number of highly differentiated instances with just that file and one line to start Terraform.

Interpolative provisioning for Terraform as described above is extremely convenient and powerful, though you need to know when to use it, why and when not to use it. Interpolative provisioning is included with EL2  SV.