Gruntwork Newsletter, September 2018

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,

This month, we made major updates to Terratest, our IaC testing library, including adding support for Google Cloud, RDS, SSH Agent, and log file gathering; updated our ECS modules to support Service Discovery (based on Route 53), daemon services (e.g., run exactly one DataDog container on each ECS node), and volumes; fixed some important issues with our cross-account IAM Roles and aws-auth script; fixed a bug in our SQS module that revealed an important Terraform issue; and many other fixes and tweaks. Read on for all the details.

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

Gruntwork Updates Terratest supports Google Cloud, RDS, SSH Agent, log file gathering, andmore

We’re continuing to grow and improve Terratest , our open source, swiss-army knife for testing infrastructure code. With lots of help from the open source community, we’ve added a number of major new abilities to Terratest this month. Here are the highlights:

Google Cloud Support:We added support for GCP to Terratest! Terratest now supports a broad collection of GCP features including getting public IPs, adding labels, getting a random region or zone, reading/writing in GCS buckets, and much more. This is available in Terratest, v0.10.0 .

Gather log files: Added methods that allow you to fetch files over SSH from servers, EC2 Instances, and ASGs. The main use case for this is to fetch the contents of log files (or any other files you want to see!) from EC2 Instances at the end of the test to make debugging a test failure 10x easier. This is available in Terratest, v0.9.17 .

SSH Agent: You can now use ssh-agent authentication with Terratest’s SSH methods by simply setting the SshAgent field to true in the ssh.Host struct ( Terratest, v0.9.16 ). You can run an in-process SSH agent using the ssh.NewSshAgent method and have Terratest use that SSH Agent for SSH connections via the new OverrideSshAgent parameter in ssh.Host ( Terratest, v0.10.1 ). You can use the new SshAgent property in terraform.Options to specify an in-process SSH agent to use when running Terraform. This makes it easier at test time to use custom SSH keys with remote-exec , files , and other ssh-based provisioners ( Terratest, v0.10.2 ).

RDS: You can now use Terratest to test your RDS databases! Check out the new methods in the aws package, including GetAddressOfRdsInstance , GetWhetherSchemaExistsInRdsmysqlInstance , GetParameterValueForParameterOfRdsInstance , and GetAllParametersOfRdsInstance . This is available in Terratest, v0.10.3 . Support for other DBs and checks will be coming in the future.

ECS Service Discovery support on module-ecs

Motivation:AWS ECS makes it easy to deploy Docker containers as long-running ECS services, but as ECS selects which EC2 instance will run the container, and as EC2 Instances can be replaced or scaled up or down, ECS services have dynamically assigned IPs. If you want your services to be able to talk to each other, you need some form of service discovery so they can find out which service lives at which IPs. In the past, we used internal load balancers for this purpose, but a few months ago, Amazon announced integrated support for Service Discovery in ECS that allows you to reach your ECS services through hostnames managed by Route 53.

For example, service foo can talk to service bar at bar.internal-domain.com and service baz at baz.internal-domain.com . With integrated support for service discovery, ECS can now take care of automatically registering IPs when a new container is deployed and de-registering them when the container is deployed or crashes. Here are some of the advantages of using ECS Service Discovery over a load balancer:

Direct communication between your services (no extra hops) Lower latency, if using AWS internal network and private namespaces You can do service-to-service authentication Not having a Load Balancer also means fewer resources to manage You can make a logical group of services under one namespace

Solution:We created a terraform module under our module-ecs package called ecs-service-with-discovery . It allows you to deploy an ECS Service with Service discovery in AWS, taking care of registering the ECS service, configuring the network, and making a the necessary Route 53 alias for public hostnames. Currently our module supports public or private hostnames (examples are provided for both scenarios) and tasks with the awsvpc network mode. host and bridge network modes will be supported in future updates.

What to do about it:Upgrade to version v0.8.0 of module-ecs if this functionality would be useful to you.

Run daemon services on each Instance in your ECScluster

Motivation: Many of our customers needed a way to run exactly one copy of a specific Docker container, such as a DataDog agent, on each EC2 Instance in their ECS cluster. This was hard to do with the ECS scheduler, so typically, some sort of hack was required.

Solution: We’ve added a new ecs-daemon-service module that that you can use to deploy exactly one task on each active container instance that meets all of the task placement constraints specified in your cluster.

What to do about it: The ecs-daemon-service module is available in