The document discusses the implementation of Infrastructure as Code (IaC) using Terraform for managing infrastructure across multiple AWS regions, emphasizing the benefits of automation, team collaboration, and version control. It covers topics like module creation for reusable components, state management using remote backends, and best practices for managing changes in a CI/CD environment. Additionally, it highlights potential challenges associated with Terraform's active development and compatibility issues.

1. TERRAFORM IN ACTION
The road to IAC

2. WHO AM I
➤ Damien Pacaud
➤ Director of infrastructure @ teads
➤ Dev & Ops
➤ In love with automation
➤ twitter.com/serty2

3. INFRA AS
CODE ?
Blueprints to your infra

4. OUR INFRASTRUCTURE
➤ 2 AWS Regions
➤ EU-WEST-1
➤ US-EAST-1
➤ Highly elastic platform
➤ 6M RPM average traffic
➤ Peak around 8.5 M
➤ 77% Europe
➤ 23% US
US-EAST-1
EU-WEST-1

5. OUR NEEDS
➤ Operate a 3rd region
➤ Reverse engineer existing regions
➤ Build a staging environment
➤ Better support turnover
➤ Track infra changes and revert them easily

6. ONE SOLUTION
➤ Infrastructure as code
➤ Templates describing your infra
➤ Documentation is in the code
➤ Easier to create a staging env
➤ Code is versioned via Git

7. OUR CHOICE
➤ Terraform
➤ Support for many providers
➤ Cloud IAAS : AWS / GCP / Azure
➤ Virtualization : vSphere / vCloud Director
➤ Monitoring : Datadog / Grafana / statuscake
➤ Alerting : PagerDuty
➤ Open source & Well maintained by HashiCorp
➤ Highly declarative and easily readable

8. TERRAFORM
Hello world and beyond

9. provider "aws" {
region = "eu-west-1"
profile = "perso"
}
resource "aws_vpc" "vpc_perso" {
cidr_block = "10.0.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
instance_tenancy = "default"
enable_classiclink = false
tags {
Creator = "Terraform"
}
}
resource "aws_subnet" "subnet_public" {
vpc_id = "${aws_vpc.vpc_perso.id}"
cidr_block = "10.0.4.0/22"
availability_zone = "eu-west-1a"
map_public_ip_on_launch = true
tags {
Creator = "Terraform"
}
}
HELLO WORLD

10. PLAN

11. APPLY

12. STATE

13. RESULT

15. WHAT ABOUT TEAMWORK ?

16. TEAMWORK :: BACKENDS
➤ Store your state file(s) remotely using terraform backend
➤ Many different backend available (azure, gcs, consul, s3, http…)
➤ S3 is a great choice for this use case
➤ Enable encryption
➤ Enable versioning
terraform {
backend "s3" {
bucket = "terraform"
key = "myProd.tfstate"
region = "eu-west-1"
profile = "perso"
}
}

17. TEAMWORK :: STATE LOCKING
➤ Locking is pretty new
➤ introduced in 0.9.0
➤ Only works with S3, Consul and Local backends
➤ S3 locking involves DynamoDB
➤ Seems pretty straightforward (haven’t tested it)
terraform {
backend "s3" {
bucket = "terraform"
key = "myProd.tfstate"
region = "eu-west-1"
profile = "perso"
lock_table = "terraform_lock"
}
}

18. TEAMWORK :: REMOTE APPLY (CI)
➤ Mutual agreement from team
➤ No-one should apply from its machine
➤ Jenkins only will apply
➤ Job concurrency == 1
➤ Needs discipline but works well
➤ Enforces the use of Pull-Requests

19. MODULES
Because DRY

20. WHAT ARE MODULES ?
➤ A module
➤ is just a folder containing terraform templates
➤ defines a reusable component
➤ is composed of multiple resources
➤ can and should be versioned, tagged
➤ By convention
➤ main.tf : contains resources declaration
➤ variables.tf : contains input variable declaration (with default values)
➤ outputs.tf : contains output variable names and values

21. MODULE DECLARATION :: MAIN.TF
#VPC
resource "aws_vpc" "vpc" {
cidr_block = "${var.vpc_cidr}"
enable_dns_hostnames = true
enable_dns_support = true
instance_tenancy = "default"
enable_classiclink = false
}
# DHCP options
# This is important to populate search section in /etc/resolv.conf
resource "aws_vpc_dhcp_options" "vpc_dhcp_options" {
domain_name = "${var.domain_name}.${var.env} ${var.aws_region}.compute.internal"
domain_name_servers = ["AmazonProvidedDNS"]
}
# DHCP association
# the option needs to be associated with the VPC
resource "aws_vpc_dhcp_options_association" "vpc_dhcp_options_association" {
vpc_id = "${aws_vpc.vpc.id}"
dhcp_options_id = "${aws_vpc_dhcp_options.vpc_dhcp_options.id}"
}
# Internet Gateway, required so that instances get access/be accessed from the Internet
resource "aws_internet_gateway" "internet_gateway" {
vpc_id = "${aws_vpc.vpc.id}"
}
# S3 VPC endpoint, required so that instances with private IPs can get access to S3
resource "aws_vpc_endpoint" "s3_endpoint" {
vpc_id = "${aws_vpc.vpc.id}"
service_name = "com.amazonaws.${var.aws_region}.s3"
}

22. MODULE DECLARATION :: OUTPUTS.TF
output "vpc_id" {
value = "${aws_vpc.vpc.id}"
}
output "main_route_id" {
value = "${aws_vpc.vpc.main_route_table_id}"
}
output "cidr_block" {
value = "${aws_vpc.vpc.cidr_block}"
}
output "igw_id" {
value = "${aws_internet_gateway.internet_gateway.id}"
}
output "s3_endpoint_id" {
value = "${aws_vpc_endpoint.s3_endpoint.id}"
}

23. MODULE DECLARATION :: VARIABLES.TF
variable "vpc_cidr" {}
variable "env" {}
variable "aws_region" {}
variable "domain_name" {}

24. USING MODULES :: MAIN.TF
module "vpc_staging" {
source = "git::git@github.com/myorg/mymodule.git//vpc?ref=0.1"
aws_region = "eu-west-1"
env = "staging"
vpc_cidr = "10.100.0.0/16"
domain_name = "teads"
}
module "vpc_prod" {
source = "git::git@github.com/myorg/mymodule.git//vpc?ref=0.1"
aws_region = "eu-west-1"
env = "prod"
vpc_cidr = "10.0.0.0/16"
domain_name = "teads"
}

25. USING MODULES :: OUTPUTS.TF
output "vpc_staging_id" {
value = "${module.vpc_staging.vpc_id}"
}
output "vpc_prod_id" {
value = "${module.vpc_prod.vpc_id}"
}
output "vpc_staging_igw_id" {
value = "${module.vpc_staging.igw_id}"
}
output "vpc_staging_main_route_id" {
value = "${module.vpc_staging.main_route_id}"
}
output "vpc_staging_cidr_block" {
value = "${module.vpc_staging.cidr_block}"
}
output "vpc_staging_s3_endpoint_id" {
value = "${module.vpc_staging.s3_endpoint_id}"
}
output "vpc_staging_main_vpn_gateway_id" {
value = "${module.vpc_staging.main_vpn_gateway_id}"
}

26. USING MODULES
➤ Modules allows to reuse the same code in different environments
➤ The same module can be used with different input variables in staging
and production environment
➤ The same module can be sourced multiple times, even in the same file
➤ Modules should be sourced from git tags / branches
➤ This allows to update a module while not breaking apply capacity
➤ Use terraform get -update command to source the module before
planning / applying

27. OUR PATH
WITH
TERRAFORM
what we’ve learnt

28. A FEW RULES :: SOURCE CONTROL
➤ Jenkins and Jenkins only will apply
➤ Work on Feature Branch, plan on Feature Branch (through Jenkins)
➤ Pull-Request before merging to master
➤ Only master gets applied
➤ Always Plan before Apply and then Plan again
➤ No silver bullet
➤ Pretty strict rules
➤ Master can be broken

29. A FEW RULES :: ENVIRONMENTS
➤ No unit tests available
➤ Use a staging environment
➤ Always test your code / module in staging before prod
➤ Even to change the name of a Security Group

30. A FEW RULES :: ISOLATION
➤ Large state files are impractical
➤ Changing something may lead to risking everything
➤ The smaller the component, the smaller the risk
➤ Each component has its own state
➤ Reference state from one component in another one
data "terraform_remote_state" "vpc" {
backend = "s3"
config {
bucket = "terraform"
key = "vpc.tfstate"
region = "us-east-1"
profile = "perso"
}
}

31. A FEW RULES :: DIRECTORY STRUCTURE
➤ Define directory level variables
➤ i.e. : environment.tf
➤ contains env and profiles variables
➤ Directories are duplicated between staging and
production
➤ Directories are duplicated between regions
➤ This is the granularity that we need

32. ISSUES
Terraform’s Dark Side

33. STILL NOT 1.0
➤ Development is very active
➤ New releases will break compatibility
➤ Read changelog before updating
➤ Secret management out-of-the-box is scary
➤ Apply will fail
➤ Even when plan is ok
➤ Example : Wrong CIDR in a subnet attached to a VPC

34. STILL NOT 1.0
➤ RTFM
➤ and read it carefully
➤ ex : Security Group name / description
➤ Declarative, Declarative, Declarative
➤ Stay away from those loops and arrays
➤ Depends on providers so YMMV

35. ONE MORE
THING

36. WE’RE HIRING
➤ Many positions open
➤ We have great arguments
➤ Talk to your friends
➤ https://teads.tv/teads-jobs/

37. QUESTIONS ?