Devopsdays 2019: terraform workshop - Mikhail Advani¶

Terraform introduction¶

The workshop’s git url: https://github.com/mikhailadvani/terraform-workshop . It has a number of terraform modules with *.tf files (“what you want to configure”) and *.tfvar files (variables about what you’re configuring).

An advantage, compared to many other tools: ease of deletion. Just remove it from your configuration and terraform makes sure it is gone.

Some terraform commands:

• init: initializing your entire terraform module, like downloading the necessary plugins.

• plan: figure out what will be done. So a dry-run.

• apply: do the actual modifying.

• output: outputs values.

• refresh: it re-computes the outputs (this command isn’t used that often).

A drawback of the 0.11 version: it doesn’t handle relative local paths, everything has to be absolute. That’s why he advocates to run terraform inside a docker, as you can control the paths there (there’s no username in the path anymore).

• Inside the part-1/ directory, run terraform init to download the plugins.

• terraform plan to see what will be done (you have to answer questions).

• terraform apply to actually perform the action (you again have to answer the questions).

• terraform plan -out myplan outputs the plan to a file. Here you have to answer the questions. If you subsequently run terraform apply myplan, the plan is applied without you having to answer anything. This is great for running it from a CI/CD system.

• You can pass -var-file=something.tfvars to pass variables.

Inside your module, there’s a terraform.tfstate file with the full state such as terraform knows about it. Don’t commit it to github, as it can contain passwords in plain text.

In part-2, the configuration contains a couple of “resources”. An s3 bucket, a local file and an s3 object. There’s automatic dependency handling: if you use one resource in another (like between the s3 object and the s3 bucket, the dependencies are handled in the right order.

Remote state¶

If there are multiple people who can run terraform, you need two things:

• A locking table (he showed and example with amazon dynamodb in part-3/ of the workshop). This prevents two people from updating the infrastructure at the same time.

• Remote state. Not local state, as it can get out of date when your colleague runs it on his machine. The part-3/ has example config to store the state on an s3 backend. There’s a list of available backends on the terraform website.

Terraform really likes its state. That is the basis. The source of truth is its own state file, not the reality that it manages. So don’t do any manual work on resources handled by terraform. Don’t give anyone write access: only use terraform.

If you’re migrating existing infrastructure to terraform, you first have to define it in terraform. You can then run “import” individually for every specific resource: the import will add them to the state.

Modules¶

There are all sorts of modules on https://registry.terraform.io/

You can also make your own modules in order to re-use pieces of configuration. If you move configuration to a separate module in an existing project that already has a configuration, you need to explicitly move over the state as the identifiers will change (something to module.my_module.something. (terraform state mv something module.my_module).

Note: the main directory in which you ran terraform init originally, that is the “root module”.

Something to look at: someone mentioned https://github.com/gruntwork-io/terragrunt as a nicer way to work with multiple modules. It really works nicer, but there is a drawback of a smaller community for terragrunt as compared to the main terraform community size.

Modules can be stored in git. You can put multiple modules into one git repository, but it is better to stick to one-module-per-repository.

Tip: test your modules! There is a terratest module. You might need to use “outputs” to grab IDs of created resources for use inside the tests or in the teardown.