Gruntwork Newsletter, June 2020

Once a month, we send out a newsletter to all Gruntwork customers that describes all the updates we’ve made in the last month, news in the DevOps industry, and important security updates. Note that many of the links below go to private repos in the Gruntwork Infrastructure as Code Library and Reference Architecture that are only accessible to customers.

Hello Grunts,

In the last month, we updated the Reference Architecture to take advantage of all the new EKS/Kubernetes features (e.g., support for Fargate, managed node groups, EFS, cluster security groups, etc) and published an upgrade guide, created reusable masks to help fight COVID-19 (all proceeds go to charity), added support for cross-region replication to our Aurora and RDS modules, added EFS support to our ECS modules, and made many other fixes and improvements. In other news, Terraform 0.13.0 Beta is out, HashiCorp has announced their Cloud Platform, and there’s a new and exciting Kubernetes provider for Terraform in the works.

As always, if you have any questions or need help, email us at support@gruntwork.io!

Gruntwork Updates

undefined

EKS Reference Architecture Updates

Motivation:**** Over the past 6 months, we’ve added many new features to our EKS solution, including support for Fargate, managed node groups, EFS, cluster security groups, etc. Many of these features have been adapted into our module for EKS (terraform-aws-eks), but we have not had the chance to update the Reference Architecture to be able to take advantage of these developments. We also did not have detailed instructions to help Reference Architecture customers update their clusters to the latest versions.

Solution: We’ve updated the Acme Reference Architecture examples to the latest version of Kubernetes, EKS modules, and Helm v3! We also published a detailed upgrade guide that walks you through the process of how to update your existing Reference Architecture to the latest versions. Check out our guide and let us know what you think!

undefined

Grunty-approved COVID-19 masks

Motivation: COVID-19 continues to be a problem around the world and we wanted to do something to help.

Solution: We’ve created a reusable face mask that you can buy to protect yourself, and, as all the proceeds go to Crisis Aid International’s COVID-19 Relief Fund, your purchase also helps to protect the world!

What to do about it: Check out Not all heroes wear capes, some wear masks for the full details and get yourself a mask in the Gruntwork store!

undefined

Cross-region replication for RDS and Aurora

Motivation: Our rds and aurora modules have supported replication across Availability Zones since day one, but customers that had more strict requirements around availability, disaster recovery, and global access wanted a way to create replicas in totally separate regions.

Solution: As of the release of module-data-storage, v0.12.19, both the rds and aurora modules now support cross-region replication! For example, here’s how you can set up a primary MySQL instance in us-east-1 and a replica for it in us-west-2:

# Configure a provide for the primary region
provider "aws" {
region = "us-east-1"
alias  = "primary"
}
# Configure a provide for the replica region
provider "aws" {
region = "us-west-2"
alias  = "replica"
}
# Deploy the MySQL primary
module "mysql_primary" {
source = "git::git@github.com:gruntwork-io/module-data-storage.git//modules/rds?ref=v0.12.19"
# Run the primary in the primary region
providers = {
aws = aws.primary
}
name           = "mysql-primary"
engine         = "mysql"
engine_version = "5.6.37"
port           = 3306
instance_type  = "db.t3.micro"
# Must be set to 1 or greater to support replicas
backup_retention_period = 1
}
# Deploy the MySQL replica
module "mysql_replica" {
source = "git::git@github.com:gruntwork-io/module-data-storage.git//modules/rds?ref=v0.12.19"
# Run the replica in the replica region
providers = {
aws = aws.replica
}
# To indicate this is a replica, set the replicate_source_db param
replicate_source_db = module.mysql_primary.primary_arn
name           = "mysql-replica"
engine         = "mysql"
engine_version = "5.6.37"
port           = 3306
instance_type  = "db.t3.micro"
}

What to do about it: Check out the rds-mysql-with-cross-region-replica and aurora-with-cross-region-replica examples for the full sample code. Special thanks to Jesse Bye for contributing the Aurora cross-region replication feature!

undefined

Mount EFS Volumes in your ECS Tasks, including Fargate Tasks!

Motivation: Last month, we released an efs module that makes it easy to create an NFS file system you can share across your AWS services. Now we needed a way to mount these EFS volumes in those services.

Solution: In v0.12.20 of module-data-storage, we added support for creating EFS access points and the corresponding IAM policies for them, and in v0.20.3 of module-ecs, we’ve updated the ecs-service module with support for mounting the access points from those EFS Volumes in your ECS Tasks, including Fargate Tasks! All you need to do is specify the volumes you want to use via the efs_volumes input variable:

module "fargate_service" {
source = "git::git@github.com:gruntwork-io/module-ecs.git//modules/ecs-service?ref=v0.20.3"

# Specify the EFS Volumes to mount
efs_volumes = {
example = {
file_system_id          = module.efs.id
root_directory          = null
container_path          = "/example"
transit_encryption      = "ENABLED"
transit_encryption_port = null
access_point_id         = module.efs.access_point_ids.example
iam                     = "ENABLED"
}
}
# ... (other params omitted) ...
}

Where module.efs is an EFS volume with access points created using the efs module. Check out the docker-fargate-service-with-efs-volume example for fully working sample code. Special thanks to Milosz Pogoda for the contribution!

What to do about it: Give EFS Volumes in your ECS Tasks a shot and let us know how they work out for you!

undefined

Open Source Updates

cloud-nuke

terraform-aws-vault

helm-kubernetes-services

Terragrunt

Terratest

undefined

Other updates

module-data-storage

module-security

module-cache

module-ci

package-lambda

terraform-aws-eks

package-messaging

module-ecs

module-asg

module-vpc

module-server

DevOps News

Terraform 0.13.0 beta

What happened: Terraform has announced a beta program for Terraform 0.13.0.

Why it matters: The major features in Terraform 0.13.0 are:

What to do about it: We do not recommend upgrading to Terraform 0.13.0 yet. We will be keeping our eye on it, waiting for it to get closer to a final release, and then will test our codebase with it for compatibility. We will announce when our testing is complete and it is safe to upgrade (and if there are any backwards incompatible changes to take into account).

HashiCorp Cloud Platform

What happened: HashiCorp has announced that they are launching the HashiCorp Cloud Platform (HCP), a fully managed cloud offering of all of HashiCorp products.

Why this matters: Up until now, if you wanted to use HashiCorp products such as Consul, Vault, or Nomad, you had to run and maintain them yourself. These are all reasonably complicated distributed systems, so this could be a significant amount of work. Now, HashiCorp is beginning to launched managed offerings, where they will run these tools for you, and allow you to use them as a SaaS offering.

What to do about it: Currently, they are only offering early access (private beta) to HCP Consul for AWS. HCP Vault is coming in the future. See the announcement for the full details.

New Kubernetes provider for Terraform

What happened: HashiCorp has announced a new kubernetes-alpha provider for Terraform.

Why it matters: The current Kubernetes provider for Terraform has always lagged significantly behind Kubernetes features, limiting your ability to use Terraform to manage your Kubernetes clusters. The new kubernetes-alpha cluster allows you to use native Kubernetes manifests directly—albeit in HCL, rather than in YAML—so you always have access to all features supported by Kubernetes. Moreover, by leveraging a new feature called Server-Side Apply, you will be able to leverage the plan functionality of Terraform, where it shows you the diff of what you’re about to change in your Kubernetes cluster before you run apply to actually deploy that change. Being able to use HCL— with full support for variables, functions, and integration with the rest of your infrastructure—instead of plain-old-YAML, may make Terraform a very compelling way to manage your Kubernetes cluster.

What to do about it: Feel free to give the new provider a shot—though bear in mind that it is currently experimental and cannot yet be installed from the Terraform Registry (see the announcement blog post for details)—and let us know what you think! In the meantime, we will be keeping a close eye on this new provider to see how it compares with the current provider, as well as other Kubernetes tools, such as Helm, and will keep you posted on whether we will integrate it into the Gruntwork IaC Library.

EC2 Auto Scaling now supports Instance Refresh

What happened: AWS has (finally!) released native support for updating EC2 instances in an Auto Scaling Group (ASG).

Why this matters: ASGs are a great way to run multiple EC2 instances and automatically replace unhealthy instances, but up until now, rolling out changes (e.g., new AMIs) has always been left up to the user (e.g., see the modules in module-asg for how we’ve implemented rolling deployments). Now AWS supports a native way to do rolling updates.

What to do about it: Terraform support is still pending. Once it’s available, we plan on incorporating it into module-asg. PRs are also very welcome!

Security Updates

Below is a list of critical security updates that may impact your services. We notify Gruntwork customers of these vulnerabilities as soon as we know of them via the Gruntwork Security Alerts mailing list. It is up to you to scan this list and decide which of these apply and what to do about them, but most of these are severe vulnerabilities, and we recommend patching them ASAP.

Ubuntu

Text Link