Infrastructure as Code with Terraform

0:00Hey friends, welcome to the HashiCorps Certified Terraform Associate Certification here on CBT Nuggets. Now this particular version of the examination is 004 and pretty much this examination is going to be a multiple choice examination but that doesn't mean we're just going to spend all of our time talking about theory very much instead we're going to be getting hands-on and beginning to really learn how to use Terraform to manage infrastructure. Now the first thing that I would like to highlight to you is in this particular examination as you can see right now for this particular version the Terraform version that has been tested is Terraform 1.12 so that is the version that I'm going to be using in this particular course and this is the one that I recommend that you also have at home. So the thing is Terraform is a quick moving piece of software there's going to be newer versions you might be tempted to get a later version but I really would just encourage you to stick with this particular version and get comfortable with it. So friends if you just go to the actual website and you look at the objectives you're going to see some of the things we're going to be talking about within this particular course as you can see it's jam-packed with a lot of good stuff so we have things like the basic Terraform fundamentals discussing things like providers we'll learn how Terraform uses and manages states and we'll also get to dive through a whole bunch of other topics

1:17that are super super fun things like Terraform configuration so actually getting hands-on using things like variables and understanding outputs changing our infrastructure in this declarative manner. Now as you can see here by just skimming through the actual objectives there's a lot more than I can just talk about right now but as we progress out this course as you're going to learn we're going to cover all of these subjects in great detail. So for the moment before we begin let me just tell you a little bit about my little environment that I have right here. So in my case here my primary workstation is going to be an Ubuntu virtual machine this is where I'm going to be installing my software this is where the main automation is going to happen. Now what I will say is if you happen to go and download Ubuntu you might notice that your system looks a little bit different from mine and the reason being is because whilst I'm doing all the work on Ubuntu I'm actually connecting to Ubuntu via an SSH connection and I'm actually using a different style of Linux it's a kind of new popular style of Linux and this is known as Omachi. Now the only reason why I'm using this is because of the tiling options okay it makes it really really good for my recording to actually have these different windows and control the size this is not a prerequisite for you at home to also go and install it. If you just go and download plain old Ubuntu that is going to be perfectly fine just for you. So really this additional step is just a kind of

2:34form of beautification because it makes the recording process a little bit easier when I have multiple windows. So don't get hung up on it that's what I'm saying okay now the main things that we want to be talking about are the actual tools that we have installed on the system like I say I happen to be on an Ubuntu machine which as we can see right here I have Ubuntu 24.04 and what I also will say here is that this particular skill really is just an introductory skill we'll talk about actually setting up our environment from scratch in the very next skill within this particular course so do not worry about it right now but in the meantime what I want to show you is that I do actually have Terraform installed at this particular stage and the version like I say is version 1.12 very very important what you'll also notice by the way is that I have an ARM based architecture that is because I'm actually recording this inside of a virtual machine and my actual primary computer actually is an M1 MacBook so it's got the Apple silicon so because of that I need to have the ARM based architecture if you happen to have a different style of architecture definitely don't worry about it just install Ubuntu and it's going to be quite just fine now similarly also installed on my system right now I have Docker as we can see right here and I've also got something really really cool and this is known as LocalStack now if you've not heard of this it kind of acts like an emulation of Amazon's AWS so as opposed to you

3:54having to connect to the cloud and pay money to spin up particular services and interact with AWS you can kind of do this simulation by speaking to your own local system via LocalStack and it kind of allows you to perform the same types of workflows as you ordinarily would with AWS so friends that's just a brief little introduction as to what we're going to be doing and the general setup of things with that now out the way let's go and get to the meat of things and begin talking about Terraform

0:00All right, friends, before we actually dive into Terraform, what I want to do is to show you some of the other ways in which you can potentially manage your infrastructure. And basically what I want to do is I want to highlight their kind of shortcomings and as to why Terraform might actually be a better solution. So in this case here, what I'm going to be doing is talking about building a simple little Docker container. And pretty much this can be done in different ways. For example, perhaps the most obvious example is say, for example, you wanted to go and build this out in AWS, okay, so within the cloud itself.

0:33One way in which you could do this is you could go to the AWS website and you can log in and go onto the actual console and begin clicking things, you know, clicking the little buttons, getting the actual thing set up. So for example, if I just showed you AWS console for a moment, let's just go to the images. Okay, so right now we have an image of what the website actually looks like. So say, for example, you want to go and build a virtual machine, you could then go and click on this particular icon and that would take you to another page. You could then click on more things, tick more boxes, so on and so forth.

1:07So like I said, this is one way in which you can do this. And the kind of beauty of this method is you're not worrying about writing codes or doing anything too complex. You know, you just point and click and point and click and then eventually the resource that you want ultimately gets created, but there is a bit of an issue here. Say, for example, a bit further down in the future, someone says to you, hey, by the way, see this particular service that is configured, why is it configured that particular way and who perhaps set it up? Well, the reality is this might actually be a little bit of a mystery.

1:37There is no obvious record as to who did the thing. Now, even more problematic than that, let's say, for example, you wanted to go and spin up another similar service, perhaps any different zone or a different region. Well, once again, what you're gonna have to do is to go to the website and begin clicking through all these options and just hope you remember that you do it the same way. Worse yet, let's say the website has been updated and things are actually different. This suddenly can be quite complex and it's not a reliable way to have a reproducible service. And this is certainly not a reliable way in which to manage your infrastructure.

2:11Here's another problem as well. Let's imagine you want to have a large scale of things being created or perhaps maybe you have to deploy something really quite quickly. Well, you can imagine that powered up with lots and lots of coffee if you're trying to under the clock with your boss looking over your shoulder, trying to frantically click through all of these particular options on this particular webpage, hoping you don't miss a box and just trying to do it as fast as you can, this is very error prone. So whilst this is a kind of low barrier of entry, it really isn't difficult to get things stood up for the first time, but it's not a robust way to manage your services.

2:47So scratch that, let's actually talk about a second way in which you could do this. What you could do is you could go and write a simple little script. So the advantage here is that you have the logic written in a text file. You can then save that particular file into some type of version control system, such as Git. So you have a full record of the changes. You know who did it, you know when, and it is easily deployable because you just effectively execute the scripts. So for example, this could be a Python script or maybe it's going to be a bash script. The point is, is that it's a little bit better than trying to click your way through all of these particular boxes on the websites.

3:24So take for example, something that I just talked about. Let's say we want to go and deploy a container, okay? And in my case, I'm going to go and deploy it using a bash script. So what I've got here is a little file called provision.sh. Okay, so not to turn this into a lesson on bash. All we have here is a fairly simple script. At the top here, what I'm doing is effectively saying that if we happen to have an error, we want to exit on that particular error. And then all I'm doing here is then running some commands. I'm trying to build a container called web with these particular port mappings.

3:57And it's based on this particular Docker image. And then after that, what we do is we echo out or print out the statement, creating container web, and it's done. Then as a little test, what we do is we copy this particular text into this particular file. And then at the end, we get this particular thing here. So pretty much it's a little bit of a frivolous example, admittedly. But the point is, is that all the steps are effectively in this script and I can just execute them and then have all of these steps take effect. Okay, so check it out. Let's go back here, okay? So first things first, if I do a listing, we're gonna see here that the greeting file does not actually exist.

4:31And if I happen to look at my Docker containers, we don't actually have anything running. However, watch what happens if I say execute that particular script. So if I go and just hit enter here, check what happens, okay? It says creating container web done and writing the greeting file. So if I do a listing now, indeed, we can see here the greeting file was created. And more importantly, if I do a Docker PS, we can see here that the container was created. So all I had to do here was just execute the script way, way easier than perhaps, you know, clicking about on a website, that type of thing.

5:04So this can be a little bit better, but there is a little bit of a limitation. Watch what I mean, okay? Say for example, I don't know that this particular service is up and running and I try to run the script again, okay? So if I hit enter, check this out, we get an actual error. It says here we have a conflict. The container name web is already in existence. So we got an error on the system. So because of this, effectively, the script just died. Now, what you could potentially do is inside the script, you can have particular logic written to say, hey, by the way, before you try to create it, go and check this, go and check that.

5:37Make sure it does not already exist before you try to create a copy. That is what you can potentially do, but this just begins to make things more and more complex. So check this out. What I'm gonna do here is actually remove this particular container, okay? So if I hit enter, it's no longer there, like so. And instead, this is where the drum roll comes in. What I'm now gonna do is to actually deploy this particular container this time using Terraform. Now, the whole purpose of this is I'm trying to highlight something to you about the way Terraform works. Terraform is a declarative tool.

6:08So let me just go and demonstrate how this works so we can actually see it in action, okay? So what I'll do here is I'll create a little directory. Let's just call this like demo or something like that. And I'll go inside this directory, like so. And what I'm gonna do here is to create a file called main.tf, okay? So open this up. Okay, so inside of here, what we have is a basic Terraform configuration file. Now, what I will say is that if this is the very first time that you're seeing Terraform, this can kind of look a little bit intimidating. You know, I'll just fully admit that that's the way I felt when I first saw it. But for the moment, don't stress about the actual syntax.

6:40We'll talk about that in an upcoming skill. Just very briefly, what I want you to note is we're trying to create a Docker container and it's gonna be called web, okay? And we have the actual port mappings specified right here. Now, one thing I just want you to note here, just as a kind of brief aside, I'm not actually writing any type of specialized logic saying, you know, check if this container exists or anything like that. We've just specified this is what we want. So with that said, let's go and begin the execution and see what actually happens, okay? So first things first, what I'm gonna do here is initialize the directory using Terraform init.

7:12Just give that a moment. And what I'm now gonna do here is just say Terraform apply, and I'm gonna say dash auto approve. We'll talk about all these commands in an upcoming skill, like I said, but for the moment, just bear with me. So if I go and hit enter, watch what's gonna happen, okay? We effectively go and create that resource in a flash. See that right there? One added. If I now say docker ps, we're gonna see here, we have just created that container seven seconds ago. But the beauty is this. Let's say I try to rerun this again. Previously in the bash script, what we got before was a big fat old error.

7:44Now in this case here, things might look a little bit different. So check this out. Okay, I'm gonna go back and I'm gonna arrow up and try to apply the same configuration. Watch this, okay? Look at that. No errors, but nothing was added. Terraform just happened to realize that it already existed and it didn't try to recreate it. It already had the intelligence to understand that context. And this, my friends, is exactly what we're talking about with declarative configurations. We're not having to worry about what already exists. We just specify what we want our end state to be and the system itself is smart enough to make that a reality.

8:20So if nothing happened to exist, what Terraform would have done as we saw it would create it. But if it already exists, it's gonna go and leave it alone knowing that it already exists. Now, one last concept that I want to talk to you about just before we end this video. There are two main kind of skills of thoughts with respect to configuration management. We can have this idea of mutable infrastructure and we also have another approach known as immutable infrastructure. Now, when we take a mutable approach to our configuration management, we are effectively leaving the thing in place and just making changes to it.

8:52So we upgrade it, we patch it, we make small changes as we go on. Whereas, if you happen to have an immutable approach to your infrastructure, what that means is that when you happen to build something, you don't actually change it. You leave it as it is. It is immutable. So the question, therefore, you might be thinking, what if you really do need to change some particular configuration? Well, the answer is in the immutable approach, you don't change the existing one. You just pull it down, destroy it, and build a brand new one with all the changes that you want to see.

9:22So you're not actually changing an existing container or an existing service. You fully remove it and rebuild the new one with the changes that you want to see. Now, admittedly, this might seem a little bit bizarre at first. It might seem a little bit wasteful. But to be honest with you, there is actually a very, very good reason to do this. Ultimately, it makes your environment much more predictable, much more easy to manage. And quite honestly, this is the type of approach that configuration management tools like Terraform actually prefer. So friends, now that we're beginning to get a rough taste about how Terraform actually operates, let's talk about a little bit more of the details in the very next video.

0:00All right, friends, let's now talk about the subject known as infrastructure as codes. All right, so this is a pretty weird term. What on earth are we talking about? Well, our infrastructure, that refers to things like our servers, our networks. This could be like Amazon SD storage buckets, that type of thing. Now, the thing about this is, well, when we're actually making it as code, what this refers to, we're talking about actually defining all this information in particular configuration files. So, like I say, as opposed to clicking a little graphical user interface, just like we saw with Terraform, we can actually define these in machine-readable files.

0:37This is what we're talking about. And the cool thing about this is that these files, like I say, can be put into version control systems, which, if you're unsure of version control, that is just a way for us to keep a record of a particular file and all of its changes. So that would be using a tool such as Git or uploading the actual information onto GitHub, that type of thing. And pretty much this is all we're talking about when we're talking about infrastructure as code. We want all our configurations, all of our infrastructure to be represented in these files, say, for example, in a version control system.

1:08So really, like I say, the kind of gold standard goal here would be to have our declarative configurations. So this would be representing our actual end states that we want to actually have. So the amount of servers that we have, the style of servers and their ultimate configurations. As you mentioned, we want that to be version controlled so we can actually see every particular version of every particular change we make. And the cool thing about this is, like I say, this allows things to be very repeatable. Because, say, for example, you want to spin up a new instance of a particular service, well, you already have these version control files.

1:41And what you can do is just make a slight modification, perhaps change the target zone, that type of thing. And then suddenly, your automation system can read in those files and then basically replicate that same type of environment in the new zone. So really, all of this is automation-friendly. This is what we're looking for. So for a moment, let's just think about what we saw in the previous video when we talked about our bash script. Now, this kind of embodies some of the attributes that we're talking about here, but it doesn't fully do so. For example, the bash script, well, it is automated, as we saw.

2:13You know, it is actually scripting out these changes. The bash script is your regular text file. So, of course, it can be version controlled, but it is not declarative. This is what we're talking about. This is one of the kind of limitations of doing this type of scripting. So now here is the next concept that I want to talk to you about. And this is a kind of a weird word. You might be thinking that I'm just making it up, but it really is a word that really has a meaning. And this is talking about things being idempotent. So say, for example, let's imagine this, okay? Let's imagine you've got a car key, okay? Now, you're going to have to go and really forgive my terrible artistic skills, okay?

2:46This is about as good as I can do. So imagine I've got a lock button and imagine I've got an open button. So let's say you get out of your car and you're going to go and do some shopping. So you get out and you press the lock button. So suddenly, what happens is you get that... And then because of that, as a result, what happens is your car just locks up. It's suddenly in the lock state. Now, here's the thing. What happens if you press the lock button again? Nothing actually changes. The actual end state is still the same. The car is ultimately still locked.

3:17The only difference is that when you happen to try to invoke a change in its state and you press the other button to open it, then something actually happens. Now, this is kind of what we're talking about with respect to idempotence. Realistically, what we're saying here is that when you perform a particular operation, when that operation is idempotent, it doesn't really matter how many times you do that particular operation. You can do it once, you can do it 15 times. You're going to have the exact same end state results. Now, if you happen to remember what we saw in the previous video when we happened to look at Terraform, when we said Terraform Apply, when there was no actual Docker container configured, what it did was it made the actual change.

3:55But once the actual end state matched our desired state and we reran the same command, nothing actually happened. We still had the exact same end state. The one container was still existing. And if I just reapplied and reapplied and reapplied, we would still have the exact same state, just like pressing the lock button on your phone or on your phone, on your car keys over and over and over again. Until you actually make a meaningful change, like pressing the open key or changing the actual outcome, you know, like maybe spinning up a different type of Docker container or deleting the Docker container, that is only when a change is actually going to happen.

4:31So all of this is to say is that Terraform acts in an idempotent manner. This is actually by design. So for example, if I just happen to look at my terminal right here, and what I'll do is I'll create a little directory, let's just call this idempotent. And I'll go into that directory. And what I'll do is I'll create a new main.tf file. Okay. So friends, once again, we're not going to go and sweat about the actual syntax right here. We'll talk about that in a later skill. But like I say, what we're doing here is we're just going to use Terraform to create a simple little text file called test.txt.

5:02And inside of it, it's going to have this particular content. So again, right now, this particular file does not exist. So what I'm going to do here is to run Terraform and try to create it. Okay. So let's just save this like so. I will once again initialize Terraform. Let's give it some time. So there we go. So what I'll do here is I'll say Terraform apply. And again, I'll just say auto approve. So if I enter, give it a moment and bam, the resource was added. So if I now do a listing inside this directory, we can see here we actually have this file called test.txt.

5:32And if I happen to open up the contents, what we're going to see here is it says hello from Terraform. Now, the beauty is, is if I try to rerun it and we have no change at all, the end state is already as it is, nothing is going to change. We're just pressing the locked button over and over and over again. So again, rerun, nothing changes, as we can see right here. And again, if I open up the file, nothing has actually been modified. And I can just keep doing this over and over and over again. Nothing is going to change. However, if I go back into the file and I perhaps change something, maybe, you know, the actual file name or the contents.

6:04So let's maybe go and say hello from Terraform again. So it's actually changed this time. Because this is going to be a different end state, well, the change is actually going to be implemented. So now if I rerun Terraform and hit enter, look at this. One has been destroyed. You see this right here, and then one was added. This is what we're talking about with immutable infrastructure. We didn't just go and modify the currently existing one. We fully deleted it and then recreated the new one with the new content. So now if I open up this particular file here, we have the new one with this particular content.

6:35And I could just keep running it. And until a change is actually detected, nothing is going to be changed right here.

0:00All right, so the next thing I want to talk to you about are the business's advantages of infrastructure as code. Because here's the thing, us as engineers, we kind of think about the best ways that it can help us with our own workflow, but realistically, to actually get things in reality, in the real world, it kind of has to make business sense. So imagine, let's say you're talking towards the big boss, okay, the one that's in charge of your budget, the person who signs off on the type of software that you can use. Realistically, if they're not an actual engineer, they don't care about the differences between declarative configuration and compare that to imperative configuration.

0:35That really isn't what is driving their thought process. And I mean, why should it? Why should they care about these particular technical terms? They're not going to, but there are certain things that they will understand, and quite honestly, this comes down to things like money, which is obviously very important for a company. So let me just give you some examples of why using infrastructure as code can actually make sense, in a financial sense, to your actual boss, to the one that signs off on this type of stuff. So, drum roll, please. Well, the first thing I'm going to tell you about is, well, it's quite an obvious one.

1:07This is actually the speed of deployment. So imagine previously, you used to go and click about on a graphical user interface, trying to spin up things and, you know, trying to deploy a whole infrastructure in a particular area. Maybe this took days or perhaps even weeks. Whereas, if you happen to have infrastructure as code, you can just have Terraform deploy the state or any modifications that you need, and then suddenly, bam, everything has changed and you have the outcome that you want, your desired state. So this isn't just a cool thing for engineers because, you know, it speeds things up.

1:40That's a cool metric, we do care about it. But realistically, in a business sense, what speed ultimately means is that you're spending less time doing a particular task, meaning that you can be more productive elsewhere in the business, elsewhere in the environment. Not just that, by the way. Say, for example, you have an engineer who has written your infrastructure as code. If you want to just go and deploy these changes with minimal updates, perhaps this is now possible for the junior engineer to handle as opposed to the senior engineer. Ultimately, what this means at the bottom line is that the employer can pay less experienced people, people who do not cost as much to do the actual job.

2:18Now, in a similar sense, another advantage we could have using infrastructure as code is consistency. Now, from our point of view, perhaps that just means having a production environment and then maybe a staging environment or a test environment. And we kind of think about this in more technical terms, whereas with respect to the person making the business decisions, what you can actually tell them is that this translates into less downtime, which ultimately saves money. Now, another potential advantage could be the fact that you effectively have an audit of everything that is happening. So, for example, if everything is done in version control, every change that is made is ultimately logged.

2:53So, whilst for you as the engineer, this might be, you know, a kind of a handy feature to have, with respect to your manager or your boss, this can mean something a little bit extra. You can effectively tell them, by the way, when a particular auditor wants to know what actually happened, you know, like who actually deployed this particular VM on this particular site, or who changed this security configuration. Well, if everything is done as infrastructure as code and it's all in version control, you're going to have a full audit of everything that happened and who made the change and when.

3:23So, this is really, really good for company compliance. So, for example, and I'm not going to go and deep dive and to get too deeply at all, I just want to give you a rough idea about what this might actually look like. So, check it out. If I just say mkdir and I create a little directory, let's just call this git demo, okay? So, I'll go inside of here and I'm going to say git config global and I'll specify my name is going to be, let's just say, John McGovern and I'll also specify my email is like john at example.com, okay? Let's just imagine that's my email, okay? So, what I could do here is initialize this particular directory and let's imagine we have some type of configuration file for a particular site, okay?

4:00So, I'll say site.cfg and as opposed to trying to write some real configurations, let's just write some dummy stuff. So, I'll just say this is just some configs. I'll just write the changes and what I'm going to do is I'm going to put this into version control. So, I'll just add it and then I'm going to go and commit this, which ultimately writes it in to the log file. Again, don't worry about the details of git too much and I'll just have a message saying first configuration, okay? So, if I say git log, we're going to see here I have an insertion in that particular log. We have the name of the author who actually made the change, their email and the time and date of when this particular configuration change happened.

4:34We also get a little description or a message. So, for example, if later on I happen to go and modify that particular file, so go inside of here and then just say this is some more configs I'm adding and again, just save it. I'll state the change and I'll just have a message saying adding a second line of configuration. Again, insert it. So, now once again, if I look at the git log, we're getting a full audit of what is happening. We can see here I had the first configuration and then about two minutes later, I added a second line of configuration. Who did it? John McGovern at this particular email.

5:05And say, for example, the configuration change is quite complex. What I can do is I can compare the actual snapshots. So, for example, if I say git diff and then if I just take a copy of this particular commit or at least some of the first identifying characters such as these right here and I paste it and then I say compare it against this particular commit. So, let's grab some characters here which identifies it and just compare them both. If I hit enter, look at this right here. What we're actually seeing here is that the original file just said this on its own whereas the new one, this is what we actually have.

5:37We have this second line that has been added like so. So, really as we can see here, as we're making changes to our entire infrastructure, we're kind of telling a story. We're saying who made the changes, why they made them and what changes actually happened. So, then again, if you can imagine you had some really bad problem, this is quite a good thing for disaster recovery because you actually know what changes were made and when they were made. And if you want to go and roll back out of danger, you can just go back and call a previous version of a file and then go and deploy that old configuration, ultimately rescuing the situation and fixing the damage.

6:12Now, you'll also notice, by the way, just by virtue of having infrastructure as code, this is kind of self-documenting because pretty much all of your configurations are, well, within basic text files and every single change has been logged. It's just like a living, breathing document, everything that you're doing, everything that you have. And again, you do not have to do anything special. This is just a byproduct of the very nature of this type of approach. And again, one final thing, and this really cannot be overstated, we have a great reduction in human error when we happen to deploy these type of systems because as opposed to you trying to frantically click or frantically type out configurations, if you happen to have your state defined in a particular file to actually make the changes that you're trying to implement, it can be just as simple as typing terraform apply and then suddenly all the changes that you have defined, they are a reality in your environment.

0:00All right. So one of the things you want to know with respect to Terraform is just who actually compares with other utilities in this particular sphere. So, for example, if you are used to dealing with infrastructure, you might have heard of other tools such as let's maybe say Ansible or perhaps maybe you've heard of something called Chef or Puppet and there are tons and tons of these different types of tools. So here's the thing I want to do here is to draw a line in the sand and really differentiate between two different categories of these tools. One happens to focus in on infrastructure provisioning, whilst the other one is focused in on configuration management.

0:36Now, just looking at these particular terms, it might not be so obvious as to what the difference actually is. Now, realistically, the tools that happen to provision things, they really are all about building the actual infrastructure itself. Whereas the configuration management tools, they actually decide what actually is configured inside of the infrastructure, what is running on the infrastructure. So imagine you happen to have a plot of land, okay? And on that plot of land, what you're going to do here is build three different houses. So what you do is you go and contact a building contractor and they go and build those houses for you.

1:09So this can be house number one, this can be house number two, maybe it's a little bit bigger. And then we also have house number three. So in terms of the foundations, the cement, the joists, the plumbing, all that stuff was done by the actual builder themselves. So now we have these three buildings available. However, what actually goes inside of each of these buildings is not the job of the actual builder. So instead, what you could do is get an interior designer to design each of these three so they are unique. So in this one here, we have particular paint colors, we have particular furniture, maybe it's more rustic.

1:41Maybe this one here is a little bit more grandiose, you've got chandeliers, that type of stuff. And maybe this one here is more modern and practical with more modern appliances. Whatever it may be, the point is there is a clear separation between the duties of the builder and the interior designer. Now this is in effect what we're talking about with respect to provisioning infrastructure versus configuration management. Provisioning infrastructure would be the person who is building the houses. You know, they're saying how many houses actually should there be and how big are they, what are the shape of them.

2:11Whereas when they're up and running, what goes inside of them is the purview of the configuration management tool. So to put it a little bit more concretely, let's say you want to spin up three virtual machines out in the cloud. So here is VM1, here is VM2, and here is VM3. Now let's say that this particular machine is going to be an Ubuntu machine. And let's maybe say it's going to have 100 gig of disk space and let's maybe say four CPUs, whatever it may be. This one here can perhaps be like Red Hat Enterprise Linux. Maybe this one has 200 gig of disk space and let's maybe say it's got eight CPUs.

2:45And over here, let's maybe say this one here is a Mac OS virtual machine, okay. This one here also has 100 gig of disk space and let's maybe say it's got six CPU, whatever it may be. These values don't really matter so much. The point is, is that these are the actual buildings. These are the things that would be deployed via the provisioning tool. Now once these machines are up and running, the provisioning tool has no real say as to what goes inside of them, how they're actually going to be run. So let's say they're all up and running. And on the Mac OS virtual machine, you want to have like, say, Adobe Premiere installed, okay.

3:18Well, this decision to have the particular software running on the actual machine, this was not made by the provisioning tool. This was made by the configuration management tool. Similarly, let's maybe say on the Ubuntu machine, you want to have an Nginx web server running on it. Once again, that would be the purview of the configuration management tool. And maybe on this one here, you want to have like OBS to do some streaming on, okay. Again, this would be installed via the configuration management tool. Now when it comes to the type of tool that Terraform is, Terraform really falls into the provisioning style of tool.

3:48It's the thing that spins up things like virtual machines and containers, that type of thing. However, once the virtual machines are up and running out in the cloud or whatever it may be, when you want to install things like Premiere or OBS or Nginx, that would be done via a different tool, a tool such as Ansible. So what I want you to really know is that tools like Ansible and Terraform, they're not really competitors. They really work in harmony together. And similarly, it's not just Ansible. So you have Ansible. You have Chef. You have Puppet. All of these are examples of configuration management tools. They don't build the virtual machines.

4:20They don't build the containers. They can reach into existing virtual machines and install software on them and configure them and make the changes and add files, that type of thing. But they don't go about actually creating them in the first place. Whereas the creation of these virtual machines, that would be explicitly the type of thing you would do with Terraform. But again, as you might imagine, this is not the only tool that can do this type of provisioning. So another tool you could use for this type of job would be AWS CloudFormation. Another one you could use would be Azure's Bicep. But one of the big limitations of AWS CloudFormation is that it can provision things, but it only provisions things in AWS's cloud.

4:56Similarly, with Azure Bicep, this provisions things, but it only provisions things within Microsoft Azure. Whereas with Terraform, Terraform could talk to AWS. It can talk to Azure. It can talk to Google Cloud. It really is independent of a particular provider.

0:00Okay friends, so we kind of closed on the idea that Terraform was kind of platform agnostic, meaning that if you want to use it to manage your infrastructure in AWS you can or in Microsoft Azure you can, in Google Cloud you can, it really can do all in that regard. So the whole point is is that regardless if you're talking to AWS or Azure or even on your own local system, perhaps you're building infrastructure there, when you're using Terraform the workflow really is the same, you do your Terraform initialization to initialize a working directory. You can then issue the Terraform plan command, which we've not actually seen yet, but this will tell you what Terraform will actually do before it actually does it. And then when you're happy to execute you can say Terraform apply regardless if you're talking to AWS, Azure or locally, it's the same type of workflow. What ultimately happens is you talk to these endpoints via a type of abstraction layer or a translation layer known as a provider. So in essence what that allows you to do, it allows you to define your end states in a really kind of standardized way in your main configuration file and all you do is in that particular configuration file when you're talking to AWS you say hey by the way use the AWS provider and what it does it takes the actual desired state that you have configured in your main.tf file and when you're talking to AWS it does all the AWS tricks to make sure that

1:19AWS actually understands the request, whereas if you're talking to Azure you write your same style of configuration file. You just mentioned by the way I want to use the Microsoft Azure provider so then it goes to the translation layer and then it makes sense to Microsoft Azure so on so forth. This is how things actually operates. Now this might be a little bit confusing at first, I know when when I first heard about it I still was like I don't really know how that's working. Don't worry about it, we're going to be looking at this in detail in an upcoming skill. In fact I believe it will be the next skill we'll look at providers in detail and it really will make more sense when you see it hands-on. But really just try to conceptualize that it's kind of like a plugin and that it just tells Terraform how to talk to a particular API for a particular platform.

2:04So whether it's an AWS provider, an Azure provider, a Docker provider, a GitHub provider, whatever it may be there's tons and tons and tons of them. The point is is that regardless of what you're trying to do the actual core of Terraform really stays consistent and feels familiar when you're using it. Now let's just whilst we're on this subject let me just kind of define a few terms okay. You might actually hear this a few times we hear this term called a multi-cloud. What on earth does this actually mean? Well as it might actually sound like it really is referring to that you might have your infrastructure in multiple different clouds so it's not just all in AWS.

2:38Some of it might be in AWS but other parts of it might actually be in Azure that type of thing. By virtue of your infrastructure being in multiple different clouds this falls under the term of multi-cloud. Now there is another one which is kind of similar but it's a little bit different this one is called a hybrid cloud implementation. Now a hybrid cloud really is when you're mixing public cloud infrastructure like you're actually talking to AWS or Azure like I said but you're also using things on-premises so you also have things locally within your own network. So it's a kind of a hybrid of the cloud you are using the cloud but you're also relying on your own infrastructure as well. So for example you maybe you're using AWS but you're also using like VMware locally inside your own data center. The point is is that Terraform can still deploy all this it can still handle it no problem at all. Now just one last thing to close here because I really just want to make this very very clear. When we're using Terraform like I say we get that abstraction so that if you want to talk to AWS or if you want to talk to Azure you can in the same type of workflow as we talked about. Terraform init, Terraform plan, Terraform apply and as we learned all of this is made possible via the use of providers. Now one thing I want to highlight to you because providers can't actually change the underlying details of the individual platforms.

3:57What on earth are you talking about? Well for example you can use the same type of syntax the same type of configuration files to deploy similar things across these different platforms but there are some things you just cannot do you cannot mix and match. For example as I said AWS they will actually have their own particular terminologies and own particular things. So for example an EC2 instance that only actually exists in AWS. Just because you're doing Terraform you can't just suddenly say I want to have an EC2 in Microsoft Azure because that doesn't make sense to Azure at all they don't use that terminology. So what Terraform can do you can pretty much say you know I want a virtual machine of this type and you can specify it will be an EC2 instance of this particular type in AWS whereas on Microsoft Azure you could deploy an Azure virtual machine and they would ultimately function the same type of way they're both virtual machines but they have different terminologies. Terraform can't just change that part okay it can abstract the way you talk to these providers but it can't change particular details try not to get that confused. Effectively Terraform is really just abstracting away your workflow not the underlying cloud. So basically what I'm saying here is that while Terraform tries its best to make your life as easy as possible so

5:12that you have a kind of standard interface for a way to manage your infrastructure depending on the cloud you're talking to there are just some details that are going to be slightly unique for each of these platforms.

0:00Okay friends, so to wrap up all I want to do is to talk to you about some of the different forms of Terraform that you can actually have okay. So first thing to state here is that you might have heard some older terminology and there are new ways to say these things okay so we want to be getting on the same page here. Okay so with that said the first type that I want to tell you about is Terraform Community Edition. Now like I say there was an older way to refer to this very often people would just refer to as the Terraform CLI some people would refer to as Terraform OSS for open source software but the kind of official name now it's really just Terraform Community Edition and this is what I've been using so far it's pretty much a freeway in which you can use Terraform. It's a command line tool and you just download it and then you can do things like Terraform Init, Terraform Apply that type of stuff. Now the thing about this particular implementation is that it runs locally on your system. So right here on my Ubuntu machine this is where it's installed this is where the state of my infrastructure is actually being tracked although I probably should be a bit clearer there that's maybe a little bit confusing.

1:04What I'm saying here is with respect to our state when it comes to Terraform Community Edition it's your responsibility to manage it so you can manage it locally on your own system but if you want to perhaps outsource this to some type of remote back end some remote storage that you actually manage you can do this via Terraform Community Edition. Now here's the thing it's really good for us doing demonstrations and working alone here just myself but when it comes to a type of enterprise environment say for example you have a team of engineers this isn't really kind of built for that type of thing. There's no real easy way whereby you can enforce policy or whereby you can share your state safely between different engineers. It really is quite a limited version it's good for you managing your own infrastructure yourself doing demonstrations learning the tool but it's not really the enterprise way in which to actually use Terraform.

1:56So now it comes to the second implementation and this one is known as HCP Terraform. Now all this is is HashiCorp's cloud platform for Terraform and this used to be back in the day used to be known as simply Terraform Clouds. So the whole thing about this is that this is Terraform or rather should I say HashiCorp's managed platform so they're the ones that run it you just sign up you pay for it you use it. In fact there actually is a kind of free tier whereby you have a limited use of the actual utility but realistically for the kind of real deployments you would actually have a proper account that actually gets built. So again the cool thing about this is that you can actually have teams involved in your particular organization and when you happen to deploy a particular configuration the actual state is saved for you within HashiCorp's own infrastructure and this is stored in a secure way whereby we have encryption we have history and with respect to your teams of course you get the type of enterprise experience you would expect so you get things like role-based access control and again depending on your use cases depending on how much you're using it what you're using to deploy you'll also get things such as cost estimation because it is going to be a build experience you're not just going to get all of this for free when you're using it for real okay you know the free tier does exist but no major corporations are really

3:13using the free tier to actually manage their infrastructure so really the cost estimation can be a really good utility for you again especially in that kind of business environment whereby you have to get a sign off from one of your managers who might not necessarily be an engineer and then the third implementation of Terraform we can get this one is simply referred to as Terraform Enterprise. Now realistically the way you conceptualize this it really is just HCP Terraform but it's for you on your own premises so you get a lot of the same types of benefits you get to have your type of team implementation you get your role-based access control as we talked about and by the way which I didn't actually mention before with respect to the HCP Terraform you also get access to a nice graphical user interface it's not just all command line Terraform again the benefit of this is if you happen to have a really strict policy with respect to your data where things are stored if it has to be run on your own system within your own secure network Terraform Enterprise allows you to get the benefits of HCP but inside that particular self-host environment

0:00All right, friends, let's go and validate what we learn within this skill. So the first thing we're going to do here is to launch the lab below. So go and click on this and give it some time to load. Now, once it does load, we're going to go and open the Ubuntu 1 virtual machine and then open the terminal and you should see a Terraform configuration file. Now, once you execute this, the file will spin up a Docker container. Now, before making the actual configuration, you're going to go and confirm there are no Docker containers by running the docker ps command. And then following that, once you have confirmed, I want you to then initialize the Terraform working directory and then apply the configuration.

0:36Now, once it has completed, you want to rerun the docker ps command to confirm that the container was indeed created. Now, rerun the Terraform configuration. And then I want you to notice the output and tell me has anything actually changed. Then go and edit the Terraform configuration file and modify the name of the container. Now, with this change in place, I want you to then rerun the configuration file and inspect the output to confirm the changes. So, friends, that is the lab. Go give it a go and I will see you in the very next video where we discuss the solution.

0:00Alright friends, let's go and walk through the answer then. So we'll go here to our lab environment. We're going to go and open Ubuntu 1. So just double click this and give it a moment to load. In the meantime, let me go and collapse this to get some more space. Alright friends, as we can see here, if we do a listing, we have a Terraform configuration file. And the first thing I'm going to do here is to make sure that no Docker container is actually running. So I'll say docker ps and hit enter. And as we can see here, we get an empty output. So I'm now going to do here as per the instruction, as I'm going to go and initialize the Terraform working directory and then apply the configuration.

0:33So we'll go here and I'll say Terraform and then init. And if I hit enter, that should initialize like so. And now with this done, I will say Terraform apply and you can either say auto approve, like we saw in the actual skill itself. Or if you so wish, what you can do is just say Terraform apply and to enter and then just say yes to this and then hit enter again. So what I should now do is create the actual container. So we can see here at the bottom, one has been added. So if I now say docker ps and to enter, we now actually have some outputs. And if we go back to the instructions right here, what we're now going to do is to rerun the Terraform configuration and notice has anything actually changed.

1:08So if I go here and rerun it like so. And this time, let's just maybe add auto approve. If I hit enter, as we're going to see here, bam, nothing has been added, nothing changed and nothing destroyed. So now what I'm going to do here is to edit the configuration file and modify the name of the container and then rerun the configuration and see if anything changes. So inside of here, I will save them and go into the configuration file like so. Now down here, if we look at the actual name right here, okay, so let's go and change this to let's maybe say, I don't know, let's say validation web or something. Just choose anything that's a little bit different.

1:39And if I save this and now I rerun the configuration and to enter, look at it right here, we actually destroyed the previous container, as we can see right there, and then we created a brand new one like so. So friends, that is us for our validation challenge on our introduction to Terraform. I hope this has been informative for you. I'd like to thank you for viewing.