Terraform

curl -fsSL https://apt.releases.hashicorp.com/gpg\
 | sudo tee /etc/apt/keyrings/hashicorp.asc >/dev/null

cat << EOF | sudo tee /etc/apt/sources.list.d/hashicorp.list >/dev/null
deb [arch=$(dpkg --print-architecture)\
 signed-by=/etc/apt/keyrings/hashicorp.asc]\
 https://apt.releases.hashicorp.com $(lsb_release -cs) main
EOF

sudo apt update  && sudo apt list  --upgradeable
sudo apt upgrade && sudo apt install terraform
terraform version

Structure

sdlc/ ├─ main.tf # Main Terraform config file ├─ variables.tf # Variable declarations ├─ terraform.tfvars # Variable assigned ├─ outputs.tf # Output definitions ├─ provider.tf # Provider-specific config ├─ terraform.tfstate # Terraform state file ├─ dev.tf # Dev Env config for development ├─ prod.tf # Prod Env config for production ├─ modules/ # Directory for custom modules │ ├─ module1/ # Custom module 1 │ │ ├─ main.tf # Module-specific Terraform config │ │ ├─ variables.tf # Module-specific variables │ │ └─ outputs.tf # Module-specific outputs │ └─ module2/ # Custom module 2 │ ├─ main.tf │ ├─ variables.tf │ └─ outputs.tf ├─ environments/ # Directory for env │ ├─ dev/ # Development env │ │ ├─ main.tf # Env specific Terraform config │ │ ├─ variables.tf │ │ └─ outputs.tf │ └─ prod/ # Production env │ ├─ main.tf │ ├─ variables.tf │ └─ outputs.tf ├─ scripts/ # Scripts or utility for IaC └── README.md Summary variables.tf is essentially the variable declarations needed to make the module work. More specifically, the variables you want to be able to pass into the module for it to work the way you want it to. From a beginner's POV, the module in question is the root module. If you're unclear what I mean by this, this is the directory where you've got all your *.tf files when you're first starting out, and where you also have your terraform.tfvars file. Once you get to the point that you're ready to write a separate module, then that module (in another dir) will itself have its own variables.tf file. So when you call the module, you will want to pass values to the variables named in the module's variables.tf file. Rephrasing: terraform.tfvars contains bootstrap values that get passed to the root module's variables.tf file. When you call a module, you don't have access to a separate terraform.tfvars file, but you do expressly pass them when you call the module. Those variable names need to match the declared variables in the module's variables.tf file. If you set a variable in terraform.tfvars but it doesn't exist in variables.tf, you'll get a warning that the variable doesn't exist and is therefore ignored. Very briefly: A collection of *.tf files in a single directory is a module If those *.tf files exist in the root level directory of a stack (ie, where you cd to in order to run terraform), then you have the option of creating terraform.tfvars, rather than always editing values into variables.tf If those *.tf files exist in a module other than the root level directory, you do not have the option of using terraform.tfvars in that directory terraform.tfvars should be considered your way of setting variables for your deployment; if you're still editing variables.tf for every one of your unique deployments, then your stack still needs work before you can consider it ready to be shared with others A bit murkier: Naming the file variables.tf is merely a convention. You could call it yourname.tf and it'll still work just fine. Terraform will read all *.tf files in the directory and treat the contents the same regardless of how the file is named. Murkier still: There are other files along with terraform.tfvars that can be used, but just like terraform.tfvars, only used in the root module's directory. Those files follow a naming format of *.auto.tfvars or *.auto.tfvars.json. The former follow the same formatting rules as terraform.tfvars, whereas the latter need to follow standard JSON notation. A good example: Would be a file named mypasswords.auto.tfvars This allows you to have local password definitions that don't get checked into git/GitHub, whereas checking terraform.tfvars into the repo, while perhaps being too specific to your particular usage, won't end up compromising your deployments with an accidentally shared set of credentials. It could even contain a set of reasonable defaults that you and your team may want to change, depending on needs. Heck: You could create deployment1.auto.tfvars and completely ignore using terraform.tfvars, if that's how you want to roll. I should note that variables.tf can set default values (overridden by whatever you set in terraform.tfvars), as well as doing validation on what is passed to it. TL;DR terraform.tfvars is what you pass to your stack to make it meaningfully distinct from any other deployment. variables.tf declares the variable names that you need to pass to the stack. Playground terraform init terraform plan terraform apply terraform destroy terraform fmt -diff -recursive -write=false terraform fmt -diff -recursive terraform fmt -check -recursive terraform plan -out=tfplan References Terraform » reddit » variable.tf vs. terraform.tfvars Terraform » Adding Untracked Resources to TF State Terraform » terraform.tfvars vs. variable.tf Terraform » CLI Packages for Ubuntu Terraform » Input Variables Terraform » Output Values Terraform » Local Values Terraform » .tfvars Terraform » Jenkins Terraform » fmt Terraform » TFState » Sonatype Nexus 3 Terraform » Resources » Behavior Terraform » Resources » Blocks Terraform » Creating Modules Terraform » validate Terraform » Resources Terraform » Language Terraform » console Terraform » init Terraform » get Terraform » .terraform.lock.hcl excluded from .gitignore Terraform » Items to include in .gitignore Terraform » Backend » Configuration Terraform » Sapcelift » .gitignore Terraform » TFState » GitLab Terraform » force-unlock Terraform » Remote State Terraform » State Locking Terraform » .gitignore Terraform » Provider » azurerm Terraform » Provider » azuread Terraform » Provider » google Terraform » Provider » Linode Terraform » Provider » aws Terraform » Module » azurerm Terraform » Module » eks Google Cloud CLI Minikube AWS CLI Vagrant Kubectl Ansible Helm AWS K8s K9s Nexus CIDR Git