Introduction to Terraform

- What is Terraform? Let's use HashiCorp's own words to describe this product, and we're going to break it up into sections. "Terraform is an infrastructure-as-code tool that allows you to build, change, and version infrastructure safely and efficiently." Okay, that helps a little bit. Let's add some more to that. "This includes low-level components such as compute instances, storage and networking, as well as high-level components such as DNS entries, SaaS features, et cetera." Okay, that's a little bit more detail and that gives us a little bit more color. Let's close it out with the final statement. "Terraform can manage both existing service providers and custom in-house solutions." For this particular course, we are going to look at a little bit of both, we're primarily going to be using an AWS provider, but we are going to create some custom solutions within that in order to achieve our goals. There is a section of this that I want to drill down a little bit deeper into, infrastructure-as-code. What is infrastructure-as-code? Well, this is going to help you use automation to deploy infrastructure. Well, we know that Terraform is an infrastructure-as-code tool, so that makes sense, but this is going to help us take advantage of DevOps principles in terms of reliable quality deployments that are also repeatable. And we want to be able to perform all work using code where it makes sense to do so, as an acknowledgement that infrastructure-as-code, while it is a very useful tool, it's not perfect. There are two types of infrastructure-as-code. The first of these is imperative, and this leads us to use the command line or scripts in order to get work done. And there's no guarantee of item potency when we do this. What is item potency? Well, item potency means that, if you were to execute the same task over and over and over again, you would end up with the same resulting state rather than having multiple resources deployed. And so with an imperative infrastructure-as-code, you get a lot of flexibility, the ability to do whatever you want, but you lose some of that item potency. And so here's an example of just using the AWS command line to create a Kinesis Firehose delivery stream. And in some cases, if we were to enter this command exactly over and over again with the same variables, it's going to recognize that the resource is already created. But if we were to use another command, like one that allows us to create a new EBS volume and execute that over and over and over again, every single time, we would get a new volume. And so that wouldn't be item-potent. The other type of infrastructure-as-code is declarative. Declarative is going to use more structured text files or templates rather than command lines and scripts. And with declarative, you get some sort of engine on the backend that's going to compare the template to the existing resources, determine the gap, and then fill that gap. Declarative infrastructure-as-code is usually item-potent, and here's an example, using Terraform to create an EC2 instance, and you can see that the format is very different than using the AWS command line. Next, what about some benefits of infrastructure-as-code? I've kind of alluded to some of them, but it can help us with faster deployments because infrastructure-as-code tools are going to tend to use parallelism to deploy as many resources at the same time as possible. We get faster infrastructure changes too because it's only going to look at the gap between the template and reality to provide that difference. We get faster recovery with the ability to roll back, that's something with a command line and scripts that's really difficult, how do you roll back if it fails? You get less configuration drift because you don't have click ops happening, you don't have somebody getting into the console and making manual changes outside of using infrastructure-as-code. You get reusability of code as well, so you could take the same template and apply it multiple times by just changing one or more variables. You get version control because you're treating your infrastructure as code, it's right in the name. Those templates become your source code and you should treat them accordingly. And finally, it helps your infrastructure to become self-documenting. Now, let's take a look at some of the Terraform constructs that we're going to be using as part of this course. First, we have actual resources, and so this is going to be all the different object types that we see in a Terraform template, like an EC2 instance. We have variables, and these are the parameters which can help make our templates reusable, and it gives us the ability to consolidate any hardcoded values into a central location. Next, we have modules, and this is a more advanced usage of Terraform where we create multiple resources, but make it appear as a single resource, and so we're going to obfuscate all that extra work behind the scenes. Next, we have outputs. And so this is going to be the resulting resources, being able to query the properties that comprise them or other values that we want to be able to access between different stacks. And so that leads me to backend. This is going to be where we store the state files as well as our lock files to allow us to perform this work across teams of people without them stepping all over each other's work. And finally, we have remotes, and these are directly related to outputs because this is what we're going to use to be able to query the content of those outputs from one stack to another across our infrastructure. Now, let's take a look here at Terraform and AWS. If we deploy resources from a laptop or a desktop, so we provision some AWS resources, we use Terraform to do it, what happens? Well, we have a lock file that's stored locally, and this prevents multiple actions from the same client operating system. We also have the resource state and the outputs, and those are stored locally as well, this is all the default configuration. This is a single point of failure. This doesn't account for somebody's laptop being stolen or becoming unavailable for some reason, and this doesn't allow for collaboration really at all. So what do we do differently? Because this isn't a resilient design, this isn't going to help us meet DevOps principles. What we do instead is we take advantage of Terraform's ability to store state files in an S3 bucket, and then we can access those state files from anywhere that we have access to that S3 bucket and the objects. We are also going to store the lock files in a DynamoDB table, which will allow us to collaborate and the ability to essentially check out a particular stack of resources so that nobody else can make changes while that is going on.