DEV Community: Ifeanyi Nworji

Blue/Green Deployment with Nginx Upstreams Using Docker Compose

Ifeanyi Nworji — Sat, 13 Dec 2025 07:37:02 +0000

Auto-Failover, Zero Downtime, and Manual Traffic Switching

One of the core responsibilities of a DevOps engineer is ensuring application availability in the presence of failure. Downtime is rarely caused by deployments themselves, but by how traffic is handled when something goes wrong.

In Stage 2 of my DevOps internship, I implemented a Blue/Green deployment architecture using Nginx upstreams and Docker Compose, focusing on:

Zero failed client requests during outages
Automatic failover within a single request
Manual traffic switching without restarting containers
No application code changes
No image rebuilds

This article is a beginner-friendly but production-accurate walkthrough of the solution, explaining both the configuration and the runtime behavior in detail.

Problem Overview

We are provided with two identical Node.js services packaged as pre-built Docker images:

Blue — primary (active)
Green — backup

Each service exposes the following endpoints:

Endpoint	Purpose
`GET /version`	Returns JSON + headers
`GET /healthz`	Liveness check
`POST /chaos/start`	Simulates failure
`POST /chaos/stop`	Restores service

The task is to place Nginx in front of both services and guarantee:

All traffic goes to Blue by default
On Blue failure, Nginx automatically switches to Green
No client request returns non-200 during failover
Application response headers are forwarded unchanged
Traffic can be manually toggled between Blue and Green

Architecture Overview
The final architecture is intentionally simple and production-aligned:

Client --> Nginx (8080) --> Blue App (8081) OR failover to Green App (8082)

Key characteristics:

Nginx is the single public entrypoint
Blue/Green run simultaneously
Docker Compose orchestrates everything
No Kubernetes, no service mesh, no rebuilds

Environment-Driven Configuration

All behavior is controlled via environment variables, making the setup CI-friendly and reproducible.

Key variables:

BLUE_IMAGE, GREEN_IMAGE
ACTIVE_POOL (blue or green)
RELEASE_ID_BLUE, RELEASE_ID_GREEN
PORT, BLUE_PORT, GREEN_PORT
NGINX_PORT

This design ensures:

No hardcoded values
Safe traffic switching
Easy automated verification

Docker Compose: Service Breakdown

Blue Application Service

app_blue:
  image: ${BLUE_IMAGE}
  container_name: app_blue
  restart: always
  environment:
    - PORT=${PORT}
    - RELEASE_ID=${RELEASE_ID_BLUE}
    - APP_POOL=blue
  expose:
    - "${PORT}"
  ports:
    - "${BLUE_PORT}:${PORT}"
  healthcheck:
    test: ["CMD-SHELL", "node -e \"process.exit(0)\""]
    interval: 5s
    timeout: 2s
    retries: 3

What this achieves:

Runs the provided Blue image without modification
Injects runtime metadata used in response headers
Exposes the service internally to Nginx
Maps a direct port (8081) for chaos testing
Keeps the container healthy and restartable

The Green service is identical, differing only in image, release ID, and port.
This symmetry is critical for Blue/Green deployments.

Nginx Reverse Proxy

nginx:
  image: nginx:latest
  ports:
    - "${NGINX_PORT}:80"
  volumes:
    - ./nginx/nginx.tmpl:/etc/nginx/templates/default.conf.template:ro
    - ./nginx/entrypoint.sh:/docker-entrypoint.d/10-envsubst.sh:ro
    - ./nginx-logs:/var/log/nginx
  environment:
    - ACTIVE_POOL=${ACTIVE_POOL}
    - PORT=${PORT}

Key decisions:

Nginx is the only public interface
Configuration is templated, not static
Logs are persisted for inspection and alerting
No container restarts needed for traffic switching

Nginx Upstreams: Blue/Green Routing

The heart of the solution lies in the Nginx upstream configuration.

Timeout and Retry Configuration

proxy_connect_timeout 1s;
proxy_read_timeout 5s;
proxy_send_timeout 3s;

proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 2;
proxy_next_upstream_timeout 8s;

These values ensure:

Failures are detected quickly
Retries happen automatically
Total request time remains under 10 seconds
Clients never see partial or failed responses

Primary / Backup Upstreams

upstream blue {
  server app_blue:${PORT} max_fails=1 fail_timeout=5s;
  server app_green:${PORT} backup;
}

upstream green {
  server app_green:${PORT} max_fails=1 fail_timeout=5s;
  server app_blue:${PORT} backup;
}

Why this works:

max_fails=1 marks the primary unhealthy after a single failure
fail_timeout=5s enables fast recovery
backup ensures Green is only used when Blue fails
The same config supports both active pools

Deep Dive: Request Flow During Failure
This is the most important part of the system.

Normal Operation

Client sends:

GET http://localhost:8080/version

Nginx forwards to Blue
Blue responds with 200
Headers returned:

X-App-Pool: blue
X-Release-Id: <RELEASE_ID_BLUE>

Failure Scenario (Blue Down)

Chaos is induced directly on Blue:

POST http://localhost:8081/chaos/start?mode=error

Now let’s trace a single client request.

Step 1: Request Hits Nginx

The client is unaware of Blue or Green.

Step 2: Nginx Proxies to Blue

Blue is the primary upstream.

Step 3: Blue Fails

Blue returns a 5xx or times out.

Step 4: Nginx Intercepts the Failure

Because of:

proxy_next_upstream error timeout http_5xx;

Nginx does not forward the failure to the client.

Step 5: Immediate Retry to Green

Within the same client request, Nginx retries the request to Green.

Step 6: Green Responds Successfully

Green returns:

HTTP 200
X-App-Pool: green
X-Release-Id: <RELEASE_ID_GREEN>

Result:
The client sees HTTP 200, even though Blue failed.

Why Proxy Buffering Matters

proxy_buffering on;

This ensures Nginx does not stream partial responses.
If Blue fails mid-request, Nginx can safely retry Green without exposing errors to clients.

Header Preservation
Each application response includes:

X-App-Pool
X-Release-Id Nginx forwards these headers unchanged:

proxy_pass_header X-App-Pool;
proxy_pass_header X-Release-Id;

This allows:

CI validation

Runtime verification

Clear observability of which pool served the request

Manual Blue/Green Switching

Traffic switching is handled by configuration templating.

Entrypoint Script

envsubst '$ACTIVE_POOL $PORT $RELEASE_ID_BLUE $RELEASE_ID_GREEN' \
  < default.conf.template > default.conf

This allows:

Changing ACTIVE_POOL=green
Regenerating the Nginx config
Reloading Nginx without downtime No containers are restarted.

Stability Under Sustained Failure
During a ~10 second request loop:

Zero non-200 responses
≥95% responses from Green
Blue remains isolated until healthy

This satisfies all grader stability requirements.

Key Takeaways

This project demonstrates:

Blue/Green deployment without Kubernetes
Auto-failover within a single HTTP request
Resilience implemented at the proxy layer
Environment-driven infrastructure design
Production-grade reliability using simple tools

Conclusion

High availability is not about avoiding failure—it’s about handling failure correctly.

By combining Nginx upstreams, Docker Compose, and strict timeout and retry controls, we achieve:

Zero downtime
Safe rollbacks
Transparent failover
CI-ready verification

This approach mirrors real production systems and is an excellent foundation for any DevOps engineer.

If you’re learning DevOps, mastering patterns like this matters far more than chasing tools. Reliability is a design choice.
Explore the code here

Automating Dockerized App Deployment with a Bash Script

Ifeanyi Nworji — Sat, 13 Dec 2025 06:06:16 +0000

DevOps is all about automation, reliability, and efficiency. In Stage 1 of my DevOps internship, I built a robust Bash script to automate the deployment of a Dockerized application to a remote Linux server.

Whether you’re a developer, system administrator, or DevOps enthusiast, this guide will walk you step by step through creating a production-ready deployment script that handles everything from cloning a repository to configuring Nginx as a reverse proxy.

Why Automate Deployment?

Manual deployment is error-prone, inconsistent, and time-consuming. Automation provides:

Consistency: Ensures deployments are identical every time.
Speed: Reduces human intervention and saves time.
Reliability: Detects errors early and logs them for troubleshooting.

By the end of this guide, you’ll have a single Bash script (deploy.sh) capable of fully deploying your Dockerized app to a remote server.

Step 1: Collect Parameters from User Input
The first step is interactively collecting essential details:

Git repository URL
Personal Access Token (PAT)
Branch name (defaults to main)
SSH credentials (username, server IP, key path)
Application port

We also validate the inputs to prevent script failure later. Example snippet:

# Git Repository URL
while [[ -z "${GIT_REPO_URL:-}" ]]; do
    read -rp "Enter the git repository URL: " GIT_REPO_URL
    [[ -z "$GIT_REPO_URL" ]] && log_error "Repository URL cannot be empty."
done

# Personal Access Token (PAT) - hidden input
while [[ -z "${GIT_PAT:-}" ]]; do
  read -rsp "Enter your Git Personal Access Token (PAT): " GIT_PAT
  echo ""
  [[ -z "$GIT_PAT" ]] && log_error "Personal Access Token cannot be empty."
done

# Branch name (default = main)
read -rp "Enter branch name [default: main]: " GIT_BRANCH
GIT_BRANCH=${GIT_BRANCH:-main}

#SSH username
while [[ -z "${SSH_USER:-}" ]]; do
    read -rp "Enter remote server SSH username: " SSH_USER
    [[ -z "$SSH_USER" ]] && log_error "SSH username cannot be empty."
done

#Server IP address
while [[ -z "${SERVER_IP:-}" ]]; do
    read -rp "Enter remote server IP address: " SERVER_IP
    if [[ ! "$SERVER_IP" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}$ ]]; then
        log_error "Invalid IP format. Please enter a valid IPV4 address."
        SERVER_IP=""
    fi
done

# SSH key path
while [[ -z "${SSH_KEY_PATH:-}" ]]; do
    read -rp "Enter path to SSH private key: " SSH_KEY_PATH
    if [[ ! -f "$SSH_KEY_PATH" ]]; then
        log_error "SSH key file not found at $SSH_KEY_PATH"
        SSH_KEY_PATH=""
    fi
done

# Application port (internal container port)
while [[ -z "${APP_PORT:-}" ]]; do
    read -rp "Enter internal application (container) port (e.g., 8080): " APP_PORT
    if ! [[ "$APP_PORT" =~ ^[0-9]+$ ]]; then
        log_error "Invalid port. Please enter a numeric value."
        APP_PORT=""
    fi
done

Tip: Always validate user input using conditionals to ensure URLs are valid and files exist.

Step 2: Clone or Pull the Repository
Next, we authenticate using the PAT and clone the repo, or pull the latest changes if it already exists:

REPO_NAME=$(basename -s .git "$GIT_REPO_URL")
WORK_DIR="$HOME/deployment/$REPO_NAME"

# Create deployment directory if not exists
mkdir -p "$(dirname "$WORK_DIR")"

# Authenticated URL (PAT safely embedded)
GIT_USERNAME=$(echo "$GIT_REPO_URL" | awk -F[/:] '{print $(NF-1)}')
AUTH_REPO_URL=$(echo "$GIT_REPO_URL" | sed "s#https://#https://$GIT_USERNAME:$GIT_PAT@#")
if [[ -d "$WORK_DIR/.git" ]]; then
    log_info " Repository already exists. Pulling latest changes..."
    cd "$WORK_DIR"
    git reset --hard
    git clean -fd
    git fetch origin "$GIT_BRANCH"
    git checkout "$GIT_BRANCH"
    git pull origin "$GIT_BRANCH" || {
        log_error " Failed to pull latest changes from $GIT_BRANCH"
        exit $EXIT_UNKNOWN
    }
else
    log_info " Cloning repository into $WORK_DIR..."
    git clone --branch "$GIT_BRANCH" "$AUTH_REPO_URL" "$WORK_DIR" || {
        log_error " Failed to clone repository. Please check your URL or PAT"
        exit $EXIT_UNKNOWN
    }
    cd "$WORK_DIR"
fi

log_success " Repository is ready at: $WORK_DIR"

This step ensures your local project folder is always up-to-date with the remote repo.

Step 3: Navigate into the Project Directory
After cloning, we enter the project folder and validate the Docker setup:

# Check for Docker configuration  files
if [[ -f "Dockerfile" ]]; then
    log_success " Found Dockerfile - ready for Docker build."
elif [[ -f "compose.yaml" || -f "compose.yml" || -f "docker-compose.yaml" || -f "docker-compose.yml" ]]; then
    log_success " Found docker-compose.yml - ready for multi-service deployment"
else
    log_error " No Dockerfile or docker-compose.yml found. Cannot continue deployment."
    exit $EXIT_UNKNOWN
fi

Step 4: SSH into the Remote Server
Using SSH, we perform connectivity checks and prepare to execute remote commands:

# Validate SSH key exists
if [ ! -f "$SSH_KEY_PATH" ]; then
    log_error "SSH key not found at: $SSH_KEY_PATH"
    exit $EXIT_SSH_FAIL
fi

# Test SSH connection (non-interactive)
ssh -i "$SSH_KEY_PATH" -o StrictHostKeyChecking=no -o BatchMode=yes "$SSH_USER@$SERVER_IP" "echo 'SSH connection successful!'" >/dev/null 2>&1
if [ $? -ne 0 ]; then
    log_error "Unable to connect to remote server via SSH. Please verify credentials, key permissions, and IP address."
    exit $EXIT_SSH_FAIL
else
    log_success "SSH connection verified successfully."
fi

Step 5: Prepare the Remote Environment
On the remote server, we need to ensure all dependencies exist:

Update packages
Install Docker, Docker Compose, and Nginx
Add user to Docker group
Enable and start services

ssh -i "$SSH_KEY_PATH" -o StrictHostKeyChecking=no "$SSH_USER@$SERVER_IP" bash <<EOF
set -e

echo "Updating system packages..."
sudo apt-get update -y && sudo apt-get upgrade -y

echo "Installing required packages (curl, ca-certificates, gnupg, lsb-release)..."
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# --- Install Docker if not installed ---
if ! command -v docker &>/dev/null; then
    echo "Docker not found. Installing Docker..."
    curl -fsSL https://get.docker.com | sudo bash
else
    echo "Docker already installed."
fi

# --- Install Docker Compose if not installed ---
if ! command -v docker-compose &>/dev/null; then
    echo "Installing Docker Compose..."
    sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-\$(uname -s)-\$(uname -m)" -o /usr/local/bin/docker-compose
    sudo chmod +x /usr/local/bin/docker-compose
else
    echo "Docker Compose already installed."
fi

# --- Install nginx if not installed ---
if ! command -v nginx &>/dev/null; then
    echo "Installing nginx..."
    sudo apt-get install -y nginx
else
    echo "nginx already installed."
fi

# --- Add SSH user to docker group ---
if ! groups $SSH_USER | grep -q docker; then
    echo "Adding user '$SSH_USER' to docker group..."
    sudo usermod -aG docker $SSH_USER
    echo "You may need to log out and back in for this to take effect."
else
    echo "User '$SSH_USER' already in docker group."
fi

# --- Enable and start services ---
sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl enable nginx
sudo systemctl start nginx

# --- Confirm installation versions ---
echo "Confirming versions..."
docker --version
docker-compose --version
nginx -v

echo "Remote environment setup complete."
EOF

Best practice: Always confirm installation versions and service status:

docker --version
docker-compose --version
nginx -v

Step 6: Deploy the Dockerized Application
We transfer project files to the server and build/run Docker containers:

rsync -avz -e "ssh -i $SSH_KEY_PATH -o StrictHostKeyChecking=no" \
    --exclude '.git' --exclude 'node_modules' --exclude '.env' \
    "$CLONE_DIR/" "$SSH_USER@$SERVER_IP:$REMOTE_APP_DIR" >/dev/null 2>&1

ssh -i "$SSH_KEY_PATH" -o StrictHostKeyChecking=no "$SSH_USER@$SERVER_IP" bash <<EOF
set -e

cd $REMOTE_APP_DIR

# --- Detect Docker configuration ---
if [[ -f "docker-compose.yml" ]]; then
    echo "docker-compose.yml found. Starting with Docker Compose..."
    sudo docker-compose pull
    sudo docker-compose build
    sudo docker-compose up -d
elif [[ -f "Dockerfile" ]]; then
    echo "Dockerfile found. Building and running manually..."
    APP_NAME=\$(basename \$(pwd))
    sudo docker build -t \$APP_NAME .
    sudo docker run -d -p $APP_PORT:$APP_PORT --name \$APP_NAME \$APP_NAME
else
    echo "No Dockerfile or docker-compose.yml found in project directory."
    exit 1
fi

# --- Step 3: Validate container health ---
echo "Checking running containers..."
sudo docker ps

# --- Step 4: Verify app is accessible on the specified port ---
echo "Validating application accessibility on port $APP_PORT..."
sleep 5
if curl -s "http://localhost:$APP_PORT" >/dev/null; then
    echo "Application is running and accessible on port $APP_PORT!"
else
    echo "Application did not respond on port $APP_PORT. Check container logs."
    sudo docker logs \$(sudo docker ps -q --latest)
fi
EOF

This ensures the container is up, healthy, and accessible on the specified port.

Step 7: Configure Nginx as a Reverse Proxy
Nginx forwards traffic from port 80 to your Docker container:

DOMAIN_NAME="${DOMAIN_NAME:-example.com}"

# Create a temporary nginx config locally with correct escaping for nginx $-vars
TMP_NGINX_CONF="$(mktemp /tmp/app_proxy.XXXXXX.conf)"

cat > "$TMP_NGINX_CONF" <<EOF
server {
    listen 80;
    server_name ${DOMAIN_NAME};

    location / {
        proxy_pass http://127.0.0.1:${APP_PORT};
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
        proxy_cache_bypass \$http_upgrade;
    }

    access_log /var/log/nginx/app_access.log;
    error_log /var/log/nginx/app_error.log;
}

# SSL placeholder (Certbot or self-signed)
# server {
#     listen 443 ssl;
#     server_name ${DOMAIN_NAME};
#     ssl_certificate /etc/ssl/certs/app.crt;
#     ssl_certificate_key /etc/ssl/private/app.key;
#     location / {
#         proxy_pass http://127.0.0.1:${APP_PORT};
#         proxy_set_header Host \$host;
#     }
# }
EOF

NGINX_CONFIG_PATH="/etc/nginx/sites-available/app_proxy"
NGINX_ENABLED_PATH="/etc/nginx/sites-enabled/app_proxy"

# Copy config to remote /tmp then move with sudo to proper location to avoid permission issues
scp -i "$SSH_KEY_PATH" "$TMP_NGINX_CONF" "$SSH_USER@$SERVER_IP:/tmp/app_proxy.conf" >/dev/null 2>&1 || {
  log_error "Failed to upload nginx config to remote host."
  rm -f "$TMP_NGINX_CONF"
  exit $EXIT_NGINX_FAIL
}

rm -f "$TMP_NGINX_CONF"

# Apply config remotely: install nginx if missing, remove default, move config, enable, test, reload
ssh -i "$SSH_KEY_PATH" -o StrictHostKeyChecking=no "$SSH_USER@$SERVER_IP" bash -s <<'REMOTE_EOF'
set -e

NGINX_CONFIG_PATH="/etc/nginx/sites-available/app_proxy"
NGINX_ENABLED_PATH="/etc/nginx/sites-enabled/app_proxy"

# Install nginx if missing
if ! command -v nginx &>/dev/null; then
  echo "Installing nginx..."
  sudo apt-get update -y
  sudo apt-get install -y nginx
fi

# Remove default site if present
if [ -f /etc/nginx/sites-enabled/default ]; then
  echo "Removing default nginx site..."
  sudo rm -f /etc/nginx/sites-enabled/default
fi

# Move uploaded config into place
sudo mv /tmp/app_proxy.conf "$NGINX_CONFIG_PATH"
sudo chown root:root "$NGINX_CONFIG_PATH"
sudo chmod 644 "$NGINX_CONFIG_PATH"

# Enable site (idempotent)
sudo ln -sf "$NGINX_CONFIG_PATH" "$NGINX_ENABLED_PATH"

# Test and reload
if sudo nginx -t; then
  echo "nginx config OK - reloading"
  sudo systemctl reload nginx
else
  echo "nginx config test FAILED"
  sudo nginx -t || true
  exit 1
fi

echo "Nginx reverse proxy configured"
REMOTE_EOF

Step 8: Validate Deployment
Check that everything is running and accessible:

ssh -i $SSH_KEY $REMOTE_USER@$REMOTE_IP "docker ps"
curl http://$REMOTE_IP

All services should respond correctly.

Step 9: Logging and Error Handling
Logging is critical for troubleshooting. Our script:

Saves logs to deploy_YYYYMMDD.log
Uses trap to catch errors
Exits with meaningful codes

LOG_FILE="$LOG_DIR/deploy_$(date +'%Y%m%d_%H%M%S').log"

# --- Logging functions ---
log_info()    { echo -e "\033[1;34m[INFO]\033[0m $1"    | tee -a "$LOG_FILE"; }
log_success() { echo -e "\033[1;32m[SUCCESS]\033[0m $1" | tee -a "$LOG_FILE"; }
log_warn()    { echo -e "\033[1;33m[WARN]\033[0m $1"    | tee -a "$LOG_FILE"; }
log_error()   { echo -e "\033[1;31m[ERROR]\033[0m $1"   | tee -a "$LOG_FILE"; }

# --- Error trapping ---
trap 'handle_error $? $LINENO' ERR
handle_error() {
    local exit_code=$1
    local line_no=$2
    log_error " Script failed at line $line_no (exit code: $exit_code)"
    log_error " Deployment aborted. Check $LOG_FILE for details."
    exit "$exit_code"
}

Step 10: Idempotency and Cleanup
The script is safe to rerun. Previous containers are stopped/removed before redeployment. Optional --cleanup removes all deployed resources.

Conclusion

By building this Automated Deployment Bash Script, I’ve learned how to:

Interact with users in Bash scripts
Automate Docker deployment
Configure remote servers and Nginx
Implement robust logging, error handling, and idempotency

This project mirrors real-world DevOps workflows and is a great starting point for anyone looking to build production-grade deployment scripts.
Complete repo link

Building and Testing a Mini VPC with Python and Linux Namespaces

Ifeanyi Nworji — Wed, 12 Nov 2025 14:25:50 +0000

Overview
In this project, I built a Mini Virtual Private Cloud (VPC) system on Linux using nothing but Python and native networking tools.
It mimics real AWS networking — with public/private subnets, NAT, VPC peering, and firewall policies — but all runs locally.

This setup is perfect for DevOps learners and cloud enthusiasts who want to see how networks actually work behind the scenes.

fig.1 VPC network diagram

Bridge (br0) → acts like your VPC switch
Namespaces → represent isolated networks
veth pairs → connect subnets to bridge
iptables NAT → allows outbound access only from the public subnet

Step 1: Setup

make setup

Step 2: Create the VPC

sudo python3 vpcctl.py create-vpc vpc1 10.10.0.0/16 --public-interface wlp2s0

This creates a virtual private cloud (VPC) simulation with the name vpc1 and a designated IP address range, linked to your actual public network interface.
10.10.0.0/16: This is the IP address range (specifically, a CIDR block) that the VPC will use for its internal network. The /16 denotes the specific size of the network, allowing for over 65,000 internal IP addresses within the VPC.

--public-interface wlp2s0: This flag tells the script to connect the simulated VPC to your actual physical network interface named wlp2s0(your system can have a different interface, run this command to see yours: ip addr show or ifconfig). This allows the resources inside your simulated VPC to communicate with the outside world (e.g., the internet) via your computer's real connection.

Step 3: Add Subnets

sudo python3 vpcctl.py add-subnet vpc1 public --type public --base-cidr 10.10.0.0/16

sudo python3 vpcctl.py add-subnet vpc1 private --type private --base-cidr 10.10.0.0/16

Creates:

vpc1-public → 10.10.1.0/24 (Internet access)
vpc1-private → 10.10.2.0/24 (Internal only)

Step 4: Deploy Demo Applications
Run a web app in the public subnet

sudo ip netns exec vpc1-public python3 -m http.server 80

From your host:

curl 10.10.1.2:80

You should see the directory listing

Run a web app in the private subnet

sudo ip netns exec vpc1-private python3 -m http.server 80

From host:

curl 10.10.2.2:80

You’ll get no response — because private subnets aren’t exposed externally.

Step 5: Validate Connectivity
Communication within the same VPC

sudo ip netns exec vpc1-private ping -c 3 10.10.1.2

Works (internal VPC communication).

Internet access from public subnet

sudo ip netns exec vpc1-public ping -c 3 8.8.8.8

Works via NAT.

Internet access from private subnet

sudo ip netns exec vpc1-private ping -c 2 8.8.8.8

Blocked — no default route to internet.

Step 6: Test Multiple VPCs and Peering
Create two VPCs

sudo python3 vpcctl.py create-vpc vpc2 10.20.0.0/16 --public-interface wlp2s0

sudo python3 vpcctl.py create-vpc vpc3 10.30.0.0/16 --public-interface wlp2s0

Add subnets to VPC2 and VPC3

# PUBLIC SUBNET on vpc2
sudo python3 vpcctl.py add-subnet vpc2 public --type public --base-cidr 10.20.0.0/16

# PRIVATE SUBNET on vpc2
sudo python3 vpcctl.py add-subnet vpc2 private --type private --base-cidr 10.20.0.0/16

# PUBLIC SUBNET on vpc3
sudo python3 vpcctl.py add-subnet vpc3 public --type public --base-cidr 10.30.0.0/16

# PRIVATE SUBNET on vpc3
sudo python3 vpcctl.py add-subnet vpc3 private --type private --base-cidr 10.30.0.0/16

Check isolation

sudo ip netns exec vpc1-public ping -c 2 10.20.1.2

Blocked — fully isolated by default.

Peer them

sudo python3 vpcctl.py peer-vpc vpc1 vpc2

Now ping again:

sudo ip netns exec vpc1-public ping -c 2 10.20.1.2

Works (controlled communication after peering).

Step 7: Apply Security Policies (Firewall)

sudo python3 vpcctl.py apply-policies vpc2 --policies policies.json

Policies.json:

[
  {
    "subnet": "10.20.2.0/24",
    "ingress": [
      {"port": 80, "protocol": "tcp", "action": "allow"},
      {"port": 22, "protocol": "tcp", "action": "deny"},
      {"port": 443, "protocol": "tcp", "action": "allow"}
    ]
  }
]

would automatically block SSH access while keeping web traffic open.

Test policies:

Start a simple HTTP server on port 80 in the target namespace (vpc2)

sudo ip netns exec vpc2-public python3 -m http.server 80

Test from the source namespace using nc:

sudo ip netns exec vpc2-private nc -vz 10.20.1.2 80

Step 8: Cleanup

make cleanup

./cleanup.sh

Removes:

All namespaces
The bridge
NAT/firewall rules

Ensures no residual configuration remains.

To run this with just one command:

make all

and clean up with

make cleanup

Github link