DEV Community: Lucas de Souza

Rolling update EC2 with Terraform

Lucas de Souza — Sun, 27 Sep 2020 22:18:58 +0000

This post is just an implementation of @endofcake's article. I'm going to show a real example on how to use the rolling update technique with EC2. If you want to get more background about the difference between Rolling Update and Blue/Green please check his post.

Using Terraform for zero downtime updates of an Auto Scaling group in AWS | by Alexander Savchuk | Medium

Alexander Savchuk ・ Aug 25, 2018 ・
Medium

🚨Warning🚨

Extreme rolling techniques ahead. Proceed with caution.

Terraform can do Blue/Breen natively, just add create_before_destroy = true in the lifecycle block and the terraform will create the resource in a blue/green manner.

resource "azurerm_resource_group" "example" {
  # ...

  lifecycle {
    create_before_destroy = true
  }
}

Fig.1 - Lifecycle block example.

In other to show this update I decided to create a really simple web page using Packer to create the images.

Speed things up with Packer

Before we dive into how to create rolling updates with terraform let's talk a little about Packer.

HashiCorp Packer aims to build automated machine images, which means, we can create scripts to configure images with our application inside, installing all the dependencies that our application needs.

In our example, we use Packer to build a very simple HTTP server. I created a simple script that will install Apache web server and create a web page with a specif background color ( you can choose the color, exciting isn't it? ).

To update the "version" of our application just change the color variable to any color of your preference. The default color of our web page is red.

variable "color" {
  default = "red"
}

variable.pkr.hcl

I won't get into details of Packer in this post, but basically, Packer will create an EC2 instance, execute the scripts/basic-website.sh inside it, and take a snapshot of that instance, saving it as rolling_update_{{timestamp}}. The execution of this script is described in the provisioner block.

I know that isn't a good tutorial, but enough of Packer for now.

Rolling Update with Terraform

Well, here's the fun part. Terraform has no way to do this.

Terraform has no way to know if your application is alive nor to check what is the current version; because it was not built for this purpose.

Although we can configure health-checks on Targets Groups and Auto Scaling Groups, Terraform will not care if the application is healthy after finishing the apply phase.

In other to create the rolling update with Terraform we are going to use a little hack... We are going to use CloudFormation!

CloudFormation gives to Auto Scaling Group a really cool feature, the UpdatePolicy. This is a policy that is triggered every time that ASG is updated, which means if we launch a new version of a launch template we can trigger our ASG to update its instances.

We can take advantage of this CloudFormation automation and blend it into Terraform!

Ok, Lucas, @endofcake already explains all this to us.

Less talk and more code.

First, clone this git repository:

souzaxx / Rolling-Update-Terraform

Code example for RollingUpdate with Terraform and Packer

Create our first AMI going inside the packer folder.

cd packer
packer build .

Wait until the AMI is created

After that, go back to the root of the repository and apply the terraform.

cd ..
terraform init
terraform apply

To check that our web page is up and running gets the LoadBalancer DNS from Terraform output terraform output lb_dns and open it in your favorite browser or just curl it curl $(terraform output lb_dns).

Update the Image

In other to check the update progress, execute this loop in another terminal:

while true; do
curl $(terraform output lb_dns)
sleep 1
done

Now, create a new "version" of our application by choosing a color. You can overwrite the default variable passing -var 'color=green' into the packer CLI.

cd packer
packer build -var 'color=green' .

Wait for its completion and apply the terraform again:

cd ..
terraform apply

We can check that lauchconfiguration and cloudformation resources have changed.

Confirm the apply and check the curl loop to see the changes in realtime.

Conclusion

I hope this post was useful for your studies in Terraform and in my next post I want to show this process with a real application such as Consul.

Clean up

terraform destroy --auto-approve

and delete all the AMI created by Packer:

Thank you for your time and

Terraform + Helm = ❤️

Lucas de Souza — Sun, 20 Sep 2020 14:53:54 +0000

If you ever tried to manage IaC with Terraform you might end up with “Well, the cloud resources are fine, but how am I going to deal with my Kubernetes cluster???”

In this post, I want to share a simple and functional example of how you can integrate Helm with Terraform using the best of each tool.

The setup of this integration became much easier after Helm v3 was released. Now, you can simply pass your Kubernetes credentials to the Helm Provider and start deploying your charts using Terraform!

provider "helm" {
  kubernetes {
    config_path = "/path/to/kube_cluster.yaml"
  }
}

You can now deploy Charts using the helm_release resource 🎉.

resource "helm_release" "example" {
  name       = "my-redis-release"
  repository = "https://kubernetes-charts.storage.googleapis.com" 
  chart      = "redis"
  version    = "6.0.1"

  values = [
    "${file("values.yaml")}"
  ]

  set {
    name  = "cluster.enabled"
    value = "true"
  }

  set {
    name  = "metrics.enabled"
    value = "true"
  }

  set_string {
    name  = "service.annotations.prometheus\\.io/port"
    value = "9127"
  }
}

Ok, that's fine Lucas, but you have basically shown the Helm provider page... Am I wasting my time here?

In this post, I want to deal with all this excessive set {} parameters in the helm_relase resource. There must be an easier way to manage these variables.

Actually, the tutorial has already shown us how! We can use the values parameter and pass all our variables in a YAML format.

values = [
  "${file("values.yaml")}"
]

Instead of using the file function, we can also pass in EOF format:

Lucas...

Okay, okay, I'm sorry! I'm getting into the point, wait a little longer!

templatefile

In terraform, we can create dynamic templates using the templatefile function. Combe this function with the values parameter in the helm_release resource and we get a lot of flexibility!

The templatefile function has a slite different syntax than Terraform, but you can easily adapt to it.

An example would be:

backends.tmpl

%{ for addr in ip_addrs ~}
backend ${addr}:${port}
%{ endfor ~}

And to render this template:

templatefile("${path.module}/backends.tmpl", { port = 8080, ip_addrs = ["10.0.0.1", "10.0.0.2"] })

Giving the output:

backend 10.0.0.1:8080
backend 10.0.0.2:8080

And yes, we can also use if statements if you wondered.

We can use all this flexibility right into the values parameter, and here is an example of how to create a dynamic values.yaml:

Templatefile also accept terraform objects making our life easier

If you want to follow the complete example:

souzaxx / EKS-on-steroids

In my next post, I'll explain in more detail about this project and how it can help eks clusters running out IPs address.

Thank you for your reading,

Stay safe; stay well.

Lucas.