Applying Database & Reviewing Resources

[00:00:00]
>> Erik Reinert: So let's go here and again. So this is our environment, this is our database. And so now what I'm going to do is I'm going to go back to the root level, I'm going to run Terraform in it again and again. You have to do this every time you add a new module because it has to set up the configuration and all that in Terraform.

[00:00:20]
And then I'm going to do Terraform plan. While this is running, I want you to note really quickly, at my command, you, you'll see here that I do out terraform TFPlan. You don't have to do that here. I'll go back. So you don't have to do that. But the main reason why I do is because it makes it so that when you run plans, you can create files that then you can reference directly in kind of like an immutable way where, you know, like, okay, I made this file, now I can run apply against it.

[00:01:00]
You'll normally do this in CI/CD. As a matter of fact, we'll do this in CI/CD as well. And it kind of makes it nice too, because when you do it in CI/CD, you can generate the plan in one job and then save that as an artifact and then only use it if the deployment is triggered, but you still get that plan.

[00:01:19]
So if you want to download the plan and then rerun it, you can do that as well. I do like exporting it as a file. Just in my mind it's a little bit nicer, but. Okay, cool. You can see that when I ran my plan, I now have an SSM parameter.

[00:01:36]
It's going to get created in staging database password. So I can get the database password. And then you'll see here, here's my database instance. Again, because it's a database, there's not like hundreds of resources here. We only have three. Yeah, Amazon doesn't really have a ton of resources for databases.

[00:01:57]
Terraform apply. So let's go ahead and apply it now. Now, databases do take a few minutes, so if you guys want, you guys can go ahead and keep trying to get your plans and everything for your environments.
>> Speaker 2: Much rather type some commands than a bunch of click ops.

[00:02:15]
>> Erik Reinert: Well, that's like again, you say that now because you know it, right? But when you don't know how to do all the like CLI and everything. Again, that feels like a scene in the matrix like that we know. He's like, what are you looking at? You know, everything.

[00:02:31]
You know, like they don't. Like I talked To. I can't remember who. I talked to somebody recently and I was like, you really have no idea what I do, do you? And they're like, yeah, no, I've. And this is like, I don't know if this gives you guys perspective at all, but for like years, people just constantly thought I was busy.

[00:02:55]
Like, no, no, no, no, I get it. You're busy, you're busy, right? And I'm like, well, yeah, I know I'm working, whatever, you know. But they're like, no, no, no, you're busy, you're busy. What I didn't realize is they'd come into my office, they'd look at my monitor and it would be so confusing.

[00:03:09]
They just assumed I was always working on work stuff. And I was like, no, no, this is personal. Like, I'm doing this for fun. And then they'd be like, so you're technically just like playing around right now? I was like, yeah. And then they're like, my God. Like, you know, they didn't realize that, you know, there is a difference between like the code you open for work and when you're work working versus even just learning and having fun or whatever, you know.

[00:03:35]
So, yeah, it is a kind of a massive step away for some people to understand how it can be valuable, how it can actually save you time when just looking at it is incredibly daunting and scary. So I get it, I totally do. But yeah, you're absolutely right.

[00:03:54]
That's why these things were created. Whereas to solve the problem of having to do repetitive tasks that are really complex, you know, over and over and over and over again. So yeah, there you go. Now, we have a database. And so what's kind of cool is, and we haven't really done this yet.

[00:04:14]
But this is where in my mind it really does start to feel like you're using the cloud provider for what its purpose is, which is to build infrastructure on top of it and get to be able to see it and manage it and work with it very easily, right?

[00:04:31]
How many of you have ever done self hosting? Just curious, like how many of you have actually done. Okay, so we got a couple self hosted stuff. When you do self-hosting, you don't get an out-of-the-box UI normally, [LAUGH] right? You don't. There's a lot of work that takes to get to what you see here.

[00:04:49]
So the fact that it is so approachable and so easy is why again, the cloud is really valuable. And so like, for example, if I want to go and look at my VPC or my network that I created. I can just go to VPC at the top. I can go to VPCs here.

[00:05:04]
You'll see I have a couple of them. By the way, if you're curious why I have a VPC called Alta4 LLC Bulbasaur, that's because me and a friend of mine were debating on what would be the best way to version things. And so I figured versioning by Pokémon name would be great, right?

[00:05:27]
0 to 100. So technically, that's the first cluster, the first virtual environment that we have, right? And so if we were to create a new one and need to migrate it to it or whatever, then that one would be, what is it? Ivysaur or Venusaur or whatever. But yeah, so I do it by convention of Pokemon.

[00:05:50]
But yeah, that is a fun way to do versioning and stuff like that. If you, you didn't want to just do cluster one, cluster two, cluster three, I do it by Pokemon. Anyways, so the staging network is right here. You can see that actually my Alta 4 LLC Bulbasaur and my staging have the same address space.

[00:06:15]
That means that if I did try and connect these two networks together, we would have collisions and they wouldn't work. So they would be incompatible to effectively be conjoined. Whereas the default comes with a 172 address space, meaning that I could connect those two together and I wouldn't have that problem.

[00:06:37]
So that's just kind of another thing to note is just keep an eye on your networks IP spaces and make sure that you're not creating overlaps if you don't want them to overlap. Yeah,
>> Speaker 3: bit of an aside, but where would you build in controls over who can do a terraform destroy, for example, on certain resources or protections against tearing things down?

[00:07:00]
>> Erik Reinert: Yeah, so it's a little tricky and you might end up doing it in multiple places. So one of the places you could prevent people from deleting things is this is what I do for my company and the projects I work on. I actually create roles for plans and roles for applies.

[00:07:24]
That means that when you plan, it's read only. They can't actually write anything. Nothing can be created. But then when we apply, you have access to create and put and all that kind of stuff. However, with Amazon's policies, that doesn't mean that you could prevent a delete. Put could mean in some cases change or delete, right?

[00:07:47]
So that may mean that you have another layer of granularity around terraform, maybe by default. In all Honesty. That's where Terraform Enterprise comes in. Because Terraform Enterprise is about not letting people run locally and making everybody run through their cloud platform and their ui. And you'd basically want to achieve the same.

[00:08:14]
You'd basically want to say, okay, nobody's allowed to apply locally. And if you want to do a delete, you have to go through a user interface and click a button and have permissions to click that button and then it'll run a delete plan. But you have to build something around Terraform to kind of fully stop it.

[00:08:31]
But you can kind of stop it, like I said with the plan and apply roles that'll at least make sure that if you wanted to give a read only role to developers locally so they could test the plan but then not apply it, then you would just give them that read only role for all of the resources.

[00:08:48]
And then if they tried to plan or delete or apply or destroy, they couldn't do either. So yeah, that's another approach you could take. Yeah,
>> Speaker 4: or put the apply on the actual cd whenever you push this out, just put the role that can apply on the continuous delivery in your repo.

[00:09:09]
>> Erik Reinert: Yeah, just keep that in CI/CD if you want. Cool. Okay, so if we click on the vpc, there's actually something I do want to point out which is really nice in my opinion. I'm really glad they added this. You could see a full resource map or network map of your entire VPC or virtual private cloud.

[00:09:33]
So what you're seeing here is three different availability zones, US West 2A 2B 2C and all of the subnets that are provisioned in them. You can see as if I hover or when I hover over them, it shows how they actually route. So this is kind of nice too, if you wanna see if a subnet's connected to a public versus a private network, right?

[00:09:56]
You can see that. And so here you can see that private goes basically entirely through the private NAT gateway. And so you can see all of the, you get to see actually all of the subnets that are connected to the private NAT gateway for Internet access. And then you can see the 1 Networks or subnets that are connected to public.

[00:10:15]
And then. Yeah, all the way here on the. Right. These are the actual. Sorry, so this is the Internet gateway and then this is the NAT gateway. These are the route tables. How many of you know what a route table is? Okay?
>> Speaker 4: IP tables.
>> Erik Reinert: Yeah, it's basically, a routing table is a network.

[00:10:39]
I guess an easiest way to call it is like A networking principle or part of networking that says these IPs in this space can communicate with these IPs in this space. So when we say a route table, we literally mean that all of these subnets are routing out to this Internet connection right here, which is our NAT gateway, versus these, which just route out to this public Internet gateway right here.

[00:11:07]
Again, just a little bit of networking knowledge for you. If you're curious, say yeah, and then we can see CIDRS. We can see there's our 10.0.0.16. We can add flow logs. What's cool about flow logs is flow logs enables you to log all of the networking traffic coming in and out of your vpc.

[00:11:25]
So if you wanted to monitor things for security reasons or other things like that, you can monitor them through flow logs. Yeah. Another thing, you can also look at your subnets. So if you want, you click on subnets, we can see all of our subnets here again, we can see all of our route tables as well.

[00:11:40]
So if you're curious to see like how routing works, you just click on routes. And just to give you a quick idea of like what routing means or how to read it effectively, you have your destination and your target. So your destination is effectively what you're trying to route from and basically what you're trying to route to.

[00:12:01]
So in this case we're saying 000 is out of the NAT gateway. So that means that if you route to the NAT gateway, then you should be able to access 000 and then anything local you can access 10.0.0.16 if you're local effectively to the network. So what this really means is just we only have Internet access and we have access to our 1000 network.

[00:12:27]
There's no other address spaces that we have access to. Yeah, that's really it for the network. So then we can take a look at RDS really quickly. So here's RDS again, another Amazon Console ui. But this would show you where all of your databases are and it shows you in a list format.

[00:12:46]
So again, you can kind of see like all of your databases and some micro information about it, like the CPU connectivity, all that kind of stuff. But if we click on it directly, we can get more information about it, like the endpoint. So if you were curious, like, well, what's the URL of it?

[00:13:00]
This is where you can get the URL of your database. You can also see monitoring. So out of the box you get very simple monitoring. So you'll get like burst balance, checkpoint lag, CPU credit, all that kind of stuff. Utilization, database connections, disk queue depth. Like a lot of the more standard things you won't get, like transactional metrics.

[00:13:23]
That's really more what the database insights. This like big buy me button is right here. But this will make it so that you can actually see like transactions, how long they're taking, what kind of lag they're introducing into the database, all that kind of stuff. So another thing to note about RDS and really just Amazon services in general.

[00:13:46]
Amazon is such a massive, massive ecosystem that other ecosystems exist on top of it like a shark and pilot fish. And what I mean by that is, don't feel limited by the observability that you even see here. Like I said before, we are trying to create observability and we are gaining that.

[00:14:07]
Like, if I want to, I can go and take a look at my network observability in the VPC section. If I want to take a look at my database observability, I can look at the RDS section, right? But it doesn't mean that it stops there. Like, if you've ever heard of Grafana before, there are other solutions like it Grafana Cloud, where you can hook into metrics that are inside of Amazon, create dashboards, create better, more customized metrics that you may have, create more like customized alerts, or change the platform.

[00:14:41]
You don't have to feel like you have to be vendor locked into Amazon even though you're like hosting resources on Amazon. And a good example of that is, for my company, I actually run Amazon Resources, but they're all lambdas. And what I do is I ship all of my metrics to Grafana Cloud.

[00:15:00]
Grafana Cloud's a lot cheaper. You get a lot of really cool benefits out of it. And personally, I just don't like the CloudWatch UI. I'm not a real big fan of it. I like the Grafana ui. And so that's another reason why I use Grafana Cloud as well.

[00:15:17]
So, yeah, you don't have to feel like your monitoring stack and everything like that has to be on Amazon just because you're creating infrastructure on Amazon. But yeah, we've got pretty much everything here. You can click on configuration, you can see that we've got two CPUs, one gigabytes of RAM.

[00:15:35]
You might be curious as to why we have more CPUs than RAM. This is just a default to how databases are provisioned. If you do like a micro or something like that, you might get more CPU versus RAM versus other instance Sizes that give you more RAM versus cpu.

[00:15:55]
So it's just because this one in particular is a very small instance, and it focuses more on giving CPUs versus RAM, in this case. Maintenance and backups, so this is kind of important. I'm not gonna go super down this road, but if you are working in a modernized deployment environment, you're gonna have backups in some sense.

[00:16:18]
Now realistically what you would do is you would probably configure this in the terraform module that created the instance, right? But regardless, you may want to make sure that you set up some kind of like maintenance or backup settings, make sure that it has automated backups. Like right now you'll see mine are disabled, right?

[00:16:40]
That means that if my instance or anything were to die or you know, I needed a restore for any reason, I would be kind of, you know, in trouble. And so it may be good to create, you know, or enable backup. Set it to like a seven day retention plan at least so that I have the last seven days of data if I need to revert or anything like that.

[00:17:02]
Just another thing to put out there. I'm not trying to check every single box, you know what I mean? A lot of this terraform automation is for you to take and play with and build upon and grow. This is just the first step. And that's kind of another thing about taking this scale approach.

[00:17:23]
You don't really stop with the scale approach. You're kind of always adding and growing and things like that. And so you'll always find new things to fix or tinker with or whatever scale is kind of like, again, outside of hardening and things like that. Scale is kind of like one of the last steps.

[00:17:43]
Normally, an application really has.