Build and manage complex application platforms with Terraform

[Music] welcome everyone to build and manage complex application platforms with terraform for those of you who haven't figured it out yet this is the Deep dive session on terraform stacks and Perna and I are thrilled to show you what we've been up to now before we dive in we're going to do we're going to break the ice a little with a some interactive

Q&A so we just ask that you humor Us for a moment here I'll ask the first question now by a show of hands how many of you are experiencing or have experienced challenges managing dependencies across your workspaces or your root modules and maybe this has led you to build some custom tooling try and Stitch things together terraform your terraform is that ringing any bells yeah it's a little hard to see but

definitely some folks out there all right and then how many of you have spec specifically experienced this issue because of progressive apply challenges when deploying kubernetes I'm talking about needing to split up that configuration to avoid having to do targeted applies to get your kubernetes cluster up and running before you do something like deploy a name space inside yeah definitely definitely some folks here yeah thanks Sarah I'll jump

in with the next question uh do you deploy the same infrastructure using the same configuration but passing in different input values for your variables this could be because you're doing the same workload across Dev staging and production or you're doing U multi-ion deployments for an application does that ring a bell yes great I see a lot of hands that's awesome keep your hands up if you have a setup that you need to repeat like 10 times okay a lot of hands anybody doing

this over 100 times it's getting fewer but still a few hands and anybody doing this over a thousand times okay I don't see too many hands but I see some in the back actually well you're not alone and between Sarah and I we've talked to at least 70 different customers deeply researched these topics and truly thought about how we could make it better for our users my name is paa

I joined Hashi Corp as a product manager a little over a year ago and I focus on platform Engineers using terraform to support multiple application teams I'm really excited to be here with Sarah today who you might recognize because she's popular but for our YouTube audience why don't you introduce yourself yeah hello everybody I'm Sarah Hernandez I'm also a product manager here at hashy Corp and I've had the pleasure fun and challenge of researching and building Stacks over the last couple years of my career here and

in this session we'll be diving into these challenges and more so Perna's going to kick things off by showing us an application platform example and the complications that result when we try and deploy that using workspaces then I'll go ahead and introduce stacks and per will take that same sample application and model it using Stacks then we get to the fun part and that's going to be the demo where we deploy real infrastructure using stacks and then we'll wrap things up and show you what other use cases you might be able to use use a stack for I'll hand it back

to you thank you yeah this part is going to be super familiar uh but we'll do it together we have a simple application called hashib bank it's a web app we're going to run it on kubernetes and we're going to use terraform today to deploy this application on AWS which is our Cloud platform for the demo um we're going to need several Cloud resources to build this application but to simplify today's discussion we'll focus on the VPC and eks

resources and for the general practice we'll deploy our application inside of a namespace and the cluster as we think through the workspace design we'll try to collect those resources in the same configuration that can be planned and applied together and we'll try to split code across team boundaries to help us keep things modular this will also make sure that our run times are short and with that let's get started we will deploy the first thing which is a networking components uh this will include the VPC and a few other n netw workking infrastructure that we need

before we can even bring up the kubernetes cluster and that's what we will do next uh now terraforming kubernetes is very interesting as many of you might know uh we need a lot of other services to be deployed in that cluster for the smooth deployment and operation of our app container and we'll want to simplify identity management so we want to enable oidc in the cluster so before we can deploy our services we want to enable oidc in the cluster before we can do that we need to bring

up our kubernetes cluster all of these dependencies will prevent us from running terraform over this configuration if we try to plan it to all together and so we are forced to break things up we need one workspace for just the cluster another workspace for everything else and of course we also need a workspace for our application with that we have four workspaces as with any application we need one environment for development another environment for prod and this is our primary channel for signing up new users so we need Disaster Recovery as

well so with that we end up with a total of 12 workspaces across three environments for just one application imagine the proliferation of workspaces and configuration when you have to support hundreds of application teams I don't even want to but you probably know what that's like but we'll come back to this application and this is the same set of workspaces that we were just discussing they're just organized under different projects one project for each environment now all of these works spaces need to be planned and applied in

the right order because of all the dependencies we talked about so far and also because we want to test out our changes in lower environments and then gradually promote them up to production ordering also becomes critical when we make changes to Landing zones which service blueprints for foundational infrastructure any changes made to Landing zones will have a cascading effect on all the infrastructure that depends on it in the words of one of our users if we were to plan and apply this in the wrong order then we'll end up building house of cards that comes

crashing down this is all about the planning coordination necessity just to make everything work next what we see here is a visualization of uh the plan and apply cycles of our terraform runs which are now scattered across various workspaces what we don't see here is the time it takes to review the output from each of these plans analyze the differences and as you can imagine there is no easy way to track changes across these dependent envirment

requirements it's so messy and if you ever decide to spin up a new region the ordering and the coordination that we've talked about it just gets that much Messier in short as your infrastructure scales the management of these workspaces becomes increasingly complicated and we were asking ourselves what if there was a better way and as it turns out there is a better way we thought to ourselves terraform is great could we extend it out a little bit further and that's exactly what we ended up doing here so Stax is going to take

your infrastructure as code and it's going to turn it into infrastructure as code AS code with a new layer of configuration that's going to sit right on top of your terraform modules now we're not Reinventing the wheel here don't worry really what we're doing is extending Concepts that you're using and you're familiar with today and so we're taking those terraform modules and establishing them as a foundation to for a workflow that's going to help you better organiz and deploy

them now as many of you know a standard terraform configuration allows you to deploy one Ro module and you can only do that one time the issue that brought many of you to this room here today but with a stack we're able to deploy multiple root modules and we can repeat them multiple times all within a single configuration now does that sound too good to be true I'll go ahead and introduce some of the Concepts that make up a stack to

show you how a stack is actually able to accomplish this so we start out by declaring what we want to deploy using what are known as components in a stack and now each component is going to map to a top level terraform module so an example of this would be having a networking a compute and a storage module each mapped to a component in my stack and now components are going to allow us to logically separate our infrastructure into smaller parts with interdependency so we're

componentized that module of modules pattern that a lot of you are already deploying today and then we have deployments and this is going to be where we declare how many times we want this collection of components to be deployed so this Canna allow you to repeat your infrastructure

without needing to repeat your code so we can keep things don't repeat yourself dry and some of the ways that we've seen some of you try and accomplish this in the wild today include reusing the same configuration across your workspaces or your room modules and then swapping out things like your workspace variables or your TFR files so deployments is really going to be the native way to accomplish this from within a single stack

but as you can imagine manually reviewing and applying changes across several repeated infrastructure instances that can be quite tedious some of you are telling us you're deploying things in the scale of hundreds maybe a couple in the back thousands at that scale it's pretty much impossible to do anything manually and that's why we're introducing what are known as orchestration rules um and so this is going to allow you to define granular check blocks that sit directly in your

configuration to do things like Auto approve a deployment plan if it meets the criteria defined in these checks allowing us to kind of remove the need for a lot of those manual operations and then our final concept today is going to be the one that helps us get around some of these chicken and egg situations like the ones we're talking about here with kubernetes this concept is called deferred changes and it's a bit of a tricky one but it turns out it ends up being exactly like what the name gests

so we'll end up deferring some changes for later and so what this looks like in practice is I can start out by making a configuration change and terraform is going to realize it doesn't have enough information to plan and apply this all right now so instead of failing which is what it does today terraform is going to split this into a couple parts so it's going to take all of the things that it can plan right now and it's going to produce for us plan part one then it's going to save the the rest of the things

that it doesn't have enough information for for later so it'll defer those changes we can apply plan part one and now that terraform has a little bit more information to go off of it's able to plan the rest of the changes that we deferred for later and produce plan part two and once we apply plan part two we have now successfully set up our configuration using deferred changes it does sound too good to be true so we are going to take all these new concepts of stacks and try and go back to our application and model it out

as a stack we'll kick things off very similar to workspaces with the core networking components and we're going to try and group together those resources as one component that share a common provisioning life cycle so we'll start out with the first component being the VPC component and then progress to the kubernetes component uh this is where we will Source our kubernetes provider and all the other providers that we need and once we have this component defined we'll move on to the remaining things that we need to deploy in the cluster

for this one let's take a moment to just understand how the breakdown goes we have one component for the rback rback is going to be a onetime setup and so we are creating a separate component just for that all the subsequent authentication will be done using that rback so then we have uh a name space for our application that's going to be its own component and all the remaining services that will be shared in the cluster will be declared in the kubernetes add-ons component so we have our three components in the cluster as service and then finally we have another

component for the application itself and with that we have our entire set of components declared now we'll move on to the second concept that we learned about which is deployments we know we want to deploy this application in three different environments we will model those out with deployments so we now have three deployments one representing an environment for all of these deployments we have the same set of variables defined but we can pass in different values for each of the deployments this way we have isolation without repetition

which is great and all this looks great conceptually but let's take a look at the code to make this a little bit more concrete and we'll also see the remaining two concepts in action you ready yeah ready okay all right so starting out from my editor here the first thing you're going to notice are going to be some new file extensions and we'll start out by taking a look at the ones that end in t f stack. htl this is going to be known as

our stack configuration it's going to be where we declare our components our providers and our variables in the stack now in my file here I have laid out a component block for each of those components that Perna so nicely laid out for us earlier and I'm going to take a deeper look at this eks component here now looking at the component you might be wondering H this looks very similar to a module and you're not wrong components are essentially wrappers around our modules so it's going to make

sense that they're going to take in a lot of the same parameters as a module would take in we're going to start out by sourcing the module that this component is going to stand up and in this case I am using a local module but you can Source modules from all the same places that you're used to sourcing modules from today so the registry get repositories then we'll go ahead and pass in all of the inputs that this module exps and if you look closely at some of these inputs you'll notice that some of them are outputs of other components in my stack here like the VPC

ID the final thing we're going to pass in here is going to be our providers and this is a really important step because in a stack we declare all of our providers at the top level and I'll show you that in a moment and we can also have multiple instantiations of the same provider so it's really important to tell my component which providers to use here now I'm also using the for each meta argument here across a set of regions um so I'll end up getting this

component set up for me for each region passed into this list it's a great way to dynamically scale our infrastructure based off something Dynamic like regions um and we can also map this to the appropriate AWS provider and the way I'm able to do that if I switch over to my provider's file you don't have to declare it in a separate file like this but I find it it does help with organization our AWS provider block here is also able to use this for each uh meta argument over that set of read this has been a long requested ask for

terraform and so we've included it here in stacks and then the other thing I'll point out about our providers is that they don't use aliases you'll notice that but we actually directly are going to name our providers here and that's how we're able to distinguish across multiple instantiations of the same provider now the last thing I'm going to point out here is that we are using an output of that eks component that we just looked at as an input to our provider um um so remember that for

later but also at runtime terraform is going to look at the inputs and outputs across not only the components in my stack but also across the providers and it's going to use that to determine the graph of dependencies for the order of operations for plan and apply and this is going to be a really important first step for working around some of those kubernetes issues that's great the components look fairly intuitive can you also show us what deployments look like yeah absolutely I'll switch over here to the TF deploy htl file so this is going to

be known as our deployments configuration it's going to be where Weare declare our deployments the inputs and then our um authentication specifics for our stack and so I have those deployments that Perna described for us earlier and we're able to differentiate the inputs across our deployment deployments if we want so here I'm using the US West 2 region for development but in production I am using both the US West 2 and the US least one region for

production but for those inputs that we want to keep the same across our deployments we can use something like a locals block to go ahead and make sure that we are keeping things dry not repeating oursel and you might notice here that I'm using some authentication specifics in my locals block you might wonder oh do I have to use the same authentication method across all of my deployments and the answer to that is you don't have to you could in this case use a different AWS account for each one of the deployment in the stack here but I'm

just going to use one account because it keeps things a little bit simpler for our demo and so the way that I was able to go ahead and set up my authentication was I went um into my AWS account prior to this I created a role with a trust policy because I'm using oidc op and I pointed that at my HTP terraform organization my AWS testing project inside of it and I used this AWS workload identity audience then when I came and wrote my configuration I dropped in one of these identity token blocks and all it needs to reference is

the audience from the trust policy we created and um at runtime this is going to expose for me a jot that I can directly pass into my deployment along with the roll Arn and those will get passed into the providers that we took a look at earlier amazing as fun as it is to look at configuration I'm very CED to see dataform do its magic over this yeah well let's go ahead and switch on over to my HTP terraform organization and we

can see this in action um we're inside of my AWS testing project here and the first thing you're going to notice are that we have both stacks and workspaces living inside of our projects here you can think of them kind of like siblings and so they're both going to inherit things from the project like um variables permissions and authentication methods so we'll start by creating a stack and I'm going to hook it up to that repo that we were just taking a look at we'll create create

it and so immediately we see that a new configuration is being prepared for us and so what that means is that HTP terraform is pulling out the latest commit in the connected repository and it's starting to parse out all the deployments in it and once it does that it's going to start queuing independent and isolated plans for each of the deployments in this stack and so that information is starting to come in here we'll go ahead and take a deeper look at this configuration

one and now every commit or merge event that happens in the connected repository is going to result with one of these configuration versions this is configuration one because it's the first one we've seen in this stack and we'll be able to see here details about the triggering commit um and I can also see things like all the dependencies so in this case I'm sourcing a lot of subm modules from the registry and their versions so I can tell if anything changed unexpectedly and then the last thing I can see here

is all of the plans that were triggered for each of the deployments in my stack and here we can see that all of our plans are planned for us um so we'll go in and take a deeper look at the development plan and so plans and a stack are going to be broken down by component this is a great way to sort of segment your changes your like changes together and we'll go ahead and expand out the eks component here and if you look here this diff here probably looks pretty similar

to what you're used to seeing today with terraform yeah I love the readability when things are organized by component I did notice a new label there which is like has deferred changes I'm looking here in case youall are wondering why I'm here can you say more about yeah definitely so one of the examples kubernetes namespace has some of those deferred changes and when we expand it out it lets us know that provider configuration is unknown and if you remember from earlier we looked at that kubernetes provider and we know it's sourcing some outputs from the eks cluster which is not stood up yet so it

makes sense why this um kubernetes Na Space is having some trouble planning right now so what terraform has done is it saved it for later with along with some of the other components and it was able to plan the eks and the VPC components so what it's letting us know is after the plan here is applied automatic follow-up plans are going to be processed for all of these deferred changes like the ones for our kubernetes Nam space and our Hashi Bank app and and so I think that the

development plan here actually looks like it's going to be pretty successful but maybe we'll just go take a look at disaster recovery and production just make sure nothing unexpected is happening we can use the next plan toggle here at the very bottom of the page to cycle between our plans so now we're in the disaster recovery plan here and it turns out Disaster Recovery is not very interesting it looks just like our development plan um so everything looks like it's going to be good there and we can move on to reviewing production and now this plan looks a little bit

different um if you remember from earlier the production deployment was using two regions so it was using Us East one and US West 2 and so what we're seeing here is a copy of each component for both of those regions but in general it looks like everything is going to be successful here so I think we're ready to move on to approving that development plan that sounds great wouldn't it be so convenient if we could just automate some of this for development at least

yeah we can definitely do that I'll go ahead and switch back to my editor here and we're in the deployments configuration again and I'm going to uncomment this orchestrate block here and so this is going to be what enables us to use those orchestration rules we talked about earlier the rule type I'm using here is auto approved so anytime the conditions met in the check block below are met for given deployments plan

it'll get Auto approved and so we can take a deeper look at the condition that I'm using here so I'm going to look at the plan context and make sure that there's nothing being removed um and then I'm also going to look at the plan and make sure that it's for the development deployment because we wouldn't want to Auto approve production or disaster recovery and so I'll go ahead and save and commit this and then we can see what happens um when the change comes into HTP terraform

all right so that new configuration is getting prepared for us just like we saw last time um so we'll get that a moment here okay so if we scroll on down at the bottom what we expect to see happening next is that the disaster recovery and the production deployments should both end up with another plan waiting for approval just like we saw earlier but for the development deployment because

we know it's full of additions and it's the development deployment it's going to meet the the checks that we outlined in that orchestration role so what we want to see is we want to see development get Auto approved and we want to see it start applying changes and so there we have it development is currently applying changes we'll give that a moment to complete but in the meantime what you're going to start seeing here is going to be a few of these check marks in the planning look icons um and that's because terraform is going through a

sequence of plans and applies because of those deferred changes but ultimately what we want to land on is a big green check mark letting us know that everything has finished planning and we've successfully set up our changes so we'll just give that another moment and there we have it and then the other thing that I think is kind of neat about this view is that we get this little rollout tracker so for configuration two we can go ahead and expand that and it's going to show us the progress of the roll out so one out

of three deployments have this change and you can imagine how at scale when you have a lot of deployments this will be quite useful for giving you an idea of how far your change is rolled out now we'll go ahead and click into that development deployment and come down to the bottom and so we noticed that there were three plans that got applied we'll start out talking about plan two so that was going to be the plan where we planned and applied the eks component and the VPC component then after that we followed up

with plan 2-2 which plan and applied all of those deferred changes we had like the um hashy Bank app and the namespace but then we ended up with a third one plan 2-3 and terraform is telling us it had no changes and so this is because every stack plan and apply sequence is going to complete with one of these convergence checks where there's going to be a final plan with no changes that's just making sure that we didn't miss any deferred changes and so that terraform resolved everything I'm

guessing that means the app is deployed at least in development let's go check it out I'm going to grab the URL out of the state here which I'll point out much nicer than reading a state file and there we go development is up and running we're ready to do some Banking and we can even move on to approving this change in disaster recovery and production amazing yay well that was a great demo I'll quickly summarize what we just saw we were able to deploy our hashib bank

application using a single stack configuration we were able to deploy it in three different environments using deployments terraform was able to plan changes over the single configuration defer changes when it did not have enough information and then replan until everything converged now there are several use cases where Stacks is a great way for organizations to build better and deliver faster one common pattern we see is the factory patterns when large

organizations have multiple account multiple application teams they need to vend out several cloud provider accounts that could be modeled so easily with our Stacks configuration format the other region I mean sorry the other use case is multi- region deployments um with multi-region deployments in our demo today we were using the for each meta argument for the provider to deploy the same workload in two regions but we could also model that out using deployments and stack is really flexible in a way that you can see things in a

way that Mak sense for you and then finally Beyond kubernetes there are several workloads like Nomad and console and Vault and console which cannot be deployed using a single terraform configuration today but Stacks is about to change that and finally bringing us to the end I want to share the three coets of stacks that make it so powerful for operational efficiency number one is scalability being able to spin up new regions easier tenant isolation all of this leads to improved productivity the new config structure empowers users to

rapidly create and modified repeated instances of their infrastructure and the new language constructs allow for the ability to codify business Logic for automated approvals and overall this reduces the need for manual reviews second is improved visibility with a single stack configuration you get a single pane of glass to easily identify and address issues and then finally the third is consolidation with the four changes we allow users to consolidate their configuration so that they no longer

need to break their infrastructure and split it up across different workspaces and then individually Target those workspaces all in all making changes based on events makes it so that you spend less time on coordination and more time on monitoring the roll out of your changes anything else you want to add yeah well there's really so much more to Stacks that we couldn't possibly fit in a quick 30 minute session like this although not for lack of trying we stuffed a lot of content in definitely go ahead and check out our documentation

and our tutorials for a lot more content and to get started with our public Beta And if you liked what you saw here today and you want to try it out yourself I've included a GitHub repository so definitely grab a picture of that um and you can go ahead and try out deploying hashy Bank on your own yeah we definitely try to jamine a lot we talked really fast but thank you so much for joining us in person today if you have any feedback or thoughts please find us at the booth today and tomorrow and and if you're watching this online share your feedback in the comments thank you

thank you [Music]