Transcript
and today I'm going to demonstrate how to use the Stacks feature in HTTP Terraform. Stacks provide a powerful configuration layer in Terraform that simplifies managing your infrastructure modules and then repeating that infrastructure. For this demo, I'll be deploying a Kubernetes cluster hosting a simple HashiBank web application to illustrate how you can use Stacks to streamline the deployment and management of Kubernetes clusters with Terraform. Let's start out by taking a look at the configuration for my stack. Stacks replace Terraform's traditional root module structure with a new configuration layer on top of your Terraform child and shared modules. Stack configuration files use a new file type, tfstack.htl, to define what you would like to deploy. In this configuration, I have a component block for each top-level module I need to include in this stack, including a VPC, EKS cluster, Kubernetes namespace, and my HashiBank web app. In this example, each of my components sources a local module. However, component sources support referencing modules from all of the same places as a standard module block. Each component also takes in a set of inputs, which can be outputs to the previous component. In a stack, you also declare all of your providers in your stack configuration and then pass necessary providers into each of your components. I've now switched to the file where I've declared all of my providers for this stack. Here you can see that I can also use outputs of my components as inputs to my providers. At runtime, Terraform is going to construct a graph of dependencies based off these inputs and outputs, and we'll use it to determine not only the plan and apply order for the components in my stack, but also for the providers in my stack. The deployment configuration file, tfdeploy.htl, defines how many times HTTP Terraform should deploy a stack's infrastructure. I'd like to deploy a development, production, and disaster recovery instance of my HashiBank app, so I've declared a deployment block for each way I'd like to repeat my infrastructure. Here I can customize the inputs for each deployment as needed. For example, I'm using one region for disaster recovery, US-East-1. And if we scroll up here, a different one for development, US-West-2. I've also defined an orchestration rule here using an orchestrate block, which allows me to define check blocks that auto-approve any deployments that meet the criteria defined in these checks. In this case, I will allow any plans in development to be auto-approved if there are no resources being removed. Switching over to the HTTP Terraform console, I'm going to create a stack for this configuration, which I've already configured to point to the repository we were just looking at. Immediately we see that a new configuration is being prepared for us where HTTP Terraform is looking at the latest commit in this connected repository and is figuring out what deployments and components are in my stack. The stack has picked up my three deployments and has started to queue plans for each one. We can see that if we scroll down here. Looking at the quick view for production, we'll be able to see some details on the plan expanded out. I'm going to click into my VPC component here, and we can see details about the 23 planned additions, which look like what I'm used to seeing in a standard Terraform plan today. Terraform has also let us know that this plan is ready to be approved with deferred changes. And what that means is that some resources did not have enough information for Terraform to produce a full plan, like this Kubernetes namespace, which has an unknown provider configuration. Instead of failing, which is what standard Terraform does today, my stack is allowing me to approve a partial plan here and is letting me know that it will produce follow-up plans for resources like my namespace once that information is available after apply. Now, closing out of the production plan, I want to focus your attention here on the development deployment, which does not have a plan pending approval, and is instead currently applying changes. Because of that orchestration rule I showed you earlier, development didn't require manual approval. My development deployment has completed applying. Clicking in, we can see a history of what was applied, and we can see that multiple plans and applies took place in order to get all of my infrastructure set up, thanks to the deferred changes. I can expand the state here to grab the URL of my HashiBank application, and let's just make sure that that's all set up. And it looks like my application is up and running. We can see that it's been deployed successfully. Now, I'm ready to move on to approving this change for production and even disaster recovery. This demo covered a lot of ground, so I'll summarize a few key takeaways here. Deployments in a stack allow easily repeating infrastructure, useful across environments like dev, staging, and production, or when deploying across multiple regions or cloud provider accounts. Deferred changes in a stack streamline deploying workloads with complex dependencies like Kubernetes, making it possible to do this with a single Terraform configuration. Orchestration rules in a stack allow automating approvals, reducing the need for manual and error-prone reviews. For more information about stacks, check out the HTTP Terraform docs and tutorials at developer.hashicorp.com and head over to cloud.hashicorp.com to get started. Thanks for watching. Microsoft Mechanics www.microsoft.com www.microsoft.com www.microsoft.com www.microsoft.com
