Jam Notes Guide: Terraform Templates, Tips, and Integrations

A summary of our first 3 Jam sessions, focusing on Terraform templates, general tips, and integrations

JUN 18, 2021 | JESSICA ERDMAN
undefined

If you've been following our journey at InfraCode, you know that we are dedicated to providing useful, actionable tips to our readers. In this guide, we'll summarize our Jam sessions, bringing you advice and ideas from DevOps professionals.

If you're looking to discuss these ideas with others in the industry, we encourage you to join our Slack to continue the conversation.

In this article, we'll summarize:

  • The three top Infrastructure as Code best practices
  • Common Terraform template mistakes
  • Terraform and Kubernetes--tips to use it

The three top Infrastructure as Code best practiceslink icon

It's hard to ignore the fact that Infrastructure as Code is abundant in DevOps--and it's a word that gets thrown around often, perhaps with not enough thought given to its implications and use. In fact, we'd even recommend taking a step back to consider the implications of DevOps in general--is your team truly committed to DevOps (both the people and the process)? If not, we recommend structuring your team in that allows for DevOps philosophies to thrive (less siloes, more efficiencies).

In our conversation on Infrastructure as Code best practices, similar ideas were echoed. Reusability was another important theme voiced by our speakers--and knowing how to recognize when code is reusable can be an important key to success on DevOps teams.

The top three tips for Infrastructure as Code include:

1. Consider immutable infrastructure

While reusability and flexibility are great words when it comes to Terraform, it's also important to consider underlying immutable infrastructure, where cloud resources cannot be changed after deployment. This allows some degree of consistency in a world of Infrastructure as Code.

2. Know the structuring of Infrastructure as Code.

The tree view snippet of Infrastructure as Code shows the hierarchy:

Tree view snippet below:

$ tree terraform_project/

terraform_project/

├── dev

│ ├── main.tf

│ ├── outputs.tf

│ └── variables.tf

├── modules

│ ├── ec2

│ │ ├── ec2.tf

│ │ └── main.tf

│ └── vpc

│ ├── main.tf

│ └── vpc.tf

├── prod

│ ├── main.tf

│ ├── outputs.tf

│ └── variables.tf

└── uat

├── main.tf

├── outputs.tf

└── variables.tf

With this map, you can begin to understand the overall structure of your Infrastructure as Code.

3. Don't re-invent the wheel--look for efficiencies where they exist.

For example, by using reusable Terraform modules, you can create/replicated cloud resources and not spend time copying code. These Terraform modules can be used across environments. The same is true for shared modules--there are already existing Terraform modules created by HashiCorp that you can use. Don't waste time re-inventing the wheel when these efficiencies already exist and are ready for you to use.

To read the full list of Infrastructure as Code tips and get an overview, check out the article in full.


Common Terraform Template Mistakes
link icon

A Terraform template should be well-laid out and organized in a way that's easy to use. And, by separating the Terraform template based on modules, it can ensure that teammates across departments can work on the templates remotely.

If you need to do something twice, build a Terraform template.

Looking for more Terraform template advice? Our Jam notes from our Terraform template session discuss in-depth advice. You can access it here.

The most common Terraform template mistakes include:

-Building a single Terraform template. While it may seem easier to just write one file, if you make a mistake and need to run the Terraform destroy command, you're going to take down your entire team's infrastructure. By building multiple Terraform templates, you can keep your overall infrastructure safe from this risk.

-Not thinking about your data. There's persistent and non-persistent data (data which can't be deleted versus deletable data). Plan ahead and think about different types of data.

-Not treating Infrastructure as Code as...code. Because Infrastructure as Code is still code, you still need to put it in a repository, test it, and use the code in a pipeline.

You can find more Terraform template advice here.

Terraform and Kubernetes--Tips to Uselink icon

Kubernetes is easily misused--and it can be tempting to jump into Kubernetes without considering its implications. In a recent Jam discussion, we asked about Kubernetes misuses, and general DevOps advice. To see the full conversation, check out our article in full.

If you're wondering if Kubernetes is right for your project, we have this piece of advice for you:

Don't start with Kubernetes. Don't even start with serverless. Build your app and then see whether Kubernetes or serverless is right for your product. But, don't work backward from Kubernetes.

And--another huge mistake (arguably not only for Kubernetes, but for all of DevOps): chasing buzzwords and buzzworthy tools. If you don't have a good reason for using Kubernetes (or any other tool)--don't use it.

While DevOps isn't necessarily hard, it can be complex, and with many tools available, it can be tempting to take a tool-first approach to DevOps. It's vital to take a step back and assess your project holistically before jumping into any approach--whether it's Kubernetes, Terraform, or the latest product on the market.

Read the full (and fascinating) conversation about Terraform and Kubernetes here.

As we continue to have frank discussions about DevOps and Terraform, we invite you to follow along. We encourage you to join our Slack to continue the conversation.