Enterprise DevOps & Cloud Infrastructure

Creating AWS Variable Sets

Erik Reinert

Erik Reinert

Enterprise DevOps & Cloud Infrastructure

Check out a free preview of the full Enterprise DevOps & Cloud Infrastructure course

The "Creating AWS Variable Sets" Lesson is part of the full, Enterprise DevOps & Cloud Infrastructure course featured in this preview video. Here's what you'd learn in this lesson:

Erik creates a variable set for the AWS network and cluster workspaces. This variable set provides the AWS credentials to Terraform Cloud so that any required networks and clusters can be created in AWS without the user needing to use the AWS UI.


Transcript from the "Creating AWS Variable Sets" Lesson

>> So we have this, but we don't wanna apply this yet. Why don't we want to apply this yet? What might be wrong with these workspaces once they're created?
>> Feel we haven't been told how to do anything with Amazon yet.
>> Right, we haven't given it any credentials or any of that yet.

So, before we do this, let's go back to our route, right? We'll go to settings, go to variable sets, and now we're gonna create a new variable set for Amazon, right? So we're gonna say, fem-eci-aws, now you won't be able to add it to any workspaces yet. So that's the caveat here, but that's okay, that's okay.

We'll add three new variables. The first one is gonna be AWS_ACCESS_KEY_ID, right? Where we need to get our access key. So let me go grab that really quickly from Doppler.
>> Environment variables?
>> Yep, make sure you add it as an environment variable, right? So there's my access key ID.

I've added that. So you can see that's there, right? So then I'm gonna go to add a variable again, environment variable. AWS_DEFAULT_REGION, us-west-2, this doesn't need to be sensitive. Now we'll add one more which does need to be sensitive which is our AWS_SECRET_ACCESS_KEY. I'll move this over really quick and set that the to Sensitive and add that variable.

So now you'll have three variables, AWS_ACCESS_KEY_ID, AWS_DEFAULT_REGION and AWS_SECRET_ACCESS_KEY. So we'll hit, Create variable set. And now we should again have three variable sets. One for tfe, one for github, and one for aws. You can see now how this works, right? All right, so now that we've got that, let's go back to our workspace.

See details. Confirm and apply. Now, it may automatically run the repos or it may not. It sometimes depends on just how TerraForm cloud is feeling. I don't really know what the differentiator is on when it wants to and when it doesn't. But you can see there's everything that got created instantly.

And of course, there we go. We can see that our plans are now being set up, but we know they're gonna fail, so let's just let them fail. We'll go to settings again. Go to variable sets AWS, and then we'll attach them to our AWS Projects or workspaces, sorry, apply to our AWS workspaces.

Now, there might be a question of, why don't you just add it to the whole project? You could, if you wanted to, it could make your life a little bit easier to where you don't have to do this all the time. But you may not want AWS credentials in your GitHub Automation, you know what I mean?

Just so just think about it, consider. So we're gonna hit Save Variable Set. And then if we go back to workspaces, we can see, in fact, it errored out, because we can't access anything, which is fine. So we will go to our AWS Network workspace first, which seems to still be trying to plan, and in fact, it did fail.

So, if I go to Variables really quick, look at that. That's the power of Terraform cloud and workspaces. So, you could see now if I wanted another network, new workspace, couple of variables, access keys, go out, right? So now I'm gonna go to runs, new run, start run.

And I'm actually gonna do the same thing, actually, no, let's just do it for network right now. So let's just do the plan for network. And again, I know we're moving fast, but I'll definitely catch you guys up here don't worry.
>> You didn't have a top level domain that will probably error out.

>> No, it's fine. It doesn't do anything with it. It doesn't have to be a real one, it just has to be one that is Parcelable and valid, right? So you can't just put in without a .com. [LAUGH] Awesome, look at that. All those resources. Slightly terrifying [LAUGH] but let's go ahead and confirm and apply.

>> Am I gonna be poor after this?
>> What's that?
>> [LAUGH]
>> None of them actually cost any money until they're used?
>> No, we're gonna start accumulating money now but don't worry you can delete it very quickly that's why we have workspaces. [LAUGH] But there's free tier for all of this.

So, yeah, you're just going into free tier stuff right now, yeah. So there you go it's gonna start creating the VPC that's the first place it's gonna start because that's what everything exists in, right, and then whoa look at that. Yeah. Isn't that just so satisfying? All the clicks you don't have to do, so nice.

And then this is really the price costs are right here. It's the NAT gateway, right? Because we have private networking, we have internal connections and things like that there needs to be a NAT gateway there something that can access the Internet still. So this is hands down the most expensive part of the whole cluster.

It's like $30 a month. But don't worry, like I said, it's very easy to delete these and just not have to worry about it so I'll show you that in a second. This does actually take a second. So while this is running does anyone have any questions
>> Any way to disable a workspace without saving all your settings without it being deployed live.

>> Saving all your settings without being deployed live. What would be your goal with that?
>> If I didn't want it incurring costs but wanted to maintain.
>> Just destroy it and recreate it.
>> Gotcha
>> Yeah, that would be my personal recommendation. Yeah, just destroy it and recreate it when you need.

So if you're like deving stuff, right? You just need to destroy them and create them in the same dependency structure, right? So if it's cluster sits on top of network, then you gotta delete cluster first, so then you can delete network safely. Otherwise it'll be, why are you trying to delete routes, man?

Cluster's still up. But yeah, this does take a second. NAT gateway and outbound traffic cost money though, yes it does. We're not gonna be doing any outbound traffic though, so it'll only be inbound
>> How do you typically map environment to workspace? Do you have workspace and then, three different clusters for dev stage QA or is it one workspace for each?

>> Honestly it's up to you. I know that I'm only gonna create one network for what I need right now. If I wanted another network then I would be, network omething, you know what I mean? Just like we did with cluster prod. But I'm kind of doing a few opinionation here.

I'm first saying, okay, I know I wanna create a network and I know I wanna reuse that network. So I'm not really worried about creating a bunch of other networks right now. However, I do know that I might need a another cluster in the future, right? And so that's where that can be helpful, although I am noticing that is maybe not set properly.

Let's take a quick look here cuz that should actually have prod at the end of it. So let's do this. Let's go back to our TFE code real quick. It check out me Pull, so let's not apply that yet cuz there might be something going on here, so let's take a look.

So there is no prod there, but that's okay. We'll worry about it later. Don't worry, that's a spoiler for later. Yeah, go ahead.
>> You utilize open source modules or re-implement them from scratch so you have more control and quality. Let's say you notice that some features are not supported by modules-

>> Yeah.
>> Or done wrong.
>> Yeah, we do. Yeah, it's a mixture of modules and resources. It's just really depends on what fits your needs best, yeah.
>> We see many infrastructure projects which use Terraform and have the folder per environment and resource in a single repository from which Terraform is run.

Are there any pros and cons to this setup? Or how would you approach changing this at an organization and possibly migrating gradually from it?
>> So, I think for me, it's all about the design of the expectations, right? If it's just modules, then it's easy, or if it's just repositories, it's just easy to understand repo, go to the network repo, go to this repo, go to that repo.

If you start merging things together, just in general. It's gonna become more confusing, right? It's gonna, okay, where is it inside of what now, right? At Hippo we do have Ms in folders actually. We do that, but not everywhere, only in certain spaces where we want to. Another thing that makes it a little bit more challenging is you actually have to tell TerraForm which branch to track in the repo.

And there's been times before this is a massive con where I've had a developer go into TerraForm and actually change the branch it's pointed to. And then start working off of their own branch. And then I'm like, what are you doing? That's the main branch, what are you talking about?

So for me, I really don't prefer branching. If you wanted to get out of the branching scenario you would just start creating repos. And then for every branch create a new repo and then tell a workspace to point to that repo instead of that specific path in the branch.

The nice thing about all of this, if you have two repos that have the exact same data, and you run them, Terraform can't tell the difference, [LAUGH] right? Because it's just automation underneath the hood. So you can move it all the way to a completely new repo, and then just go in and change the VCS and what you pointed to, and it's in a whole new location as long as the code is the same.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now