Anthony Magalhães

Terraform's Import block functionality will help give a lot of companies the ability to bring their existing infrastructure under a unified code base. Now with the ability to use for_each inside their import block this video shows a cool way to utilize that feature to build on top of your existing pipelines without having to re-engineer anything.

4

🚀 Crazy thing to think about — when do the following Terraform files get created? 🤔 📁 .terraform/ 🔒 .terraform.lock.hcl 📜 .terraform.lock.info 🗂️ terraform.tfstate 🗃️ terraform.tfstate.backup Here’s the breakdown: 📁 .terraform/ Created when you initialize your Terraform project with the command terraform init. It contains important metadata, providers, and module information necessary for Terraform to work. 🔒 .terraform.lock.hcl This file is generated after terraform init and locks provider versions, ensuring consistency across different environments. 🔑 📜 .terraform.lock.info Temporary file created during the execution of terraform apply. It holds the state of the providers being used and is automatically removed once the apply command completes successfully. 🗂️ terraform.tfstate This state file is created or updated after running terraform apply, storing the current state of your infrastructure. It helps Terraform track the resources it manages. 🌍 🗃️ terraform.tfstate.backup This backup file is generated whenever you modify or destroy resources. It acts as a fallback in case something goes wrong during a state change. 🚧 Refer to my below article what happen we you execute terraform init #Terraform #InfrastructureAsCode #DevOps #Iac #AWS

25

🚀 Automating Terraform Formatting on Commit 🚀 Just thought I'd share a cool automation tip for our Terraform codebase. I added a pre-commit hook to our repository that automatically runs terraform fmt on all .tf files before every commit. This ensures that our Terraform files are always properly formatted, without any manual checks! I tried it and it’s pretty interesting! 😄 🛠️ How It Works: Every time we commit, the hook automatically runs terraform fmt on all .tf files 📄. If any files are reformatted, the changes are automatically staged for the commit ✅. The commit will then include the newly formatted files, so no need to manually add them! 🎉 📋 How to Use It: 1️⃣ Place the following script in .git/hooks/pre-commit (make sure to rename the file from pre-commit.sample to pre-commit): #!/bin/sh # Run terraform fmt on all .tf files echo "Running terraform fmt on all Terraform files..." # Apply terraform fmt to all .tf files recursively find . -name "*.tf" -exec terraform fmt -recursive {} \; # Check if any files were modified by terraform fmt if ! git diff --quiet; then echo "Some Terraform files were reformatted. Staging the changes for commit..." # Automatically add the formatted files to the commit git add . echo "Changes staged. Please proceed with the commit." fi echo "All Terraform files are formatted." 2️⃣ Make the file executable: chmod +x .git/hooks/pre-commit https://lnkd.in/gqCMJ37c #Terraform #DevOps #Automation #GitHooks #CodingTips #InfrastructureAsCode #TerraformFmt #DeveloperTools #DevCommunity

17

1 Comment

A solid foundation helps when building quality software. I've been using a variation of this Terraform module template repository for a while now and figured I would share. It includes: • 📦 Devcontainer designed for Terraform dev. • 🧹 pre-commit configurations for validation and linting. • 🪈 Github actions to support semantic version releases based on Conventional commits. • 📖 Automatic README generation using terraform-docs. This template solves the important things, like versioning and distribution, so that you can focus on Terraform. Let me know what you think! https://lnkd.in/ghmnUNh6

89

7 Comments

Chatgpt is becoming more of a great everyday tool in an IT person's toolbox. The more you understand it and understand how to extract the information you need out of it, its easy to skip pass the fluff or things that dont make sense. Needing to import hundreds of existing subnets into terraform using terraforms import block, i knew i did not want to import all of that per subnet and that i also needed to import these into modules. Essentially I have a code block that does a for_each through all of the subnets that come into the variable. import {  for_each = { for key, value in var.subnet : key => value if value.import }  id = each.value.import_resource_id  to = module.subnet.azurerm_subnet.main[each.key] } Only problem was i needed all of those subnets in a specific format in my tfvars file before i could do that. In comes chatgpt and a very much needed python script. As somebody who didnt have the need or time to spend a ton of time writing that script out, i was able to ask it a very small subset of questions piecing this script together found here in my github https://lnkd.in/gWSarEpH. I of course used powershell to export out the subnets in a specific format also that was needed. All in i was able to take a task that could have taken me days to complete by not having to manually import all those subnets in one by one and also generating a script using chatgpt vs having to search forums and ask around and get a bunch of methods for the same outcome. What are some IT use cases you have used chatgpt to improve daily task? #chatgpt #ai #automation #scripting

5

1 Comment

Day 4: My Terraform Learning Adventure! 🌿✨ Terraform Building Blocks & Validation! 🛠️🌿 Today, I dug into some more Terraform essentials and learned how to make my code cleaner and more efficient! Here's what I covered: 1. Terraform Block: This is the foundation of every Terraform configuration. It tells Terraform which providers (like AWS, Azure, etc.) to use and what versions of Terraform itself are compatible. The terraform block helps keep everything organized and ensures you're using the right versions for your setup. terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 3.0" } } required_version = ">= 0.12" } 2. Terraform Comments: Like in any good code, comments are key to understanding what's going on. In Terraform, comments are super easy to add and they don't get in the way of the actual configuration. I’ve started adding more comments to my code to explain why certain things are set up the way they are. # This is a comment resource "aws_instance" "example" { ami = "ami-123456" instance_type = "t2.micro" } 3. Terraform Plan: Before making any changes, terraform plan is your best friend. It shows what will happen when you apply the changes—whether new resources will be created, modified, or destroyed. It’s a great way to double-check before running apply to ensure no surprises! 😅 terraform plan 4. Terraform Validate: This command checks the syntax of your configuration and makes sure everything is formatted correctly. It’s a simple but powerful way to catch errors early before applying any changes to your infrastructure. terraform validate Today has been all about understanding these important tools that help make my infrastructure code more reliable, cleaner, and ready to go! 🚀 Can't wait to keep learning and sharing more updates with you all! #Terraform #DevOps #LearningJourney #InfrastructureAsCode #HashiCorp #Automation RAHAM SHAIK

17

1 Comment

Here are my thoughts on #observability, in no particular order: If your application doesn't produce any #logs (#metrics, #spans, you name it), troubleshooting becomes impossible. You may not even know if it's running. This is especially problematic when your application logs only during usage, but it's not being used. On the flip side, if your application generates too many logs, it can also be challenging to troubleshoot, even if you have log querying tools. Logging "Health check succeeded!" every second for routine health checks contributes to log overload, compounding the previous issue. When log entries are excessively long (structured or not, someone will have to look at your logs at some point). When structured logs contain large, embedded JSON objects. When structured logs embed lengthy lists with line breaks (which are encoded). When stack traces dive into the internals of your HTTP server (or any other third-party library). When the same information is logged repeatedly across 15 layers of error handling. When you cannot attribute an error to an invocation or input parameters. When you log sensitive information. Happy logging!

8

Terraform state got you stressed? Let’s fix that. 🌍 If you’ve ever used Terraform, you know state management can make or break your deployment. I learned this the hard way during a project where I accidentally overwrote resources due to a bad state file setup (we won’t talk about how long it took to fix). Here’s what worked for me: ✅ Remote State Storage: Use Azure Storage with state locking to avoid conflicts. 🔐 Secure Your Backend: Ensure your storage account uses private endpoints to prevent unauthorized access. ⚙️ Keep Your State Organized: Split state files for environments (e.g., dev, staging, prod) to stay in control. Managing state properly is like keeping your room tidy—less mess, fewer headaches (and fewer "what have I done?" moments). What’s your top tip for managing Terraform state? Drop it below! 👇

18

11 Comments

🌐 Interfaces in Kubernetes: Why Standardization Matters If you're starting out with Kubernetes, you've probably encountered CRI, CNI, and CSI – but why are these interfaces essential? 🤔 Kubernetes was designed to work with diverse hardware and providers, but achieving consistency across them takes time and effort. Imagine switching cloud providers for your Nodes – without standardization, every API call *should* fail! 🚫 Standardization brings the consistency that admins and developers rely on for a true cloud native experience and helps with: ✨ Consistency Across Environments Run your workloads anywhere without worrying about the specifics of your environment. Kubernetes abstracts the complexity, providing a consistent experience. 🔌 Decoupling Superpower CRI, for example, decouples Kubernetes from specific container runtimes, supporting multiple options for performance, security, and flexibility. Build for your desired state with ease. 🔗 Layered Approach for Flexibility High-level and low-level runtimes work together, enhancing Kubernetes' adaptability and scalability. Moreover, you can use whatever you find best without any vendor lock-in. Switching is easier if required 🚀 Takeaway: Interfaces like CRI, CNI, and CSI enable Kubernetes’ modularity, making it more scalable, flexible, and interoperable. 💡 #Kubernetes #CloudNative

39

Shared nothing vs. shared storage: we take a deep dive into these two architectures and discuss why WarpStream uses a shared storage architecture 👉 https://lnkd.in/ejeF8uMt

8

Amazon Q Developer Tips: No.8 Understanding Context by Ricardo Sueiras 💡 Tip 8: To maximize your experience with Amazon Q Developer, remember: Prompt + Context = Output. Providing the right context is key to getting useful code suggestions. Keep your relevant files open and refine your prompts for better results! #AmazonQ #AI #CodingTips https://buff.ly/4fYF874 #aws #cloudcomputing #devto

7

Do you work with Kyverno in Kubernetes? Help build a new IT professional certification: #Kyverno Certified Associate (KCA) by telling us what it takes to be successful in your role. Take the survey today: https://lnkd.in/gH9zbypR  #Kubernetes #DevOps #CloudNative

30

Weekly Update: I am at the three-quarter checkpoint for my Terraform studies! It looks like I’ll be ready to sit for the exam in early May. Sidenote: The import block and terraform plan generate-config-out command together allow you to take your existing infrastructure that was configured manually in the AWS/Azure console and covert it to be managed under Terraform 🤯 it writes the Terraform for you! 😍 #terraform #infrastructureAsCode #cloudcomputing #iac #devops

12

Terraform Apply-before-merge, or Apply-after-merge?. Matt Gowie of Masterpoint kicked off a great discussion on LinkedIn around a longstanding debate in the Terraform community: Should you TF apply before or after merging code? I still apply after merge; applying before merge can mask cycles in the code, where resources might only work if created in specific order, which might not be obvious when initially bootstrapping infrastructure configurations. That being said, after reading this discussion, I definitely have a better understanding of scenarios where apply-before-merge might be appropriate. Either way, the number-one goal should be to ensure that whatever ends up in your main branch is deployable and functional. Regardless of the approach, even after merge, IaC can fail and there's no substitute for drift detection with failure tracking. https://lnkd.in/gRZv8Fuz

21

3 Comments

Using the Terraform ‘merge’ Function https://lnkd.in/eNVN9qHz #Configuration #function #HashiCorp #IaC #infrastructure #merge #Terraform

16