Check out a free preview of the full Enterprise DevOps & Cloud Infrastructure course

The "Adding Providers" Lesson is part of the full, Enterprise DevOps & Cloud Infrastructure course featured in this preview video. Here's what you'd learn in this lesson:

Erik explains the providers enabled DevOps to work with multi-cloud and connect to other services within the same automation. The Terraform registry is similar to NPM and contains several providers from popular services. Project and Workspace modules are added to the file.


Transcript from the "Adding Providers" Lesson

>> So now that I've got my repo cloned, we can go ahead and get started by creating some of our automation, right? Now, when we think about the automation that we wanna create, we really need to consider the resources that we're gonna be using, right? when you are working with TerraForm 99.999% of the time, you're gonna be working with these things called providers.

Providers are really what make it so that you can do things like multicloud. They're things that make it so that you can work with other services in the same automation. In our case, what we wanna do is we wanna look up terraform provider tfe, right? This is the Terraform HashiCorp provider for Terraform Cloud Enterprise.

Now, one of the things that's really fun about providers, which you may not know is people like to experiment with providers and see, well, what could I automate, right? One thing you might not know or something that might shock you or find interesting is you can actually automate your Spotify playlists.

And that's the really great thing about Terraform is providers are just things that we make. As long as it's an API that has the ability to create things, an API that has the ability to delete things, things like that, it's automatable, but the only thing you have to do is create a provider that works with them.

And so I would recommend in your homework going into the TerraForm registry and kind of looking around and seeing about all the different providers that they have. As you can see here, we've got the AWS Azure, Google Cloud, Kubernetes, Alibaba, Oracle, right, all these different things. And if we go further down, you can even see things like Nomad, Helm, right?

And so yeah, I highly recommend taking a look at the providers, there's a lot of really cool stuff in there. Okay, so again, we wanna work with the Terraform Cloud Provider. This is gonna be a lot of your experience with Terraform, which is just finding which provider you're working with, and then figuring out the resources that you wanna use.

Now, the first resource that we really wanna find is a project, right? The project is kind of our first level of encapsulation in Terraform that makes it so that all of our workspace automation can exist in one location. For example, if I wanted to say, I just want the automation for service A, right, and that would be in the service A project, and then I could click on that project, right?

But I wanna note something about projects or even these resources in general before I go any further, which is resources are literally individuals, right? So what that means is, is that you can have a resource that creates an organization, but then you also need another resource that attaches users to that organization or other things like that.

And it can become a bit challenging especially when you're like, I don't know, am I missing an attachment somewhere or a policy resource somewhere? And so another really great way of creating Terraform automation is actually leaning on Terraform modules, right? So we've got providers, but then we've also got this concept of modules.

And modules are really community-driven Terraform codes that has been standardized, it's been worked on, and it's also been essentially kinda of battle tested for the use cases that are created. So you can see here we've got aws-modules/iam, VPC, and we even use some of these modules in this workshop just because it makes our lives a bit easier.

And again, the goal here is to create valuable modules, don't just create a module of a wrapper of a resource, there's really no value there. However, I was able to actually prepare some modules for us. And so if we actually type in ALT-F4-LLC, which is my company, and we go to Project, we can see that this is the project for creating Terraform Enterprise resources essentially, or project resources.

And what's nice about this resource versus the other one is you'll actually see if we look in here, you can see that it provides more than one resource. It'll take care of the project, but then it'll also make sure that if it needs to say have access to a team or multiple teams, right, I can just pass that to the resource and it makes my life a lot easier.

So we're gonna go ahead and actually get started by using this module, and we're gonna create a brand new file, okay? So I'm gonna go back to my source, I'm gonna hit New File,, and then I'm gonna edit it. Now what I wanna do is I really just wanna copy and paste that block of code that exists really here, right?

So if you look here, you'll see provision resources. This is really how you can kind of get started with a module, right? Now, what I copied was that part plus a couple others, which is the values of what I need, right? So module, project, source, and version, these are all normally gonna be there whenever you're using any module.

The module is the actual meta argument telling Terraform what it is. Project is the name, and then your attributes are inside of that. You might notice that, for example, in our previous one where you saw aws_vpc, something like this, you might notice that it has three arguments, but then this has two.

What's going on there, right? Well, the main point is, is one, we're telling Terraform here that this is a module, right? Whereas here we're telling it it's a resource. Modules don't have providers, and that's exactly what this is for, the provider resource, right? In this case, a module just has a name, really.

So this is a little bit of a thing to think about when you're creating and using modules is you can't just copy and paste a module unless you make sure to rechange the name of that module. You won't actually be changing what module it's using because it has a source definition and a version definition, but you will need to make sure that project or whatever, if you wanna have more than one project has more than one, it has to be unique, basically So we're gonna go ahead and make sure that that is in there, right?

Now with this, we can create a project. So if we go back to Terraform Cloud really quickly and we go to Settings. I'm sorry. If we go back to Teraform Cloud really quickly, and then we click on this little button right here, these are all of our projects.

Now you actually see I actually have one here already, so let me just go and delete that really quick. All right, cool. So again, if I open this up, you can see no workspaces were brand new, and you do get a default workspace. So that's nice. You do get a default workspace, but we want a workspace for our actual application.

So, the next thing I wanna do is I wanna use a workspace resource. Now again, I could go back to Terraform Module or TerraForm Provider and look for everything that's related to a workspace. Or I could see if maybe this developer also created one form for me that I could use and sure enough, yes, there is.

This is the second part of modules that's really cool. You can compose modules to work with other modules. So, one of the things I decided to do, which is why I created these modules was I didn't like how Terraform Cloud required you to not just create something, but then also kind of attach things to things.

It's multiple resources that have to be done. My goal is to simply create a project and a workspace, right? And so, what I did is I made it so that the project exported values that the workspace would then expect, right? So it makes it easier for you to compose your infrastructure with your own opinions by saying these are the actual attributes I care about, these are the ones that I don't.

And then this is where the Legos really kinda come together, you make them fit well together. And so this workspace should be able to work well with our module that we've already used. So I'm gonna copy this, I'm gonna paste it in here, and I'm just gonna get rid of this little line right here.

Now, it said Insert Attributes, so we wanna insert attributes just like we did with the other module. So I'm just gonna copy and paste from the example code. And then sure enough, there we go. Now, we have a project and a workspace, right? But you'll notice that if you look at my code, I have variables here like var.organization_name, right?

The point of these variables is even though we're making automation for ourselves, we don't wanna necessarily keep unique values or things of that nature in the repo if we can avoid it. We're gonna have things that are gonna need to be there for sure, but at least not having it directly in the automation code is helpful.

And so what we can do with Terraform is we can create variables that we can actually pass to the automation to make this a little bit more dynamic. And so what we're gonna do now is we're gonna actually close this out, we're gonna create a new file, and we're gonna call this, right?

Now in this, we're going to create a variable for, what was it? Our organization name, right? So I'm gonna go over here, just gonna switch that for you guys so you can see both, and then I'm going to paste in my variable block for you guys. Now again, you're gonna notice this pattern with Terraform of meta argument, name or provider name, resource name, and the name of resource.

And this is what I meant before, right, when we were talking about Pulumi versus Terraform versus whatever. This is why Terraform is so powerful versus something like Pulumi, it's so straightforward. The expectations are so easy that it really does get to the point where almost anyone could start writing automation.

The entry point is so low that it makes it really easy to do a lot of these things. So when we're talking about declaring a variable, it's literally the word variable, right, which is nice. Again, it doesn't make it too confusing. What we want to do though is we want to change the default value.

Now you might be like why are you doing this? Why don't you just copy and paste it into the organization name where it is and call it a day? We wanna make these dynamic, like I said. And one of the nice thing about variables is you can set defaults for variables, but then you can make them overvariaiable if you want.

So say, for example, if I wanted to use this, but then I was like, you know what, I kind of want to put this in a different org, right? I wanna take my whole infrastructure and I'm gonna put it in a different organization. That's challenging, that's a very daunting and challenging task.

But if you make your automation dynamic enough, it can actually make it easier to do that. And so, we wanna add our organization name, which if I click on my Terraform Cloud, and I look down on the bottom, you can see my organization name is my randomly generated word set seat-rhetoric.

So that's my org. So I'm gonna go into here, I'm gonna type in seat R-H-E-T-O-R-I-C. I believe I spelled that correct. Yes, I did. Okay, cool. And then we're gonna right quit and we're gonna save all of these. So again, let me go back to main one more time just to show you what your main should look like, all right?

You should have a project, and you should have a workspace, and then you should have description and name, and organization name for your project. And then you should have description, execution_mode, name, organization_name, and project_id. Now there's one thing I wanna do and show you really quickly before we move forward because this is a little bit of a caveat to Terraform Cloud and the the personal free version of it.

By default, they set a default execution mode in your account. This is a difference when you use a paid account because then there's a little bit more flexibility. But we wanna make sure for now, our default execution mode is set to local, because everything we're gonna be starting with at least is gonna be local.

So what we're gonna do is we're gonna go to Dettings, and then here where it says Default Execution Mode, right, we're gonna set it to Local, and then we're gonna Update organization. This is important. Let's make sure everybody does this. Because this will make sure that any other repositories or workspaces we use going forward, it'll make sure to use local first and not trying to actually set itself to remote.

So we set that, and then again, we'll take one more quick look at our variables. Looks good.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now