Network Variables & Outputs

[00:00:00]
>> Erik Reinert: The next thing we're going to add is a Variables, variables TF file. Again, just like before, we now have the opportunity to describe how we want this network to be customizable. Now, the bastion ingress, you'll notice, is there. Again, this is one of the things about Terraform which is slightly cumbersome.

[00:00:25]
I don't want to call it annoying because I understand why. But if you have a variable that's four modules higher, you will have to put that variable in every module that it gets passed through. So we created a variable for bastion ingress in the environment. Well, we also need to create a variable for the bastion ingress in the network because the environment passes the variable to the network.

[00:00:49]
If you think of it in kind of like react terms, these are our component props. So we want to make it so that we can pass down those props to all of the modules inside of the modules. That's right. I know some react stuff, but yeah, in this case that means that by the time this module gets loaded, we've passed the bastion ingress from the root module through the environment and now down to the actual network so that it can be used again.

[00:01:20]
These layers make it so that all the way up here I, I can make one little tweak and then down here it will get updated and again going back to the whole Legos or even building, that's what you want. You wanna make one tiny change and then see it propagate across a larger scale.

[00:01:38]
But some of the other stuff is a little bit more specific, availability zones. A big reason why we have Availability zones is up there is honestly just like maybe you don't wanna provision in all three AZs. Maybe, maybe you don't wanna, maybe you don't need five availability zones.

[00:01:53]
The reality of it is, is who here knows what it would take for an Availability Zone to go down, by the way? So a fun thing about azs, Amazon has built these things like end of the world scenario, surviving. The only real way most of the time an entire Availability Zone would go down is if they call it like an act of God.

[00:02:17]
It's pretty crazy. But Amazon does have like act of God redundancy, it's insane. So unless like it's a massive earthquake or, you know, I don't know, the, I don't know, the head to the network like just somehow gets completely severed. You normally don't need like 5 AZs. That's a little overkill.

[00:02:37]
And to be honest with you, you're probably spending way more money than you need to on availability. For example, even where I work, we only really use 2 AZS, 1 and then 1 for failover 3. Failover means that three parts of the country have gone down, which is kind of a lot.

[00:02:57]
Two is normally good enough, but if you find yourself in a scenario where you're at a company, this is the reason why we have this. Say you're at a company where you provisioned with 2 AZS 6 months a year later you go, okay, we actually do want three.

[00:03:12]
It is incredibly difficult if you don't have this as a setting to then go in and add that additional az, because then it has to calculate those new subnet spaces. It's got to create all the resources around it. It's a lot of work. So this is another future proofing thing where it's like, well, if in the future we want to add another az, we want to make the code dynamic enough to where I can just add it as a value.

[00:03:38]
Again, it doesn't really look like it here because we're not at that scale, but when you have 10,000 instances in one AZ and you need to replicate all of that over to another availability zone, the ability to just add a value and then see all of those instantly move over is a lot nicer than going to each one of them and be like, okay, AZ3 AZ3 AZ3 over and over and over.

[00:04:03]
So again, this is the kind of future proofing that we're talking about s little bit. Cidr. Pretty straightforward. Again, this is the address space of the actual network that we want and then the name of the network as well, which for now, the name of the network will be the environment itself.

[00:04:20]
So that means that if it's dev, the VPC will be called dev. We're going to make an outputs TF file. And can anyone guess what outputs are? We said we have variables, but what would you think an output is? Something that can get reused from other. Exactly. Yep, exactly.

[00:04:52]
Yeah. So if you group together a whole bunch of Terraform resources together in a module, you do obscure away all of the values that come out of those resources. How do you access it? If it's in a module, how do you access the VPC id? Well, Terraform provides you the ability to use outputs in modules to then say, okay, well if there is a security group that you want or subnets or VPC ID or name or whatever, it will provide it so that you can then use this as outputs, or you can use these as values in other resources or modules.

[00:05:31]
So what this is saying Is that we're going to create a network, it's going to be highly customizable. But at the same time, we wanted to export values that we can use for creating our database or creating our clusters or whatever else. And we don't have to recalculate or re look up these values.

[00:05:48]
They're already there. We can just reuse them in our code. So outputs are only local, to be clear. Meaning that this wouldn't mean that I could use this in a completely different repo. Outputs are variables, basically. So you'd only be able to use it in the local repo.

[00:06:05]
Yeah, how do you think about sequencing resource creation if you need certain outputs or something? Is that a concern? No. Yeah, it's a great question. So Terraform does what's called a directed acyclical graph. And the idea is that it will take all of your resources and then using a top sort algorithm will say, okay, what's the lowest level resource that nothing needs?

[00:06:30]
And it slowly builds out everything from there. So thank goodness you don't have to think about that. However, there are times where Terraform isn't smart enough. Maybe you have a resource that needed to be created, but it doesn't have a direct link to the thing that it depends on, which is very common.

[00:06:50]
Terraform does also provide you a depends on option. Really quickly. I'll show you. What you can do is if it doesn't or it's not able to do that, I can be like this dependson and then I can tell it like module vpc and then it will wait until that's created to then create this.

[00:07:09]
So by default it should take care of everything, but if it doesn't, you have the ability to add that manually if you need to. And sometimes you do. It's nice when it calculates everything automatically, but sometimes it's just again, your infrastructure becomes huge. You've got thousands of resources.

[00:07:27]
It's hard to always propagate that appropriately.