Skip to main content

terraform-brain-dump

· 4 min read
info

These are the notes from an internal convo I lead about terraform

  • Terraform is an Infrastructure-as-Code (IaC) tool to manage your infrastructure resources using a declarative language called Hashicorp Configuration Language (HCL).
  • Helm is a package manager for Kubernetes workloads, similar to something like apt-get or Homebrew.
  • Terraform concepts
    • Declarative systems
      • In contrast with Procedural Systems, where you must tell the system the exact steps to take, in a Declarative System you describe your end goal and the system takes care of making reality (i.e. the live system) match your description.
        • This process is called “Convergence”
      • In Kube, the description is your manifest .yaml file and convergence is handled by the [[control loop]] and operators that understand certain Kinds of resources.
      • ArgoCD you can think of as a sort of Meta-declarative system on top of Kube. The description is the AppSets, and the Argo CD Controller handles convergence by polling your source code repos and running kubectl apply (well, via Helm). After that, the kube [[control loop]] takes over.
      • Crossplane is also a meta-declarative system, where the description is a kube manifest and the convergence is handled by terraform.
    • terraform plan command reference
      • This command will compare your statefile to your source code and emit a .tfplan file containing all the commands to bring the live state in line with the source.
    • terraform apply command reference
      • This command will execute the commands in the .tfplan file and write the updated state to the statefile
      • If your source code has changed since the plan file was created, it will be marked dirty and terraform apply will not run.
    • State file
      • https://developer.hashicorp.com/terraform/language/state
      • Purpose of Terraform State
      • Store the statefile in a bucket
        • You can keep it in your repo, and track in git, but don’t. It’s a binary file with a lot of churn.
      • Terraform only knows about the resources in your source code and your statefile.
        • If you have live infrastructure that is not represented in Terraform, you will have to define the terraform code, and then import the live state into your statefile
    • Input and output
      • Each module (see next item) can define input and output values.
        • Inputs take the form of variables
        • Outputs are stored in the statefile (IIRC)
        • The outputs of a module can be hooked up as the input to another module
    • A “Module” is the base unit or terraform configuration and is a collection of resources. It’s also a bit of an overloaded term, unfortunately. I will try to clarify
      • https://developer.hashicorp.com/terraform/language/modules
      • A “root module” is the root of your configuration. It must define providers (plugins for AWS, GCP, Azure, Digital Ocean, etc) to use, the backend (i.e. where to store the statefile), and might have some define some variables
      • A “child module” defined a re-usable configuration, with variables for input, but does not define a backend.
        • The root module can import these child modules.
        • For example, you could define a tagging convention for your resources in a child module and import into all or root modules to keep that resource tags consistent.
      • A “Stack” is basically a special type of child module, which defines a bunch of related infra intended to be imported into an environment
        • E.g. you might have a standard kube cluster stand which you use to create kube clusters in all environments
        • That stack might define not just the kube cluster itself, but also autoscaling node pools, and take the name of a VPC (created by another stack) and the name of the bucket to use for volume mounts
  • Comparing Kapp, Kube, Crossplane and Terraform
    • We use Carvel - kapp for deploying kubernetes resources
      • Kapp assumes that the kube cluster exists
    • Terraform is for defining the kube cluster and related resources (e.g. the VPC its in or the bucket to use for volume mounts).
    • We also use Crossplane on our clusters to deploy cloud functions. Crossplane runs Terraform under the hood.