Further to the reference architecture explained in the article – Oracle Cloud Infrastructure Classic – Reference Architecture, we will now take a look at how to implement this using Terraform (TF).
Terraform scripts can be used to build immutable infrastructure. Once the infrastructure is built, we can then use configuration management tools like Chef, Puppet, and Ansible. We will not be using any configuration management tools in this article. All infrastrcuture provisioning will use init pre-bootstrap scripts.
First, let’s take a look at the diagram below, of the scenario we are implementing using Terraform.
Infrastructure as Code (IAC) Blueprint
It is assumed that the reader has some knowledge using Terraform. If not, this book – Terraform: Up and Running – is a good place to start. We will now highlight a few concepts related to how we will use Terraform to deploy our scenario solution.
Firstly, Terraform is a server provisioning tool in the same category as AWS CloudFormation and OpenStack Heat. In our scenario, we will use Terraform to create the four servers highlighted in our scenario diagram. We will also use Terraform to create necessary resources in Oracle Cloud such as – IP Networks, Security Protocols, Security Rules, Access Control Lists and others.
Secondly, we are going to deploy our Terraform environment using best practices for DevOps Continuous Integration (CI) and Continous Deployment (CD) environment. Specifically, we will deploy our Terraform code with the following principles:
1) Separation of Terraform configuration state files for the different tiers of the architecture. This allows us to isolate changes made to each separate tier and reduce likelihood of accidental changes to entire infrastructure
2) Use of Terraform Backends and shared remote state files for team collaboration. This is based on the assumption that we could have a large team of multiple software engineers that are required to make changes to the same code base.
3) Use of Terraform Modules for better code re-use. This involves templating resources like Bastion Server into modules; and then reusing the modules as frequently as we would like to create different Bastion Servers instances.
4) Git versioning for stage and prod environments. This involves using Git Tags during code commits to identify which version of codes we want to put into production or staging environment.
The complete IAC blueprint is illustrated in the diagram below
The URLs for the Git Repositories are below: