Managing AWS with Gitlab CI and Terraform

Terraform is a declarative language that allows you to express ‘I want this’ to your cloud provider. Here’s and example of how I manage me MX records and the “A” record in AWS for aethereal.io site and domain:

provider "aws" {
}

# root level route 53 resources
resource "aws_route53_zone" "io" {
  name          = "aethereal.io."
  comment       = "HostedZone created by Route53 Registrar"
  force_destroy = "false"
}

resource "aws_route53_record" "main" {
  type    = "A"
  zone_id = "${aws_route53_zone.io.zone_id}"
  name    = "${aws_route53_zone.io.name}"
  ttl     = "3600"
  records = ["52.167.214.135"]
}

# MX records
resource "aws_route53_record" "io-mx" {
  zone_id = "${aws_route53_zone.io.zone_id}"
  name    = "${aws_route53_zone.io.name}"
  type    = "MX"
  ttl     = "3600"

  records = [
    "1 ASPMX.L.GOOGLE.COM",
    "5 ALT1.ASPMX.L.GOOGLE.COM",
    "5 ALT2.ASPMX.L.GOOGLE.COM",
    "10 ALT3.ASPMX.L.GOOGLE.COM",
    "10 ALT4.ASPMX.L.GOOGLE.COM",
  ]
}

Naturally, we store all of this in gitlab. The next, natural progression is that we create a CI/CD pipeline to test and run our ‘infrastructure as code’. Here’s a little example to get you started. Drop this yaml file into the base of your gitlab repository and add a your AWS credentials as ‘secret variables’ in your gitlab repository and you’re in business.

---
image: jonatanblue/gitlab-ci-terraform:latest

stages:
  - plan
  - apply

cache:
  paths:
    - .terraform
  key: "$CI_BUILD_REPO"

plan:
  stage: plan
  script:
    - terraform init -backend=true -get=true -input=false
    - terraform plan -out planfile
  when: always
  artifacts:
    paths:
      - planfile

apply:
  stage: apply
  script:
    - terraform init -backend=true -get=true -input=false
    - terraform apply
  when: manual
  dependencies:
   - plan

This gitlab pipeline uses a docker container, courtesy of jonatanblue, that already has terraform installed and is suited for running terraform code in gitlab-ci. There are 2 stages:

  • plan where we look at the results of the run
  • apply where we can manually apply the proposed changes

This process works well for us. We can accept pull requests from development or other team members for changes to our AWS infrastructure and our ops team can decide whether to approve them or not. Another nice aspect is that the CI/CD pipeline has access to affect change, not individual users so we don’t have to give credentials to our AWS account just so people can look around… It’s all in the code.

Hope this helps!

Phone

(612) 840-6253

Address

750 Margaret Street
Saint Paul, MN 55106
United States of America