Terraform

From Chorke Wiki
Jump to navigation Jump to search 
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
├─ academia.auto.tfvars # User Sensitive Data
├─ 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.

Backend » HTTP

terraform {
  backend "http" {
    unlock_address = var.backend_http_tfstate_repository_unlock
    lock_address   = var.backend_http_tfstate_repository_lock
    address        = var.backend_http_tfstate_repository_base
    username       = var.backend_http_username
    password       = var.backend_http_password
    unlock_method  = DELETE
    lock_method    = POST
    retry_wait_min = 5
  }
}

backend_http_tfstate_repository_unlock = "https://gitlab.chorke.org/api/v4/projects/123/terraform/state/aws-chorke/unlock"
backend_http_tfstate_repository_lock   = "https://gitlab.chorke.org/api/v4/projects/123/terraform/state/aws-chorke/lock"
backend_http_tfstate_repository_base   = "https://gitlab.chorke.org/api/v4/projects/123/terraform/state/aws-chorke"
backend_http_username                  = "academia"
backend_http_password                  = "sadaqah!"

backend_http_tfstate_repository_unlock = "https://nexus.chorke.org/repository/terraform/chorke-sdlc/state/aws-chorke/unlock"
backend_http_tfstate_repository_lock   = "https://nexus.chorke.org/repository/terraform/chorke-sdlc/state/aws-chorke/lock"
backend_http_tfstate_repository_base   = "https://nexus.chorke.org/repository/terraform/chorke-sdlc/state/aws-chorke"
backend_http_username                  = "[email protected]"
backend_http_password                  = "sadaqah!"

Playground

aws configure --profile academia
aws configure help
aws configure list
aws configure

terraform fmt -diff  -recursive -write=false
terraform fmt -diff  -recursive
terraform fmt -check -recursive
terraform plan -out=tfplan

terraform init
terraform plan
terraform apply
terraform destroy

cat << INI | tee -a ${HOME}/.aws/config >/dev/null
[default]
region = ap-southeast-1
output = table

INI

cat << INI | tee -a ${HOME}/.aws/credentials >/dev/null
[academia]
aws_access_key_id = AKIBVWTF7RISAULV8Q6Q
aws_secret_access_key = w2JVkDIE9zRTIP/S4m7Mm4cWKlFEYlzg1iGzfCnj

INI

cat << INI | tee -a ${HOME}/.aws/config >/dev/null
[profile academia]
region = ap-southeast-1
output = json

INI

export AWS_DEFAULT_PROFILE=academia
export AWS_PROFILE=academia
aws ec2 describe-vpcs
aws s3 ls

cdktf init --template="python" –local --providers="[email protected]"


brew install cdktf

cat ~/.terraform.d/credentials.tfrc.json

cat ~/.aws/credentials 
cat ~/.aws/config

References
Retrieved from "https://cdn.chorke.org/weke/index.php?title=Terraform&oldid=12253"