Terraform for Google Cloud Essential Guide by Bernd Nordhausen

Author:Bernd Nordhausen
Language: eng
Format: epub
Publisher: Packt
Published: 2023-11-15T00:00:00+00:00

Using a directory structure to manage environments

Note

The code for this section is under the chap05/directory-structure directory in the GitHub repo of this book.

We saw that using workspaces with Google Cloud projects is an easy way to manage nearly identical environments. All we have to do is to create an additional workspace and supply different values in our variable definitions file. However, one of the major limitations of this approach is that the environments must be nearly identical.

Using our example, let’s say we want to have two small servers in the development environment, but in the production environment, we want to have two medium and one large server. Provisioning two servers of different sizes is easy, as we can specify different server sizes in the variable definitions file. However, having a third server of a different configuration only in production is more challenging. We could define a combination of conditional expressions and a count meta-argument, as follows:

count = (terraform.workspace == "prod") ? 1 : 0

However, that can get overly complex very quickly. A better approach is to have different subdirectories for each environment and use modules to keep our code DRY. So, if we want to have two environments, our directory structure looks like the following:

. ├── dev │ ├── backend.tf │ ├── main.tf │ ├── outputs.tf │ ├── provider.tf │ ├── terraform.tfvars │ └── variables.tf ├── modules │ └── server │ ├── main.tf │ ├── outputs.tf │ ├── startup.sh │ └── variables.tf └── prod ├── backend.tf ├── main.tf ├── outputs.tf ├── provider.tf ├── terraform.tfvars └── variables.tf

We have three subdirectories, dev, prod, and modules. Both dev and prod contain the usual files, including their own backend and variable definitions files. The modules subdirectory contains the configuration files for the server module like before.

So, looking at the two main.tf files, we can see how we can define two small servers for dev and three servers of different sizes for prod:

chap05/directory-structure/dev/main.tf

module "server1" { source = "../modules/server" name = "${var.server_name}-1" machine_size = "small" environment = var.environment } module "server2" { source = "../modules/server" name = "${var.server_name}-2" machine_size = "small" environment = var.environment }

In prod/main.tf we change some variable settings and add one additional module declaration for the third server:

chap05/directory-structure/prod/main.tf

module "server1" { source = "../modules/server" name = "${var.server_name}-1" machine_size = "medium" environment = var.environment } module "server2" { source = "../modules/server" name = "${var.server_name}-2" machine_size = "medium" environment = var.environment } module "server3" { source = "../modules/server" name = "${var.server_name}-3" machine_size = "large" environment = var.environment }

With these files in place, we can now run Terraform in each subdirectory specifying the appropriate project ID as an argument:

$ cd dev $ terraform init $ terraform apply -var project_id=[DEV-PROJECT-ID] $ cd ../prod $ terraform init $ terraform apply -var project_id=[PROD-PROJECT-ID]

This structure allows us to have different configurations between the environments yet keep our code DRY. This approach requires the effective use of modules, whether they are stored locally or remotely in Cloud Storage or a repository. When using separate directories, we often need to share state data between the configurations in the different subdirectories.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.