1. Understanding DRY principle
Everyone, and welcome back to the KP Labs course. So in today’s lecture, we’ll be speaking about the dry principle in software engineering. Now, the dry principle specifically applies to the software development area. Now even in infrastructure as code, we are actually developing something with the help of code, and this is the reason why the dry principle even applies here. So let’s go ahead and understand more about what Drive’s principles are all about. To summarize in software engineering, Drive stands for don’t repeat yourself. is basically a principle of software development that is aimed at reducing the number of repetitive patterns within the software code.
Now, in the earlier lectures, specifically in the lectures where we were discussing the variables in Terraform, the main aim was to remove the static pattern and refer to the single source of information. So, if you remember this specific diagram where there was one source and we used to give the value to this specific source, and we used to refer to or reference this specific source within the TerraForm TF files, this was what variables were all about. Now the dry approach is very similar. So if you look into the coding that we have been doing, let me give you one of the examples so that it will become much easier to understand. So if I quickly go to Kplabs TerraForm, within the two-tire architecture, if I open EC two web TF, you see we are creating a resource and we are specifying various values over here.
Now, even with another project, EC 2 underscore apt, you see we are creating another resource and repeating the same software patterns. So let’s assume that there are 100 projects. In 100 projects, we will have 100 resource blocks, which might have very similar values. And this is what “repetitive pattern” means. Like in 100 projects, we actually have the same repeated value. And this is one of the things that we want to avoid in infrastructure as a code-based methodology. So this slide should be easier to understand. Now, generally in the TF files that we have been writing, this specific resource block is something that is repeated across multiple projects. And the aim of the dry principle is to reduce the repetitive patterns within software development, and this specific part is something that is repetitive. Now, the same goes with Elastic IP as it does with another resource.
So if two projects have the same resource, then that resource will be repeated, be it elastic IP, a load balancer-related resource, or TerraForm. So, in a centralized structure, we basically have a source over here. So within the source, this is very similar to the variable part. Within the source, we reference it; within the TerraForm taf file, we reference the source, and we basically give the value we give the resource block to the source. And within the various TerraForm TF files that are included in the project, we directly reference them to the source. So what happens here is that these Terraforms files will be almost empty. It will not really have much code. The code will be centralized in this source block. And this is what the TerraForm modules are. So let me give you one of the real-life examples of what this could look like.
So let me just minimise this. And I have created a directory called life-hyphen-demo. If you look into the project, you’ll notice that I have EC to highlight Web TF. So this is what EC to underscore Web TF looks like. And along with that, we’ll open the EC to understand Web TF, or one more directory where we’re not using the centralized approach to modules. So you see, this is what the module-based approach looks like. And this is what the module-based approach looks like. See, it’s very small code when compared to the right-hand column. Now, what we are doing here is referencing a central source.
So within this KPLABS demo, I have created a folder called “modules.” And within the modules, I have actually defined the software patterns. So this is basically the resource block. So this is very similar. So this is the module. And within the module, we have defined the resource block. And from the projects that we have, it might be 100 projects or it might be 1000 projects. All the projects we reference directly to this source will automatically inherit these values. So let me give you an example of what it might look like. So, if I do a quick dir, this is the simple underscore web TF. So if I do a Terraform plan, it will basically take the value. So this specific structure will take its value from this specific structure, and this structure is referred to in this module. And whenever you do a TerraForm plan, you will see that it works as expected.
So now you see the instance type is “twice dot micro.” So now let’s do one thing. Let me change this specific value to 2, and I’ll save this and let me do a TerraForm plan again. And now you see the instance type has changed to “two small.” So this is what the Terraform modules are all about. So in this demo, I just wanted to give you a high-level overview of what modules are all about. So in very simple terms, whenever you hear the word “module,” just understand that modules are nothing but a centralised source where the code is defined, the resource blocks are defined, and those resource blocks are being used in the TerraForm TF file, in the individual project. So this is what the modules are all about.
2. Implementing EC2 module with Terraform
Now in the earlier video we were discussing about the basics of Dry principle, and we also had demo on what TerraForm modules are all about. So in today’s video, we’ll go ahead and start with the practical, where we’ll be implementing our first TerraForm module. So, let’s get started.
So, let’s do one thing: let’s create a new folder; I’ll call it KP Labs hyphen modules. And within this folder, I’ll create two folders. The first folder name would be “modules,” and the second folder name, let’s call it “projects.” Now, inside the project again, we’ll create two folders. One is A, and the second is B. So it is something like “project A” and “project B.” So now let’s do one thing; let’s go back to the main folder. And within the modules, you can have modules for a lot of things. For example, if you work with AWS, you can have modules for EC2, Route 53, Cloud Front, and so on. So currently, for today’s practical, we’ll be creating a module for EC 2. So let’s create one more folder. I call this folder “easy to.” All right, so let’s say tomorrow you want to create a module for cloud front.
So you go ahead and create a new folder and call it “cloud front.” So within the EC, we’ll basically have to add our TF file, which will be used for creating an EC instance. So, going back to our Atom editor from our earlier video, we had basically created a simple EC-2 instance. So, this is a simple resource block. I copy this resource block, and within the Kplabs iPhone modules, under the modules directory, insideEC two, we’ll create a new file. Let us call them EC and TF. And I’ll paste the resource code over here.
So, to summarize, within the EC2, we have created a TF file for EC2, which basically creates an EC2 instance here. So now what we’ll do is, to just give you an overview, we have a module, and inside this EC-2 module, we have basically added a simple EC to a resource. So, we’ll be referring to this specific module from one of our projects. So now, within the project, let’s go to project A. And then, within project A, I’ll make a new file called EC-dot-TF. Now, within this file, we do not again have to add the EC to the instance resource. All we have to do is make a reference to the module that we have created. So I’ll call it a module and give it the name. Let’s call it “easy to module” here. And then you have to specify the source. So the source is dot, dot, slash, and I’ll dot, dot, slash yet again. And from there, we’ll go to the modules directory, and within the modules, we’ll go to the EC2 two year.
So this dot slash is basically to go from this specific directory to A. And then we are also specifying one dot slash.
So from A, it goes to the projects, and then you have modules, and then you have VC 2. So you can even put this one in the terminal. Let me quickly show you. So let’s do one thing: let’s copy this entire path and put this path within my terminal. As a result, when you do a dot slash and slash, So now you are in the KP Labs Hyphen Modules directory. So, when I run a Dir, you’ll notice two folders: modules and projects. And this is what exactly we are doing. We are doing two-dot-slash, then we are going to modules, and then we are going to EC 2. So this is the way in which you can refer to the module that has been created. Now, one more thing that you will need is the provider, TF. So let’s copy the providers.tf from our earlier project.
I’ll make a new file in a callas providers TF and copy it here. So now let’s go back to projects, and we’ll go inside the A project. Now, the first time you do a Terraform plan, it gives you an error saying that this module is not yet installed. So you need to do a terraform in it to go ahead and install the module as well as provider-related blocks. So, let’s quickly Terraform it. So the first thing it is doing is initializing the module, and then it is also downloading the plugin associated with the provider block. Great. So now it says that things have been successfully initialized. So now let’s go ahead and do a TerraForm plan. And, as expected, you can see a plan associated with the EC to implement immediate savings. So now, as we were discussing, if you look at this diagram, it will be easier for you to understand.
So we have a module here. So in this diagram, the module name is Source, where you have basically added your TerraForm code, and from different projects you can go ahead and call this module, and all the contents that are present within the module will be initialized. One of the advantages is that, say, you have a developer who wants to create an EC2 instance. So he does not really need to understand all the configurations related to the EC2 instance. Like AMI instance types, it can be a security group, et cetera. All he has to do is call the EC2 module that the DevOps team might have been creating. So these are the only three lines that the developer might have to use in his PF file, and that’s about it.
And when you go into organizations, you will see that the team, which can be a DevOps team or a Microsoft theme, is there. The team might have already created modules for various resources. And all you have to do is call that module to create the relevant infrastructure. So, before we go any further, if you want to see the instance type, it is TWO micro. So these two micros are basically referenced within the module. So whatever change that you might want to make, you will have to go to the modules here, and you can change the aspect here. So within the modules, let’s go ahead and change this to 2 large.
I’ll go ahead and say this now, if I do a TerraForm plan. When you look at the instance type, it is now two dots large. So this is often an advantageous situation because you will see the developer launching simple two-instances with as much as 16 GB of RAM. Some decide to use 32 GB, RAM, and so on. So if you’re using the modules, all you can tell the developer is to use these three lines within the TerraForm files, and an EC2 instance will be created for them. Now, what is the type of that easy instance? What is the AMI used to launch the EC2 instance? All of that is taken care of at the module level. So the developer does not really have to worry about that. All he has to do is add these three lines and run TerraForm apply to have his EC to instance for testing created. So that’s the high-level overview of TerraForm modules. I hope this video has been informative for you, and I look forward to seeing you in the next video.
3. Variables and Terraform Modules
Hey everyone, and welcome back. Now in today’s video, we’ll discuss some of the challenges that you might have to deal with while working with TerraForm modules. Now, one common need of infrastructure management is that you will be building multiple environments, like an environment for staging, an environment for production, and so on. So depending upon the environment that you are working with, some of the variables would differ accordingly.
As an example, for staging, you might want to use two micro EC instances. However, for production, where you will have a lot of traffic, you want your EC2 instance type to be “m four dots large.” Similarly, depending on the environment where you are working, some of these values will change accordingly. So generally, whenever you make use of modules, if you hard code a value similar to this, what will happen is that you will not be able to change it from the destination. So let’s say that within the source module, the instance type is “twice micro.” So for development, t = 2 micro seems to be good enough for staging; let’s say you need t = 2 small, and for production, you need m = 4 large.
So depending on the environment, this specific value related to instance type is changing over here. Now, since you have hard-coded it within the source module, you will not be able to change it within the destination of the Terraform from where you are calling the source module. So this is one challenge.
So let’s quickly look into it, followed by looking into how we can overcome this. Now, in the earlier video, we had basically referenced our first EC-2 module from Project A. So if I quickly do a TerraForm plan here within the project A directory, you will see that the instance type here is “two micro,” which is the same as that which is mentioned in the module. Now let’s say that I want to change that instance type to “two large.” Now, if I try to put it here, let’s say the instance type is equal to “two large.” All right? and let’s see what happens. I’ll clear the screen, and let’s do TerraForm plan. And now you see, it is basically giving you an error saying that the argument of the instance type is not expected here. So, as we previously stated, if you have hard coded the things within your module, you will not be able to override them from the destination year. So in our case, let’s open up the module file. So in our case, the instance type of TWO micro is hard-coded within the module itself, and hence you will not be able to override this specific thing from the destination. So if you want to deal with this kind of scenario, then you can make use of variables.
So now, instead of hard-coding this value, you can basically create a variable. I’ll say VAR for instant underscore type. Allow me to close the destination here. So what we have done is make the instance type value a variable whose value will be stored within the instance underscore type variable. So now let’s go ahead and create a variable called TF in the same modules directory. So let’s call it variable instance underscore type and set the default value to t two micro. Now, giving a default value here is important because, as you can see, within the instance type, this is a variable. So that basically means that there is no instance type that is assigned. So it might happen that a user doesn’t assign an instance type as well. So what will you do if the user has not explicitly specified the value associated with the instance type variable? So in such a case, a default value of t + 2 micro will be used. So, let’s go ahead and close this and within my EC two dots TF. You have now specified that the instance underscore type is 2 large.
So since you have explicitly specified it, this specific value will override it because within the variable here, this is a default value, and the default value will always be overridden by the explicit value that you define. So now let’s do a Terraform plan yet again, and within the instance type, you should be able to see the instance type as “large.” So, for example, while designing a module, you can choose to make a specific argument a variable that can be overwritten from the destination. However, with certain arguments, you can keep it static so that the destination cannot modify it. So for example, let’s say that within your easy-to-instance resource, let’s assume that this is a hardened image. So you can choose to hard code this specific value within the modules so that from the destination, no one should be able to override that hardened image with a non-hardened image. So that can be one of the possibilities that you can do. So that’s the high-level overview. I hope you understood how you could override the variables from the modules when referencing them from the destination. So with this, I’ll conclude this video. I hope this video has been informative for you, and I look forward to seeing you in the next video.
4. Terraform Registry
Hey everyone, and welcome back. Now in today’s video, we’ll be discussing the TerraForm Registry. So the TerraForm Registry is a repository of modules that are written by the TerraForm community. So the registry can help you get started quickly with Terraform. So, let’s say that tomorrow you are planning to write a module for the EC instance. So instead of writing a module from scratch, you can quickly search the Terra Terraform Registry to see if someone else has already written one. And if it is already written, then you can directly use that instead of writing one from scratch.
So not only will it save you a good amount of time, but generally, the modules that are part of the TerraForm Registry are community build. As a result, multiple people commit to keep the module active. Now, one of the great features within the TerraForm Registry are the verified modules. So within TerraForm Registry, you can find verified modules that are maintained by various third-party vendors. So there are multiple modules available for AWS, VPC or RDS, ELB, and others. When it comes to verified modules, keep in mind that they are rebuilt by Hashicovand actively maintained by contributors to ensure that they are up to date and compatible with both TerraForm and the respective providers. This badge, which appears over here, is one way to identify the Verified Module.
So this blue verification badge indicates whether a specific module is verified or not. Now, module verification is currently a manualprocess, and generally it is still limited to small group of trusted hashicoff partners. So that’s the overview. Let’s jump into the demo so that this can be better understood.
So currently, I am in the TerraForm registry. Now, if I quickly browse the modules here, you’ll notice that there are multiple modules available for different providers. So you have a Google provider, you have a tablet provider, you have an Azure provider, and so on. And this is the verified batch that we were speaking about. Now, you can also filter by provider over here, so you can also filter by provider so that all the modules that appear are part of the AWS provider. So this is one way. The second method is to filter by the module that you intend to use. So, if you do an EC-2 over here, you’ll see that there are so many modules that are available as far as the EC-2 is concerned. Now, if you click on the Verified Batch, you only see that for the EC Two instance, you only have the first module, and the second Verified Module is for the security group.
So this becomes much easier because if you do not select the verified, there will be so many others, and you are not sure exactly how they will function. So let’s go ahead and do a verification, and let’s open up one of them. So within here, you basically get the basic instructions on how you can reference it and also some of the basic usage examples and the various inputs and whether they are required or not. So this is how the module looks in the Terraform registry. Now, one important part to remember is that if you intend to use the TerraForm registry module within the code, you can make use of the source argument that contains the module path. So this is a very simple example. Assume you’ve referenced a module and named it “EC” for a hyphenated instance. So within the source, you give the location, which is TerraForm, hyphen AWS, hyphen module EC2, two instances of AWS.
So this is one source, but typically you can also fetch it directly from the TerraForm registry. You can also specify the appropriate version of the module. So do note that a module can also have multiple versions, and you can hardcode a version over here. So going back to the EC two-module over here, currently you see that there are multiple versions that are available. So depending upon the requirement, you can hardcode a specific version so that it remains there. So that’s the high-level overview. Let’s do one thing; let’s go ahead and try it out. And we’ll be launching a new EC2 instance on AWS from this verified EC2 instance module. So if you go a bit down, this is the basic usage example over here. Now, do remember that although this is an example, not everything might be needed. So this is one important part to remember. So let’s do one thing first. Let’s go ahead and copy this up, and within the Atom editor, let me go ahead and paste it. As you can see, there are several things defined here, such as a key name, monitoring, this VPC security group, and so on. So not all of these are required. So if you quickly look into the inputs, there are certain inputs that are required. So these are the mandatory ones.
So these include the AMI. Let’s go a bit down. You have the instance type; you also have the name; and the other ones are primarily defined as no. Now, one very important part to remember here is that if you look into the node section, ideally it is recommended that you also read the things that are specified within the node. And within the node, it states that one of the subnet IDs or subnet underscore IDs is required. If both are provided, the value of the subnet’s ID is prepended to the value of the subnet’s ID. So along with this, you will also have to specify the subnet’s ID. So first let’s do one thing: let’s clear the code and remove the things that are not required. So the key name, “monitoring,” and the VPC SecurityGroup ID are not required. The subnet ID is required. Another thing to keep in mind whenever you use a ready-made example is the instance count. So if you run this, then in total, five easy-to-instance processes will be launched.
As a result, your costs may increase. So this is not what we want; we’ll just use one instance count. The second thing about which you have to be careful here is the AMI ID. So always verify the AMI ID because in AWS, depending on the region that you use, the AMI ID changes. So if you are planning to launch an EC2 instance in the Mumbai region, the AMI ID will be different from when you intend to launch that instance in the North Virginia region. So every region has its own AMI ID. And the third important thing here is that this is just the module. It assumes that your AWS configuration has already been completed in terms of the access key and secret key associated parameters. So what I’ll do for simplicity is basically add the provider where the region is defined and the access and secret key are also defined. The next thing that you have to change is the AMI ID.
So from whichever region that you have hard-coded within the TerraForm file, So if you see, I have added USWest 2, which is the Oregon region. So from here, always verify the appropriate AMI ID. So let’s select the AMI ID associated with the Amazon Linux 2. So you’ll see that this is the AMI ID over here. Let’s copy this up, and I’ll replace the AMI ID over here. So that’s the highly valuable overview; this is what is required. So let’s go ahead and try it out. So, within the CLI, we currently have a file called registry Hyphen TerraForm TF. If you quickly open this up, it basically contains the exact thing that we had configured within the Atom editor. So the next thing you need to do is make a terrain in it. So when you do a terraform in it, the module that is part of the registry is downloaded within your local path. So let’s try it out. So far, everything has been successfully initialized. Now, a las las is the command that is specific to Linux. You will see that you have an Apache TerraForm directory that we already know about.
So let’s open this up, and within here you have modules. So let’s open this up. Within modules, you have an EC-2 cluster. Then you have the name of the module along with the version. As you can see, you have the main TF, the outputs dot TF, and the variables TF. And if you open up the main TF, this is the exact module over here. Now, apart from that, if you want to also have a second approach to reading the modules, you can look into the source over here. So the source here is basically the GitHub page that contains the actual module contents. So if you see over here, you have the main TF, the outputs, and the variables. So if you quickly open this up, these are basically the contents that we were looking at in the CLO. So this is a quick way to go over what the module contains and how things have been defined. Great. So let’s go back and develop a registry habit, TerraForm TF. Let’s go ahead and do a TerraForm plan.
So far, things appear to be going well in terms of the plan. Let’s also create a TerraForm application. So let’s say yes. All right, so our execution has failed, and if you look at the error, it states that an invalid subnet ID was found. So we made a small typo over here. So the subnet ID of this AMI would go into the AMI ID section over here, and the subnet ID would have to fetch it from AWS. So from here, let’s quickly go to the VPC. And currently there are multiple subnets that are available; let’s copy one of them, copy the subnet ID over here, and replace that within the TerraForm code. So let’s clear the screen. So now let’s go ahead and do another Terraform yet again. Great. So now it says that creating an instance is easy. Let’s quickly wait for a moment here. So it took around 43 seconds in Sierra, and from the AWS console, you see that our instance is working as expected. So that’s the high-level overview of how you can search for appropriate modules from the TerraForm registry and how you can use that module within the CLI. Now again, once you have done the practical, do not forget to destroy the things that you have created to avoid getting charged with AWS.
5. Terraform Workspace
Everyone, and welcome back to the KP Labs course. So in today’s lecture, we’ll be discussing the TerraForm workspace. So the concept, the analogy of “workspace,” actually comes from Linux. So, in Linux, we had a feature called “workspace,” which was also replicated in Windows. And the same analogy is now even used in Terraform.
So before we actually go ahead and understand what TerraForm workspaces are all about, let me actually show you what exactly a workspace is in the Windows operating system. So, as you can see, I have a lot of tabs open right now. So this is actually one workspace. Now, if I press Alt Tab, you can see that I can switch between multiple open windows. Now that I know what the workspace feature in Windows is, let me click over to your task view. And now I have two desktop computers. Now, in desktop two, you can see that I don’t have anything open. So you see, I just have one software programme for recording when everything is closed. So there can be multiple workspaces. So that is what one workspace will be like for working.
So there will be all of the necessary software open over here. So let me quickly go to the desktop one. And within this, if you will see, I have all important software like Atom, editor, command prompt, Windows, SAP, and everything else that is part of one workspace. Now I can have a second workspace. So this is my desktop, and this is my workspace, where I have all of these things open. Now I can switch to a second workspace, which is desktop two. And here I can have all the things related to entertainment, So all the things that I would require, maybe games and all, I can have them open over here. So this is what the concept of “workspace” is all about. When you examine the concept of workspace, you will notice that the basic thing, including wallpaper and files, is the same across multiple workspaces. However, the things that are deployed here are different on different workspaces.
Terraform workspace, which is very similar to this, also works. So, basically, TerraForm workspace allows us to have multiple workspaces, or I should say TerraForm allows us to have multiple workspaces. And each of these workspaces can have a different set of environment variables. So let’s understand this with an example. So let’s assume that this is project A. Now, within project A, I have a staging workspace, and within the staging workspace I have a different set of environment variables, which is instance type 2 micro. Now, the same goes with production. When I switch to the production workspace, the instance type changes from t2 micro to m4 large whenever I run a Terraform application automatically. And if I go to a dev workspace, the instance type will be selected as “nano” when I do a Terraform apply. So depending on which workspace you select, different environment variables would really apply. So, it’s time for a demo, because a demo is something that will give you a good example.
So, I am currently in a directory called Kplabs Workspace. And if you go into the Kplabs workspace, I have a simple EC-2 PF file, and this is where I have referred to the module EC-2 that we are working on now. So, if I do a Terraform workspace, you see, it is giving me the option of various workspace-related configurations. So, if I do a Terraform workspace show, it will show me my current workspace, which is prod. Now, within this, let me do a TerraForm Plan and various environmental settings. It could be AMIID, security groups, or instance type, but it would be specific to this workspace. As you can see, the instance type is currently M for large. Now, whenever I switch workspaces, if I do a Terraform Workspace list, you can see that these are the three workspaces that are currently available. So let me switch to the developer workspace. So currently I am in my development workspace. And if I do a TerraForm Plan right now, the instance type, you see, automatically gets computed with T-2 micro. So, this is the advantage of TerraForm Workspace. There are several additional benefits to having a Terraform workspace, which we will discuss during the implementation phase. So, I hope you understand what workspace concepts are all about and what TerraCom Workspace is all about in a high-level overview.
6. Implementing Terraform Workspace
Hey everyone, and welcome back. Now in the earlier video we were discussing at a high level overview about a TerraForm workspace and how depending upon the environment, there can be different variable configurations that we can achieve. So let’s do one thing: let’s jump into the practical aspect and look into how we can design a workspace from scratch. So, for today’s demo, I have a folder called “KP Latch Hyper Workspace.” And inside this folder, I have a file called “splash workspace TF.” Now if you look into the file AplashiPhone Workspace TF, this is a very simple file that has a resource of “AWS instance” and basically creates an easy AWS instance. This is something that we have already seen quite extensively. Now, what we want is that if we have a default workspace, then we need an instance type, which is t two nano. If we have a dev workspace, then we need an instance type, which is tw0-micro.
If you have a large workspace, you’ll need the instance type “large.” So this is something that we want. So let’s look into how we can achieve that. Now, from the CLI, if you do a TerraForm Workspace Hyphen held, these are the available subcommands here. Now one of the subcommands is “Show,” which basically shows you the name of the current workspace. So let’s try it out. So I’ll say TerraForm workspace demonstration. So by default, you are always in the default workspace. Now, if you want to create a workspace, you can make use of a new command.
So let’s try it out. As a result, I’ll say Terraform workspace is new. I’m going to call it “Dev.” So it says that we have created and switched the workspace to Dev. So if you do a Terraform workspace show, you will see that we are in the Dev workspace. Now, in a similar way, let’s create one more workspace and let’s call it “Prod.” All right, so now if you do a TerraForm workspace list, it will show you all the workspaces that are available. And the star basically denotes which workspace you are currently in. Now, depending on the name of the workspace, we want the instance type to change. So what we have to do is make use of maps as well as functions. So let’s do one thing; let’s go ahead and first create a map. So I’ll call it a variable. Let’s do an instance type, and the type that we’ll be using is a map. Let’s do a default, and say we have a default where you need T two nano if you have a workspace of default. If you have a workspace named “Dev,” then the instance type should be “micro.” And if you have a workspace of fraud, then the instance type should be “two large.” All right? So that’s the high-level overview.
So let’s go ahead and remove this. Now that we have this map function created, the next thing that we have to do is change this instance type. So the first step is to turn it into a variable. As a result, I say VAR instance type. And what we want is for the instance type to change depending on the workspace. As a result, we must create a Terraform workspace. So what we have to do depends on Terraform’s workspace. So if a workspace is the default, then the instance type should be “nano.” As a result, it should retrieve the value from era from the workspace. So what we have to do is make use of an additional function. So for our use case, the lookup function is mostly idle. So we have already looked into what the lookup function is. So you must use the lookup function and then supply a map. In our case, the map is of the virtual instance underscore type, and there is also a key. The key here is the value that Terraform workspace will provide. As a result, TerraForm workspace will display the workspace that you are currently in.
And based on that, the appropriate value within the map will be shown. All right? So let’s go ahead and use a lookup function. So the syntax is lookup followed by map, a comma, and the key. So this default value is optional. So we have a lookup followed by the map. So map is the instance type variable followed by a comma. Then you have a Terraform workspace. Great. So this seems to be fine. Let’s try it out. So from the CLI, let’s quickly do a TerraForm plan. So the directory is not initialized; let’s quickly do a TerraForm in it. All right? So once the initialization is done, let’s quickly do a Terraform plan. Now, if you look a bit up, currently the instance type is “two large.” Now, this can be verified if you do a Terraform Workspace show; currently, you are within the Production workspace. So for the product, the instance type is “two large.” So let’s try switching to Dev. So let’s clear the screen.
Let’s do a TerraForm Workspace selection. Dev. Once done, let’s do a TerraForm plan yet again. So, if you look a little higher, you’ll notice that the instance type is “twice micro.” So, hopefully, you have a general understanding of what workspace entails. Now let me quickly show you one more important thing that you need to remember. So when you do a Terraform apply, let’s go ahead and do a Terraform apply for the current development workspace. So I’ll say yes; fantastic. So it took around 55 seconds, and our instance is now created. Now, if you look into the directory of Kplab’s workspace, you will see that there are two folders that are available. The first is the TerraForm dot, and the second is TerraForm th state d. So keep this Terraform in mind, state D. Now, if you go inside this folder, you will see two more folders. One for development and one for production. Now remember that in workspaces, TerraForm maintains the state file separately for each workspace. So, in the dev workspace, the TerraForm th state file will be in the dev folder, and in the production workspace, it will be in the production folder.
So since we had created an easy instance for development, if you open this up, you will see that you have a Terraform or a state file that is available, but for production, you will not see any files because there are no applications that we have done. And for the default workspace, the Terraformer statefile will be created on the root directory. Let’s also see that. So let’s clear the screen. So I’ll do a TerraForm workspace selection by default, let’s do a TerraForm application, and I’ll do a yes. So currently the EC to instance creation has started, and now, immediately, you see a TerraForm TF statefile that was generated in the root. So this TerraForm dot PF state file is always associated with the default workspace. For any other custom workspace that you create, the PS state file will be under the TerraForm TF state directory. So that’s the high-level overview of the Terraform workspaces. I hope this video has been informative for you, and I look forward to seeing the next video. How we can use the UI actions.
