Section 1.1: The Importance of Template Files

You might wonder why template files are essential in Terraform. The reality is that templating is a robust feature that helps break down your code into smaller, more manageable sections. It also enables you to dynamically incorporate specific values into your final code. Let’s explore a hypothetical situation to clarify this point.

Consider the task of deploying an S3 bucket, a Lambda function, and an IAM role with a policy that permits the Lambda function to access the S3 bucket. Without template files, you could execute everything in a single Terraform file, but the inline code for the IAM policy could become convoluted and hard to read, especially if it’s lengthy.

Here’s an illustration of the code without template files:

resource "aws_iam_policy" "AWSLambdaBasicExecutionPolicy" {

name = "AWSLambdaBasicExecutionPolicy"

}

resource "aws_s3_bucket" "example" {

bucket = "my-example-bucket"

}

resource "aws_lambda_function" "example" {

function_name = "my-example-function"

...

}

resource "aws_iam_role" "iam_for_lambda" {

name = "${aws_lambda_function.example.name}-role"

managed_policy_arns = [

aws_iam_policy.AWSLambdaBasicExecutionPolicy.arn,

aws_iam_policy.lambda_policy.arn

]

}

resource "aws_iam_policy" "example" {

name = "my-example-policy"

policy = <...>

}

Now, let’s observe how this code transforms when we adopt template files:

resource "aws_iam_policy" "AWSLambdaBasicExecutionPolicy" {

name = "AWSLambdaBasicExecutionPolicy"

}

resource "aws_s3_bucket" "example" {

bucket = "my-example-bucket"

}

resource "aws_lambda_function" "example" {

function_name = "my-example-function"

...

}

resource "aws_iam_role" "iam_for_lambda" {

name = "${aws_lambda_function.example.name}-role"

managed_policy_arns = [

aws_iam_policy.AWSLambdaBasicExecutionPolicy.arn,

aws_iam_policy.lambda_policy.arn

]

}

resource "aws_iam_policy" "lambda_policy" {

name = "${aws_lambda_function.example.name}-policy"

policy = templatefile(

"./iam-policies/lambda-policy.json",

S3_bucket_arn = aws_s3_bucket.example.arn

)

}

lambda-policy.json

{

"Version": "2012-10-17",

"Statement": [

{

"Action": [

"s3:GetObject",

"s3:GetBucketLocation",

"s3:ListBucket"

],

"Resource": "${S3_bucket_arn}",

"Effect": "Allow"

}

]

}

In this example, we created a separate file, “lambda-policy.json,” to house the IAM policy. By using the templatefile() function, we dynamically insert the S3 bucket ARN variable. This approach not only makes the IAM policy clearer and easier to manage but also allows for easy reuse in other projects.

Section 1.2: User Data with Template Files

Another scenario where template files shine is when deploying EC2 instances with user data. Similar to the IAM policy example, while you could define your user data inline, managing it becomes cumbersome as your codebase grows. Thus, utilizing the templatefile() function for user data is a more effective solution.

Here’s how your code might look with an inline user data definition:

resource "aws_instance" "example" {

ami = "ami-0ff8a91507f77f867"

instance_type = "t2.micro"

user_data = <<-EOF

#!/bin/bash

nohup busybox httpd -f -p 8080 &

EOF

}

Now, let’s see how to revise this code using the templatefile() function for user data:

resource "aws_instance" "example" {

ami = "ami-0ff8a91507f77f867"

instance_type = "t2.micro"

user_data = templatefile("./scripts/user_data.sh")

}

user_data.sh

#!/bin/bash

echo "Hello, World!" > index.html

nohup busybox httpd -f -p 8080 &

In this case, we created a separate file, “user_data.sh,” containing the user data script. By using the templatefile() function, we can render the template and insert the user data script into the EC2 instance. This method not only keeps the script manageable but also allows for easy template reuse across projects.