CDK for Terraform in Production: Learning from Pocket

Kelvin Yeboah and Mathijs Miermans from Pocket’s engineering team joined us in a recent Terraform Community Office Hours to share a live demo of how they define and provision infrastructure using CDK for Terraform. Check out the recording to watch the live demo, and read on for a summary of how their team is using CDK for Terraform.

»CDK for Terraform

The Cloud Development Kit for Terraform (CDKTF) allows you to use familiar programming languages to define cloud infrastructure and provision it through Terraform. This gives you access to the entire Terraform ecosystem while allowing you to leverage the power of your existing toolchain.

CDKTF is under active development and is not officially recommended for production use cases. However, some early adopters, like Pocket, are already using CDK for Terraform in production, and we are excited to work with them to validate and improve workflows.

»Provisioning with Terraform Using the Familiarity of TypeScript

Pocket — a Mozilla product — is a website and app that finds the most interesting, thought-provoking and entertaining articles from trusted sources around the internet and puts them all in one place. Pocket also lets you save articles — as well as anything else you find online (videos, recipes, shopping pages, etc.) — to your personal Pocket for digging into later.

To support the user experience, the Pocket engineering team is tasked with building, maintaining, and deploying a wide variety of services, with the same type of infrastructure being deployed frequently. Over time, the team transitioned from managing infrastructure in a UI to working with Terraform, where they loved having version control and being able to manage state. But HCL was a new syntax and framework for the team to learn.

Transitioning to writing infrastructure code in their preferred programming language— TypeScript — using CDK for Terraform has allowed them to spin up new services faster and get new features in front of users with less delay. Managing infrastructure in a familiar language has also empowered their developers to engage closely with the infrastructure, giving them a better understanding of the services they are building and removing blockers.

“When CDKTF came out, that was like a game changer for us. We are mostly application developers, we are not an SRE team … so if we could write our infrastructure in code in the language that we already use, that was a game changer for us. Because then we can empower ourselves to work faster and more efficiently and build services faster.” — Kelvin Yeboah, Senior Software Engineer, Mozilla, Pocket

Another practical improvement that they’ve noticed is that they have fewer files to manage and they are able to use their existing code pipeline with CircleCI to automate the plan/apply deployment workflow. For those interested in seeing a CDK for Terraform project in action, the team’s open source GitHub repos are an excellent reference for structuring and writing code with CDKTF: https://github.com/Pocket.

»The Demo

During the live demo, Mathijs and Kelvin walked us through how to deploy a “Hello world” Apache web server in a production-ready environment using Amazon ECS in fewer than 150 lines of readable TypeScript code. In addition to provisioning infrastructure for the web server, this demo application also includes other production-ready necessities, including an ECS cluster, application load balancer, defined security groups, alarms via PagerDuty, and snapshot testing of the output JSON configuration file.

You can reference the code used for this demo in the repos below, and even follow along as you watch the recording:

• Demo source code
• Reusable constructs

»Simplifying Application Code with Reusable Constructs

CDK for Terraform allows you to manage complexity and reduce code duplication by creating custom abstraction layers, referred to as constructs. During the demo, Kelvin references the custom construct libraries that their team has built for their CDK for Terraform TypeScript applications. These are opinionated libraries that their team has built to customize the CDKTF interface to the developer team’s needs. For example, in the demo, Kelvin uses two of these custom packages to add a production-ready ECS cluster, a load balancer, and to create alarms using PagerDuty. You can find these libraries in an open source repo of Node.js packages that define their infrastructure patterns in CDKTF.

For more examples of how the Pocket team uses custom constructs to simplify their development process and ensure best practices, check out these open source repos:

• Pocket/firefox-android-home-recommendations: TypeScript REST API
• Pocket/collection-api: TypeScript GraphQL API with a relational database
• Pocket/recommendation-api: Python GraphQL API with a key-value store and AWS Lambda functions

»Get Started with CDK for Terraform

If you’re new to CDK for Terraform, the best place to get started is with the hands-on tutorials on HashiCorp Learn.

Stay tuned for a follow-up Community Office Hours on October 27, where the Pocket team will do a more thorough walkthrough of their codebase, recommended architecture, and best practices.

Source: HashiCorp Blog

Announcing HashiCorp Waypoint 0.6

We are pleased to announce the general availability of HashiCorp Waypoint 0.6. Waypoint is an application deployment tool that aims to deliver a PaaS-like experience for Kubernetes, ECS, and other platforms. Kubernetes is one of the world’s most popular deployment platforms, but there’s still too much work to go from an empty Kubernetes cluster to production-ready application deployments.

In this release, we’ve shipped a Helm-based installation method to install Waypoint with familiar tools in a couple of commands. We now support Helm as an application deployment option to make adopting Waypoint easier in existing environments.

For our YAML-free deployment options, we now support horizontal pod auto-scaling, sidecars, and Kubernetes Ingress. The result of all this work is that whether you’re writing a new application or optimizing an existing one, you can get up and running with Waypoint quickly, and it feels great on Kubernetes.

Here are some of the significant features in this release:

• Helm-based server install: The Waypoint server can now be installed into Kubernetes clusters using an official Helm chart. Installations on other platforms remain unchanged.
• Docker builds in Kubernetes: Waypoint can now build Docker images directly in Kubernetes pods, enabling a secure, self-hosted remote Docker build environment.
• Helm-based application deployment: You can now deploy your applications from Helm charts. If you already use Helm, this lets you adopt Waypoint with almost no additional work.
• Kubernetes resources in the UI: The Kubernetes resources created for a deployment (by Waypoint, Helm, or any other plugin) are now listed in the UI along with their health status.
• Kubernetes auto-scaling deployments: Allow users to configure an autoscaler in Kubernetes with Waypoint and its deployments when using a metrics server.
• Kubernetes Ingress for releases: Waypoint will support releasing deployments using an ingress controller and configuring an ingress resource for your deployments.

This release includes many additional new features, workflow enhancements, general improvements, and bug fixes. The Waypoint 0.6 changelog contains a detailed list of all changes in this release.

»Helm-Based Server Install

$ helm repo add hashicorp https://helm.releases.hashicorp.com
"hashicorp" has been added to your repositories

$ helm install waypoint hashicorp/waypoint

$ waypoint login -from-kubernetes

You can then run waypoint ui to open the web UI. Please see the Installing Waypoint for Kubernetes documentation for more details.

»Docker Builds in Kubernetes Pods

Waypoint now integrates with Kaniko to support building Docker images directly within unprivileged Kubernetes pods and enable remote Docker builds within a trusted environment. When paired with our GitOps workflow, this allows an entire build-to-deploy lifecycle powered by Waypoint.

Waypoint previously required a privileged execution environment that could be difficult to configure within hosted Kubernetes providers. Now, Waypoint works out of the box with all major Kubernetes providers. This requires no additional configuration and automatically happens for Waypoint build operations triggered by Git or the -remote flag.

We also added a guide to using Waypoint with externally built images. Many people adopting Waypoint already have a workflow to build container images, such as through CI. In this scenario, Waypoint doesn’t need to build the image, but it still needs to know the name of the resulting image so it can be used for deployment. This guide explains how to integrate externally built images into a Waypoint workflow.

»Helm-Based Application Deployment

app "my-app" {
  deploy {
    use "helm" {
      name  = "my-app"
      chart = "${path.app}/helm"

      set {
        name  = "image.repository"
        value = artifact.image
      }

      set {
        name  = "image.tag"
        value = artifact.tag
      }
    }
  }
}

»Resource Listing in the UI

The Waypoint web UI now shows a listing of all of the platform resources created by a deployment and release. This works with all deployment plugins. All resources created will be shown in the listing, regardless of which instantiation method is used in Kubernetes

This allows users of Waypoint to quickly diagnose any issues. A common scenario we found in earlier versions of Waypoint was that the Waypoint deployment succeeded, but a configuration error caused the deployed application to be broken. For example, an environment variable to connect to the database might be missing. Now, users can see that while the Waypoint deployment succeeded, the launched resources may still have errors they need to resolve.

Future versions of Waypoint will continue to add additional functionality to the resource listing, such as the ability to view more details, see diffs between deployment versions, notify on status changes, and more.

»Kubernetes Auto-Scaling Deployments

app “my-app” {
  build { ... }

  deploy {
    use “kubernetes” {
      cpu {
        request = "250m"
        limit   = "500m"
      }

      autoscale {
        min_replicas = 2
        max_replicas = 5
        cpu_percent  = 75
      }

    }
  }

  release { ... }
}

»Kubernetes Ingress for Releases

Waypoint now has an additional way to configure and release your deployments in Kubernetes when using our opinionated Kubernetes deployment plugin. Users can now create an ingress resource for a release.

Unlike the other options Waypoint supports for release, an ingress resource can be configured to match certain inbound traffic that should be routed through the ingress controller to an application’s deployment. The ingress resource will use an existing ingress controller for routing traffic per release, rather than spinning up an additional load balancer, which may cost extra money and take longer to initialize.

Configuring an ingress resource for a release is as simple as defining an ingress stanza:

app “my-microservice” {
  build { ... }

  deploy {
    use "kubernetes" {
      probe_path = "/"
    }
  }

  release {
    use "kubernetes" {
      ingress "http" {
        path_type = "Prefix"
        path      = "/"
      }
    }
  }
}

»What’s Next for Waypoint?

There are many more features and improvements in Waypoint 0.6, but they are too numerous to detail in this post. For a complete listing of changes in Waypoint 0.6, please see the CHANGELOG.

One of our primary focuses is improving workflows around multiple environments (staging, production, etc.) in future releases. Working with various environments using Kubernetes today is a very manual and error-prone process. We hope that we can bring significant automation and opinionated workflows to streamline this process better.

We hope you enjoy Waypoint 0.6!

»Next Steps

• Download Waypoint 0.6 from the project website.
• Learn more about Waypoint with tutorials on the HashiCorp Learn site.
• Contribute to the Waypoint project and participate in its community.
• Extend Waypoint by creating a plugin.

Source: HashiCorp Blog