Skip to main content

Gruntwork release 2019-01

Guides / Update Guides / Releases / 2019-01

This page is lists all the updates to the Gruntwork Infrastructure as Code Library that were released in 2019-01. For instructions on how to use these updates in your code, check out the updating documentation.

Here are the repos that were updated:

package-k8s

v0.1.4

Published: 1/9/2019 | Modules affected: eks-cluster-control-plane | Release notes

  • eks-cluster-control-plane

  • When provisioning an EKS cluster, we will now wait for the API endpoint to come up before marking the resource as created. This addresses an eventual consistency issue where chaining eks cluster resources to kubernetes resources could sometimes fail because terraform marks a resource as complete before the API comes up and is responsive. Note that this requires installation of kubergrunt. You can get back to the older behavior by setting use_kubergrunt_verification to false in the module parameters.

  • This release is not intended to be used in production, as core features of a production grade infrastructure are still missing. This is currently intended to be used for development and learning purposes so that you can plan out a migration to Gruntwork modules for managing EKS.

  • https://github.com/gruntwork-io/package-k8s/pull/43

terraform-aws-asg

v0.6.24

Published: 1/26/2019 | Modules affected: asg-rolling-deploy | Release notes

v0.6.23

Published: 1/21/2019 | Modules affected: server-group | Release notes

terraform-aws-cache

v0.5.0

Published: 1/17/2019 | Modules affected: redis | Release notes

  • redis (BACKWARDS INCOMPATIBLE)

  • redis: Adds 4 new aws_replication_group permutations to the Redis module, to workaround the inability to use interpolations in ignore_changes field in a lifecycle block (hashicorp/terraform#3116) which will have been the ideal solution to ignoring the number_cache_cluster field when in cluster_mode to prevent terraform plan diffs due to cluster resizing.

This release is backwards incompatible and to update an existing Redis cluster, use terragrunt state mv <old_address> <new_address> to ensure that your cluster isn't deleted when you run terraform apply.

For example, to migrate a cluster mode Redis cluster deployed via the aws_elasticache_replication_group.redis_with_snapshotting_without_auth_token resource, you'd simply run:

terraform state mv module.<your-module-name>.aws_elasticache_replication_group.redis_with_snapshotting_without_auth_token module.<your-module-name>.aws_elasticache_replication_group.redis_with_snapshotting_without_auth_token_with_cluster_mode 

terraform-aws-ci

v0.13.8

Published: 1/14/2019 | Modules affected: install-jenkins | Release notes

v0.13.7

Published: 1/7/2019 | Modules affected: git-helpers | Release notes

terraform-aws-data-storage

v0.8.7

Published: 1/30/2019 | Modules affected: rds | Release notes

v0.8.6

Published: 1/28/2019 | Modules affected: aurora | Release notes

v0.8.5

Published: 1/3/2019 | Modules affected: aurora | Release notes

terraform-aws-ecs

v0.11.3

Published: 1/23/2019 | Modules affected: ecs-daemon-service | Release notes

  • ecs-daemon-service

  • The ecs-daemon-service module now exposes setting pid_mode via a new variable: ecs_task_definition_pid_mode . This allow setting the process namespace to use for the containers in the task. The valid values are host and task. The default value is task and the terraform provider will not accept an empty string value without error.

  • https://github.com/gruntwork-io/module-ecs/pull/113

v0.11.2

Published: 1/16/2019 | Modules affected: ecs-daemon-service | Release notes

  • ecs-daemon-service

  • The ecs-daemon-service module now exposes a deployment_minimum_healthy_percent parameter you can use to set the lower limit (as a percentage of the service's desiredCount) of the number of running tasks that must remain running and healthy in a service during a deployment.

  • https://github.com/gruntwork-io/module-ecs/pull/111

v0.11.1

Published: 1/16/2019 | Modules affected: ecs-service-with-discovery | Release notes

v0.11.0

Published: 1/10/2019 | Modules affected: ecs-service-with-discovery | Release notes

  • ecs-service-with-discovery [Breaking Change]

  • The ecs-service-with-discovery module now sets the default family name for the ECS Task Definition to ${var.service_name} rather than "${var.service_name}-task-definition" to be consistent with the other ECS modules. If you wish to retain the old naming convention, you can now explicitly set the family name using the new task_definition_family_name parameter.

  • https://github.com/gruntwork-io/module-ecs/pull/108

  • https://github.com/gruntwork-io/module-ecs/pull/109

terraform-aws-eks

v0.1.4

Published: 1/14/2019 | Modules affected: eks-cluster-control-plane, eks-cluster-workers, eks-k8s-role-mapping, eks-vpc-tags | Release notes

  • eks-cluster-control-plane
  • eks-cluster-workers
  • eks-k8s-role-mapping
  • eks-vpc-tags

This is a compatible release of terraform-aws-eks with package-k8s v0.1.4.

terraform-aws-load-balancer

v0.13.0

Published: 1/31/2019 | Release notes

  • alb [BREAKING CHANGE]

  • The ALB requires all listeners to have a "default action" that defines what to do for a request that doesn't match any listener rule. In the past, the only supported action was to forward requests to a target group, so we used to forward to an empty "black hole" target group, resulting in a 503. The ALB now supports fixed responses, so we've updated the default action of the alb module to return a blank 404 page, which is a more appropriate status code.

For most teams, the new 404 behavior is better, so no code changes will be necessary. However, if you wish to override this 404 behavior, you have two options:

  1. You can override the default fixed response via the default_action_content_type, default_action_body, default_action_status_code parameters.
  2. You can add an ALB Listener Rule that catches ALL requests (i.e., *) and have that rule forward to a custom Target Group so your own apps can respond in any way you wish.

terraform-aws-monitoring

v0.11.0

Published: 1/31/2019 | Modules affected: cloudwatch-dashboard-metric-widget, cloudwatch-dashboard | Release notes

  • cloudwatch-dashboard-metric-widget (BACKWARDS INCOMPATIBLE)

  • cloudwatch-dashboard

  • cloudwatch-dashboard-metric-widget: Changes the stacked variable type from a string to a bool

  • cloudwatch-dashboard: Updates replacement algorithm for creating valid json from Terraform json_encode output

This release is backwards incompatible and to update an existing metric widget, simply remove the surrounding quotes on the boolean value supplied.

v0.10.3

Published: 1/22/2019 | Modules affected: alarms/alb-target-group-alarms | Release notes

terraform-aws-sam

v0.1.9

Published: 1/30/2019 | Modules affected: gruntsam | Release notes

v0.1.8

Published: 1/24/2019 | Release notes

terraform-aws-security

v0.15.7

Published: 1/21/2019 | Modules affected: fail2ban | Release notes

terraform-aws-server

v0.6.0

Published: 1/23/2019 | Modules affected: persistent-ebs-volume | Release notes

  • persistent-ebs-volume [BREAKING CHANGE]

  • mount-ebs-volume now uses the UUID instead of the device name to mount volumes. With some OS and volume configurations, the device name can change after a reboot, so using the UUID ensures that the volume is always identified the same way.

  • https://github.com/gruntwork-io/module-server/pull/41

v0.5.4

Published: 1/9/2019 | Modules affected: persistent-ebs-volume | Release notes

  • persistent-ebs-volume

  • The mount-ebs-volume script will now retry correctly if an EBS volume exists but is attached to a different EC2 instance. This is useful to ensure the script retries while an old instance shuts down and releases the volume.

  • https://github.com/gruntwork-io/module-server/pull/38

v0.5.3

Published: 1/8/2019 | Release notes

single-server

Some users may have requirements for tighter security group rules on instances, but the single-server module currently has a hard coded rule to allow all outbound traffic.

What we changed:

  • Added an allow_all_outbound_traffic variable to the single-server module and implemented it so the allow_outbound_all security group rule can be toggled on/off by end-users.
  • The variable defaults to true so existing users will be unaffected.

terraform-aws-utilities

v0.0.6

Published: 1/9/2019 | Modules affected: [NEW], [NEW] | Release notes

  • [NEW] run-pex-as-data-source
  • [NEW] run-pex-as-resource

This release introduces modules that support running python PEX files in Terraform in a way such that the scripts themselves do not need to be embedded in the pex. See the documentation to learn more about pex.

v0.0.5

Published: 1/9/2019 | Modules affected: require-executable | Release notes

v0.0.4

Published: 1/8/2019 | Modules affected: [NEW] | Release notes

terraform-aws-vpc

v0.5.5

Published: 1/29/2019 | Modules affected: vpc-app, vpc-mgmt | Release notes

v0.5.4

Published: 1/14/2019 | Modules affected: vpc-app-network-acls | Release notes

  • vpc-app-network-acls

  • The Network ACLs now allow outbound DNS (UDP, port 53) traffic, by default. Most services need DNS, so it seems like a bug to not have exposed this properly before. Note that internal AWS DNS seems to work without this, but for other DNS systems, such as the one used by Kubernetes, this is an important fix.

  • https://github.com/gruntwork-io/module-vpc/pull/47

v0.5.3

Published: 1/9/2019 | Modules affected: vpc-app | Release notes

v0.5.2

Published: 1/4/2019 | Modules affected: vpc-app | Release notes

  • vpc-app

  • You can now create Elastic IP Addresses (EIPs) for your NAT Gateways outside of the vpc-app module and tell the module to use those EIPs by setting the use_custom_nat_eips parameter to true and passing in the list of EIP allocation IDs using the custom_nat_eips parameter.

  • https://github.com/gruntwork-io/module-vpc/pull/46

terraform-kubernetes-helm

v0.1.0

Published: 1/18/2019 | Modules affected: k8s-namespace, k8s-service-account | Release notes

  • k8s-namespace [BACKWARDS INCOMPATIBLE]

  • k8s-service-account [BACKWARDS INCOMPATIBLE]

  • The RBAC roles and RBAC role bindings are now managed using the kubernetes provider as opposed to kubectl.

This is a backwards incompatible change. Specifically, the modules no longer need to specify a kubectl_config_context_name and kubectl_config_path. Additionally, we now require the number of rbac roles to be passed in as a variable to work around a terraform limitation with looping interpolated lists.

v0.0.1

Published: 1/14/2019 | Modules affected: k8s-namespace, k8s-service-account | Release notes

  • k8s-namespace

  • k8s-service-account

  • Introduces k8s-namespace terraform module, which will create a namespace and RBAC roles for admin access and read only access restricted to the namespace.

  • Introduces k8s-service-account terraform module, which will create a service account. This module also supports binding RBAC roles to the service account.