Deploying Your First Terraform Configuration

@02/02/2023

Overview

• What is Terraform
  • Workflow
  • Installation

• ‘Globomantics’ scenario

• Walk through ‘Terraform: Hello world’ demonstration

What is Terraform

• Infrastructure automation tool
  • infra meaning a layer of technology that a developer consumes with having to deploy and manage it i.e.networking, virtual machines and containers

• the core is an open-source project maintained by Hashicorp, there are paid version

• it is also vendor agnostic meaning it has no preference of any particular cloud or service, works with most

• The single binary is compiled from Go available for multiple OS

• Uses a declarative syntax,
  • describe how you want the env, TF does the rest

• Config files are written in Hashicorp Configuarion Language (HCL) or JSON

• Push based deployment

Core components

1. Executable
   1. single binary file you call to run Terraform, contains all core functionality

2. HCL Configuration files
   1. the config you are deploying is contained in HCL Configuration files, with extension .tf usually
   2. when there are multiple .tf files in a directory, Terraform stitches them together

3. Provider Plugins
   1. executables invoked by Terraform to interact with a service’s API, ie AWS
   2. most common plugins are hosted on the public terraform registry
      1. registry.terraform.io

4. State data
   1. how Terraform keeps track of what’s been deployed
   2. state data contains current info about deployment
   3. a mapping of whats defined in config to what exists in target env.
   4. Terraform, when deploying:
      1. compares updated config files to state data file
      2. calculates changes needed to make them match,
      3. makes changes
      4. then updates state data

Installing Terraform

1. Download executable for platform

2. Add to your PATH environment variable

• Terraform is available in common packet managers and even as a docker container.

You can find the installer info for Terraform here:

https://www.terraform.io/downloads.htm

NOTE

• I had trouble using brew because the xcode install tool was going to take a long time to download

• so I bypassed and downloaded mac binary directly and unzipped into /opt/terraform directory

• and added the following to my ~/.bash_profile using nano

  PATH="/opt/terraform:${PATH}"

source:

https://www.coachdevops.com/2020/04/how-to-install-terraform-on-mac-os.html

• be sure to curl latest version of binary, address available on terraform downloads page

Using the CLI

Usage:

• Will accept double -- dash or single - dash for arguments, even if they are more than single characters

• Single is preferred syntax

Terraform Object Types

1. Providers
   1. define information about provider you want to use.
   2. i.e. AWS, which account, which region

2. Resources
   1. things to create in target env ie Ec2, network, database
   2. bulk of what you write
   3. each resource is associated with a provider and usually requires additional config information

3. Data Sources
   1. a way to query information from provider
   2. not creating anything
   3. just asking for data may need to use in config
   4. also linked to a provider
   5. e.g. ami for an ec2 instance, list of Availability Zones in a region

General Block Syntax

• uses block syntax

• easier to read

• permits inline comments

• simplified version of JSON

• a sample block looks like

  block_type “label” “name_label” {

  key = “value”

  nested_block {

  key = “value”

  }

  }

1. each lines begins with block_type
   1. which specifies type of object being described

2. next are a series of labels which depend on what object we are dealing with
   1. last label is usually the name label, provides a way to refer back to object in config

3. next in block we have one or more key value pairs which make use of available arguments for object type
   1. each key is a string and value can be any of Terraform’s data types

4. can also have nested blocks inside main block
   1. inside will be more key value pairs

Example

• HCL has a defined syntax for referring to other objects

  

• if you want the whole resource, skip the attribute option
  • e.g from the above example.

    aws_instance.web_server.name

  • which will equal “web-server”

Base configuration file

• Comments are supported in HCL by using hash symbol #

• comments can break file into:

  

1. Providers
   1. identify provider, with key value pairs storing AWS account details and how we will access, and also specifying region

2. Data
   1. lists the data sources
      1. in example, data source type is an AWS Service Manager parameter with the name label ami
      2. within config block we have a key called name and the value is the path of a parameter, which in this case grabs the latest Amazon Linux AMI ID for region we’re in
      3. this value will be used later when we create our AWS Ec2 instance

   

3. Resources
   1. creates each individual resource
      1. in example we start with Networking,
      2. creating a VPC with specified Cidr block and dns hostnames setting
      3. creating an internet gateway linked to vpc using vpc.id
      4. creating a subnet in vpc with a specfied CIDR block and public IP address
      5. and more… such as a route table, in which we can create within a nested block a particular route to populate the table
   • To find out what arguments and attributes are available for a resource i.e. .vpc.id
     • read the documentation
       • at https://registry.terraform.io/providers/hashicorp/aws/latest/docs

   Terraform Workflow

   • terraform makes use of provider plugins as noted
   • before it uses plugins it gets them
   1. this is done by in initialisation process

   $> terraform init

   • init looks for config files inside current working directory
   • examines them to find any needed plugins
   • try and download those plugins from public Terraform Registry
   • unless an alternate location is specified
   • also prepares the back end of the state data file,
     • if not specified Terraform creates this in cd
   • once complete, ready to deploy infra
   2. next step is plan out deployment with terraform plan

   $> terraform plan

   • in this step terraform looks at current config, state date contents, determine differences, and make plan to update target env to match desired config
   • terraform prints out plan so you can verify changes to be made
   • not absolutely necessary to run, but pretty useful
   • you can save the changes of the plan to a file and then feed into terraform for next step
   • terraform indicates what will be created with a green + sign

   

   3. Next step is making changes in target env, done with terraform apply

   $> terraform apply

   • executes changes saved in plan using provider plugins
   • resources are created or modified
   • state data is then updated
   • if no changes are needed, terraform notifies us and makes none
   4. One last command, when done with env is terraform destroy

   $> terraform destroy

   • a dangerous command!
   • the red minus sign indicates what resources will be destroyed

   

   Summary

   1. Terraform is infrastructure automation
   2. Terraform is a single binary which can be used on almost any OS
   3. Configurations used by Terraform is HCL or JSON
   4. basic workflow is: init, plan and apply (and maybe destroy)