Explaining Infrastructure As Code with Terraform

Find out all you need to know about Infrastructure as Code with Terraform, from our demo below:

[Video Transcript]

This is a very simple purpose of this not so simple slide and that is to show you that even at first sight, Terraform code that does the magic that we've been talking about up until this point. Terraform code is not that complicated or at least not that scary now even without any prior knowledge of Terraform. 

I believe that we can all agree that this code is readable, right? You might not know what the specific syntax is or why some things are I don't know between quotes that were square brackets or why some things are not, but if you ever use AWS - Amazon Web Services or any other cloud up there, you can probably just you know, eyeball some of the things that make sense in here: like VPC, a Virtual Network which has an IP address space like this title block, you hear. 

That subnets, that also has a size of subnet IP, IP address space it's connected somehow to the DPC above, then a network interface which makes sense to be connected to a subnet and have a specific private IP address and finally, the finally an instance last one right here the resource of AWS instance, which is actually a virtual machine running in the cloud. that uses some booty image with some operating system or an AMI in Amazon speak a jobless machine image has a specific type which is the shape of the virtual machine that T2 micro in there, and of course, uses the network interface that we previously defined.

Now applying this results in a fully functional and running instance with all the necessary networking pieces created alongside it and the big question here is is this simpler then going to the cloud console and simply next, next, next, creating everything in there, right?

You might say that the best method is the one that you already know, and you would be right but having everything in code. 

Everything defined in one single place, in one single file, especially deployments much more complex, than this one allows you to apply it every single time without errors, without typos. It's going to deploy the same every single time, it is going to behave the same every single time. 

It's even going to bring itself back to compliance. If in the meantime someone tinkered with your infrastructure, someone went in the cloud console and changed some things in there, maybe used a third party tool, maybe made some manual changes in there, it's another great benefit of the chair for me. Not only delivers your infrastructure and then leaves you, abandoned you, you know, it deploys or infrastructure and then it can make sure that it's always up to date. It's always compliant with your configuration with your code. So that's the magic of this code or at least one of the magic ideas.

So how does it actually work? 

Well in a it's a very simple tool actually, it's just one simple executable file. You give Terraform your code? You write your code, give turns from your code, share from your code chair and are going to parse it. Of course, take care to download the right plugin to talk to your desired cloud provider. So it will grab a plug-in for AWS. It will grab a different plugin for azure and so on, then it’s going to transform your code into a series of API calls? 

While taking care of resource dependencies, of course, paralyzing it when it's possible so that you don't run into some abnormal states or some, you know, corrupt infrastructure behaviors in there, and sends those API calls to the cloud provider. Waits for the cloud signal that everything deployed was deployed Okay, and then stores that end state in something called the state file, which is nothing more than a very simple database like file, that reflects what has been already deployed in a cloud.

That's a State file. So basically Terraform is nothing more than a complex state machine that sends API calls. That's about it. 

And there are five main building blocks that you will find inside 99% of Terraform on configuration files, and these are the focus of our training or future training like this one? 

Because one of the difficult things about working with and learning to reform is that you have to keep in mind and work with pretty much all these concepts are the ones. I'm only showing them here and briefly covering them just to show you that it's not exactly that much than that complicated to learn right you have five tools at your disposal.

Let's say Lego bricks, and you can do pretty much anything with them.

You can deploy any type of infrastructure in any type of cloud. And that's all you need. That's all you basically need to master. By the way, the configuration on the right you can see here on the slide is not a fully functional configuration. It's missing some elements. It is just a collection of samples for the item listed on the left.

So what exactly would you be required to learn in order to use Terraform?

Well, long story short. You need to learn how to work with variables. If you ever use any kind of programming or scripting language before you definitely know what variables are, and they're no different in Terraform either. 

Second providers the provider can see that each block here actually has the corresponding type right and has a variable block a provider resource block data block in an output block now the provider block.

This one answers the question. Who is Terraform talking to in order to deploy our infrastructure or where is Terra form deploying infrastructure. 

Each provider requires its own parameters for configuration and authentication.

They don't have anything in common, of course. You're not going to authenticate the same way to Oracle cloud like in this example right here OCI as you would on a AWS or Azure or Google cloud, of course, everything is properly documented on Terraform on the website. 

Terraform is one of the DevOps tools out there that actually has a very well written and structured documentation. So I'll give it a kudos to the technical writers that have occurred for this.

Probably the most important one is the third one here the resource well resources. 

Now, resources define something that actually gets created by Terraform provider cloud.

We talked about creating infrastructure. Well, this is a piece of infrastructure in Terraform that calls it a resource.

It might be some functional components such as a virtual computer instance. It might be a user, it might be a storage entity like block storage, object storage stuff like that, but it can be a logical resource such as an online application service or a policy. 

Data sources. 

Second last one, a data source is to allow you to extract information that's already in the cloud Very useful for two things. You can extract some information that's already in the cloud, but you cannot modify things like I don't know, I would like to get the list of regions that I have access to all the list of availability zones or the list of final fault domains within availability zone stuff like that.

Secondly, it is very useful if you already have some infrastructure, deploy it in the cloud. This allows you to read information to extract all the API can provide you about some piece of infrastructure but a resource that has already been deployed sorted running in the cloud, but it's not managed by Terraform so it can work with things that are not under its management and can also import existing resources because this is a question that extremely often pops up and basically every Terraform training I had before how do we import existing resources into Terraform.

If I've decided I want to use Terraform from now on, that's great. But I already have some infrastructure running in there. I have some virtual machines, I don’t know if the authentication server has some users to find in there. How do I import them into Terraform? 

Well short answer is: Is it possible. For the long answer: we join the training because it's not that trivial but it's perfectly possible to do that. 

So you can import existing infrastructure into Terraform and finally output variables is a very simple one here. It's just a way to organize data so you can be easily queried and shown back to Terraform users.

If you want to learn more about Terraform >> Register for this course.

Terraform States

Now briefly mentioned this before but one of the greatest advantages of Terraform is its knowledge of State, remember I mentioned that state file before. 

What this means is that at any point Terraform will try to keep an up-to-date overview and up-to-date knowledge of what has already been deployed. 

This State knowledge allows Terraform to know if a configuration has already been deployed. So we can apply the same configuration as many times as you want. Terraform will know if it needs to deploy it completely, partially or not at all.

And this is also called item potency. You can actually run the same operation several times without having any adverse effect.

You  can actually apply an infrastructure configuration with Terraform deploy, all the virtual instances, all the networking configuration, everything you might have in there and then apply it maybe 10 times after the same time, the same configuration can apply it as many times as you want. Terraform is going to tell you that your infrastructure is up to date and it's not going to attempt to redeploy it from scratch, not going to duplicate or infrastructure, but because of the State knowledge Terraform also knows which part of the infrastructure that's already in the cloud. 

Is Terraform responsible for which part of that infrastructure is under its management and it’s going to look in there. Okay, I have this configuration here that you're giving me. I'm going to go look in the cloud to see if that configuration is already there or not. It’s going to check every single parameter, actually it’s not going to just check if you have two or three or a hundred virtual machines. It's going to check every single parameter for each and every single resource out there, and there are resources that have hundreds of parameters, which again it's another, it's not a feature of Terraform, that would be close to impossible for a human being to just eyeball it and check it, check some huge piece of infrastructure in to check it for compliance. But Terraform can do this for you. Just a couple of commands, actually it’s just one single command. You apply your infrastructure again, you apply your configuration one more time, it's going to tell you if it's up to date, if it needs some minor changes in there to be able to bring it back to compliance or if it hasn’t been deployed at all. 

It's going to go ahead and deploy it if you ask it to, it's pretty smart. And again, this is called item potency, the ability to run the same operation the same command multiple times without adverse effects.

It also allows Terraform to figure out if something has changed from your desired configuration. Perhaps someone made some manual changes in the cloud console or by using some other tool.Terraform can not only detect those configuration drifts, but can also automagically I would say generate the necessary list of steps of API calls that are required to bring your infrastructure back to compliance. Which is that compliance.

Well that compliance means your configuration. Your configuration is your desired state. If it's compliant with your configuration with your code then, well, your infrastructure is in compliance.

So Terraform, actually keeps track of three states.

I know the Desired State is the one that you write in your configuration file. That's what you want to have. That's what your intention is. Your Desired configuration. Terraform will read your configuration file to determine the Desired State. You have the Actual State which is how are things actually looking in the cloud environment? Is it fully compliant with the Desired State or partially or not deploy that all. Terraform will have to go online, talk to the API and ask a cloud provider about the State.

And finally the known state is the Terraform State file. The one that is stored right next to your configuration file or Terraform automatically generates it; you don't have to work with it.

Terraform does this in the back end completely transparently to the user, but it uses it to check if the actual infrastructure that's deployed in the cloud is compliant with your configuration or not. Again, someone might have edited the desired state in the meantime or someone might have changed some resources in the cloud.

Terraform will attempt at any point in time to keep these three states in synchronization and if this sounds complicated well it kind of is but it's complicated because it would be extremely hard for human admin to keep track of all this. Not so hard at all for Terraform. Again, it's one of the greatest benefits of Terraform simplifies a lot of day-to-day tasks of sys admin.