Excels provisioner concepts in Terraform

There are three types of provisioner in Terraform mainly popular to inject scripts of any installations , any specific activities to be perform inside any EC2 instances , Azure VM's ,Compute in AWS, Azure & GCP respectively .

In this article we will deep dive with AWS EC2 instance example with some surprises that how by terraform we can install Jenkins , Ansible in the EC2 instance using remote-exec provisioner . I am sharing both Ubuntu & CentOS through Terraform

CentOS:-

provider "aws" {
  region = "us-west-2"  # Replace with your desired AWS region
}

resource "aws_instance" "my_instance" {
  ami           = "ami-0c55b159cbfafe1f0"  # Replace with your desired AMI ID
  instance_type = "t2.micro"
  key_name      = "my-keypair"  # Replace with your SSH key pair name

  tags = {
    Name = "MyInstance"
  }

  provisioner "remote-exec" {
    inline = [
      "sudo yum update -y",
      "sudo yum install -y java-1.8.0-openjdk",
      "sudo yum install -y git",
      "sudo yum install -y unzip",
      "wget -q -O /tmp/jenkins.rpm https://pkg.jenkins.io/redhat-stable/jenkins-2.303.2-1.1.noarch.rpm",
      "sudo rpm -i /tmp/jenkins.rpm",
      "sudo systemctl start jenkins",
      "sudo systemctl enable jenkins",
      "sudo yum install -y epel-release",
      "sudo yum install -y ansible",
    ]
  }
}
        

Ubuntu:-

provider "aws" {
  region = "us-west-2"  # Replace with your desired AWS region
}

resource "aws_instance" "my_instance" {
  ami           = "ami-0c55b159cbfafe1f0"  # Replace with your desired AMI ID
  instance_type = "t2.micro"
  key_name      = "my-keypair"  # Replace with your SSH key pair name

  tags = {
    Name = "MyInstance"
  }

  provisioner "remote-exec" {
    inline = [
      "sudo yum update -y",
      "sudo yum install -y java-1.8.0-openjdk",
      "sudo yum install -y git",
      "sudo yum install -y unzip",
      "wget -q -O /tmp/jenkins.rpm https://pkg.jenkins.io/redhat-stable/jenkins-2.303.2-1.1.noarch.rpm",
      "sudo rpm -i /tmp/jenkins.rpm",
      "sudo systemctl start jenkins",
      "sudo systemctl enable jenkins",
      "sudo yum install -y epel-release",
      "sudo yum install -y ansible",
    ]
  }
}        

Why Inline function used in this case ?

1. In remote-exec provisioner Inline function used .
2. It allows to list of the commands directly within the Terraform configuration
3. Its a simple or one time setup tasks .

File Provisioner :-

The file provisioner in Terraform is a mechanism for copying files or directories from the local machine (where Terraform is running) to a remote resource (such as an EC2 instance, VM, or container) during resource creation or update. It allows you to transfer files as part of your infrastructure provisioning process.

resource "aws_instance" "my_instance" {
  # Other resource attributes...

  provisioner "file" {
    source      = "local/path/to/file.txt"
    destination = "/remote/path/on/instance/file.txt"
  }
}        

Let's say for an example I want to upload nginx configuration files from local to ec2 instance . Here is the step by step to follow and configure each of the nginx.conf & sites-available/mysite.conf files using File provisioner .

a. Configuration files :-

resource "aws_instance" "my_instance" {
  # Other attributes...

  provisioner "file" {
    source      = "local/path/to/nginx.conf"
    destination = "/etc/nginx/nginx.conf"
  }

  provisioner "file" {
    source      = "local/path/to/sites-available/my-site.conf"
    destination = "/etc/nginx/sites-available/my-site.conf"
  }
}        

b. Restart Nginx :-

Restart & check the status of the nginx by remote-exec commands .

resource "aws_instance" "my_instance" {
  # Other attributes...

  provisioner "remote-exec" {
    inline = [
      "sudo systemctl restart nginx"
      "sudo systemctl status nginx"
    ]
  }
}        

3. Local Provisioner :-This type of provisioner used locally not in remote EC2 instances but sometimes required to install, generate certain activities locally. Example Use Case:

resource "aws_instance" "my_instance" {
  # Other attributes...

  provisioner "local-exec" {
    command = "ssh-keygen -t rsa -b 4096 -f ~/.ssh/my-key -N ''"
  }
}        

From this local key we can log into the EC2 instance if , we wish .

Cons of Provisioner :-

• Not Always Predictable: Provisioners can sometimes behave unexpectedly. Imagine if you run a script every time you make changes, but it doesn’t always do the same thing. That can be confusing!
• Hard to Reuse: Provisioners are like one-time tools for specific tasks. It’s like having a hammer that only works for one type of nail. Not very versatile!
• Messy Configurations: Too many provisioners can make your Terraform files messy. It’s like having a cluttered toolbox where you can’t find the right tool easily.
• Mixing Things Up: Provisioners mix provisioning (setting up resources) with configuration management (software setup).It’s like trying to cook and clean dishes at the same time—it can get messy!
• Extra Complexity: Provisioners add extra steps and dependencies. It’s like adding more ingredients to a recipe—it can make things harder to manage.

Remember, while provisioners are useful, using them sparingly and keeping things simple is often better! ??