Get ready to scale - Terraform Tutorial

Now that we've covered the basics of working with Terraform, we can get our code ready to scale. We'll want our blog server to have multiple instances and to scale those instances in response to load. But we should also set up multiple environments so that changes can be tested before they reach customers. First, we'll start by setting up our environment in a new VPC. So we'll go to the Terraform registry. That's just registry.terraform.io. And we'll search for VPC. And we want this module down here, Terraform AWS modules slash VPC. If we scroll down a little bit, there's an example right here that we can actually just copy and paste. So I'll just click the copy button. And then we can go over to our repository on GitHub, and we'll go down to main, and then click the little pencil icon here. Click the drop down and go to github.dev. Now let me rearrange things a little bit to make this easier to see. I want to scroll down and find a good place to paste this. I think right below the default VPC is probably a good place. So we'll just paste that in. Let's start by giving this a custom name. So, to follow the pattern we've been using, we'll just call this blog underscore VPC. We can keep the source the same. For the name field, since this is the name that will show up in AWS, let's actually call this dev. We can keep this site or range the same. The AZs here are the availability zones. and you'll wanna change this to match whatever region you're using. In my case, this was US West 2. So I'll just say US West 2 A, B, and C. We can keep these private and public subnets the same. We'll leave enable NAT gateway set to true, but we don't need the VPN gateway, so let's just delete that line. For tags, let's keep Terraform equals true, but it makes it easy to spot that this was created by Terraform. And we can just keep environment equals dev. So now that we have all of that in there, let's go up and just delete this default VPC. That won't actually delete the VPC, it just means Terraform won't know about it anymore. Now, let's scroll down and make a couple of changes to start using this new VPC in our existing code. Now, we'll need to tell our blog instance how to use this VPC, and so the way we'll do that is actually by adding a subnet ID. We'll just say subnet ID equals, and then module.BlogVPC.PublicSubnets. Here you can see auto-complete has come up with that, so I can just hit tab. Then we'll actually need to specify which of the public subnets we want, and so we'll just use brackets and say zero for the first one. Then we'll also need to update our security group at the bottom here. We just need to change vpcid equals module.blogVPC, and here I can just hit tab, and then we'll say .vpcid. That should be all the changes we need here. That should be all the changes we need to make. Let me just close this file and click on the source control button on the left menu here. And we'll need to give a name for this set of changes. Let me close this. So for this, we will just say, create a new dev VPC. And you can see there's an alert here that these changes will be committed directly to the main branch. I'm just gonna say, don't show again. Now, normally you would wanna commit these to another branch and merge in, depending on your workflow, but we're just working directly in main here just to keep things simple. So we can see we've got those changes that we just added, and we can say commit and push. Now that those changes are committed and pushed, we can go over to Terraform Cloud, and I'll just click to overview. Let me just reload the page. So now we can see our commit has made its way into Terraform Cloud. Let's just click in and watch that plan run. And this change will actually recreate almost everything we already have deployed. So let's look at the plan that it's created. And we can see it's recreating almost everything that we already have deployed. That's because it's creating a totally new VPC. And so it has to create new instances in order to use that new VPC. So when you're ready, feel free to review this, but it should be fairly straightforward. It looks like a lot, but actually it's just because it's needing to recreate everything. When you're ready to go, just click confirm and apply, and you can leave a comment here or not. And now that should trigger another apply run, which we can watch happen right here. If you run into any errors, double check your code against the solution branch and rerun Terraform. Even if you didn't have any bugs in your code, Terraform can sometimes have an error on the first run when you make big changes like this, because the resources can be created out of order. This can be avoided by careful use of resource ordering meta parameters, which can be worth it in a customer facing production environment, but often it's cleaner to just run Terraform twice rather than cluttering up the code for a one-time change. So if your first run fails, try running Terraform again before checking the code too thoroughly. And it looks like we're just waiting on the original blog instance to be deleted. Let's see what else is going on. It looks like everything else worked successfully. This may take several minutes, so don't assume that it's failed if it just takes a little while. You can see in my case, this took about four minutes to complete. So once this is complete and you've confirmed that everything is looking green here, or if you've had to rerun it and then confirm that it's working, you can move on to the next lesson.