Terraform

Terraform: Terraform is a tool used to automate the deployment of infrastructure across multiple providers in both public and private clouds. Within this course, you will learn the fundamentals of how Terraform functions, as well as work with a real‑world example to gain hands‑on experience with the tool. We will be focusing on a few topics within the course, including creating a basic configuration and updating that basic configuration with new resources, understanding Terraform components such as variables, provisioners, providers, and more, integrating multiple providers in a single configuration, a core strength of Terraform, and using abstraction and reusable components such as modules to make your configurations consistent and repeatable. By the end of this course, you will be able to dive into the world of automating infrastructure with Terraform by your side, enabling you to be more productive and do more with less.

What You Need to Know About Infrastructure as Code

Overview

Hey everyone. welcome to my course. Before we dive into the wonderful world that is Terraform. First, I want to level set a little bit about Infrastructure as Code. Throughout the course, we are going to be using a lot of terminology that comes from the concepts in Infrastructure as code. And in order to get the most out of the course, I first want you to have a good idea of what I mean when I say Infrastructure as Code. All right, in this module, we are going to first define Infrastructure as Code. We got to start with the definition, right? We need to begin with first principles, what are we even talking about when it comes to Infrastructure as Code? Then we'll get into the core concepts of what Infrastructures as Code is. And finally, we'll talk about the benefits of using Infrastructure as Code. Why would you even use this crazy concept? But first, a definition.

Infrastructure as Code Defined

Infrastructure as Code is provisioning infrastructure through software to achieve consistent and predictable environments. There are a lot of important terms in this definition. A few that I want to call out is the fact that this is all being done through code and software. It's not a manual process. And the goal here is to achieve consistency. That means every time you use code to deploy infrastructure, it does so in a consistent way and that the environment you get at the end is predictable. It's the environment you defined in your code. To achieve this goal, there are some core concepts to talk about. The first and this should be fairly obvious, but I feel like I need to say it anyway, Infrastructure as Code is defined in code. You are going to be creating files and writing code using some sort of software language to define your infrastructure. And whether that format is JSON, YAML, or HashiCorp configuration language, Infrastructure as Code is code first and foremost. The next big concept is you should be storing that code somewhere in source control. This is code after all. Might as well treat it that way. The source control management software most people are familiar with is Git and the most popular Git platform is GitHub. GitHub uses Git source control to store repositories of code. The code is versioned, and multiple developers can work on it simultaneously. Your infrastructure you've defined in code should be stored in a versioned source control repository, whether that's on GitHub or somewhere else. When it comes to the actual code, there are two approaches to implementing Infrastructure as Code. There's declarative or imperative. Let's dive into what I mean when I say declarative or imperative with a fun example.

Declarative vs. Imperative

The terms imperative and declarative come up frequently in IAC discussions. Both terms refer to how the user provides direction to the automation platform. With an imperative tool, you define the steps to execute in order to reach the desired solution. With a declarative tool, you define the desired state of the final solution, and the automation platform determines how to achieve that state.
Imperative systems are often initially easier. You could say that an imperative system is organized more like how a human thinks. Imperative systems allow you to continue to think about configuration as a series of actions or steps, each bringing you closer to the goal. Another benefit of imperative language is that it allows you to automate very detailed and complex configurations by building up multiple layers of commands. 

Push or Pull

The last concept to look at with infrastructure as code is are you pushing or pulling configurations with the target environment? In the world of infrastructure as code, Terraform is a push type model. The configuration that Terraform has is getting pushed to the target environment. An opposite example would be a situation where there's an agent running in the target environment, and it pulls its configuration from a central source on a regular basis.

Benefits of Infrastructure as Code

Now, all of this is great, and maybe you're feeling a little hungry now. But first, let's talk about the benefits of using Infrastructure as Code. Why would you go through all the trouble of defining your infrastructure in code as opposed to manually going out and deploying it? One big benefit is the reusability of your code. Once you've figured out how to properly deploy, say, a database server for a particular application, you can take the code for that database server deployment and reuse it in any other application that needs a similar database server back end. Having those reusable components will make your life a lot easier. It follows the principle that developers call, don't repeat yourself, or DRY, programming. Write the code for a component once and make that process reusable so you don't have to repeat yourself. Defining your Infrastructure as Code opens the door to automation. You're no longer clicking around in a portal or banging out commands at a terminal. You can take your Infrastructure as Code and integrate it with an automation process or pipeline with well‑defined inputs and outputs. Once you've added automation, the creation and maintenance of your infrastructure is repeatable and consistent. Each time you need to build out or update an environment, you simply update and apply the configuration. Your new repeatable process can be used to create multiple consistent environments all governed by the same source of truth, your Infrastructure as Code. This is especially important if you want your QA, staging, and production environments to match. Lastly, one of the great things about defining your Infrastructure as Code is you've actually documented your architecture in the process of translating it to code. I've encountered situations where I thought I understood the architecture, but when I went to go define it in code, I realized there were components that I either didn't know were part of it or didn't understand how they worked. By defining my infrastructure deployment with code, I now had a deeper and better understanding of how my architecture was actually working. That's a huge benefit when everything is documented in code. Those are just a few of the benefits of Infrastructure as Code, and we haven't even touched on the auditing, compliance, security, and testing, but I think you get the idea. Once we dig into using Terraform, you'll see how all these benefits come together.

Deploying Your First Terraform Configuration

• Installing Terraform
• Terraform Object Types
• Configuration Block Syntax
• Reviewing the Base Configuration
• Terraform Workflow
• Deploying the Base Configuration
• Validating the Deployment

Using Input Variables and Outputs

• Working with Data in Terraform
• Input Variable Syntax
• Terraform Data Types
• Adding Variables to the Configuration
• Local Values Syntax
• Adding Locals to the Configuration
• Output Values Syntax
• Adding Outputs to the Configuration
• Validate the Configuration
• Supplying Variable Values
• Deploying the Updated Configuration

Updating Your Configuration with More Resources

• Adding New Resources to the Configuration
• Using the Documentation
• Updating the Network and Instance Configuration
• Adding the Load Balancer Resources
• Working with State Data
• State Data Scenarios
• Terraform State Content and Commands
• Deploying the Updated Architecture
• Updating the Outputs

Adding a New Provider to Your Configuration

• Terraform Providers
• Terraform and Provider Block Syntax
• Specifying Required Providers
• Adding the Random Provider
• Creating IAM and S3 Resources
• Viewing the Updated Configuration
• Planning and Dependencies
• Updating the Load Balancer and Instances
• Post Deployment Configuration
• Provisioner Syntax
• Updating the Startup Script
• Formatting and Deploying the Updated Configuration

Using Functions and Looping in Your Configuration

• Loops in Terraform
• Count Syntax
• For_each Syntax
• Looping Targets
• Updating the VPC and Instances
• Updating the S3 Bucket Objects
• Path Expressions
• Terraform Expressions and Functions
• Common Function Categories
• Functions for the Configuration
• Adding a Naming Prefix
• Validating and Deploying the Updated Configuration

Using a Module for Common Configurations

• Terraform Modules
• Module Structure
• Module Syntax
• Adding the VPC Module
• Creating the S3 Module
• Fixing a Failed Run