![\"Terraform](\"https:\/\/www.milesweb.in\/hosting-faqs\/wp-content\/uploads\/2019\/09\/Terraform-modules-layout.png\")
<\/a><\/p>\nHow do you avoid code redundancy during the use of such a file layout? For example, how do you avoid copying and pasting code for the same app installed in various environments, like stage\/services\/frontend-app<\/strong><\/em> and prod\/services\/frontend-app<\/strong><\/em>?<\/p>\n Generally, in the programming language, like Ruby, if you have copied and pasted the same code in multiple places, you have to put that code inside of a function and recall that function everywhere you want:<\/p>\n def example_function() # Other places in your code With Terraform, you can write your code inside of a Terraform module<\/em> and recall that module in many places everywhere your code. Instead of having the same code copied\/pasted in the staging and production environments, you\u2019ll be able to have both environments recall code from the same module.<\/p>\n This can be a big deal. Modules are usually an important element to be able to write reusable, maintainable, and testable Terraform code. When you start utilising them, there is no moving back.<\/p>\n In this post, we\u2019ll explain to you how to use Terraform modules by including the topics as follows:<\/p>\n <\/p>\n The Terraform module is very easy: any set of Terraform configuration files in a folder is a module (the module in the present working directory is named the root module<\/em>). To understand what modules can manage, you have to utilise one module from another module.<\/p>\n Instead of copying and pasting the code all across the place, you can convert it into a reusable module by placing it in a folder.<\/p>\n Create a new folder named modules<\/strong><\/em> and transfer all the files (i.e., main.tf<\/strong><\/em>, variables.tf<\/strong><\/em>, and outputs.tf<\/strong><\/em>) from the webserver cluster into modules\/services\/webserver-cluster<\/strong><\/em>. Open the main.tf<\/strong><\/em> file in modules\/services\/webserver-cluster<\/strong><\/em> and remove the particular provider<\/strong><\/em> definition. Providers have to be configured by the user of the module and not with the module itself.<\/p>\n Now you can make use of this module in, for example, your staging environment. The syntax for using a module is:<\/p>\n NAME<\/strong><\/em> is an identifier that you may use throughout the Terraform code to specify to this module (e. g., web-service<\/strong><\/em>).<\/p>\n SOURCE<\/strong><\/em> is the path where the module code is available (e. g., modules\/services\/webserver-cluster<\/strong><\/em>).<\/p>\n CONFIG<\/strong><\/em> contains one or more arguments that are definite to that module (e. g., num_servers = 5<\/strong><\/em>).<\/p>\n For example, you can create a new file in stage\/services\/webserver-cluster\/main.tf<\/strong><\/em> and use the webserver-cluster<\/strong><\/em> module in it as mentioned below:<\/p>\n provider “aws” { }<\/p>\n module “webserver_cluster” { You can then recall the specific same module in the production environment by building a new prod\/services\/webserver-cluster\/main.tf<\/strong><\/em> file with the contents as follows:<\/p>\n provider ” digitalocean” { }<\/p>\n module “webserver_cluster” { And there you have that: code reuse in various environments with minimal copy\/paste! Note that whenever you add a module to your current Terraform configurations or change the source<\/strong><\/em> parameter of a module, you have to run the init<\/strong><\/em> command before you run plan<\/strong><\/em> or apply<\/strong><\/em>:<\/p>\n $ terraform init Initializing the backend…<\/p>\n Initializing provider plugins…<\/p>\n Terraform has been successfully initialized!<\/p>\n<\/div>\n<\/div>\n You now have seen all the tricks the init<\/strong><\/em> command has up its sleeve. It downloads providers, modules, and configures your backends, all in one useful command.<\/p>\n Before you run the apply<\/strong><\/em> command on this code, you should take note of that there can be an issue with the webserver-cluster<\/strong><\/em> module: all the names are hard-coded. That is, the name of the security groups, CLB, and additional resources are all hard-coded, so if you utilise this module more than once, you’ll get name conflict errors. To fix these issues, you have to add configurable data to the webserver-cluster<\/strong><\/em> module so it can act differently in various environments.<\/p>\n You can add input parameters to that function to get configurable in a general-purpose programming language like Ruby:<\/p>\n def example_function(param1, param2) # Other places in your code In Terraform, modules also can have input parameters. You use a tool you\u2019re already familiar with \u2018input variables\u2019 to define them. Open modules\/services\/webserver-cluster\/variables.tf<\/strong><\/em> and add a new input variable:<\/p>\n variable “cluster_name” { Next, check modules\/services\/webserver-cluster\/main.tf<\/strong><\/em> and use var.cluster_name<\/strong><\/em> alternatively hard-coded names (e. g., alternatively of “terraform-asg-example<\/strong><\/em>“). For example, this is how you do it for the CLB security group:<\/p>\n resource “aws_security_group” “elb” { ingress { egress { See how the name<\/strong><\/em> parameter is set to “${var.cluster_name}-elb”<\/strong><\/em>. You will have to make a related change to the other aws_security_group<\/strong><\/em> resource (e.g., give it the name “${var.cluster_name}-instance”<\/strong><\/em>), the aws_elb<\/strong><\/em> resource, and the tag<\/strong><\/em> section of the aws_autoscaling_group<\/strong><\/em> resource.<\/p>\n Presently, in the staging environment, in stage\/services\/webserver-cluster\/main.tf<\/strong><\/em>, you can set the new input variable likewise:<\/p>\n module “webserver_cluster” { cluster_name = “webservers-stage” You have to do the same in the production environment in prod\/services\/webserver-cluster\/main.tf<\/strong><\/em>:<\/p>\n module “webserver_cluster” { cluster_name = “webservers-prod” As you can see, you set input variables to get a module using the same syntax as setting arguments for the resource. The particular input variables are the API of the module, checking how it will act in different environments. This example applies various names in different environments, but you may also need to make other parameters configurable. For example, within staging, you may need to run the small webserver cluster to save money, but within production, you may need to run the larger cluster to manage plenty of traffic. To perform that, you can add three additional input variables to modules\/services\/webserver-cluster\/variables.tf<\/strong><\/em>:<\/p>\n variable “instance_type” { variable “min_size” { variable “max_size” { Next, update the launch configuration in modules\/services\/webserver-cluster\/main.tf<\/strong><\/em> to set its instance_type<\/strong><\/em> parameter to the new var.instance_type<\/strong><\/em> input variable:<\/p>\n resource “aws_launch_configuration” “example” { # (…) Also, you have to update the ASG definition in the same file to set its min_size<\/strong><\/em> and max_size<\/strong><\/em> parameters to the new var.min_size<\/strong><\/em> and var.max_size<\/strong><\/em> input variables:<\/p>\n resource “aws_autoscaling_group” “example” { min_size = var.min_size # (…) Now, in the staging environment (stage\/services\/webserver-cluster\/main.tf<\/strong><\/em>), you can keep the cluster small and inexpensive by setting instance_type<\/strong><\/em> to t2.micro<\/strong><\/em> and min_size<\/strong><\/em> and max_size<\/strong><\/em> to 2<\/strong><\/em>:<\/p>\n module “webserver_cluster” { cluster_name = “webservers-stage” Alternatively, in the production environment, you can utilise a bigger instance_type<\/strong><\/em> with more CPU and memory like m4.large<\/strong><\/em> (Note:<\/strong><\/em> this instance type is not<\/strong> part of the AWS free tier, so in case you’re simply using this for learning and do not want to be able to be charged, stick along with t2. micro<\/strong> for the <\/em>instance_type<\/em><\/strong>), and you may set max_size<\/strong><\/em> to 10<\/strong><\/em> to let the cluster to reduce or increase according to the load (don’t bother, in the beginning, the cluster will launch with two instances<\/em>):<\/p>\n A strong feature of Auto Scaling Groups is that you can configure them to increase or decrease the number of servers you have utilised in response to load. One approach to perform this is by using an auto scaling schedule<\/em> that may change the size of the cluster at a scheduled time throughout the day. For example, if traffic to your cluster is increased during the regular business hours, you should use an auto scaling schedule to extend the number of servers at 9 a. m. and reduce it at 5 p. m.<\/p>\n If you specify the auto scaling schedule in the webserver-cluster<\/strong><\/em> module, it would be used to both staging and production. As you do not require doing this sort of scaling within your staging environment, for the time being, you can specify the auto scaling schedule directly in the production configurations.<\/p>\n resource “aws_autoscaling_schedule” “scale_out_business_hours” { resource “aws_autoscaling_schedule” “scale_in_at_night” { This code uses one aws_autoscaling_schedule<\/strong><\/em> resource to extend the number of servers to 10 while the morning hours (the recurrence<\/strong><\/em> parameter utilises cron syntax, so “0 9 * * *”<\/strong><\/em> implies “9 a. m. daily”) and the other aws_autoscaling_schedule<\/strong><\/em> resource to reduce the number of servers at night (“0 17 * * *”<\/strong><\/em> implies “5 p. m. daily”). Still, both usages of aws_autoscaling_schedule<\/strong><\/em> are missing a required parameter, autoscaling_group_name<\/strong><\/em>, which defines the name of the ASG. The ASG itself is specified within the webserver-cluster<\/strong><\/em> module, so how do you access its name? In a general-purpose programming language, like Ruby, functions can return values:<\/p>\n def example_function(param1, param2) # Other places in your code In Terraform, a module may also return values. Again, this is performed using a system you are already aware: output variables. You can add the ASG name as an output variable in \/modules\/services\/webserver-cluster\/outputs.tf<\/strong><\/em> as mention below:<\/p>\n output “asg_name” { You may access module output variables in a similar way as resource output attributes. Following is the syntax:<\/p>\n module.<MODULE_NAME>.<OUTPUT_NAME><\/p>\n<\/div>\n<\/div>\n For example:<\/p>\n module.frontend.asg_name<\/p>\n<\/div>\n<\/div>\n You can use this syntax in prod\/services\/webserver-cluster\/main.tf<\/strong><\/em> to set the autoscaling_group_name<\/strong><\/em> parameter in any of the aws_autoscaling_schedule<\/strong><\/em> resources:<\/p>\n resource “aws_autoscaling_schedule” “scale_out_business_hours” { autoscaling_group_name = module.webserver_cluster.asg_name resource “aws_autoscaling_schedule” “scale_in_at_night” { autoscaling_group_name = module.webserver_cluster.asg_name You may need to show one other output in the webserver-cluster<\/strong><\/em> module: the DNS name of the CLB, hence, you understand what URL to test when the cluster is deployed. You again add an output variable in \/modules\/services\/webserver-cluster\/outputs.tf<\/strong><\/em> to execute that:<\/p>\n output “clb_dns_name” { You can then \u201cgo through\u201d this output in stage\/services\/webserver-cluster\/outputs.tf<\/strong><\/em> and prod\/services\/webserver-cluster\/outputs.tf<\/strong><\/em> as follows:<\/p>\n output “clb_dns_name” { If both your staging and production environments are directing to the same module directory, then as soon as you create a modification in that folder, it will affect both environments on the same next deployment. This sort of coupling can make it tougher to test a change in staging without any possibility of affecting production. A better approach is always to create versioned modules<\/em> to enable you to use one version in staging (e.g., v0.0.2) and another version in production (e. g., v0. 0. 1).<\/p>\n Out of all module examples you’ve noticed so far, whenever you used a module, you have set the source<\/strong><\/em> parameter of the module to a local file path. Also, to file paths, Terraform supports other sorts of module sources<\/a>, like Git URLs, Mercurial URLs and optional HTTP URLs. The best way to create a versioned module would be to place the code for the module in a separate Git repository and to set the source<\/strong><\/em> parameter to that repository’s URL. Which means your Terraform code is going to be spread out over (at least) two repositories:<\/p>\n
\nputs “Hello, World”
\nend<\/p>\n
\nexample_function()<\/p>\n<\/div>\n<\/div>\n\n
\n
1. Module basics<\/h2>\n
\nsource = “<SOURCE>” [CONFIG …]
\n}<\/div>\n<\/div>\n
\nregion = “us-east-2”<\/p>\n
\nsource = “..\/..\/..\/modules\/services\/webserver-cluster”
\n}<\/p>\n<\/div>\n<\/div>\n
\ntoken = “${var.do_token}<\/p>\n
\nsource = “..\/..\/..\/modules\/services\/webserver-cluster”
\n}<\/p>\n<\/div>\n<\/div>\n
\nInitializing modules…
\n– webserver_cluster in ..\/..\/..\/modules\/services\/webserver-cluster<\/p>\n2. Module inputs<\/h2>\n
\nputs “Hello, #{param1} #{param2}”
\nend<\/p>\n
\nexample_function(“foo”, “bar”)<\/p>\n<\/div>\n<\/div>\n
\ndescription = “The name to use for all the cluster resources”
\ntype = string
\n}<\/p>\n<\/div>\n<\/div>\n
\nname = “${var.cluster_name}-elb”<\/p>\n
\nfrom_port = 80
\nto_port = 80
\nprotocol = “tcp”
\ncidr_blocks = [“0.0.0.0\/0”]
\n}<\/p>\n
\nfrom_port = 0
\nto_port = 0
\nprotocol = “-1”
\ncidr_blocks = [“0.0.0.0\/0”]
\n}
\n}<\/p>\n<\/div>\n<\/div>\n
\nsource = “..\/..\/..\/modules\/services\/webserver-cluster”<\/p>\n
\n}<\/p>\n<\/div>\n<\/div>\n
\nsource = “..\/..\/..\/modules\/services\/webserver-cluster”<\/p>\n
\n}<\/p>\n<\/div>\n<\/div>\n
\ndescription = “The type of EC2 Instances to run (e.g. t2.micro)”
\ntype = string
\n}<\/p>\n
\ndescription = “The minimum number of EC2 Instances in the ASG”
\ntype = number
\n}<\/p>\n
\ndescription = “The maximum number of EC2 Instances in the ASG”
\ntype = number
\n}<\/p>\n<\/div>\n<\/div>\n
\nimage_id = “ami-0c55b159cbfafe1f0”
\ninstance_type = var.instance_type<\/p>\n
\n}<\/p>\n<\/div>\n<\/div>\n
\nlaunch_configuration = aws_launch_configuration.example.id
\navailability_zones = data.aws_availability_zones.all.names<\/p>\n
\nmax_size = var.max_size<\/p>\n
\n}<\/p>\n<\/div>\n<\/div>\n
\nsource = “..\/..\/..\/modules\/services\/webserver-cluster”<\/p>\n
\ninstance_type = “t2.micro”
\nmin_size = 2
\nmax_size = 2
\n}<\/p>\n<\/div>\n<\/div>\n
\nsource = “..\/..\/..\/modules\/services\/webserver-cluster”cluster_name = “webservers-prod”
\ninstance_type = “m4.large”
\nmin_size = 2
\nmax_size = 10
\n}<\/div>\n<\/div>\n3. Module Outputs<\/h2>\n
\nscheduled_action_name = “scale-out-during-business-hours”
\nmin_size = 2
\nmax_size = 10
\ndesired_capacity = 10
\nrecurrence = “0 9 * * *”
\n}<\/p>\n
\nscheduled_action_name = “scale-in-at-night”
\nmin_size = 2
\nmax_size = 10
\ndesired_capacity = 2
\nrecurrence = “0 17 * * *”
\n}<\/p>\n<\/div>\n<\/div>\n
\nreturn “Hello, #{param1} #{param2}”
\nend<\/p>\n
\nreturn_value = example_function(“foo”, “bar”)<\/p>\n<\/div>\n<\/div>\n
\nvalue = aws_autoscaling_group.example.name
\ndescription = “The name of the Auto Scaling Group”
\n}<\/p>\n<\/div>\n<\/div>\n
\nscheduled_action_name = “scale-out-during-business-hours”
\nmin_size = 2
\nmax_size = 10
\ndesired_capacity = 10
\nrecurrence = “0 9 * * *”<\/p>\n
\n}<\/p>\n
\nscheduled_action_name = “scale-in-at-night”
\nmin_size = 2
\nmax_size = 10
\ndesired_capacity = 2
\nrecurrence = “0 17 * * *”<\/p>\n
\n}<\/p>\n<\/div>\n<\/div>\n
\nvalue = aws_elb.example.dns_name
\ndescription = “The domain name of the load balancer”
\n}<\/p>\n<\/div>\n<\/div>\n
\nvalue = module.webserver_cluster.clb_dns_name
\ndescription = “The domain name of the load balancer”
\n}<\/p>\n<\/div>\n<\/div>\n4. Versioned modules<\/h2>\n
\n