Enterprise DevOps & Cloud Infrastructure

Renaming the Workspace

Erik Reinert

Erik Reinert

Enterprise DevOps & Cloud Infrastructure

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

The "Renaming the Workspace" 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 renames the workspace to clarify its purpose and uses the moved meta-argument to update Terraform. The separation and visualization of state are also discussed in this lesson.


Transcript from the "Renaming the Workspace" Lesson

>> We created a new set of resources, right? You guys got to understand how we move that to the cloud. Then you guys got to understand how we can create a configurable set of options or configurable map, essentially, or DSL or whatever you wanna call it, that then made it so that powers which resources gets created and how they're configured and stuff like that, right?

But there's one other thing we kinda wanna change here really quickly, which is this is just called FVME CI Workspace. [LAUGH] It doesn't really give me much of help of actually knowing what this workspace is, right? So we wanna lean on our moved one more time, right? And what we want to do is we want to actually change these names here, right?

And so we're just gonna change this one to tfe. The project can stay the same. You can call it whatever you want. That project is really not important. But what is, is knowing which workspace is which, right? And so we're gonna make sure to rename the workspace from fem-eci workspace to fem-eci-tfe, because this is for our Terraform automation.

However, if I plan this, okay, cool. So here you go, pull one to add and one to destroy. No, we're getting into that destroy situation again, right, because we changed the key, the key is the name of the resource. And so what we wanna do, right, as we did before is go to our main file, right?

Now we don't have any moves here or you either applied it and they're still there, right? I would recommend first after applying to make sure all of your moves are done, right, we'll add a new moved. And this one is gonna be from module.workspace, eci-workspace. Oops, right? And I'm just going to duplicate this really quickly, give it a 2, and then change it to tfe.

And I'll leave that up for a second for you guys. The point of this is, we don't want to actually use the name workspace here, again, it just doesn't help us whatsoever. But I'm showing you guys where changes can impact when you accidentally or might not want to delete things, right?

So, keys, really important to try and keep the same. If you change the key, you might actually have to recreate that resource, which means that you might have to put a moved in there. So it's just something to be considerate of whenever you're making these changes is, try and name it once the first time, try and name it right, right?

Try and think about what you're making a little bit so that you're not trying to have to go back and do moves and all that kinda stuff, right? And so once you've got that in place, I'm going to do a plan. And then sure enough, you could see now my workspace name is being changed, right, but it's not being destroyed.

And so then if I want, I can do apply just like that. So I'll give you guys a second to catch up. So now, if I go in Terraform Cloud, I should see it's already updated, fem-eci-tfe, right? So as I said before, this is a scenario where it really goes to show, again, be aware of the values that you're changing.

You might accidentally change something that if it's especially in a configuration loop like this or something, it could impact the recreation of the service. So just be aware of that, essentially. Now, there is one slight change, or one slight problem here, right? And that problem is is that our backend.tf is still pointed to our old workspace, right?

It's not called workspace anymore. It's now called fem-eci-tfe, right? So the second change we have to make is to our actual backend.tf, right? So again, I'm gonna just quickly close this out, all right. There's the backend.tf file that you need to update. Let me open up the main.tf file as well, oops.

There you go. And so this is basically the two files that you need to update. And again, we are making sure that the moved is added so that when we renamed our project to terraform tfe or fem-eci-tfe, that doesn't get recreated. And then also because we renamed the workspace, we have to make sure that the backend is properly set.

Because otherwise if I didn't do that, if I tried to do another plan, it would actually fail. Does anyone have any questions so far, problems, anything like that?
>> Since that workspace is basically just a location for the state, does it really matter if you keep, I guess, the resources in one workspace but the state in another?

>> Because we have a terraform tfe workspace, the lifecycle of all those components stay in that state, right? But in the future when we create a GitHub workspace, a network workspace, another workspace, you could merge states together, sure, all in one workspace, or you could put them in separate workspaces and stuff like that.

But the goal of why we're separating the states we are is to make it so that the changes stay together, right? So, I guess I don't really know where else this state would go, except for in this workspace, right? You could create a project per, say like, well, okay, when we get to GitHub, then we could create workspace for GitHub, but then we'd have to manually do that, right?

But with this approach, we can do it automatically in one place, and then go to the other place to create the repo. And that's kinda like what we talked about yesterday where to set these up, you have to do two steps. The step of the state is in terraform tfe, and then the state of the repos in TerraForm GitHub when we get to that.

But TerraForm GitHub has its own state that we don't want mixed with terraform tfe. So when we update GitHub, we don't wanna touch TerraForm, and so that's why we keep them separate.
>> Yes, separation of states.
>> Exactly.
>> I was curious, are there any nice visualizers for state [INAUDIBLE].

>> [LAUGH] I'd love to see you build it. There's not much, no. Have you ever seen huge dependency trees? They just get [SOUND] it's like that. I think anytime anyone's tried to visualize state, it's just this big madness of, it's like Charlie Day and it's always sunny. And it's like the huge wall but you'd basically just be looking at that, so.

I'd love to see somebody visualize it in a way where it's actually helpful. I haven't seen that yet, though. Yeah, really, I would love to see it. The best way to look at state right now is really doing this command right here, doppler run -- terraform list. Oop, sorry, list.

By the way, after we change our backend make sure to init, you do have to do an init one more time. So make sure to do that after you change your backend. And then if I do state list, I can actually see everything that's in my current state once it returns.

There we go. So you could take this data and then make it into a cool website or something like that. [LAUGH] That would be really cool. But I haven't seen that yet, unfortunately.

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