DEV Community: Kishore Kumar

The Hidden Power of Terraform: Why State Management Is Critically Underrated

Kishore Kumar — Mon, 12 May 2025 02:26:43 +0000

When learning Terraform, most people focus on syntax, modules, and provider configuration. While these are essential, one of the most critical components—Terraform state management—is often neglected.

Despite being the backbone of how Terraform functions, state handling is frequently misunderstood. In this article, we’ll explore why state management is essential, what risks poor state practices introduce, and how to manage Terraform state correctly and securely.

What Is Terraform State?

Terraform uses a file called terraform.tfstate to track and map infrastructure resources that it creates and manages. This file:

Maintains the relationship between your configuration and real-world infrastructure
Detects drift or changes between code and reality
Determines what resources need to be added, modified, or destroyed

By default, the state file is stored locally. While this is acceptable for experimentation or small-scale projects, relying on local state in collaborative or production environments is risky and unscalable.

The Risks of Mismanaging State

Improper state management can have serious, often irreversible consequences:

Concurrency Issues: Without state locking, multiple users or automated pipelines may apply changes simultaneously, leading to state corruption or unpredictable behavior.
Exposure of Secrets: State files may store sensitive information—such as passwords or tokens—in plain text, making them a security risk if not properly secured.

Why Remote State Is Non-Negotiable

Remote state stores the terraform.tfstate file in a centralized and secure location, allowing teams to collaborate safely and reliably.

Popular backends for remote state include:

AWS S3 (with DynamoDB for state locking)
Azure Blob Storage
Terraform Cloud or Enterprise

Benefits of remote state:

Enables collaboration through shared access
Ensures safe, atomic operations with state locking
Provides automatic versioning and backup
Enhances security with encryption at rest and in transit

The Importance of State Locking

State locking is vital in preventing multiple operations from modifying the same state file concurrently. Without it, infrastructure changes may overlap and conflict, potentially resulting in broken deployments.

Backends that support locking include:

AWS S3 with DynamoDB
Azure Blob
Terraform Cloud
Consul

With state locking, Terraform automatically acquires a lock before making changes and releases it afterward, preventing simultaneous modifications.

Useful Terraform State Commands

Terraform offers powerful CLI commands for inspecting and managing state directly:

terraform state list                # Lists resources in the current state
terraform state show <resource>    # Displays details of a specific resource
terraform state rm <resource>      # Removes a resource from the state file
terraform state mv <old> <new>     # Renames or moves a resource in state

Terraform Backend Configuration

Below is an example of how to configure a remote backend using AWS S3 with DynamoDB for state locking in your backend.tf:


terraform {
  backend "s3" {
    bucket         = "tfstatebucket"
    key            = "env/prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "my-terraform-lock-table"
    encrypt        = true
  }
}

for Azure Blob Storage


terraform {
  backend "azurerm" {
    resource_group_name  = "infra-rg"
    storage_account_name = "infrastoragestate"
    container_name       = "tfstate"
    key                  = "stateFiles/${var.github_run_id}/terraform.tfstate"
  }
}

Dockerfile Deep Dive, Part 1: CMD vs ENTRYPOINT and COPY vs ADD

Kishore Kumar — Sun, 06 Apr 2025 06:39:37 +0000

Hello, DevOps Enthusiasts!

Mastering Dockerfile instructions is essential for creating efficient, secure, and maintainable container images. In this post, we’ll break down two commonly misunderstood pairs of instructions—CMD vs ENTRYPOINT and COPY vs ADD—through a clear, side-by-side comparison.

If you find it helpful, your support will help continue the series!

↻ CMD vs ENTRYPOINT in Dockerfile

Both CMD and ENTRYPOINT define the command that runs when a container starts, but they behave differently.

CMD

CMD defines the default command or arguments that are executed when a container starts—only if no other command is provided at runtime.

You can override CMD during container execution by passing a new command to docker run.

FROM alpine

CMD ["echo", "Hello Readers"]

If you execute the container with docker run image-name, it will print:

Hello Readers

However, if you provide a different command when running the container, it overrides the CMD instruction entirely.

For example:

docker run image-name echo "Hello Devops Diaries Reader!"

This will produce the output:

Hello Devops Diaries Reader!

This behavior makes CMD useful when you want to define a default command, but still allow users or scripts to run something else if needed.

Tip: Use CMD when you want to specify default arguments or commands that can be easily changed by the user at runtime. For example, you might use CMD to set a default shell or script to execute.

ENTRYPOINT

The ENTRYPOINT instruction defines a command that always executes when the container starts.

Unlike CMD, it cannot be overridden by a command passed at runtime unless you explicitly use the --entrypoint flag. If a command is provided during container execution, it is appended to the ENTRYPOINT.

FROM alpine

ENTRYPOINT ["echo", "Hello Readers"]

Output:

Hello Readers

If we try to override the command by using the same as CMD in the runtime command

docker run image-name hello

Output:

Hello Readers hello

In this case, the command gets appended to the ENTRYPOINT.

Example with --entrypoint to override the ENTRYPOINT

You can override the ENTRYPOINT at runtime using the --entrypoint flag. This allows you to change the command that is executed when the container starts.

docker run --entrypoint echo myimage "Hello, Custom Command"

In this case, instead of executing the default ENTRYPOINT (which is echo Hello Readers), it will execute echo Hello, Custom Command.

➕ COPY vs ADD in Dockerfile

Both COPY and ADD move files into a Docker image — but behave differently.

COPY – Clean and Predictable

Use it for: Copying local files and folders from your build context.

Syntax:

COPY <src> <dest>

Why use it:

Only handles local content
No extraction or downloading
Clear and secure

Example:

FROM python:3.9
WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY app.py .

ADD – More Features, More Risk

Use it for: Archives and remote URLs.

Syntax:

ADD <src> <dest>

Extra features:

Extracts .tar, .gz, etc., automatically to the target folder.
Downloads from URLs directly into the image.

When you use ADD with archives like .tar or .gz, it will automatically extract the contents to the specified target folder. This behavior can save you a step, but it also introduces complexity if you're not expecting it.

Examples:

Extract an archive:

ADD app.tar.gz .

In this example, the contents of app.tar.gz will be automatically extracted into the current working directory (.). If you specify a folder, the contents will be extracted to that directory.

Download from a URL:

ADD https://example.com/file.txt /data/

This command downloads the file.txt from the URL and places it into the /data/ directory inside the Docker image.

Best Practice

Use COPY by default
Use ADD only for extraction or remote URLs (prefer curl or wget instead)

Originally posted in here

If you found this article helpful, please share it with your DevOps colleagues. Feel free to reach out to me at mail@iamkishorekumar.in with any thoughts or questions. Let’s grow together!

About Me – DevOps & DevSecOps Engineer

Kishore Kumar — Thu, 27 Mar 2025 03:22:47 +0000

Hey there! I'm Kishore Kumar, a DevOps & DevSecOps Engineer with 5 years of experience in the IT industry. My expertise spans across CI/CD, Cloud, Kubernetes, and Security Automation, helping teams build robust, scalable, and secure infrastructures.

I believe in sharing unique insights from my DevOps journey, so I write detailed, practical articles on my blog: blog.iamkishorekumar.in My goal is to simplify complex DevOps and DevSecOps concepts, build real-world solutions, and help engineers upskill.

🚀 What I Do

CI/CD & Automation – GitHub Actions, Terraform, and Infrastructure as Code
Cloud & Kubernetes – Deploying scalable apps on AWS, Azure & Kubernetes
DevSecOps & Security – Implementing security in CI/CD pipelines with:
SAST (Static Analysis) – Semgrep, SonarQube
DAST (Dynamic Analysis) – OWASP ZAP
SCA (Software Composition Analysis) – Trivy, Dependency-Check
Container & Infra Security – Trivy, Kube-bench Blogging & Knowledge Sharing – Writing hands-on guides & DevOps strategies

🌐 Check Out My Portfolio

👉 iamkishorekumar.in – My personal site
👉 blog.iamkishorekumar.in DevOps insights.

🔗 Connect with Me

GitHub: KK-Repos
LinkedIn: linkedin.com/in/iamkishorekumar
Email : mail@iamkishorekumar.in

💡 Support My Work

If you find my content valuable, consider supporting my work! Your support helps me continue sharing high-quality DevOps insights. I’m also open to freelance consulting, collaborations, and sponsorships in DevOps & DevSecOps.

Let’s grow together! 🚀

The Dockerfile Disaster: How a Non-Root User Broke Our Production App!

Kishore Kumar — Tue, 25 Mar 2025 02:25:11 +0000

We all know running containers as root is risky. So, like a responsible DevOps engineer, I switched my Docker container to a non-root user. Everything seemed fine… until my app failed to csv export failed in our production

What went wrong? 🤔

The app lost write permissions to a directory.
The container crashed due to EACCES (permission denied) errors.
A small security tweak caused an unexpected production issue.

I spent hours debugging before finally solving it. Want to know the fix? 🔥

👉 Read the full story and solution here:
🔗 The Dockerfile Disaster – How a Non-Root User Broke My App’s File Exports

Have you ever faced permission issues in Docker containers? Let’s discuss in the comments! 👇