π Terraform Series β Day 9

Search for a command to run...

No comments yet. Be the first to comment.
π Terraform Series β Automate Your Infrastructure Starting a complete **Terraform series** where Iβll cover everything from **basic to advanced level** with real-world practicals. In this series, you will learn: β’ What is Infrastructure as Code (IaC) & why it matters β’ Terraform fundamentals (providers, resources, state) β’ Writing and managing Terraform configurations β’ Variables, outputs & modules β’ Remote state & state management β’ Provisioning infrastructure on AWS β’ Automation & real-world use cases β’ Advanced concepts like workspaces, modules, and best practices π― Goal: Help you automate infrastructure and become job-ready in DevOps. Perfect for **beginners, students, and DevOps learners** who want hands-on experience. Stay tuned and letβs build infrastructure the smart way β‘π» #Terraform #DevOps #Cloud #AWS #InfrastructureAsCode #Automation
Conditional Expressions (Ternary Operator) π Abstract In real-world DevOps projects, infrastructure often needs to behave differently based on environments such as development, staging, and productio
Master GitLab CI/CD Variables, Secrets Management, Artifacts & Best Practices π Introduction In the previous article, we learned how GitLab Runners execute CI/CD pipelines and how to configure Self-H

Learn GitLab Runners, Hosted vs Self-Hosted Runners, Runner Registration, Tags, Pipeline Editor & Parallel Jobs π Introduction In the previous article, we created our first GitLab CI/CD pipeline and

Learn Continuous Integration, Continuous Delivery, Pipelines, Stages, Jobs & .gitlab-ci.yml π Introduction In the previous articles, we explored GitLab fundamentals, repository management, and collab

Learn Docker Scout, Multi-Stage Builds, Docker Hardened Images (DHI), SBOM, Docker Model Runner, Ask Gordon AI, and production-ready container security through practical, real-world examples. Introduc

Import Repositories, Mirroring & Repository Management Best Practices π Introduction In the previous articles, we learned the fundamentals of GitLab, created projects, and configured secure authentic

Meta Arguments: count vs for_each with Output
In Terraform, managing multiple resources efficiently is a common requirement in real-world DevOps projects. While creating multiple instances may seem straightforward, choosing the right approach can significantly impact scalability, flexibility, and maintainability.
This blog explores Terraform meta arguments, specifically count and for_each, and demonstrates how they behave differently when creating multiple resources. It also covers how outputs change based on these approaches and when to use depends_on for explicit dependencies.
After completing this blog, you will be able to:
Understand what meta arguments are in Terraform
Create multiple resources using count
Identify limitations of count
Use for_each for better flexibility
Handle outputs correctly for both approaches
Understand the use of depends_on
Meta arguments are special Terraform keywords that control resource behavior.
Common Meta Arguments:
count
for_each
depends_on
lifecycle
π In this tutorial, we focus on:
count
for_each
countβ Code
resource "aws_instance" "my_instance" {
count = 2
ami = var.ec2_ami_id
instance_type = var.ec2_instance_type
}
Terraform creates 2 EC2 instances
Indexed as:
aws_instance.my_instance[0]
aws_instance.my_instance[1]
countoutput "ec2_public_ip" {
value = aws_instance.my_instance[*].public_ip
}
[*] β Splat Expression
Used to extract values from multiple resources
countUsing count has restrictions:
Same configuration for all instances
Cannot assign:
Different names β
Different instance types β
for_each (Better Approach)resource "aws_instance" "my_instance" {
for_each = {
Apurv-1 = "t2.micro"
Apurv-2 = "t2.medium"
}
ami = var.ec2_ami_id
instance_type = each.value
tags = {
Name = each.key
}
}
each.key β Instance Name
each.value β Instance Type
π Each instance becomes unique and configurable
terraform apply
β Old Code
aws_instance.my_instance[*].public_ip
count β returns list
for_each β returns map
π So [*] does not work here
for_eachβ Public IP
output "ec2_public_ip" {
value = [
for instance in aws_instance.my_instance :
instance.public_ip
]
}
β Public DNS
output "ec2_public_dns" {
value = [
for instance in aws_instance.my_instance :
instance.public_dns
]
}
β Private IP
output "ec2_private_ip" {
value = [
for instance in aws_instance.my_instance :
instance.private_ip
]
}
After applying for_each:
Different instance names β
Different instance types β
Correct outputs fetched β
depends_onβ Definition
depends_on is used to explicitly define dependencies
βοΈ Example
depends_on = [
aws_security_group.my_groups,
aws_key_pair.my_key
]
When Terraform cannot detect dependency automatically
When using hardcoded values
When dependencies are indirect
β When NOT to Use
key_name = aws_key_pair.my_key.key_name
π Terraform automatically handles this (implicit dependency)
Use count β for simple, identical resources
Use for_each β for flexible and scalable setups
Understand difference between list vs map outputs
Use depends_on only when required
βA complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.β
π§ Email: gujjarapurv181@gmail.com
π GitHub: github.com/ApurvGujjar07
πΌ LinkedIn: linkedin.com/in/apurv-gujjar