Deploy Terraform Templates with GitHub Actions

0:11Hi, guys.

0:12My name is Trevor Sullivan.

0:13And welcome to another CBT nugget skill.

0:16In this skill, we are going to be exploring

0:18how to integrate a few different popular technologies

0:21in the DevOps ecosystem.

0:23Now, one of those tools that we're

0:25going to predominantly be focusing on in this bill

0:28is GitHub Actions here.

0:30And GitHub Actions is a managed workflow engine

0:33that allows you to perform really any type of automation

0:37task that you might want to.

0:39Now, most people, when they hear of GitHub Actions,

0:41are probably going to think of continuous builds,

0:44continuous integration testing, continuous deployment.

0:47And we're going to be focusing kind

0:49of more on the continuous deployment side of things here.

0:53So our objective here is for our little development team right

0:57down here to basically be able to push infrastructure code

1:01changes up to GitHub Actions, or up to, I should say,

1:05a GitHub repository.

1:06Not specifically actions, of course.

1:08But basically, write code locally.

1:11Use Git as a local tool on your dev system

1:14to basically commit changes.

1:15And then push those changes up into a GitHub repository.

1:18And then once those changes have been pushed,

1:21the GitHub actions service, which is the workflow engine

1:24and automation engine, basically will pick up

1:27on those code changes in the Git repository

1:30and then will publish those to the Amazon Web Services cloud

1:34platform.

1:35Now, Amazon Web Services has a declarative configuration

1:39management service, known as AWS CloudFormation.

1:42And CloudFormation basically, it's

1:45a managed service that allows you to take

1:47a template of resources.

1:49And then you can basically create

1:51what's known as a stack of resources

1:53and push that up to CloudFormation

1:55to create a stack.

1:56And then the CloudFormation service

1:58basically behind the scenes will go ahead and provision

2:02and make any configuration changes

2:04to cloud resources that were requested inside

2:07of that template file.

2:10Now, what's unique about the CloudFormation service

2:13in AWS is that CloudFormation actually manages the back end

2:18state for you.

2:19And state management, when you're

2:21talking about declarative resource

2:23provisioning and management, is very important.

2:27And so essentially, any time that you

2:29create a resource in your cloud vendor,

2:32such as Amazon Web Services, take a EC2 instance

2:36for example, which is essentially

2:37just a virtual machine.

2:38That EC2 instance, let me just kind of

2:41find a little EC2 logo right here and bring that in.

2:46So how about this guy right here.

2:48And so once you provision EC2 instance or virtual machine

2:52into your AWS account, that EC2 instance

2:55will automatically be assigned a unique identifier, also known

2:59as the instance ID.

3:01And any types of management tasks

3:04or API calls against that particular EC2 instance

3:08are going to require that you manage it by using the instance

3:12ID as an input parameter.

3:14So if you want to delete the EC2 instance,

3:17if you want to stop or start the EC2 instance,

3:21or make any configuration changes,

3:23like resizing that EC2 instance to a different instance type

3:26with a different number of virtual CPUs

3:29and the memory assigned to it, then any of those changes

3:33would have to pass in the instance ID

3:35that you are wanting to affect.

3:38Now, the Terraform utility here that we are looking at

3:41is very similar in some sense to a CloudFormation in the sense

3:46that it allows you to deploy resources up

3:50to Amazon Web Services.

3:51However, what's different about Terraform

3:53is that it doesn't handle the state management for you.

3:56So when Terraform provisions the EC2 instance

4:00in this particular example.

4:02Whereas Cloud formation will record that unique instance ID

4:05and keep track of it over time, the Terraform utility

4:09doesn't inherently do that for you.

4:11I mean, it does technically, but it actually stores that state

4:15as a separate file that you as a developer or a DevOps engineer

4:20are ultimately responsible for managing.

4:22And they call that the Terraform state file.

4:25So any time that you deploy a Terraform template out

4:29to your cloud vendor, like AWS, then that

4:32is going to generate a state file to your Terraform state.

4:36And then you're going to have to maintain that file in order

4:39to maintain continuity in managing

4:42your stack of resources.

4:44So the nice thing about CloudFormation is that it takes

4:47care of that state management aspect for you,

4:49whereas Terraform doesn't.

4:51However, it does give you a lot more flexibility.

4:55One of the disadvantages of using CloudFormation,

4:58which is native to AWS, is that it is a proprietary service

5:02within the ecosystem.

5:05So there are some hacky ways that you

5:07could use CloudFormation to deploy technically

5:09to other cloud vendors.

5:10But all things considered, the AWS CloudFormation

5:13is really designed to deploy AWS cloud resources.

5:17Whereas Terraform is actually a cloud agnostic tool.

5:21So you can use Terraform to deploy resources

5:24to a variety of different services.

5:27AWS just happens to be one of those.

5:29But it also supports things like Google Cloud and Microsoft

5:32Azure, as well as several other providers out there.

5:36So it's kind of got a plug-in based model,

5:38where Terraform can support a number of different cloud

5:42providers.

5:43So we're going to be doing in this case is actually

5:46using the GitHub action service right over here

5:49to trigger a deployment of a Terraform template.

5:54And that Terraform utility is actually

5:56going to run within the context of GitHub actions.

6:00But we'll call out to the Terraform CLI utility

6:02and deploy a template that is sourced from the GitHub

6:06repository here and executed through GitHub Actions.

6:09So any time that our dev team is going to make an infrastructure

6:13change to the Terraform template file,

6:16those changes will automatically be picked up

6:18on by the GitHub action service.

6:21It'll trigger the Terraform deployment utility.

6:24And then it will publish those changes out to AWS.

6:29Now, the other thing that we're going

6:30to have to do as well, as any time we're dealing with GitHub

6:33actions here, is we're going to have

6:34to set up cloud credentials in order

6:37to ensure that Terraform has the necessary AWS credentials

6:42and permissions to publish changes and deploy

6:46and manage resources in our account.

6:48And to do that, we're going to be using AWS

6:52identity and access management.

6:54Let me just draw a little bit of a line right over there.

6:57So AWS IAM is going to provide the access credentials

7:01for our Terraform utility, which is, again,

7:05running inside the context of the GitHub Action service

7:08to deploy those changes out to our AWS account.

7:11So there's a few moving parts here,

7:13but we're going to build this solution step by step here.

7:16And we're going to start by just kind of setting up

7:19our connection between GitHub Actions and AWS.

7:21Then we will go ahead and add in a Terraform template file.

7:26We'll set up a GitHub actions workflow

7:28that actually invokes Terraform, runs the Terraform plan

7:31command.

7:32And then followed by a Terraform apply command

7:35to actually apply those changes to the AWS account.

7:38So why don't we jump into the next video

7:40and actually start building out this solution.

7:42I hope this has been informative for you,

7:44and I'd like to thank you for viewing.

0:11Hey, guys, and welcome back.

0:12So in this video, what we're going

0:14to do is start out by setting up our integration between GitHub

0:18actions and the AWS Identity and Access Management service

0:22to ensure that the GitHub actions' runner, which

0:25is essentially just a virtual machine that is executing

0:28our GitHub actions workflows, has the necessary access

0:32to publish and manage--

0:33provision and manage resources in our AWS account.

0:37So let's jump into our AWS Management

0:40over here, for starters, and we'll navigate down

0:43to the IAM service.

0:46And the first thing that we're going to want to do

0:48is to set up our identity provider here.

0:51And this is basically making AWS IAM

0:55aware of our GitHub repository, that we want to use GitHub

1:00as a source to trigger different actions inside of our account.

1:04And there is some good documentation

1:06on GitHub around setting up OpenID Connect,

1:11and that document is called "Configuring OpenID Connect

1:14in Amazon Web Services."

1:15And so I actually have some separate training here

1:18at CBT Nuggets that focuses on this as well.

1:20So we're going to speed through this a little bit.

1:23So if you get lost, go ahead and watch my other skill that

1:26talks about connecting GitHub actions to AWS,

1:30and it'll talk about your different authentication

1:32options here.

1:33So for starters, we're just going

1:34to go ahead and create this identity provider, which

1:37I already have here.

1:37And then once that identity provider has been created,

1:41I'm going to go ahead and create a role.

1:43And a role in AWS is essentially an application identity

1:46that doesn't have any static credentials associated with it.

1:50In fact, you dynamically obtain credentials from the service

1:55when you need them.

1:56And so that is actually a more secure option

1:58than storing any static credentials.

2:00And then I'm going to choose web identity over here

2:03because we're going to be using our GitHub identity

2:06provider in order to obtain credentials for this role.

2:11And then on the Permissions section

2:13here, we need to make sure that we

2:14provide Terraform any permissions

2:17to manage our account.

2:19And for starters, I'm just going to go ahead and give it

2:21to VPCFullAccess so that we can manage different VPC resources

2:25inside of our account.

2:26But if you are going to provision

2:27any other types of resources, maybe EC2

2:30instances or virtual machines, you

2:32might want to attach EC2FullAccess there as well.

2:35I'll go ahead and actually just check that off.

2:37And then we'll go ahead and create this role.

2:40I'll call this github-actions-terraform2 and

2:46hit Create Role.

2:48And then once this role has been created,

2:50one of the typical things you need

2:51to do when you're setting up OpenID Connect

2:53is to edit the trust relationship on the role.

2:58And we will basically need to add in a condition here

3:01to ensure that our GitHub repository has

3:03access to obtain credentials using this role identity.

3:08So to do that, we're actually going

3:10to need to go and create a new repository.

3:13So I'm going to go into my GitHub organization which is

3:16github.com/cbttrevor.

3:19There's two T's in there, cbttrevor.

3:21And then I'm going to click on New.

3:24And we'll give our GitHub repository a name,

3:26like github-workflow-terraform, and we'll

3:32go ahead and make that a public repository and click on Create.

3:37So this will give us an empty repository to work with.

3:40And I am going to go ahead and just create a file here.

3:45I'm just going to call this asdf so that I

3:47have an empty file in here.

3:49And it's kind of weird, but if you

3:51don't have any files in your repository,

3:53you can't use this Codespaces feature.

3:55So I am actually going to go ahead and provision a codespace

3:59so that I have a nice browser-based editing

4:01environment in order to author the different files,

4:05like the workflow files as well as the terraform

4:08files and things like that.

4:10So let's give this codespace a second to build,

4:13and then it'll launch me into my VS Code environment right here

4:16and I can start working inside of my browser

4:19here without having to install VS Code.

4:21So this is a really nice feature.

4:22If you haven't tried out GitHub Codespaces,

4:25then I would definitely encourage you to check it out.

4:28But in any case, now that we have a GitHub repository

4:31created, we now need to basically

4:34take our organization, cbttrevor,

4:37and our repository name right here

4:40and plug that into this condition.

4:43And right here in this Configuring OpenID Connect,

4:46there is a condition right here that we're going

4:48to copy over into our role.

4:52I'm going to go ahead and come into Condition, StringEquals

4:55and then just replace the octo-org with my org,

4:58cbttrevor, and then go ahead and replace

5:00octo-repo with my repository name right here.

5:06I'll paste that in and fix the formatting.

5:08And then the branch here, I'm going to replace octo-branch

5:11with just the main branch because that's just

5:13the only branch we're going to be dealing with here.

5:15And let me just make sure there's

5:16no extra space in there.

5:17Yeah.

5:17So it's just line-wrapping there a little bit.

5:19So nothing to worry about there.

5:21So we'll hit Update Trust Policy,

5:23and now our GitHub repository will have access

5:27to use this role identity.

5:30Cool.

5:30So let's go ahead and start out by configuring

5:34a base workflow that is just going

5:37to set up our AWS credentials.

5:39And to do that, if we go to the Actions Marketplace--

5:44let's head over to the GitHub Actions Marketplace here--

5:47and search for AWS Credentials, and there

5:51is an action here called Configure AWS Credentials

5:54that's going to allow us to retrieve our session

5:56credentials using that IAM role, we basically

6:00just need to specify the role to assume

6:02and then plug-in the ARN to our role.

6:06I'm going to come into my Codespaces editor here

6:08and create a .github directory and then a workflows directory,

6:13and this is a special directory path where GitHub is going

6:16to search for workflow files.

6:18And then I'm going to create a new file called

6:21terraform-deploy.yml.

6:24And inside of this file, we are going to plug-in our On section

6:29so that we can trigger this.

6:31And we'll say workflow_dispatch manual triggers,

6:34and then we'll also do a push event as well.

6:37Every time we push code changes, it

6:38will automatically pick up on those

6:41and then attempt to run our workflow.

6:44And then down here, I'm going to go ahead and do jobs and set up

6:47a job called terraform-deploy.

6:50And we'll say runs-on ubuntu-latest.

6:55And for our steps here, I'm going

6:59to go ahead and add in the first step, which is

7:02to configure AWS credentials.

7:05And so let's go ahead and just give this a name,

7:08and I'll just say name, Configure AWS Credentials.

7:14All right, so what we need to do now

7:16is add in our "with" section here

7:18because we do need to specify the role that we

7:21are going to assume.

7:22So under the "with" property right here--

7:24I'm referring back to the documentation

7:26here on the GitHub Actions Marketplace--

7:28I'm going to plug-in role-to-assume in our file

7:31here, and I need to grab the ARN, or Amazon Resource Name,

7:35of this role.

7:35So I'll copy that to my clipboard and paste it in.

7:38And then the other thing we can do here

7:40is set our default AWS region.

7:42I'll just do a aws-region and set it to us-west-2

7:46but feel free to use whichever region

7:48is appropriate for your particular use case.

7:50If you're in a different part of the world

7:52and you want to get better performance,

7:53just find a region that's close to you.

7:56All right, so let's go ahead and save this file,

7:59and then we'll go ahead and commit and push this

8:04to our repository.

8:06So we'll say "Adding workflow file"

8:09then do sync changes to push that up to our Git repository.

8:14And then we'll go over to Actions here,

8:16and we should see it attempt to trigger.

8:19Now, there is one other thing that I need to do as well,

8:22and that is going to be to set the id-token permission

8:27to write.

8:28Otherwise, we won't be able to obtain our credentials.

8:31So, sure enough, you can see that it failed right here.

8:34And it says "Credentials could not

8:35be loaded, please check your inputs,"

8:37and that's because we actually need to add in this permission

8:40to the GitHub workflow.

8:42So permissions, id-token is write, save that,

8:46and re-commit this and say "Add write permission for token."

8:53And then we'll do sync changes once more,

8:56and then we should have another invocation of our action here.

9:01And basically it's going to run really fast

9:03because the only thing it's doing

9:04is going out and obtaining credentials.

9:06Let's give this a second to run here and just

9:08make sure that our credentials are retrieved correctly.

9:12And this time, sure enough, it works.

9:14So if you're missing that permission, go ahead and just

9:17add that into your workflow file here,

9:19and you should be good to go.

9:21All right, so now that we have set up our role in IAM

9:25and we've also set up our basic structure for our GitHub

9:28workflow here, the next thing that we need to do

9:30is go ahead and add a Terraform template file into our project

9:34here.

9:35I hope this has been informative for you,

9:37and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:11Hey, guys, and welcome back.

0:13So in the last video, we did the basic kind of infrastructure

0:16set up to get GitHub actions connected over

0:19to Amazon Web Services using the OpenID Connect method, which

0:23I do generally prefer, although you can, of course, generate

0:26static credentials with an IAM user instead of an IAM role

0:30if you would prefer to do that, and then store

0:32those values as secrets.

0:34That's certainly an option that you have.

0:36But what we need to do now is come into our repository,

0:40and add in a Terraform state file--

0:43sorry, not a state file, but a Terraform template file.

0:46So I'm going to head over to the Terraform docs.

0:49I'm just going to search for Terraform docs,

0:51and head over to the home page if I can click on the link

0:54without Google moving elements around on me.

0:57And basically the first thing that we

0:59need to do in Terraform here is take a look

1:02at the configuration language.

1:03And there are a few different providers.

1:06And a provider is basically defining a cloud service

1:10that we want to publish to.

1:12And so there is an AWS provider.

1:15Actually, I'm just going to head over to the registry, here

1:19the Terraform registry.

1:21And if we search for AWS the provider,

1:25click on a provider's right here, and then drill

1:27into the AWS provider, it will show us

1:31how we can use the AWS provider to interact with the service.

1:37So this is a module here.

1:41Trying to look for where the actual provider itself is.

1:46So let's drill into AWS again here.

1:49And I'm actually going to click on the Terraform provider

1:54right here.

1:56And this will take me over to GitHub here,

1:58and hopefully they have an example right here.

2:02We'll click on using the provider.

2:04And this is actually what I'm looking for right here.

2:06So basically, we just need to specify

2:08the provider is going to be AWS, and then we

2:11want to specify the region that we want to be working in.

2:15So I'll be using US West 2, but feel free

2:17to use a different region if you would like to.

2:20So let's copy the provider here into our editor.

2:25And we're going to create a new file called, let's say,

2:28trevorterraform.tf.

2:31You can call that whatever you want to, of course.

2:34And then it will change this region to West 2.

2:38And I'm just going to delete this little placeholder

2:40file that I created earlier, because I don't need it

2:42anymore, because I've got my code space provisioned.

2:46And now that we've got the provider defined here,

2:48and we've got the credentials that are coming from the GitHub

2:51workflow itself, I can now start to add in different resources.

2:56And there's a couple of different ways

2:57that you can do that.

2:59One way is to use something known as a module.

3:02And you can kind of think of a module in Terraform

3:05as being kind of a building block

3:07that consists of several different resources.

3:09So if you're familiar with AWS, and you're building out

3:12things like a VPC, for example, a VPC,

3:16a software-defined network in the Cloud,

3:18essentially, is basically just a CIDR block.

3:20But you actually have to, in order

3:21to actually deploy different resources into the VPC,

3:24you first have to subnet it.

3:26You also have to attach things like an internet gateway,

3:29or a NAT gateway, depending on what you're

3:32going to be using it for.

3:33If you want EC2 instances to be public or private,

3:36or if you're going to be using things like RDS,

3:39Amazon RDS provisioning database services into that VPC,

3:43there's a lot of options there.

3:45You've also got things like your route tables, your security

3:47groups, as well, to allow inbound or outbound access

3:51to different services, and things like that.

3:53So modules are kind of a composition

3:55of several different types of resources.

3:57A VPC, a subnet, security group, and things like that

4:00allow you to construct an entire resource.

4:03Whereas if you are interested in just building

4:06with the base building blocks themselves,

4:08that is what we know as a resource.

4:11So a resource could be like a VPC, or a subnet, or a security

4:16group.

4:16And so rather than using a module that

4:18ties all those concepts together,

4:20you can instead use those building blocks individually

4:23instead.

4:23You can kind of think of them like LEGO pieces.

4:26Rather than having a LEGO piece that's already been constructed

4:29for you out of several different pieces,

4:31you can actually take those individual pieces

4:33and then piece them together.

4:35But there is actually a resource--

4:40not a resource, a module right over here on the registry--

4:44let me come back to my registry tab here--

4:46and there are modules for things like VPC.

4:51We've got a module here for security groups.

4:54We've got modules for IAM resources and things like that.

4:57But I'm going to go ahead and grab this module right here

5:00for VPC.

5:01And as you can see, this shows us an example of what

5:05a VPC module would look like.

5:08So inside of a VPC module, it actually

5:10allows us to define private subnets and public subnets.

5:14So we can actually subnet everything

5:16from within a single module rather

5:18than having to define all of these individual resources

5:21separately, and then stitch them together manually.

5:25So our VPC could have an optional name.

5:27Of course, it has to have a CIDR block.

5:29That's one of the essential properties of a VPC,

5:32is that you have to define your supernet

5:34so that you can then subnet it into smaller environments.

5:38You also have the ability to map your different subnets

5:41to availability zones in AWS.

5:44So if there's specific availability zones

5:46that you want to use in this VPC,

5:48you can specify those as an array, as well.

5:51You can also choose if you would like to enable a NAT gateway,

5:54if you want to have private resources on private subnets,

5:57have outbound access to the internet.

6:00You can also switch on the VPN gateway,

6:02rather than having to provision that

6:03as a totally separate resource, as well.

6:05So this is kind of a convenience module

6:07that allows you to construct several different resources,

6:11individual resources, in AWS just

6:14by using this module instead.

6:16So I am going to go ahead and construct

6:18one of these VPCs inside of my Terraform template here.

6:25So let's go ahead and do module.

6:27And we'll call this trevorvpc.

6:30And then we'll go ahead and set the source of our configuration

6:35here to use the Terraform modules/vpc/aws.

6:42We'll go ahead and bring that in here and just paste that in.

6:45And then we need to set the CIDR block.

6:47So let's go ahead and set the CIDR block parameter here.

6:50We'll say cidr equals 10.70.0/16, for example.

6:57And then I'll just go ahead and save this,

6:59because I don't think any of these other properties

7:01are mandatory.

7:03I could be wrong about that.

7:05But we'll find out when we actually attempt to deploy it.

7:08And then the idea here is that later on, once we

7:12start adding more content to this Terraform template,

7:16we'll actually automatically deploy those changes

7:18through GitHub actions using that push event that we've

7:21already configured.

7:22So now that we've added in a base

7:24Terraform template file here, let's go ahead

7:27and actually run the necessary commands inside

7:30of our GitHub actions workflow to actually test and do

7:33a plan, and then a deploy on this particular template.

7:37I hope this has been informative for you,

7:39and I'd like to thank you for viewing.

0:11Hi, guys, and welcome back.

0:12So in this video, we are going to take this Terraform template

0:15file, the very, very basic file here with just a simple VPC

0:20configuration, and we are going to go ahead and deploy

0:23this out to AWS as part of our GitHub actions

0:27workflow right here.

0:28So go ahead and open up your workflow file.

0:30You don't have to name it Terraform dash deploy

0:32if you don't want to.

0:33You can just name it whatever you'd like to,

0:35as long as it conforms to the GitHub actions expected schema

0:39here.

0:40So you need on section, you need the job section,

0:42and things like that in order to define a very basic workflow.

0:46But as long as you have a valid workflow file,

0:48you can name it whatever you want to.

0:49And now down here under the steps, under our Terraform

0:53deployed job, right now the only thing

0:56that we have going for us is that we are configuring our AWS

0:59credentials and setting a default to AWS region

1:02as part of that process.

1:04So at this point, we need to actually run

1:06the Terraform tool.

1:08Now, normally you would have to install Terraform.

1:11However, thanks to GitHub actions and the software

1:14that they pre-install onto the service,

1:16onto their images that they use to spin up

1:18these virtual machines, Terraform is actually included.

1:21Now, how do we know that?

1:22Well, we can search for GitHub actions included software

1:27environment, and check out this documentation here

1:31for GitHub actions virtual environments.

1:33This will take you over to a GitHub repository

1:36that contains information about the different images.

1:39And if you scroll down to available environments,

1:42these are the different operating system based images

1:44that you can run a GitHub actions workflow based off of.

1:48So I am using Ubuntu latest right here,

1:52which is a Ubuntu 20.04 LTS, long term support, which

1:55is focal fossa.

1:57That's the code name for it.

1:58And if you click on the link for included software right here

2:01this will show you basically this huge list

2:04of all the different programs that

2:07are pre-installed on the base image for Ubuntu focal fossa.

2:12And this is all provided by GitHub.

2:14So we've got things like our different runtimes and package

2:18managers.

2:19We've got the pip package manager.

2:20We've got NPM.

2:22We've got a Homebrew for Linux.

2:24We've got Helm if we want to deploy Kubernetes helm charts.

2:28We've got yarn, if you prefer yarn

2:30over NPM for JavaScript projects.

2:33We've got a whole bunch of other tools

2:35down here, like Docker Compose is pre-installed.

2:38And if we scroll down just a little bit here under Tools,

2:41under the Tools heading right under project management,

2:44we have Terraform version 1.1.3.

2:48So this is really nice because we

2:49don't have to add an extra step into our GitHub actions

2:53workflow to install Terraform.

2:56Unless, that is, you need a specific version of Terraform.

2:59If Terraform 1.1.3 doesn't work for you for some reason,

3:03then sure you could go ahead and install your own version

3:06over top of that instead.

3:08But I'm just going to rely on the built in version of it

3:11for the time being.

3:13So I'm going to go ahead and close that tab right over here,

3:16come back to my editor, and we are

3:19going to go ahead and add a run step in here.

3:22And there is a great document I like to refer back

3:25to for GitHub workflows called "workflow syntax for GitHub

3:29actions."

3:30And there is a run option that you have under steps.

3:37So if you take a look at jobs and then steps.run,

3:42you can add in a run step and it will basically

3:45invoke a shell script, or just a command line program.

3:49And by default it will use the bash shell, I believe.

3:53However, you can actually override the shell

3:55that it's going to use if you would like to.

3:58So you can actually add in the shell option

4:00right here on your step configuration,

4:03and that will change the shell that is being

4:05used by the run command here.

4:07So if you wanted to run PowerShell,

4:09for example, which is also pre-installed in the GitHub

4:12actions Ubuntu focal fossa image,

4:15then you could certainly do that as well.

4:17But for the time being I don't really

4:18need to do any PowerShell scripting,

4:20so I'm just going to use the default shell.

4:23And let's do run.

4:25And then the first thing I need to do

4:27is do a Terraform initialization to initialize the provider.

4:30We'll do a Terraform init, and I'll go ahead and just give

4:34this step a name.

4:36We'll say run Terraform init command.

4:41And then we'll add in another command here.

4:43So I'll go ahead and just select these and then

4:45do Alt Shift down arrow, and that

4:47will copy those two lines down.

4:49And we'll do a run Terraform plan.

4:52I'll say run Terraform plan command.

4:54And then we'll do Terraform plan.

4:57And I'm going to go ahead and just save this for now

4:59and test this before we actually attempt

5:01to deploy it just to make sure that plan step actually runs.

5:06So let's go ahead and add in our template file here.

5:10And then we'll add in our updated workflow file

5:13and also add the change here where I'm deleting that ASDF

5:17placeholder file.

5:18And I'll say adding Terraform template and update workflow.

5:25Control Enter to commit, and then we'll

5:27do sync changes, hit OK.

5:29That'll push the changes up to GitHub

5:31and kick off a invocation of our workflow.

5:38So we'll go over to Actions right here.

5:40And as you can see, we've got a new invocation right here.

5:43And if we drill into that, we've got our Terraform deployed job.

5:47And it looks like we are missing some configuration options

5:53here.

5:53So let's go ahead and take a look at this.

5:55So we've got no configuration files.

5:57It says it can't find any configuration files.

6:01So it's looking for TF files.

6:02And of course, the reason for this

6:04is because we did not check out our source code.

6:08Sometimes I just forget to do that.

6:10So with GitHub actions one of the things that you actually

6:13have to do is check out your source code.

6:15And if we head over to the GitHub actions marketplace

6:19right here, and go to Actions, and then search for checkout,

6:25this is the action that we can use inside of our workflows

6:30in order to check out our source code onto the GitHub runner

6:35system, the virtual machine that's

6:36actually running our workflow.

6:38Now, there's a bunch of options that you can specify

6:40under the with property here.

6:42But we don't really need to specify any of these

6:45unless you are using some kind of advanced scenario

6:47where maybe you need to provide a custom SSH

6:50key to provide access, or you want

6:52to clone it to a different path on your local file system,

6:57or if you want to specify the repository that you

7:00want to clone.

7:00But by default, it's just going to clone

7:02the current repository.

7:04So I'm just going to grab this uses statement right here

7:08and come back into my configuration on my workflow

7:12here.

7:13And before we do anything else, we'll

7:16go ahead and just add in this checkout step.

7:19And I'll give it a name.

7:21We'll say name and say Clone, source code, and save this.

7:27And then we'll go ahead and commit that change.

7:30We'll say add checkout step to workflow,

7:34and do another sync changes, and click OK.

7:37And then we will monitor this action again.

7:41So here it is.

7:41Here's our new invocation currently in progress.

7:44We'll drill into the job and see what we get for output.

7:49All right, so this seems to have gone much better this time.

7:52And so what you can see is right here the very first step

7:55after this built in setup job--

7:57we don't have to define the setup job.

7:59That's just built into GitHub actions.

8:00But then the very first thing that's

8:02defined in our actual workflow is the clone source code here.

8:05And so this is basically cloning our Git repository

8:09into the local file system.

8:12And so that's going to provide us

8:14access to the files that are inside of our repository.

8:17Next, we have configure AWS credentials.

8:19We already know that that's working just fine because we

8:22tested it previously.

8:23Next, we have the Terraform init command.

8:25And this is basically going to take a look at our Terraform

8:28template file.

8:29And it is going to see that we have referenced the AWS

8:34provider.

8:35So if we come back in here, we defined

8:37our provider AWS right up here, though it

8:39is going to download the necessary provider

8:42plug-in for AWS.

8:45And so it's downloading version 3.72.0 right here.

8:49And that's going to make sure that we

8:50can use that provider in our actual execution

8:54of our template deployment.

8:57And then after that, we've got run

8:58Terraform plan right down here.

9:01And at this point, it's going to show us any changes

9:04that Terraform is planning to make to our account.

9:07So we've basically defined this new resource called an AWS VPC.

9:12This is actually part of the module that we've defined.

9:14But basically, it's going to go ahead and just define

9:17a new VPC.

9:18The little plus sign here just indicates

9:20that it's a new resource that it's going to be provisioning.

9:23That's this little legend right here.

9:25So it's going to create a VPC, and it's

9:29going to set our CIDR block to the property

9:31that we set in that high level module previously.

9:35So at this point, it says planning to add one resource.

9:38There's zero resources to change and zero to destroy.

9:42So at this point, nothing has actually been executed.

9:45We have simply kind of planned out what

9:47our state changes will actually look

9:49like if we were to execute it.

9:52So let's go ahead and jump into the next video

9:54where we will customize our workflow

9:58to actually deploy this change.

10:00I hope this has been informative for you,

10:02and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:11Hey, guys, and welcome back.

0:13In this video, we are going to take a look

0:14at how to actually apply our changes as part

0:18of our GitHub actions workflow.

0:20And then we'll also take a look at how

0:22to make some changes to the template a little bit

0:25later on so that we can see the automation in action as we

0:29are making changes to our source code, which basically

0:32just consists of our Terraform template at this point.

0:35So in the last video, we got our Terraform init and Terraform

0:39plan commands working just fine.

0:42We of course, had to add in the step

0:44to clone our source code here, as well.

0:45So we have access to our Terraform template right

0:48here in the root.

0:49But let's go ahead and switch over to our editor here.

0:53And we are now going to add in another step

0:56after we run the plan step here.

0:58And we'll just go ahead and select these lines,

1:00do Alt-Shift down arrow again, nice VS code shortcut.

1:04And then we're going to run Terraform Apply or Deploy.

1:07You can think of it like deploying your changes

1:09or applying changes, right?

1:11And so what we're going to do is run Terraform Apply.

1:15However, if we just run that by itself,

1:17things are going to fail.

1:19Do you know why that is?

1:20Well, I'll give you a hint.

1:22So it's because, if we run Terraform apply,

1:24we are making production changes, right?

1:27We're actually making resource changes to our AWS account.

1:30And if this was a production account with a business

1:33critical application, then the changes that are being planned

1:37could potentially have a significant impact, potentially

1:41a negative impact if misconfigured to our production

1:44application.

1:45Now, that production application we don't want to go down.

1:47We don't want to affect the end users of our business

1:50applications negatively.

1:51And so by default, the Terraform Apply command

1:55actually will prompt you and say, hey,

1:57are you sure that you actually want to apply these changes?

2:00It's basically just an interactive sanity check

2:02to make sure that you actually are

2:04going to be OK with the changes that have been proposed

2:08by the Terraform plan command.

2:10So in order to work around that, we

2:13have a parameter for the Terraform CLI.

2:17So if I come back to the Terraform documentation

2:20here and just go back a level up here to the Terraform Intro,

2:26go to the Terraform CLI, there is a document.

2:31Let's see.

2:32We've got alphabetical list of commands.

2:34We have the Apply command right here.

2:36And then we have an optional parameter

2:38on here called -auto-approve.

2:41So the first parameter right here you can see, auto approve,

2:44it says skips interactive approval of plan

2:47before applying.

2:48Now, this is really important when

2:50you are running the Terraform utility

2:53in any kind of background service

2:54that you don't have console access to, right?

2:57We're not actually typing Terraform Apply

2:59into our terminal here.

3:00We're not firing up PowerShell locally or iTerm2 locally

3:04if you're on Mac OS, for example,

3:06and actually running that command.

3:07Because it's running in the background

3:09on a GitHub actions virtual machine or a runner,

3:13as they call it, we need to make sure

3:15that we are not being prompted for any kind of input.

3:18Otherwise, that will simply cause our workflow to fail.

3:22So what we need to do is go ahead

3:24and add in the -auto-approve argument

3:30there to the Terraform Apply command.

3:33And that should apply any changes to our environment,

3:38to our AWS account, right?

3:39And so we saw previously in the proposed output from the plan

3:43step that the plan step is going to add in a new VPC

3:48resource right here based on that module,

3:50the VPC module that we're using, which

3:53is a high-level construct over here in the Terraform Registry.

3:59So all we did is we specified the CIDR block.

4:01We didn't specify any private subnets.

4:03We didn't specify public subnets or azs that we

4:05want to use for those subnets.

4:06We also didn't choose enabling a NAT gateway.

4:10So the service is really not going to do anything for us

4:12there.

4:13But we will come back and then add these things

4:15in a little bit later on.

4:17So if I go ahead and just save this file and do a commit--

4:23we'll say adding Terraform Apply step to workflow,

4:28Control-Enter, say, yes, we want to stage and commit

4:31all changes, and then let's do a sync to push those changes

4:35to our repository, and then that's

4:38going to automatically, thanks to the push action,

4:41kick off a new execution here.

4:44And we're going to see an issue here.

4:46But I'm not going to reveal it quite yet here.

4:49[LAUGHS]

4:50So let's just watch this run.

4:51So we've got cloned source code configure AWS

4:53credentials, Terraform init--

4:54that's going to download the AWS provider onto the runner,

4:58and that has to happen each time.

5:00And then we run the Terraform plan command,

5:02which again, is going to say this is the planned changes

5:06to add in this VPC.

5:07And now we're running the Terraform Apply,

5:09which is actually going to make those configuration changes.

5:13Now, remember, the IM role that we configured here

5:16in the Configure AWS Credentials step, the role

5:19named GitHub actions Terraform 2--

5:23that role we assigned the policy to that role in AWS

5:26IM to allow it access to the VPC APIs.

5:31And so that's why this succeeded here.

5:33If we had not given it the permissions policy in AWS IM

5:37to ensure that the role has access to the VPC APIs,

5:42the Apply step would have actually failed,

5:44because the permissions were not there

5:47to call the necessary create to VPC REST API in the AWS REST

5:53API for the VPC Service in order to create that resource.

5:56But because we assigned that permission,

5:58we do have a successful execution here.

6:01So now let's go over to the AWS Management Console.

6:05Take a look at the VPC Service here and see what we've got.

6:11So if we go into Your VPCs, sure enough,

6:16you can see right here we've got a VPC with 092ba as the ID,

6:21and it has a CIDR block of 10.7/16,

6:25which is exactly what we specified in our Terraform

6:29template file.

6:30Now, I also have a couple of other ones here.

6:33I have my default VPC and just another one

6:35that I created here previously.

6:36I'm going to go ahead and clean up this old one really quick

6:39just so we don't run out of VPCs.

6:41I think there's a limit of five by default,

6:43or something like that.

6:45But let's go ahead and try to run this again.

6:49So I'm actually going to come back into my Actions here.

6:52And I'm not going to make any changes.

6:55So nothing has changed at this point with our Terraform

6:57template.

6:58It still just has this little module in it

7:00right here with a CIDR block set.

7:02And if we run this again, what do you think

7:04is going to happen?

7:05Do you think it's just going to look at the CIDR block

7:08and say, OK, well, the CIDR block is already set properly,

7:11so I'm not going to make any changes, right?

7:13So if we do a Terraform plan, it's basically

7:15going to say there's no changes to apply, right?

7:18Let's find out.

7:20Then I'm going to come back into actions here.

7:22I'm going to take this last execution that was successful.

7:25I'm going to click on these little dots over here.

7:27Or actually, let me drill into it first and then click on

7:30these dots right up here--

7:32or sorry, this button right here.

7:34[LAUGHS] It's right in front of me, and I can't even see it.

7:36So re-run all jobs, and so that's

7:38going to trigger the exact same execution of the workflow

7:42to run again.

7:44And if we drill into the job and check out the logs here,

7:49let's see what happens.

7:51We're setting up our credentials,

7:53running a Terraform init, running the plan command.

7:58And let's see what the plan command says.

8:01So when we run the plan command, look what it says right here.

8:04It says, let's create.

8:06It's going to create a VPC--

8:10sorry, it automatically closed that on me.

8:12So it says I'm going to create a new resource, a VPC,

8:15and I'm going to give it a CIDR block of 10.7/16.

8:20So what's wrong here?

8:21Well, think about this.

8:22We've already created our VPC, right?

8:25And our VPC had the correct CIDR block.

8:28We didn't make any changes to the template file.

8:30But Terraform plan is telling us that it's

8:32going to create a new resource.

8:35And if we scroll down a little bit down here to Apply,

8:39it says Terraform will do this action.

8:41Once again, it's basically just doing another plan right

8:43before it does the Apply.

8:45And sure enough, it says creation

8:48complete after three seconds.

8:50So it actually added a new resource.

8:52It says that right here-- apply complete!

8:54Resources-- 1 added.

8:56So what happened here?

8:58Well, this is where the state management

9:00comes into play with Terraform.

9:03And Terraform supports different state management back ends.

9:07Now, by default, the back end where your state will be stored

9:12is stored in a local file.

9:16But when the GitHub runner is terminated,

9:19so after our workflow is finished, all finished running,

9:21the entire file system and that virtual machine

9:24that is running our workflow is discarded.

9:28So we don't have access to that state file anymore.

9:31And so what's essentially happening here,

9:32if we come back into the VPC console,

9:35is that it actually created a duplicate VPC.

9:39And of course, we don't get to specify the ID.

9:42The ID is automatically generated by the AWS VPC

9:45Service.

9:45But what's happened here is Terraform

9:47has made us another VPC.

9:50So if we were to run that workflow a third time,

9:53then Terraform is actually going to give us

9:55a third VPC with the same CIDR block.

9:58But that's not what we want to happen, right?

10:00What we want to actually happen is

10:02we want to just have a single VPC with that CIDR block.

10:07And if we are to make any changes to the configuration,

10:09like perhaps changing the name tag, for example,

10:12then we want Terraform to update the existing VPC.

10:16We don't want it to create entirely

10:18new VPCs, because that really defeats

10:20the whole point of doing declarative configuration

10:22management, right?

10:24So basically, if we take a look at the Terraform Docs

10:29here and then drill into--

10:32let's go back here, go into the configuration language,

10:35and take a look at state.

10:38The state section really deep-dives

10:40into the different state storage back ends.

10:43But essentially, if we go into the overview here,

10:47the state file, by default, is called Terraform--

10:54let me find the file name right here.

10:56So we have Terraform import.

10:59Here it is.

10:59So it's called terraform.tfstate.

11:02And so that file is actually getting

11:04created by the Terraform CLI when we run the Terraform Apply

11:09command.

11:10And it's going to store the state, the unique ID of the VPC

11:14that gets created by AWS.

11:16When we call, or when Terraform calls, the Create VPC

11:19API for us, it's going to actually store

11:21that ID, that unique identifier, for that VPC into this state

11:25file so that, in the future, if we make any additional changes

11:29to the configuration of that particular VPC,

11:32Terraform will be able to look up the existing VPC

11:36and then make changes to it rather than

11:39duplicating that resource.

11:41So how do we deal with this?

11:43Well, I'm not going to get too deep

11:45into the weeds in the back end state management.

11:48I'm going to show you a hacky way to do this.

11:51And so the hacky way to do this is

11:53to actually commit the Terraform state

11:56file to your Git repository.

12:00And this is not the recommended way to do this.

12:03However, it will kind of show you

12:04what that file looks like with fairly minimal effort.

12:08Now, if we go back over to our workflow

12:11here, after we run the Terraform apply command here,

12:15let's say that we want to pick up that terraform.tfstate file

12:19that's generated by this Terraform apply command

12:22and then add that to our Git repository and push it back.

12:26Well, there's a pretty easy way to do that.

12:29And again, this is not recommended

12:31for production state management, but it

12:33is kind of the easiest way to just get access to that file

12:36and kind of extract it out of the GitHub runner.

12:40So what we're going to do is you go back to the GitHub Actions

12:44marketplace here and search for an action called

12:49commit and push, I think-- commit and push.

12:54And I'm going to sort by most installed.

12:57And there's a bunch of different actions that we can use here.

13:01The most popular one, by far, is this one right here

13:04by Stefan Zweifel.

13:07I hope I'm saying that right.

13:09And what we're going to do is come in here

13:11and grab this step.

13:12And this is basically a commit and push action.

13:15So it will add in local files that

13:18have been changed in the context of the Git repository

13:20that was cloned locally by the checkout step, that very

13:23first step that we added.

13:25And then it will commit those changes on the local file

13:28system on the GitHub runner.

13:30And then it'll push those changes back to our repository.

13:34Now, we have the ability to specify a file pattern.

13:37So I am going to specify a file pattern that

13:40simply includes the name of Terraform active state.

13:43So let's go ahead and say Commit Terraform State File

13:49as the name of this step.

13:51And then we'll go ahead and do uses.

13:54Or actually, I already have uses in my clipboard

13:56there, so I'll go ahead and just paste this in.

13:58And then for the with section, where

14:01we can add in input parameters to this action,

14:04I'm going to specify the file pattern.

14:07And we'll go ahead and just do file pattern,

14:10and then we'll say terraform.tfstate.

14:13So that's the only file that will get added, committed,

14:16and pushed to our Git repository.

14:19And then the other thing that I can do

14:21is set a commit message, as well.

14:23So I'll say commit message and just say

14:27adding Terraform state file, or maybe updating Terraform state,

14:31because it could always change in the future.

14:34And so now we're going to push this back to our code

14:37repository.

14:37However, we need to, because we're now writing back

14:40to our repository, we actually need

14:42to add in another permission.

14:44And this permission is called contents.

14:47And you can look this up in the GitHub workflow syntax

14:49documentation if you want to.

14:51But if we are going to commit and push back to our Git

14:54repository on GitHub, we need to add in this contents permission

14:58and give it write access.

15:00So we'll go ahead and save this, and then we

15:02will commit our change to our workflow file

15:05and say adding Terraform state commit step.

15:10And we'll do Control-Enter to commit and then push our change

15:13back to our Git repository.

15:16And if we go back to Actions, we should have a new execution

15:19pop in right here.

15:21And we'll see what happens.

15:23All right, so here's our new execution.

15:27And as you can see right over here,

15:29we currently have two VPCs.

15:32And I think it's actually going to create a third one,

15:34because we haven't done any state management yet.

15:37And so the first time it runs after we add in the state

15:40management component to it, it's going to actually have

15:43to create a whole fresh one.

15:45So in just a second here, it'll pop probably pop

15:48in with a third VPC that has a 10.7 CIDR block.

15:55So it looks like everything just completed here.

15:58Let's do a quick refresh-a-roo here.

16:00And sure enough, as I just expected,

16:03it created a third VPC.

16:05Now, which one did it create?

16:07I think it's-- want to say it's the one with 009,

16:10but let's just check over here.

16:13Go down to the Run Terraform Apply,

16:17and it'll tell us right here at the end.

16:20It looks like it's actually the 0c2 one.

16:22So it tells us what the ID of that resource it just created

16:25is.

16:26And so basically we've got this 0c2.

16:30And so now, if we were to make any changes to our Terraform

16:34template file, hopefully those changes

16:35would get made to this particular resource.

16:39So we'll give that a shot in the next video.

16:41I hope this has been informative for you,

16:42and I'd like to thank you for viewing.

0:11Hey, guys, and welcome back.

0:12So in this video, we are going to make a change

0:15to our Terraform template.

0:17And we basically just want to test and verify

0:20that our Terraform state that we committed back to our Git

0:23repository is actually taking effect any time that we run

0:28the Terraform apply command, and periodically getting

0:30updated every time that the workflow executes.

0:34All right, so I've got these two defunct VPC IDs here.

0:38So I'm just going to go ahead and just

0:39clean these up really quick.

0:41The two that were created before we

0:43did the state management stuff.

0:45The 0c2 is the one I want to keep.

0:47So I'm going to go ahead and delete this one as well.

0:51And I'm just going to leave my default VPC with the 172 CIDR

0:54block in place.

0:55All right, so now we're down to just the VPC that we

0:58have the state management on.

1:00So let's take a look at the state management

1:01file for starters.

1:03So if we come over to our project here, go to code,

1:07you can now see that we have this commit message saying

1:10updating Terraform state file.

1:12And it's called Terraform dot TF state.

1:16All right, so now that we've got this file in our repository

1:20here, we can explore it.

1:21And this is what the Terraform state file actually looks like.

1:25So we've got a version.

1:27We've got the Terraform version that was used to deploy.

1:30We've got this huge resources section that kind of describes

1:33the state of our resources.

1:35And you'll notice that under our resources

1:39we have this instances section right here.

1:42And then under attributes of a specific instance of a resource

1:47we have the ID attribute here or property.

1:52And the ID property sure enough is this VPC ID

1:56that was generated by AWS.

1:58So now, because I'm storing the state file in Terraform inside

2:02of my Git repository side by side with my Terraform template

2:06file itself, now I have information about the VPC

2:11that is in my AWS account.

2:14And

2:14Any changes that I make to my Terraform template file

2:17are going to get applied to this VPC

2:21rather than creating a whole new one

2:23like we saw happening before.

2:25So let's go ahead and take a look at this module over here.

2:31And as we could see previously when we first explored this,

2:34we have the ability to provide different subnets.

2:38And we can make those either private subnets

2:39or public subnets by simply creating

2:42an array called private subnets that the VPC module here

2:46is expecting or public subnets.

2:49And then we can also tell it which access AZs,

2:52or availability zones, we want it to use.

2:54And because we're working in the US West 2 region,

2:59if we were to create a subnet, for example,

3:01I believe we just have four different AZs.

3:05You can just come into the create subnet

3:07here, and then take a look at your availability zones.

3:10So we've got 2A, 2B, 2C, and 2D.

3:13And so we could basically limit and say,

3:15I only want subnets in 2A or 2B.

3:19And so we could limit that by using that property.

3:22And then once we make those changes,

3:24those will be applied back to our VPC.

3:27Now the other thing I wanted to mention to you here,

3:29just a general observation, is that in our subnets here--

3:33I don't have any filters applied,

3:34so I'm looking at all the subnets.

3:36The only subnets that I have are under my default VPC for this

3:41region, which is this one 172.31/20.

3:44And so right now, we have a VPC with the ID 0c2,

3:51but it doesn't have any subnets at all.

3:53It's not subnetted in any capacity.

3:55We don't have any private subnets.

3:57We don't have any public subnets.

3:58In fact, I don't think we even have an internet gateway

4:01either.

4:01Yeah, see if we go to internet gateways,

4:03we don't even have an internet gateway attached probably

4:05because we don't have any public subnets.

4:08So it says, well, if you don't have any public subnets,

4:10you don't need an internet gateway.

4:11Because that's the whole point of the internet gateway

4:13is to expose your resources directly

4:16to the public internet, like EC2 instances or anything

4:19that has an Elastic IP address, for example, attached to it.

4:23So what we're going to do is actually edit here

4:26in our code spaces environment.

4:28We're going to open up Trevor Terraform dot TF.

4:31And in this module here, we're actually

4:34going to change the configuration.

4:37And one of the things that we'll do is add in public subnets.

4:42And so we'll pick a couple of CIDR blocks to assign to that.

4:46They'll say public subnets equals array.

4:49And I'll say 10.7.100.0/24.

4:56And I'll also add in, let's say 10.7.200.0/24 and four AZs.

5:07If you recall, we have this AZs property

5:09that is also going to an array of AZs inside of this region

5:13that we want to support.

5:14And so I'm going to say, well, I only

5:16want you to create these subnets in US West 2A or US West

5:242, let's say, C.

5:26All right, so basically we're saying

5:27we want two public subnets and we want these AZs supported.

5:31So now at this point, as a DevOps engineer,

5:33because we've set up our fully automated pipeline in GitHub

5:36actions, I don't have to worry about manually

5:39deploying these changes.

5:40I can literally just make these changes to my Terraform

5:42template file right here, and then commit those changes,

5:46push them to my GitHub repository,

5:48and the GitHub action service is automatically

5:51going to pick up that change thanks to the push event

5:54that we defined right here.

5:56So every time we've been pushing code changes,

5:58it's automatically getting triggered.

6:00And so we don't have to do anything else.

6:02That's literally all we have to do to make changes

6:04to our environment is to save this file,

6:07come into source control, and commit the change,

6:11say adding public subnets and AZ config to Terraform template,

6:20and we'll say sync changes, and it is complaining.

6:25Why is it complaining?

6:26Let's see, oh, that's probably because when we executed

6:31our GitHub workflow up here, it automatically committed

6:35this Terraform state file.

6:37However, our code spaces environment, our client machine

6:40that we're basically working on with VS Code here,

6:43doesn't know about that change yet.

6:45So I actually need to synchronize that change

6:47locally.

6:48So I'm going to do a Git pull.

6:50Of course, it's not going to like that.

6:52So I need to do a quick Git reset.

6:54So let me do that.

6:56We will do F1 in our editor here and we'll say,

6:59undo last commit.

7:02And so that will basically just restage our change here.

7:05And so now we can go ahead and do a Git pull.

7:08And so that is going to download this Terraform state

7:11file from our GitHub repository onto this local dev system

7:16that's running in code spaces.

7:17But even though it's running in GitHub code spaces,

7:20it's actually just a client machine

7:22that's separate from GitHub.

7:24It's not actually synchronized directly with this

7:26unless we actually do a Git pull operation on it.

7:29So that's why we saw that inconsistency there.

7:32So now I'll go ahead and just recommit this file now

7:34that we are synchronized, and then

7:36push that change up to GitHub.

7:41And that, of course, is going to trigger our actions here

7:44to execute.

7:46And we'll drill into the logs here

7:48and see what the Terraform planning output looks like.

7:51So it'll basically say, OK, I'm going to add these subnets,

7:54and I think that's pretty much it.

7:56Actually, it'll probably add an internet gateway too

7:59since we made a public subnets, because otherwise they

8:01wouldn't be public.

8:04So there's the Terraform initialization.

8:06We're doing a Terraform plan now.

8:09And in the Terraform plan output,

8:12sure enough, we have a bunch of stuff here.

8:16So we've got plus subnet and 7.100.0/24,

8:21that's going to be put in 2A.

8:23Then if we scroll down, we're going to see and 10.7.200.0/24

8:28US West 2C.

8:30So neither of the subnets that we added

8:32are getting placed into the 2B or 2D availability zones.

8:37Because, again, in our module configuration,

8:40we told Terraform that we did not

8:42want to use either of those availability zones.

8:45And then the other thing that you'll

8:46notice here-- sorry, it keeps closing this on me--

8:48is that we have an internet gateway that's

8:51going to be added as well.

8:52And it'll be attached to our VPC.

8:55So you can see right down here it's

8:56going to attach that internet gateway to our VPC for us.

9:01And then down here, it's actually

9:02doing some routing setup.

9:03So it's going to create an AWS route table, a VPC route table.

9:08And it's going to create that for the internet gateway.

9:11So that's going to be a routing table rule in our route table.

9:16And then down here is the actual route table itself.

9:19Though the route table contains routes, and this is a route,

9:23and this is the route table.

9:25And then down here, we have a route table association,

9:28which basically takes the route table which

9:30contains the rule that goes to the internet gateway,

9:33and it's going to associate that route

9:35table with both of our subnets.

9:37And so it's basically saying that it's

9:39going to associate the two subnets that we have down here

9:42with the route table.

9:45So we have two separate associations right there

9:47and the subnets, and that's it.

9:50So if we come over to the VPC console

9:55now and take a look at subnets, now you

9:58can see right here under VPC, I can go ahead and just filter

10:03things down to that VPC ID.

10:05Let's choose the 0c2 one just to clean things

10:08up a little bit in this view.

10:09So now you can see we've got two subnets.

10:12We've got them associated with the 0c2 VPC.

10:16And then the CIDR block that we have right here

10:19is what we specified in our Terraform file.

10:22You can see our availability zones right here.

10:24That looks good.

10:25A and C, that excludes B and D, which

10:27we didn't include in our file.

10:30And then we've got things like our route table here.

10:32So we've got this public route table.

10:34We should now have an internet gateway sure enough,

10:36which is attached to our VPC.

10:38And what else do we have?

10:41Do we have any security groups?

10:43We should have a default security group, I think,

10:45at least.

10:45Yeah, they've got a default security group right here 0c2,

10:51on the VPC named 0c2 as well.

10:54So that's what things look like.

10:56That's how we can set up an end-to-end workflow

10:59using GitHub actions, using Terraform, and then very

11:04rapidly being able to make changes by simply committing

11:07those changes right up here to our GitHub repository.

11:12And we did all that pretty much with really

11:14just two files, our Terraform template file, which is really

11:17not that big, and then our workflow right here,

11:20which is really doing all the heavy lifting as well

11:23as our AWS IM configuration to allow our GitHub actions runner

11:28environment to actually obtain roll credentials from IM.

11:32I hope this has been informative for you.

11:33And I'd like to thank you for viewing.