Enterprise DevOps & Cloud Infrastructure

Configuring a Version Control Provider

Erik Reinert

Erik Reinert

Enterprise DevOps & Cloud Infrastructure

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

The "Configuring a Version Control Provider" 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 connects Terraform Cloud to a version control system (VCS) like GitHub. A variable representing the GitHub installation ID is added to a ata file so it can be added to the workspace.


Transcript from the "Configuring a Version Control Provider" Lesson

>> So let's go ahead and start working on the next section, okay? So we've set up, now, I do wanna note really quickly, if you're following along in the example repositories, that's the URL, This has branches in it. And if you click here, you'll see all of the branches of everything we're gonna do today.

So we just finished this, we're gonna get to this next. Or actually, we finished this, we finished this and we're here now, okay? So we're gonna go to setup-vcs-configuration. Again, this is just so that you guys have it if you wanna copy and paste code and stuff like that to make it a little easier?

But we're gonna still go through it one-on-one. So let me go back to my terraform.tfe, switch back to my tab. Okay, so as I just said, we committed our code, we pushed it up, right? Awesome, but do you guys think that if I go into right now and I change some code, you guys think that it'll just do it automatically for me because it's in Git now?

What do you guys think?
>> Probably won't if you don't tell it to.
>> Exactly, yeah, if you don't tell it to, it's not gonna do anything, right? And [LAUGH] it's so funny that you said magic, because it is true. There's half of it where it's very magical, and then there's other than half where it's, if you don't know what you're doing, it's not gonna work at all.

[LAUGH] And so this is one of those scenarios where, yeah, we have to tell it, hey, we need to synchronize to a repository. The cool part about that is we actually can do that in automation too, which is pretty nice. So the first thing we wanna do is is we wanna connect to version control.

So what we're gonna do is is we're gonna go to Settings in Terraform Cloud, and we're gonna scroll all the way to Version Control. And then we're gonna click General. Or, I'm sorry, Providers, my bad, Providers, right? So these are VCS providers. These are the things that you can actually connect git repositories to and all that fun stuff.

I'm gonna hit Add VCS provider. Now, it has a lot of options, which is actually really nice. They have integrated with a lot of VCS providers. For us, we want GitHub. Now, you'll notice that I already have it installed.
>> Yeah, my Terraform account is SSO.
>> You signed in through.

Then yeah, it might already be connected. Yeah, so if you signed in via SSO, you might already see this connected. If you didn't have that, you should have seen a GitHub link there. [LAUGH] And when you click that, it will then make it so that you can select which account you want to install Terraform Cloud into.

You can see here I have a bunch of different accounts. I wanna install it into my main account, right? So I'm gonna click on this, I'm gonna tell it that I can access all my repos. And then we're good to go. Now, I'm not actually gonna go through this process, right, because I just wanted to show you what it looked like to connect it to GitHub, right?

This is actually going into the workspace and manually setting it up, which is what we don't want to do, right? We want this to be an automation. So what we really wanna do is we wanna figure out how we can add this to automation, right? And the biggest way to do that is first we need to understand or know what is the application in GitHub so that we can tell it this is the one unique value.

Because we just installed it to GitHub, we're gonna need the ID of that installation so that when we tell the code, hey, use GitHub, it has the key or the ID of the installation that it knows how to use. So what we're gonna do first is we're actually gonna navigate in GitHub one more time to our settings and installations where I just was.

So if you go to GitHub, scroll to Applications, you'll see Terraform Cloud sitting here. What we wanna do is when we get here, we wanna get the installation ID, right? The installation ID is essentially, again, the ID that we want to get and use in our code. So I'm gonna hit Configure, and then I'm actually gonna do a little trick, which I'm gonna go to the left, I'm gonna go to my URL, I'm gonna slide all the way over here.

You're good? Cool, and then this is the ID. So that's actually your installation ID right there. Yes, welcome to DevOps. [LAUGH] This is the beauty of DevOps, finding where they hide the things you need. And so yeah, sure enough, that's the only real great place to find the installation ID, but it will give it to you there.

So yeah, go ahead and let me, you got that now? Cool, okay. So now that we have our installation ID, just copy that, put it somewhere in a notepad or something like that. But what we wanna do after we get that installation ID is we wanna go back to our automation and actually set it up so that it can use that installation ID.

Now, I've already talked to you about variables and locals and stuff like that, where do you think we should put this value? Should it go in variables or should it go in locals?
>> Probably variables.
>> Why?
>> Because it might depend on what user is doing.
>> Exactly, yeah.

And it might change in the future, you might disconnect. You might do what we just did, which is accidentally break it. [LAUGH] And you have to disconnect it and reconnect it. Well, that means you got to go into your automation, make a change, and then rerun everything, right?

Or we can just make it a variable. And so that variable then makes it so that we can configure it elsewhere and it becomes easier to manage. So what we're gonna do is we're gonna add two new variables. The first one is gonna be our github-app-installation-id, and then the second one is going to be our github-organization-name, right?

Now the reason why we have both of these is because as we've said before, Terraform Cloud doesn't really know any of these things inherently, at least in our code. It might know it on the Cloud website, but it won't know it in our actual automation code. And so this app installation ID, we need to know that installation ID because this is what is in Terraform Clouds database, basically, right?

If we didn't have this, we'd have to figure out another way of looking this up. And I'll be honest, this is the easiest way to manage this. Data lookups, and stuff like that become a little bit more challenging with app installations. So I think this is the best way to approach this.

So what you're gonna do is, you're gonna grab that app-installation-id that you had from earlier, copy it, and we're just gonna paste it right in here, right? Then we can get this out of here, and we're good. Now the only other thing we need to change is the organization-name, all right?

So we're gonna go here, and you're gonna wanna give it the github-organization-name. Now you might be like, well, what's an organization? Just user, it's just your username. [LAUGH] Yeah, so it's just your username. My name is Erik Reinertsen. Cool. So we've got those two, right? There's one other file we need to add, and I'll put it up on the side so you guys have it.

And this is what is called a data file, data.tf. Now again, this is just a naming convention, you can call it flibbity flurb, you can call it whatever you want, [LAUGH] but I like to name the file basically what all of the things are inside it like I did with locals, right?

So locals has locals, data has data. Data is essentially stuff that exists outside of your current automation that you need to look up, right, things that you need to find. And so what we really need to find is our github-app-installation. And that's on the Terraform Cloud side. You guys see how we're slowly connecting GitHub Terraform, we installed it, right?

So now Terraform and GitHub can communicate with each other. But we have to tell Terraform which workspaces can have access to the installation so that we can set up that connection between the workspace and the repository. All we did was just authorize Terraform to access it. We didn't really tell it to start syncing repos, right?

And so what we wanna do is we want to pass that variable to a data lookup. This is really the equivalent of an API call, right? It's gonna make an API call out to Terraform Cloud and say, hey, I already know your organization, I already know your user, so somewhere in there, there's got to be an installation with this GitHub App ID in it.

If that's the case, then I can find the Terraform side of it. Once we have the Terraform side of it, we can do one other thing. Which is we can then go to our main.tf file, and we're gonna tell the workspace that it needs to have what is called a VCS repo.

Oops, right? So if we switch these, oops, sorry. So if we switch these, get rid of that really quickly, you can see that I've also added a new block of configuration to the root of my workspace. Now, why do I want this here? Why am I telling something that every workspace is going to be impacted by to start tracking repositories?

Why might I wanna do that?
>> Because the workspaces are being defined by those repositories.
>> Exactly, yeah. So the idea is is that we're gonna have a one-to-one, where a workspace must have a repo now going forward. This is more of that chicken before the egg scenario.

Where we didn't have a workspace, so we had to create the workspace, right? We had a repo, but we had to create the repo first so that we could then write the code to then create the workspace, right? However, after we committed that code and we pushed it, nothing happened, right?

And the whole idea behind that is because although we have it set up, we don't have it connected yet, right? And on top of that, we also know that every workspace going forward from our design, and again, I'll bring this up one more time just so that you guys recall it, but if we go back to our, what's it called, the workflow, right?

Every workspace has a repo. So going forward, we wanna make sure that every workspace we create asks for a repository, and it must have that repo. If it doesn't have it, then it should not be created. This is a standardization that we're setting, right? So that going forward you have to create the repo so that we can then connect it.

And that's why that connection to GitHub is so important. Because going forward, Terraform has to be able to access every single one of the repos that you need to use, right?

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