Welcome to the very first blog post of this year. This post is an introduction to Terraform which is a tool to manage various cloud infrastructure services in the form of code. You essentially codify your infrastructure and thus also known as . Infrastructure as Code (IaC) Talking about Digital Transformations that organizations go through, the cloud has proved to be of immense importance and often stands at the epicenter of their transformation journey. Over the years and decades, it has become very evident that cloud platforms not only help reduce time and cost but rather – let the customers focus on their core business. Due to the increasing demand and flexibility of cloud providers, it becomes more important to manage cloud infrastructure resources. Terraform works on the concept of Infrastructure as Code (IaC). In simple terms, the ability to represent your infrastructure in the form code is attributed to IaC. Let us take for example any compute resource on a given cloud – EC2 on AWS. Requesting an EC2 instance from AWS is a matter of signing up with AWS, providing a bunch of values, and click on a “Launch” button. Your resource will be ready in a few minutes. As far as you are able to provide those values to AWS, nothing stops you from having your own resources on the given cloud provider. Of course, this is a traditional way to do the same. Terraform provides a way to take these credentials and inputs in the form of and process these configurations to create a resource in the target cloud. These configurations are a way to describe the desired resource in a language that is understood by Terraform. Internally, Terraform makes use of cloud provider APIs to carry out the creation of the resource. configurations Terraform is a product by , and uses (HCL) syntax to represent the configurations. In the given example, EC2 instance can be represented in HCL as below in its simplest form. Hashicorp Hashicorp Configuration Language provider “aws” { region = “us-west-1” } “aws_instance” “myec2” { ami = “ami-12345qwert” instance_type = “t2.micro” } resource This small example is enough to understand the capabilities of Terraform. The code contains 2 blocks- and . provider block lets the Terraform know, that we are going to use provider in the region “ ”. resource block let’s the Terraform know that out of all the infrastructure resources offered by AWS, we want to create a resource of type “ ” (EC2). This is represented by 1st parameter to resource block “ ”. The 2nd parameter is the name of our choice to be given to the resource – in this case, “myec2”. Resource block has a couple of arguments that indicate the AWS machine image and the type of instance to be used to create this resource. provider resource aws us-west-1 instance aws_instance Thus we have successfully managed to express our infrastructure in the form of code. We will not go into the details of the syntax in this post as it would be covered in another post. However, let us go through certain advantages of IaC. Since infrastructure creation is now condensed in config/code files, it is easier to maintain the same since we can now leverage version control systems like Git to collaborate and maintain the same.The time required for the planning phase of infrastructure is drastically reduced as the configurations can be written in a short amount of time and are readily consumed by Terraform to create cloud resources in the matter for few minutes.Changes to the infrastructure are easier and can be compared to code changes. Advantages for application management lifecycle in case of software development are also applicable for infrastructure. Thus, making it more efficient. Features of Terraform Terraform acts as the core of orchestration when it comes to creating cloud resources to deploy various end-to-end services. Orchestration: Since Terraform supports most of the clouds including AWS, MS Azure, and GCP, it becomes less of a worry when it comes to vendor lock-in issues. Terraform registry provides the documentation for all the supported cloud providers. Syntax patterns used to code infrastructure on various clouds are the same, so the learning curve related to provider-specific APIs can be put on a back burner. Cloud agnostic: Infrastructure expressed in Terraform files is declarative – thus as a developer, you don’t need to worry about making terraform understand the steps required to create a resource. Rather, all you need to do is let Terraform know about the desired state and Terraform takes care of steps internally. Declarative syntax: Terraform provides modules functionality which helps in reusing the Terraform code. A complex infrastructure can be divided into multiple modules and each module can be reused in different projects. It is very easy to convert a given terraform configuration into modules and Terraform has its eco-system for pre-built modules. Modules: When the infrastructure is created by Terraform, a state is maintained, which can be shared with other team members for collaboration purposes. Terraform offers the ability of remote state management, which helps prevent confusion amongst team members in case if they attempt to recreate the infrastructure. State: Terraform is not a full-blown provisioning tool, but it helps in day 1 provisioning activities. Terraform’s and blocks provide the ability to run inline scripts which can be used to install software components once the resource is created successfully. This is especially useful to assist configuration management tools like Chef, Ansible, and Salt Stack to install their respective agents, and have them send “UP” signal once they are installed successfully. Provisioning: local-exec remote-exec Terraform is available for use as open source software as well as Enterprise version. Open Source: Workflow [init – plan – apply – destroy] There are simple steps involved in successfully executing the Terraform code. These steps are closely related to the lifecycle of resources being created on cloud platforms. Again, these steps are cloud-agnostic, meaning the same steps/commands are used to resources on any given cloud provider. create, update, and destroy This blog post doesn’t cover installation steps for Terraform. It is assumed Terraform CLI is already installed on the system. Note: – Once we have configuration files ready, the very first command to run is . The Terraform binary installation does not include support for all the cloud providers at once. Instead, based on the provider to be used, appropriate plugins are downloaded before the Terraform code is executed. In our example, running would download the “aws provider” plugin. This command helps initialize the backend for a given Terraform directory. init terraform init terraform init – is used to generate an execution plan. Based on the configuration provided, Terraform generates an execution plan. In this phase, Terraform performs feasibility checks in terms of syntax errors, API authentication, state verification, etc. Running highlights if anything needs to be fixed before actual execution. If successful, it outputs a summary of potential changes in the infrastructure. It is ideal to run this before apply, as it makes you aware of any risks before modifying the infrastructure. plan terraform plan terraform plan – is used to execute any changes to the infrastructure. It is recommended to run before running , as planning creates a plan file which is referred to during apply phase. However, if in case is executed directly, a new plan file will be created automatically. apply terraform apply terraform plan terraform apply terraform apply – is used to destroy any resources which are part of the current configuration/state. destroy terraform destroy Let us wrap this post by executing the code we wrote in the previous section in the similar sequence. please use the correct AMI based on your preferred region. Note: Navigate to the directory where above mentioned code is saved in a .tf file. terraform init Output: Initializing the backend... Initializing provider plugins... - Reusing previous version of hashicorp/aws from the dependency - Installing hashicorp/aws v3 ... - Installed hashicorp/aws v3 (signed HashiCorp) Terraform has been successfully ! You may working Terraform. Try running see changes that your infrastructure. All Terraform commands should work. you ever modules backend configuration Terraform, rerun this command reinitialize your working directory. you forget, other commands will detect it remind you so necessary. lock file .22 .0 .22 .0 by initialized now begin with "terraform plan" to any are required for now If set or change or for to If and to do if terraform plan Output: An execution plan has been generated and is shown below. Resource actions are indicated the symbols: + Terraform will perform the actions: + { + ami = + arn = (known ) + associate_public_ip_address = (known ) . . . Plan: , , destroy. Note: You didn t that exactly these actions will be performed subsequently run. with following create following # aws_instance.example will be created resource "aws_instance" "myec2" "ami-12345qwert" after apply after apply 1 to add 0 to change 0 to ------------------------------------------------------------------------ 't specify an "-out" parameter to save this plan, so Terraform can' guarantee if "terraform apply" is terraform apply Output: Plan: 1 to add, 0 to , destroy. you want perform these actions? Terraform will perform the actions described above. will be accepted approve. Enter a : yes aws_instance.myec2: Creating... aws_instance.myec2: Still creating... [ s elapsed] aws_instance.myec2: Still creating... [ s elapsed] aws_instance.myec2: Still creating... [ s elapsed] aws_instance.myec2: Still creating... [ s elapsed] aws_instance.myec2: Still creating... [ s elapsed] aws_instance.myec2: s [ =i ef3120a0006a153] ! Resources: added, , destroyed. change 0 to Do to Only 'yes' to value 10 20 30 40 50 Creation complete after 51 id -04 Apply complete 1 0 changed 0 terraform destroy Output: Terraform destroy Plan: 0 to add, 0 to , destroy. you really want destroy all resources? Terraform will destroy all your infrastructure, shown above. There undo. will be accepted confirm. Enter a : yes aws_instance.myec2: Destroying... [ =i ef3120a0006a153] aws_instance.myec2: Still destroying... [ =i ef3120a0006a153, s elapsed] aws_instance.myec2: Still destroying... [ =i ef3120a0006a153, s elapsed] aws_instance.myec2: Still destroying... [ =i ef3120a0006a153, s elapsed] aws_instance.myec2: Still destroying... [ =i ef3120a0006a153, s elapsed] aws_instance.myec2: Still destroying... [ =i ef3120a0006a153, s elapsed] aws_instance.myec2: Still destroying... [ =i ef3120a0006a153, m0s elapsed] aws_instance.myec2: Destruction m5s Destroy ! Resources: destroyed. change 1 to Do to managed as is no Only 'yes' to value id -04 id -04 10 id -04 20 id -04 30 id -04 40 id -04 50 id -04 1 complete after 1 complete 1 In the next post, we would go through Terraform Syntax.