Enterprise DevOps & Cloud Infrastructure

Adding AWS Repos to Workspace

Erik Reinert

Erik Reinert

Enterprise DevOps & Cloud Infrastructure

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

The "Adding AWS Repos to Workspace" 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 adds the AWS repos to the Terraform Cloud workspaces. The changes cannot be applied yet because the AWS credentials are not added to the workspace.


Transcript from the "Adding AWS Repos to Workspace" Lesson

>> So now what do we have? Well, we have an automation repo for an aws-network, and we have an automation repo for an aws-cluster. So here again is one of the great parts about automation. Once you create your automation repos, you can essentially deploy them, right? Now, there's a couple of things we know, which is we know we need workspaces.

We know we need to connect it to VCS, and we also know at some point we have to configure these things, right? So we gotta do all three of these. We gotta create repos, we got to connect them to VCS, and then we have to add the environment variables and all the other variables we need so that it can run properly.

Cuz right now, if it tried connecting to Amazon, do you think it would work?
>> Probably not.
>> Probably not, yeah, because we don't have any of that, yeah. So what we're gonna do, is we're gonna go back into our main tfe repo. Make sure to pull in so you got your latest changes, and then git checkout- b.

And this one we're gonna call feature/add-resources or addworkspaces, we'll call it addworkspaces. So feature/addworkspaces, okay, so now we're on a new branch. What file do you think I would go into?
>> Locals.
>> Locals, exactly, yep. Now, I'm gonna copy and paste some code here, but remember, always reference the branch in the repo if you need.

All right, so you can go to the FEM1, this is cluster, let me go to the Terraform one, yeah, tfe and if we go to 5 we should be able to go to locals, and if we keep scrolling, look at this. Whoa, wait a minute, variables? What do you mean variables?

This is another great part about Terraform. We don't need to add variables anywhere else because Terraform Cloud can store variables. So what this means is all you have to do is create a repository for your automation and then deploy it to a workspace, and that's exactly what we're gonna do.

So I'm gonna copy this workspace, the ECI AWS network workspace and then I'm gonna copy the cluster workspace as well. There's two of them there, ECI cluster, an ECI AWS network, okay? And remember, this is in the terraform-tfe repo under the fifth branch, yes.
>> I do you notice the second one is titled cluster prod?

>> Yep, as we said before, the cluster has to be an environment. And we've also said that we can't have the same name for the same resource twice, so we have to put a unique separator there, which in this case is the environment. So I'm gonna paste all of that in.

I'm gonna just double check everything, make sure it all looks good. So remote, look at this already set to remote, bam, out of the box, right? Because there's nothing needed, it knows the automation that it needs to look at, and it's just gonna run it. Now, the important change or difference is this part right here, we haven't introduced this yet, right?

This is what makes it so that you can programmatically configure your workspaces without having to go into the UI. This also makes it so that if you wanna rename a network or anything else, you actually go here. There's no need for a workspace for the specific repo and one to one and all that stuff because we're gonna make a lot of networks potentially in the future right?

So what we're really trying to do is is we're trying to make a multi use repo, and then just attach workspaces to it with different variables, right? And that'll make it so that we have different networks, okay? So in this case we have our variables array and then inside of it we have a terraform value, so it says category terraform.

Remember how we had environment variables and terraform variables? This is how you differentiate those two, if I wanted to have an environment variables, I would just say M or environment, one or two, I don't remember. HCL is important in circumstances like this. When you have like an array, or an object, or a map, or something like that, that requires parsing, you actually have to tell it that it's an HCL or HCL value.

That's because you can also do not, you just do basic strings and stuff like that. So if you're doing in a scenario where you're like I wanna pass an array to my workspace then I want to do that through Terraform cloud you would then make sure that it's an HCL variable that you're using.

You'll notice that on the second one though, I don't have that I just have category key and value, right? That's because these ones, these aren't HCL values and remember I told you before there's a way to where you can actually make it so that there are like the same defaults.

So you don't always have to add these values. So to make that work, there is one other change we need to do, which is we need to go to the main.tf file. And if you scroll down, we'll see that we now have a try and a variable is being added to our workspace.

See that? So I'm gonna go to main, And then I'm gonna paste in my variables. Now this try is a nice little function that Terraform provides. Which will make it so that if this is not even populated, it will return with an array at least, so it doesn't break anything, right?

So that's why we put the try there. We don't have to put tries for anything else, because technically those variables are being passed to the variables module. So that module then must have tries inside of it to know for the circumstances of when we are using the HCl value or not and stuff like that so that's very helpful for us, right?

So that's the network and on top of it that's also us make making sure that the workspace is wired in the way that we need, okay? So let's go back to this really quickly and let's look at the cluster. Because again, like you said, there was a couple interesting things about this workspace compared to the other ones.

For starters, it's got an environment attached to it, right? Well, the reason for this is because if I did this and then I tried to create multiple clusters, would it work? Nope, we'd have a conflict, so there still is a bit of work that you have to do here.

Now I'm gonna show you a little later how we can even save ourselves more time, but I think you might even start seeing how that's possible, right, with our for loops and stuff like that. I showed you it with AZs and subnets, right, all that kind of stuff, it's the same paradigm here.

Now, if we go to the cluster, you'll see that cluster also has variables, right? And one of them is our don't look at that, it's the variables that was in our repository. So let's take a quick step back one more time and look at our chart, all right?

So we've got TerraForm cloud and then we've got our workspaces down here, right? You mustn't forget that this guy is gonna go back, so that it can come back down and change other things And we said in the network module that we wanna make this customizable, right? We can, in Terraform TFV, it does not just become something that manages workspaces, but it's also the source of truth for pretty much most of your configuration of your infrastructure, right?

These repositories are meant to be dynamic. They're meant to be plug and play where I could give you it and you could run it just like like we're doing right now. The only thing that makes them unique to you is the variables that you pass to the workspace, right?

So in this circumstance what I'm gonna do is I'm gonna give myself a domain, so I'm gonna say, okay, well I own the domain altofor.dev. So that's what my cluster is gonna point to, right? Anything on this domain when we set it up for a service, it will then be something like service.altifordev.

We have ingress routing out of the box. Let me say that one more time for you guys, we have ingress routing out of the box, this is very difficult and annoying to do, right? But when you can think about like okay, the cluster needs this, it needs that, it needs this, it needs that, it's just really easy to reproduce these environments, right?

So we know that our environment is prod, right? And then the other thing you'll see here is is it wants me to actually name the cluster. So I'm gonna put my name in here, so I'm just gonna say E-Reinert. I recommend you guys doing the same, and to be honest, they need to be unique because for this course, it's just to make sure that you don't run over anything.

So just give it your name, first initial, last name, and then the last thing we're gonna do is, is we're gonna create a VPC name variable that points to our F-E-M-E-C-I-V-P-C. Well, where is that? You might ask, do you see it? What line is it on? What line is that workspace referencing?

>> WPC name four, three lines above
>> The network name, yeah, so the network name here, right, is now being used as the VPC name for the cluster here. See how those legos connect? This is why we create our own modules and create our own opinions around variables.

Because if you try and just use resources every time, you're just gonna constantly fall into problems, because they are so generalized. That it's better for you to make opinions around them and then keep making those opinions on your own. Instead of saying like I'm just gonna always keep using the same resources and just juggling all this stuff, make it easier on yourself, wrap them in a module.

Give it some inputs give it some outputs and then make it a workspace make it composable, right, that's the goal here, high composability, that's really what we want, right? Do we need the domain to be a route? No, to be honest the domain does nothing here [LAUGH] It's not actually attached to anything.

It's just so that we can have a domain value there to use, so it just has to be a valid top level domain. So now that I've explained to you guys, why we're doing what we're doing, right, let's provision some infrastructure [LAUGH]. So we're gonna do init really quick, just to make sure, I'm sorry, not init my about validate, validate, do validate, cool.

So the validate looks good, awesome, so now let's commit. So let's do, Yeah, git add. What were the files? Sorry, git status, git add, locals, and main, git status git commit-m added resource or added, we'll say added workspaces and then we'll push. Create a PR, again, you can navigate to the repo if you want.

Now, it's funny [LAUGH] is you're like five repos in, and this is your first PR to Terraform tfe. [LAUGH] So that gives you an idea of how much is required to set up before you can actually get into this approval process. But if we look here, okay, cool here's all my changes let's go to my up that's good that's a good sign.

So let's look here, let's take a look at the plan, wow, look at this automation, man, so nice. So because we're using the module underneath to create workspaces, it has other automation inside of it. So it knows, hey, I'll make this variable for you called azs, we'll go ahead and populate that for you.

We'll do the same thing for cidr, we'll do the same thing for name, right? And then the cluster gets to the exact same thing, variable set, environment, name, BPC name, right? Cool, okay, so this looks good, let's go back to our PR and we're just gonna confirm and squash.

So now that we've merged our first PR to terraform tfe, let's see what happens.
>> So it only does the plan on a branch, but it doesn't let you commit.
>> Branches are just for tests, merging to main will let you actually apply it, yeah.

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