Anton has quite some open source (one I want to look at is https://github.com/antonbabenko/pre-commit-terraform). He also maintains a website on terraform best practices.
The materials for this workshop are here: https://github.com/antonbabenko/terraform-best-practices-workshop
Infrastructure as code makes DevOps possible:
You can treat infrastructure like application code.
You always know what changed.
You can verify infrastructure before deployment.
His favourite terraform best practice: read the documentation. It is updated and improved all the time. So take the time to read (and re-read) it. https://www.terraform.io, https://learn.hashicorp.com, https://www.terraform-best-practies.com
Amazon, google cloud, azure, others: all have their own configuration mechanism. Terraform can talk to all of them through providers. The advantage of using terraform is that it supports reusable components, cooperation features, remote states, etc.
You can see terraform as a “universal tool for everything with an API”. As a joke, someone made a minecraft provider. So you can place sheep upon blocks…. :-) But you can also use jira issues and so.
He doesn’t like workspaces. It isn’t infrastructure-as-code friendly. It isn’t clear from the code how many workspaces you have. And you can’t see the difference betwee various workspaces. Why it is there? Because Hashicorp needs it for their commercial offering. So: just don’t use it.
You can divide everything up into modules. Self-contained packages of terraform configurations that are managed as a group. Some do’s and don’ts:
Don’t make your module too specific by specifying a provider in your module. Too many things need to be customized here.
Don’t specify a provisioner.
Add documentation and examples. Sane defaults, clean code. Tests! And make it feature-rich. (Regarding documentation: you can use terraform-docs to generate documentation from your code).
How do you organize the modules? Everything in one big project (“all in one”)? Or one git repository per module?
All-in-one has the drawback of an undefined project scope (it can keep on growing until it is unmanageable). But you get fast prototyping. It isn’t too bad when you only have a small number of developers (and not too much time to get it working).
1-on-1 is better for reusability. And it is much clearer what the module has to do. It is also handier if you have multiple developers. If you do 1-on-1, look at terragrunt. A big advantage of terragrunt is that it supports common sets of configuration (which you can for instance use company-wide). It is a bit more opinionated, which can help. A drawback is that the output of certain commands can contain lots of noise.
Terraform 0.12 was released a couple of weeks ago. Will it help? It does mean some changes. But there are nice features:
The syntax is simpler.
“For” loops, dynamic blocks. Correctly working conditional opearators.
More types of variables.
Just use 0.12? Well, there’s a difference between terraform developers and terraform users. Developers are those that really write modules. Users are the domain experts that “only” use terraform modules by specifying correct values.
For developers, 0.12 is great. It allows you to implement nice flexible and dynamic and reusable terraform modules.
For users, 0.12 has only one great feature: the new syntax is a little bit more lightweight. It saves some typing.
0.11 has a 0.12 check command: it lists things you’ll need to fix to get it to
work also on 0.12. And 0.12 has a
0.12upgrade command that will try to
automatically fix lots of things.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):