Configuration Formats
Hashicorp Configuration Language, HCL provides two different formats of configurations wherein users can use any format that suits them the most and their preferences are
- Native format
- Json format
Native format
The Native format of HCL is a human-readable domain-specific language. Its syntax is similar to JSON but much more concise and intuitive, making it much easier to write and understand.
Native format is the preferred way to specify infrastructure, policies, or other configurations in Hashicorp tools such as Terraform. Here is a demonstration of a Terraform configuration, where it has demonstrated using Native Format:
resource "aws_security_group" "example" {
name = "Example Security Group"
vpc_id = aws_vpc.example.id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
JSON format
HCL also supports a JSON-based format aside from native format. The JSON format is a direct translation of the native HCL format into a JSON representation.
This format comes in handy if you want to programmatically generate or manipulate HCL configurations because JSON is an extremely widely-supported data format. Here is an example of a Terraform configuration showing the usage of Json Format:
{
"resource" : {
"aws_security_group" : {
"example" : {
"name" : "Example Security Group",
"vpc_id" : "${aws_vpc.example.id}",
"ingress" : [
{
"from_port" = 80
"to_port" = 80
"protocol" = "tcp"
"cidr_blocks" = ["0.0.0.0/0"]
}
],
"egress" : [
{
"from_port" = 0
"to_port" = 0
"protocol" = "-1
"cidr_blocks" = ["0.0.0.0/0"]
}
]
}
}
}
}
NOTE: The choice between the two depends on personal preference and specific use cases. Native HCL format would usually be preferred for a manual configuration management since it is more directly readable by humans than its JSON format counterpart. JSON format is much better suited for automated or programmatic workflows where the configuration needs to be generated or manipulated programmatically.
Basic Terraform Configuration File Naming Convention
Terraform recommends a set of file naming conventions to help structure your infrastructure as code configurations. This makes it easier to read and understand, navigate, and maintain your code. Let's now dive into each of the different file types and their respective purposes:
1. main.tf
The main file you will use to specify your infrastructure resources that you wish to create, update, or manage using Terraform is known as the main file. It forms the entry point for the
Terraform commands, such as terraform apply and terraform plan. When such commands are run, Terraform looks at all the resources declared in the main.tf file, and based on it, determines what steps it needs to take to bring your infrastructure into the state you want.
It carries resource blocks
2. data.tf
data.tf is used to define data sources, meaning a method by which you can fetch information from outside sources and then use this information in your Terraform configuration. This enables you to import resource details coming from external sources and use them within your infrastructure as code, thus making it more dynamic and flexible to your configuration.
It carries data blocks
3. variables.tf
variables.tf is used for defining your variables in Terraform. These allow your configurations to parameterize so that it becomes adaptable to different environments, configurations, and even use cases.
It contains the variable blocks
4. outputs.tf
outputs.tf is used for declaring your output values. These are the values that are to be computed after Terraform finishes deploying (or creating) your infrastructure.
It contains the output blocks
5. terraform.tf
terraform.tf is used for defining the required version of Terraform and the required providers to manage your defined resources within your main.tf.
The terraform file comprises the terraform blocks
6. providers.tf
providers.tf is used to define providers. This is the central location that you use to define and configure all of the providers that you use in your infrastructure code.
It holds the provider blocks
7. locals.tf
locals.tf is used to define local variables and serves as a dedicated place to define and store local values, which are variables specific to your Terraform project.
It has local blocks
8. backend.tf
backend.tf is used for defining the backend configuration of Terraform, which will indicate where the state of your entire infrastructure will be stored.
It has the backend blocks
Advanced File Naming Conventions for Terraform Configurations
As your infrastructure complexity grows, managing multiple resource blocks in a single configuration file can become cumbersome and challenging. Terraform lets you structure your resource blocks into separate files based on logical groupings so as to enhance the readability, maintainability, and scalability of your code. Examples of more advanced naming conventions include:
1. network.tf
Network.tf is used in defining networking infrastructure resources and also turns out as a central place to manage all the network related resources like VPC, subnets, load balancers etc.
2. storage.tf
storage.tf is used for defining the resources of the storage infrastructure and forms a central place for managing all storage-related resources such as buckets, permission settings, access control settings etc.
It carries resource blocks
3. compute.tf
Compute.tf is used for the definition of the resources of the computing infrastructure, and hence is also being used as a location to manage all the computing related resources like virtual machines (EC2) etc.
It carries resource blocks
NOTE:
network.tf, storage.tf, and compute.tf contain the resource blocks.
Directories
A directory is used to organize your
.tf and/or .tf.json files that's considered root module. But the root module can also contain sub-directories, which are considered sub-modules (or child module).
NOTE: Following are the recommended file naming conventions. Terraform, however, will be flexible enough to let you structure your configurations in ways best suited for your projects. The key would be to maintain consistency and organization throughout your codebase for Terraform.
Feedback
Was this page helpful?
