DEV Community: PH Saurav

Docker Networking Demystified: From Bridge to Overlay with Examples

PH Saurav — Fri, 25 Jul 2025 04:58:13 +0000

Containerization transformed everything from software development to deployment. Docker sits at the center of this transformation. Although Docker is so widely used, its implementation is surrounded by confusion and mystery.
In this article, we will try to demystify Docker networking by exploring key concepts with clear, hands-on examples. We'll break down how these networks function and why they matter.

Key Concepts:

The Foundation:

Although many draw parallels between Docker and Virtual Machines, they miss the foundational architectural difference. The building block of Docker is much different from its main focus on isolation rather than full emulation. All processes run on the same host OS, isolated through Linux Namespaces and managed by cgroups. Namespaces provide the boundaries, and cgroups manage the resource allocation. For networking, Docker leverages Network Namespaces, which will be our deep dive today. We'll explore the fascinating world of cgroups in a future discussion.

Network NameSpaces:

Linux namespaces isolate system resources, and the network namespace is no exception—it creates a completely independent network stack. Each namespace owns its own routing tables, firewall rules,
network interfaces, and even virtual devices, making every container believe it has the entire network to itself.

Linux Bridge:

A bridge connects devices at Layer 2 of the OSI model. The connection is made using network interfaces and physical MAC addresses by extending the broadcast domain.
A Linux bridge is the virtual equivalent. It creates an internal Layer 2 bridge that links multiple network namespaces, letting their interfaces communicate as if they were plugged into the same physical bridge.

Quick Reference: Core Networking Elements

eth0 (Virtual Ethernet) – The primary network interface on most Linux systems. Containers and host reach the outside world through this interface.

lo (loopback) – The loopback interface (127.0.0.1/localhost). Traffic sent here stays inside the same namespace. This allows processes on the same host to communicate using networking APIs (using Port), but the data never leaves the system physically.

MAC Address – Layer-2 hardware address (e.g., 02:42:ac:11:00:02) used by bridges and switches to deliver frames to the correct interface within the same local segment.

IP Address – Layer-3 identifier (e.g., 172.17.0.2) that lets namespaces locate and talk to each other across networks.

Environment Setup:

Practice cements understanding. To follow and try out examples given below, you will just need a Linux machine, physical or VM with Docker installed on it. I am using Ubuntu 20.04 VM running Docker version 28.3.2.

Start by listing every network interface on the host:

ip link list

You should see something similar to this:

The main interfaces that concern us are the loopback interface(lo) and Primary ethernet interface(eth0). There is another interesting interface docker0 that we will discuss in detail later when discussing bridge driver.

Docker Networking

The networking in Docker is managed by some pluggable drivers. Mainly, there are six of them. We’ll walk through each driver, then peek under the hood to see how they map to network namespaces in your environment.

1. None Network Driver

This completely isolates the container from any outside access. What I mean by that is let's see what happens when we choose none driver with --network none flag.

Let's start a container with an alpine image where the network driver is none and start a shell in it with this command:

sudo docker run -it --rm --network none alpine sh

Now run the same command we used previously to list network interfaces on host:

ip link list

You will see something like this:

Notice the container only exposes the lo (loopback) interface—eth0 is absent. Without eth0, the container has no path to the outside world; lo alone provides an isolated, localhost-only network that applications inside can use for internal communication.

Exit the container:

exit

WHY none: It's useful when you don't want your container to have any external connectivity in a fully isolated network most probably for security reasons.

2. Host Network Driver

The host driver removes network isolation. Containers share the host's network stack, including IP addresses, ports, and interfaces.

To see host network driver in action, let's start a similar image in interactive shell mode with --network host and list network interfaces:

sudo docker run -it --rm --network host alpine sh
ip link list

You will notice that all the interfaces are exactly same as the host's interface.

Exit the container:

exit

WHY host: It's useful when you don't want any isolation and want to optimize maximum bare-metal performance.

3. Bridge Network Driver

Finally, we are here with the bridge networking driver that we all use most of the time. As I mentioned above, a bridge is a device that connects devices or network segments at layer 2 and expands the network.
In this network mode, the containers are connected to a virtual Linux bridge. Containers connected to it receive their own IP addresses and can talk to one another freely while still sharing the host’s connection to the outside world.

3.1 Default Bridge Network

When someone creates a container without mentioning any network driver type, it creates a default bridge network. Now the question is, I didn't create any bridge. So, where is my container getting connected to? 🤔

Did you remember when we ran ip link list on host? There was an interesting interface called docker0. I told you we will come back to this. This mysterious interface is our default bridge.

Docker creates it by default and any container by default connects to this default bridge.

Now, to test it out, let's first check out the current status of the bridge. It should be empty if there is no container.

ip link show master docker0

Let's create two containers in the background and check their connection:

sudo docker run -d --name container1 alpine sleep 3600
sudo docker run -d --name container2 alpine sleep 3600

sudo docker exec container1 ip addr # Take the eth0 ip address
sudo docker exec container2 ping -c 2 <container1-ip-address>

So, here we can see that one container can ping the other container, so they are interconnected.

If we now again take a look at our default bridge:

ip link show master docker0

We will be able to see that there are now two connections from two containers in our docker0 bridge.

Let's clean up the containers:

sudo docker stop container1 container2
sudo docker rm container1 container2

3.2 Custom Bridge Network

Instead of using the default bridge given by Docker. We can create our custom bridge:

sudo docker network create my-custom-net

Now, if we check the interface list of the host, we will see that there is a new entry. If we check inside it, we will find it empty. This is our new custom bridge.

Let's create two new containers under this network connected to this bridge and check the connection between them:

sudo docker run -d --name container1 --network my-custom-net alpine sleep 3600
sudo docker run -d --name container2 --network my-custom-net alpine sleep 3600

sudo docker exec container1 ping -c 2 container2

Wait! With default bridge, we needed to get the IP address of container1 to check it from container2. What is going on with custom bridge? We are pinging container2 directly by name. Will this work with default bridge??

The answer is No. The custom bridge has some advantages over the default bridge. That's why Docker in its docs prefers using user-defined bridges instead of the default bridge. Here are some of the major advantages custom bridge gives over default bridge:

User-defined name for ease of management (e.g., my-network)
Automatic DNS resolution by container name. So we can use the container name instead of its IP.
Better isolation by grouping containers into different network rather than in a single default network.
Full control over IP range, gateway, etc.

** For most of the use case these 3 types of drivers are sufficient **
Let's clean up the containers:

sudo docker stop container1 container2
sudo docker rm container1 container2
sudo docker network rm my-custom-net

IPvlan Network Driver:

IPvlan creates virtual interfaces that share the host's MAC address but have different IP addresses. Perfect for scenarios where you need multiple IPs on the same interface. The containers attached directly to host.

It offers two flavors:

• L2 mode – host interface behaves like a switch (Layer 2)
• L3 mode – host interface behaves like a router (Layer 3)

The switch-vs-router debate is a rabbit hole for another day🐰. The key point is you pick the mode that matches your network design.

Let's see how it interacts with the system by trying the L2 mode.
First, we need to know in which gateway the host is on

ip route

So, to create an L2 IPvlan in this network:

sudo docker network create -d ipvlan \
  --subnet=192.168.110.0/24 \
  --gateway=192.168.110.1 \
  -o ipvlan_mode=l2 \
  -o parent=eth0 \
  ipvlan-l2-net

Now, if we create a container in this network and check its network interface:

sudo docker run -it --rm --network ipvlan-l2-net alpine sh
ip addr show eth0

We can see that the MAC address of the interface is the same as the host's, but the IP addresses are different.

Let's clean up:

sudo docker network rm ipvlan-l2-net

WHY IPvlan: Use IPvlan when you need bare-metal network performance (no bridge overhead) or when you must place
containers directly on the same Layer-2 segment as the host. This can bypass the need of NAT/Port mapping to connect to outside network all together.

MACvlan Network Driver:

Macvlan creates sub-interfaces with unique MAC addresses which makes containers appear as physical devices on your network. So it can talk to everything else on the network.

MACvlan offers two modes:

Bridge mode – every container shares the same flat Layer-2 network; all MAC addresses live in one
broadcast domain.
VLAN mode – traffic is tagged with 802.1Q VLAN IDs, slicing the broadcast domain into isolated
VLANs while still using the same physical interface.

Let's try out MacVlan bridge mode. Get the subnet & gateway similar to explained in IPvlan and create a macvlan network:

sudo docker network create -d macvlan \
  --subnet=192.168.110.0/24 \
  --gateway=192.168.110.1 \
  -o parent=eth0 \
  macvlan-bridge-net

Run two container in this network using macvlan-bridge-net:

sudo docker run -d --rm --network macvlan-bridge-net --name container1 --ip 192.168.110.201 alpine sleep 3600
sudo docker run -d --rm --network macvlan-bridge-net --name container2 --ip 192.168.110.202 alpine sleep 3600

Now ping from any device other than the host. The host won't be able to ping these IP as the host karnel is bypassing its own stack for these addresses.

ping -c 2 192.168.110.201
ping -c 2 192.168.110.201

When I try to ping the container from a physical device in my network, it results in success. So these containers are now acting like a device on my network with their own IP and MAC addresses.

Let's clean up:

sudo docker stop container1 container2
sudo docker network rm macvlan-bridge-net

WHY MACvlan: When you want containers to act like separate physical machines on the same LAN—each with its own MAC and IP—so they’re reachable directly by any host without NAT or port-mapping. The container will act like a standalone server.

Overlay Network Driver:

Till now, all the networking has been concerned with a single host. What if we have multiple hosts? Now the game is moving towards networking in Kubernetes.
But Docker has a solution for the multi-host problem, its Overlay Network. This is implemented using Docker swarm.

If we look at the diagram, we can see there is an extra VXLAN connection connecting the host. Now, what is Vxlan?

Vxlan: VXLAN is an overlay protocol that wraps Layer-2 Ethernet frames inside Layer-3 UDP packets, letting you stitch separate Layer-3 networks into one big, flat Layer-2 domain—so containers on different hosts think they’re plugged into the same switch.

Now, to play with the overlay network, we need at least 2 hosts. If you are using VMs, just clone it and create another one, and let's go along. If you have only one host, have faith in my screenshots😇.

Create an overlay network on one host change <manager-ip> to its ip, which will be the manager:

sudo docker swarm init --advertise-addr <manager-ip>
sudo docker network create -d overlay --attachable demo-overlay

Running the advertise command will output a join command. Now, run that join command on other nodes to join them to this overlay network as worker.

Now we have a overlay network where 2 hosts are connected, create one container on the manager host:

sudo docker run -d --rm --name container1 --network demo-overlay alpine sleep 3600

Crete another container on the worker node:

sudo docker run -d --rm --name container2 --network demo-overlay alpine sleep 3600

Now run this ping test from the manager:

sudo docker exec container1 ping -c 2 container2

Success! Think of it, these two containers are in totally different VMs, but they are connected to each other. This is an Overlay network.

Let's clean up:

On the worker:

sudo docker stop container2
sudo docker swarm leave --force

On the manager:

sudo docker stop container1
sudo docker network rm demo-overlay
sudo docker swarm leave --force

WHY Overlay: Overlay network comes in when you want to go with multi-host deployment with something like Docker Swarm service and want your containers to communicate across hosts physical or virtual boundaries.

Wrapping Up

Mission accomplished😰 so it’s done! We’ve covered all six networking drivers Docker offers, giving you the flexibility to tailor container connectivity to nearly any use case. From fully isolated sandboxes to multi-host overlays. I hope you’ve tried out the examples and seen for yourself how Linux networking makes all of these configurations possible. Another key piece of the puzzle is cgroups. Stay tuned we’ll dive into that concept another day. Till then, happy dockering!🐳

Breaking Free from AI Subscriptions: Cost-Effective All-in-One Solution with OpenRouter

PH Saurav — Sat, 15 Mar 2025 19:57:25 +0000

AI is here to stay. From my early days with the Copilot trial to now I am using it in different flavours and capacities. I've become convinced that AI properly used especially, in Software Engineering can significantly boost development productivity and accelerate learning. By the end of this article, I'll share my approach to leveraging AI. If you're still hesitant to use AI out of fear it will take your job, consider this: there's a much higher probability that colleagues who become proficient with AI tools will ultimately replace you instead. To me, this resistance is similar to avoiding Google searches in favour of manually reading documentation—it sounds admirable in theory but is ultimately less practical and runs counter to how modern work happens.

So having said that, one issue with every service nowadays is they're all subscription-based, and moreover, it's often not enough to have just one subscription. Some content is only available on Netflix, and other things are exclusively on Hulu. I felt similarly about major AI models as well—Copilot Pro, Claude Pro, and Grok Pro all require monthly subscriptions. We have Copilot, Tabnine, Cody, and many others in the coding space.

The recent release of models is becoming overwhelming, with Grok, R1, Gemini, and others rapidly emerging to challenge the monopoly of OpenAI and Anthropic. For someone like me who uses these models infrequently or in bursts and loves to play with different models to get a better grasp of improvements in AI, paying for subscriptions feels like a waste of money. Of course, you can purchase API keys and pay for credits as you go, but then you're managing different billing accounts and keys for each model, which is hassle on another level. If only there were a single platform that could solve this problem that going to allow you to use any model you want while simply paying for actual usage. I started searching for a solution for this goal and I've found a solution and I will share all about it in this article.

Goal to achieve

Before explaining the solution, let me provide a brief overview of how I use AI in my workflow. This context will help you understand why I chose this particular approach.
I primarily use AI for interactive chat functionality. I don't prefer automatic code generation or AI autocomplete features, though you can achieve cursor-like code generation with this approach if desired. This wasn't my primary goal because I believe generating large sections of code or multiple files simultaneously via AI isn't ideal. Such practices can introduce problematic code that degrades quality and maintainability.
Instead, I prefer using AI as a collaborative companion—a tool to discuss issues with, solve specific problems, and suggest improvements. For this workflow, two essential features were critical:

Provide better pricing for variable usage patterns (Pay on Usage)
The ability to easily add coding context to chat conversations
A simple way to experiment with and switch between different AI models

OpenRouter a unified interface (All LLM in One API)

In my search for a comprehensive AI solution, I explored various approaches and discovered OpenRouter—a unified API gateway that provides access to about 300 models from major providers including every model from OpenAI, Anthropic, Google, Deepseek, and countless others. If a model is publicly available it will be available in OpenRouter. It serves as an excellent platform to monitor recent AI trends and compare model performance side-by-side.

OpenRouter even offers a multi-model chat interface where you can test and experiment with different models simultaneously. Each model is accessible through a straightforward API interface using a single API key—which is precisely what we'll be utilizing in our next steps.

Perhaps the most appealing aspect is OpenRouter's transparent pricing structure. Costs are clearly displayed for each model and prompt, with no additional fees beyond what you'd pay through official APIs. Integration is remarkably straightforward, as most custom AI chat extensions in IDEs already support the OpenRouter API protocol.

CopilotChat Replacement in IDE

If you just want to chat with different models then OpenRouter's chat interface is quite sufficient but for us software engineers we need to integrate it into the IDE to supercharge the power with coding context and a easy interface. As I mainly use VSCode, JetBrains IDE & NeoVim. I will share my tooling and configuration with some additional options available for different workflows.

For Visual Studio Code & Jetbrain IDE's

For these GUI-based IDEs, my preferred choice is the Continue extension. It's exceptionally straightforward, easily configurable, and comes with clear documentation. Alternatives like Cline provide a more Cursor-like agentic code generation experience which isn't my preference for my workflow, but may appeal to others looking for that functionality. If anyone into that they can use Cline which is more popular VSCode Plugin.

Setup is very simple:

Install the Extension.
Setup the Continue Local Config with model data

{
  "models": [
    {
      "title": "Flash 2.0",
      "provider": "openrouter",
      "model": "google/gemini-2.0-flash-001",
      "apiBase": "https://openrouter.ai/api/v1",
      "apiKey": "OPENROUTER-API-KEY"
    },
    {
      "title": "Claude 3.7 Sonnet",
      "provider": "openrouter",
      "model": "anthropic/claude-3.7-sonnet",
      "apiBase": "https://openrouter.ai/api/v1",
      "apiKey": "OPENROUTER-API-KEY"
    },
    {
      "title": "DeepSeek: R1",
      "provider": "openrouter",
      "model": "deepseek/deepseek-r1:free",
      "apiBase": "https://openrouter.ai/api/v1",
      "apiKey": "OPENROUTER-API-KEY"
    },
    {
      "title": "OpenAI: o3 Mini",
      "provider": "openrouter",
      "model": "openai/o3-mini",
      "apiBase": "https://openrouter.ai/api/v1",
      "apiKey": "OPENROUTER-API-KEY"
    },
  ],
  "contextProviders": [
  ],
  "slashCommands": [
    {
      "name": "share",
      "description": "Export the current chat session to markdown"
    },
    {
      "name": "cmd",
      "description": "Generate a shell command"
    },
    {
      "name": "commit",
      "description": "Generate a git commit message"
    }
  ],
  "data": []
}

In this configuration, I've added four models from four different LLM providers: Google's Gemini 2.0 Flash, Antropics Claude-3.7-sonnet, Deepseek's R1 and OpenAi's o3 Mini. You can add any model from the OpenRouter API you want. Now, you can choose any of these models from the chat Interface and add context with the @ symbol.

For Neovim

I tried many options for Neovim, and everyone is quite hyped about Avante. But to me, it felt like a lot of tooling I don't need as it is more focused for cursor-like code generation agentic workflow. So if anyone into that they will I think really like avante.
After testing many options, I ultimately selected CodeCompanion. It impressed me with its simplicity while still being feature-rich. It provides excellent support for different context providers, makes switching between models effortless, and maintains the lightweight experience I value in my Neovim setup.
CodeCompanion also offers clear, comprehensive documentation, making it straightforward to implement advanced features if anyone wants it.

To replicate similar experiences in Neovim you can check my config from my dotfile repo:
.dotfile: code-companion.lua

Bonus tip: If you use Lualine, you can integrate a loading animation & current model selection for CodeCompanion that significantly enhances your user experience while processing requests.
.dotfile: lualine.lua

.dotfile: spinner.lua

You can follow the getting started guide and set the OPENROUTER_API_KEY in the environment. It's good to go. The experience is in my opinion much better and polished than GitHub Copilot Chat in Neovim.

Conclusion:

After using this setup, I don't miss Copilot & Tabnine Chat at all. In fact, I'm enjoying the additional features this approach provides. Regarding cost, if someone uses expensive models like Claude 3.7 heavily - especially with agentic workflows or you are into "Vibe Coding" where millions of lines of context are shared - then a subscription service like Copilot might be more cost-efficient.

However, for occasional users like me, this approach is very affordable. Plus, you're not dependent on a provider's goodwill to access the latest models. When an API becomes publicly available, you can immediately integrate it into your workflow. In my opinion, this flexibility is invaluable in today's rapidly evolving AI landscape.

Why DB Migration Versioning when we have GIT?

PH Saurav — Mon, 25 Nov 2024 09:31:29 +0000

Database migration versioning is often a notorious pain point in software development. Anyone who worked in a big enough team merging PRs knows it is quite gross to manage and a frequent source of conflict.

Naturally, this begs the question: if we already have robust version control systems like Git, why do we need an additional layer of version control for database migrations within a version control?

I once used to be one of those developers questioning this necessity and researched the topic deeply. Recently, after coming across a recent video by a popular developer and YouTuber Theo titled "We Don't Need Migrations Anymore". I thought of sharing my understanding and taking on this in a simple manner with an example.

Let’s dive into why DB Migration versioning may be gross but may be less gross than anything else we have.

Background Information

When working on a project alone, managing the database schema during development usually doesn’t require much thought. However, once the first release is made, every schema change must be applied not only to the local instance but also to other environments like development, staging, and production. At this point, it becomes essential to establish a system to orchestrate synchronization across the team and between environments.

Then, we have two common approaches we can take to orchestrate DB schema change:

1. Declarative Schema Management
In this approach, a central database schema represents the desired state. Any changes to the desired schema are compared with the current state, and the differences are used to generate the appropriate SQL queries to transition the database from its current state to the desired state. This is very similar to how Terraform works. This method has been gaining significant popularity recently, especially among infrastructure engineers.

2. Imperative Schema Management (Migrations)
In this approach, there is no central database schema. Instead, changes are applied iteratively and represented as a series of instruction sets. Each set of SQL instructions is referred to as a "Migration." Migrations track both the previous and the next revision or version, forming a sequential chain of instructions that are executed in a specific "ORDER."

Now, as the basics are out of the way, let's see why one should choose one or the other.

At first glance, the declarative approach seems much simpler. You only need to maintain a central schema, and the rest is handled automatically. In contrast, migrations can quickly become messy. For instance, imagine two team members working on separate branches, both originating from a branch where the latest migration is A. Each developer creates a new migration, B and C, respectively. When it’s time to merge the changes, conflicts naturally arise: which migration should come after A —> B or C?

So why not use the declarative approach in every scenario? Let's understand this from an example.

Example Scenario: E-commerce Platform Expansion

Suppose your company runs an e-commerce platform that serves thousands of customers daily. The backend is powered by a relational database for managing products, orders, users, and payments deployed in production and users are already using it.

Initial Database Schema
The products table in the database has the following structure:

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    price DECIMAL(10, 2) NOT NULL,
    stock INT NOT NULL
);

Requirement Change
To support global expansion, the business has decided to introduce currency support for products and rename the name column to user_name. The changes are as follows:

Add a currency column to the products table, ensuring it is not nullable. Currency value should be provided on product creation. Old products should be considered as 'USD'.
Rename the name column to user_name, preserving all existing data.

Declarative Approach

As in the declarative approach, we maintain the desired schema, so the updated schema will be:

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    user_name VARCHAR(255) NOT NULL,
    price DECIMAL(10, 2) NOT NULL,
    stock INT NOT NULL
    currency VARCHAR(10) NOT NULL
);

Great! Now, we can call it a day. Not so easy!😁

Issues:

Existing Data Incompatibility:

        ERROR: column "stock" contains null values.

Adding a NOT NULL column (currency in products) directly without default values breaks the database if rows already exist.

Less control on specific instruction:

To change name to user_name and achieve the desired state, there are two possible approaches:

Drop the name column and create a new user_name column.
Alter the name column to user_name.

The first approach can be catastrophic for your application, and you don't have specific controls on which one will be implemented in the declarative approach.

Running in wrong "ORDER":

One important thing about SQL instructions is that they need to run in order. Suppose that, in the generated instruction, the 2nd step runs before the first one. It will cause an error. The declarative approach doesn't give us control over the execution order.

Possible Solution:

These steps can be taken to meet the new requirement for our database.

Step 1:

-- Add the currency column
ALTER TABLE products
    ADD COLUMN currency VARCHAR(10) DEFAULT 'USD' NOT NULL;

-- Rename the 'name' column to 'user_name'
ALTER TABLE products
    RENAME COLUMN name TO user_name;

Step 2 (Optional):

-- Ensure all existing products have default values
UPDATE products SET currency = 'USD';

Step 3:

-- Remove default constraints to make columns explicitly set by API
ALTER TABLE products ALTER COLUMN currency DROP DEFAULT;

Why Migrations?

Now, one can argue we can do these three steps in order one after another in a declarative approach and achieve the desired schema state without any issues. It's true. Then the approach will look something like this:

Add the currency column with default and add the user_name column in the product table.
Deploy the changes.
Ensure the currency column existing data is filled and copy the name data to user_name.
Run instructions in deployed DB.
Drop the name column and drop the default for the currency column.
Deploy the changes.

This may seem something very much doable when you are working with a local DB. But this will introduce a huge headache if you are doing it in a production environment where, most of the time, you don't have access to DB directly and orchestrating these changes to multiple environments can become a nightmare very quickly. Also, multiple people working on this kind of change can lead to possible catastrophes. But this can be a very good approach if the schema is controlled centrally by an infrastructure engineer rather than a developer. I think this is why the declarative approach is increasingly gaining popularity among infrastructure engineers.

Now, migrations solve these issues and make them safe by giving developers the ability to choose "Specific Approach" and "ORDER". Even one can run each migration with an SQL transaction, so if one fails, all the other instructions in the transaction will roll back, making it safer. It is easier to review the migrations and also easier to orchestrate specific implementation in different environments.

Managing Multiple Shadow Cloud Architectures Across Development, Staging, and Production Environments with Terraform Workspace

PH Saurav — Mon, 28 Oct 2024 14:41:07 +0000

Managing multiple shadow cloud architectures across development, staging, and production environments—where architectures are similar but not identical and deployed in different AWS accounts can be complex and challenging. There are various approaches for handling this depending on specific scenarios and requirements. In a recent project, I faced this exact scenario but found limited resources to guide me through. So, I decided to document my approach and share the solution I developed in this blog. So, others in similar situations can use this as a guide. I hope my research and experimentation save you some time.

Goals and Scenario

Set up Development, Staging, and Production environments with similar architectures but differing resource types and sizes.
Consolidate these environments into a single Terraform project to reduce complexity and avoid redundant configurations.
Deploy each environment in a separate AWS account.
Implement remote state management and enable state locking for consistency and collaboration.
Establish safeguards to prevent critical mistakes and ensure safe deployments.

Plan for Implementation

Use Terraform workspaces and a single remote state source to manage state across environments.
Utilize separate variable files to handle environment-specific differences.
Configure AWS profiles at runtime to manage deployments across different AWS accounts.
Implement an environment validator to prevent critical errors.

Setup Process

1. Setup AWS Credentials:

First, we need to set AWS credentials for our accounts. For detailed instructions, follow this doc Configuration and credential file settings in the AWS CLI. In the AWS credentials file (~/.aws/credentials), add credentials with names similar to this:

[app-dev]
aws_access_key_id = <AWS ACCESS KEY>
aws_secret_access_key = <AWS SECRET KEY>

[app-stage]
aws_access_key_id = <AWS ACCESS KEY>
aws_secret_access_key = <AWS SECRET KEY>

[app-prod]
aws_access_key_id = <AWS ACCESS KEY>
aws_secret_access_key = <AWS SECRET KEY>
aws_session_token= <AWS SESSION KEY>   # IF Needed

Here, the names of the profiles app-dev, app-stage, and app-prod are important. With these, we will dynamically choose an AWS account to deploy.

2. Setup Remote Backend for State Management & Locking

In this approach, we’ll use a single backend to manage the architecture states, leveraging Terraform’s workspace feature to separate the state for each environment. We’ll store the states in an S3 bucket and use DynamoDB for state locking. To set this up, create an S3 bucket and a DynamoDB table with a partition key named LockID in your account for state storage. For a detailed guide, check out this article. In our setup, we’re using the production account to store states, so we created the S3 bucket and DynamoDB table there. Next, let’s configure the backend:

terraform {
  backend "s3" {
    bucket         = "bucket-name"
    encrypt        = true
    key            = "app-name/terraform.tfstate"
    region         = "region"
    dynamodb_table = "dynamodb-table-name"
  }
}

Now, we have to initialize the environment. Before doing that, we need to set the account profile in which we have created the backend as our default profile for this environment. We've set this in the app-prod account, so we will set this as default. It is important to set this. Otherwise, the initialization will fail. Also, you need to run this before a session. Otherwise, you can also set this as your default profile. This way, you don't need to export it in your environment.

export AWS_PROFILE=app-prod

Now run terraform init:

terraform init  #-reconfigure tag to avoid conflict not always necessary

3. Setup Terraform Workspaces

Create workspaces for dev, stage, and prod environments with the workspace new command:

terraform workspace new <workspace-name>

To switch to a different workspace, use the select command:

terraform workspace select dev

4. Base Project Setup

Now, in the main project setup, the AWS provider takes a profile dynamically in runtime from the variable:

terraform {
  required_version = "~> 1.9.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.72.1"
    }
  }
}


# * provider block
provider "aws" {
  profile = var.profile   #Dynamically in runtime
  region  = var.aws_region
}

In variables.tf, we will set the required variables:

# * General 
variable "aws_region" {
  description = "AWS Region to use"
  type        = string
}
variable "profile" {
  description = "AWS profile to use"
  type        = string

}

5. Setup `.tfvars` for Each Environment:

We’ll manage environment-specific differences using variable files—special files that store key-value pairs for each configuration. By supplying these files at runtime, we can easily apply unique configurations for each environment. Below is an example for dev and prod; any additional environment would follow a similar structure.
Example of dev.tfvars:

# Generic variables
environment = "dev"    #Environment name for validation
project = "app-name"
aws_region = "us-east-1"
profile = "app-dev"    #AWS profile name for this environment

Example of prod.tfvars:

# Generic variables
environment = "prod"    #Environment name for validation
project = "app-name"
aws_region = "us-east-1"
profile = "app-prod"    #AWS profile name for this environment

Now, to use a specific .tfvars variable file for an environment, we can use the -var-file flag.

For example, for a dev environment, we can use this command to create a plan:

terraform workspace select dev && terraform plan -var-file="dev.tfvars"

Similarly, to apply changes to the prod environment, we can use the command like this:

terraform workspace select prod && terraform apply -var-file="prod.tfvars"

6. Safeguard to Prevent Catastrophe

Looking at the current structure, there’s a significant risk: a developer could accidentally apply the variable file for one environment to another, which could be disastrous—especially for production. To mitigate this, we can implement a validator that verifies the match between the variable file and the current workspace, ensuring the correct tfvars file is used for each workspace.
In our variables.tf we will add this variable and validator:

variable "environment" {
  description = "Environment Name"
  type        = string

  validation {
    condition     = var.environment == terraform.workspace
    error_message = "Workspace & Variable File Inconsistency!! Please Double-check!"
  }
}

In our .tfvars file, we already have a variable called environment that will hold the name of the environment it is for.

Now, if the current environment and the environment of the .tfvars file don't match, it will generate an error similar to this:

Conclusion and some tips

Now, this is it, and the environment is set. This is a great approach if the architecture for your project is quite similar for all environments. Otherwise, separate projects for all environments with module resources may be better suited.
Some common errors you may face:

If you see an Error: No valid credential sources found error at initiation, most probably you don't have any default profile set, so run the export environment command again, as mentioned in Step 2.
If your credential has a session key, it will expire after a period, and in that case, you have to update your AWS account credentials.

DEV Community: PH Saurav

Docker Networking Demystified: From Bridge to Overlay with Examples

Key Concepts:

The Foundation:

Network NameSpaces:

Linux Bridge:

Quick Reference: Core Networking Elements

Environment Setup:

Docker Networking

1. None Network Driver

2. Host Network Driver

3. Bridge Network Driver

3.1 Default Bridge Network

3.2 Custom Bridge Network

IPvlan Network Driver:

MACvlan Network Driver:

Overlay Network Driver:

Wrapping Up

Breaking Free from AI Subscriptions: Cost-Effective All-in-One Solution with OpenRouter

Goal to achieve

OpenRouter a unified interface (All LLM in One API)

CopilotChat Replacement in IDE

For Visual Studio Code & Jetbrain IDE's

For Neovim

Conclusion:

Why DB Migration Versioning when we have GIT?

Background Information

Example Scenario: E-commerce Platform Expansion

Declarative Approach

Issues:

Possible Solution:

Step 1:

Step 2 (Optional):

Step 3:

Why Migrations?

Managing Multiple Shadow Cloud Architectures Across Development, Staging, and Production Environments with Terraform Workspace

Goals and Scenario

Plan for Implementation

Setup Process

1. Setup AWS Credentials:

2. Setup Remote Backend for State Management & Locking

3. Setup Terraform Workspaces

4. Base Project Setup

5. Setup .tfvars for Each Environment:

6. Safeguard to Prevent Catastrophe

Conclusion and some tips

5. Setup `.tfvars` for Each Environment: