Infrastructure as a Service (IaaS) is the most basic cloud model, giving you the ability to create your own infrastructure resources such as networks, firewalls, load balancers, different kind of storage and of course servers.
There are other tools that can be used to orchestrate OpenStack such as the official tool called Heat, which works pretty much the same as AWS Cloudformation. They both work with “Stacks” which is basically a stack with resources (servers, security groups, databases, etc). Both Heat and Cloudformation are fantastic way to do orchestration. But both are tools for either OpenStack or Amazon Web Services.
With Terraform you orchestrate cloud services – DNS, to IaaS providers, CDN, etc. As the tool itself isn’t connected to any specific provider you also don’t get locked in. Please see a list of official providers in the documentation.
Except for the fact that Terraform allows you to orchestrate many different cloud services, it’s also pretty easy to learn. And in our experiences a lot faster than the tools mentioned above.
By the way, If you live in Stockholm and want to meet others that loves Terraform (and more HashiCorp stuff), join the meetup group Stockholm Hashicorp User Group
You can get the source for this Terraform template on Github and study it to the teeth.
Our architecture will consist of two server groups “web” and “db”. Each group having 2 compute instances (virtual machines). The groups will have a policy on them called “anti-affinity”, this is best practice and will tell OpenStack scheduler that this group may never have the compute instances on the same physical hardware, in this case to make sure your web and db instances stay redundant.
Each compute instance will run CentOS 7 and with cloud-config we’ll change the default username to “elastx”.
Three security groups (sg) will be created, demo-ssh-sg, demo-web-sg and demo-db-sg. The first sg will be on all instances allowing “everyone” to ssh. The web-sg will be on the web servers allowing port 80 and 443 (http,https) and db-sg will be on the database instances having port 3306 (mysql) allowed from the web network, keeping it isolated and secured.
SSH keypair called “demo_rsa” will be upploaded as well.
This is a very traditional network topology for demo purposes, but it shows you roughly how the environment will look like.