Arif Rahman
← All projects
10 · 2026 · Personal projectCompleted

Full-Stack Containerization & Multi-Container Networking

Built a modular, containerized web service environment and a multi-container network topology using custom Docker bridge networks and container name resolution.

Problem
“Works on my machine” failures from missing dependencies and hardcoded IP addresses.
Tools
DockerBridge networksGitSSH
Result
Repeatable image builds, and containers that talk to each other by name.

Architecture

Containerisation and bridge networkingA developer writes a layered Dockerfile, builds an image and runs containers on a user-defined bridge network, where containers reach each other by name. Code is pushed to GitHub over SSH. Step 1: A layered Dockerfile keeps builds repeatable and cache-efficient. Step 2: The image is built from source, so every environment gets the same runtime. Step 3: Containers run with published ports and managed lifecycles. Step 4: On a user-defined bridge network, containers resolve each other by name, not IP. Step 5: Code is version-controlled and pushed to GitHub over SSH.User-defined bridge network1build2run3name DNS4git push5DeveloperCLIDockerfileFROM · COPY · RUN · CMDImagedocker buildweb containerpublished portsecond containercalls web by nameGitHubSSH key auth
Containerisation and bridge networking · scroll sideways to see it allOpen full-size SVG
  1. Step 1: A layered Dockerfile keeps builds repeatable and cache-efficient.
  2. Step 2: The image is built from source, so every environment gets the same runtime.
  3. Step 3: Containers run with published ports and managed lifecycles.
  4. Step 4: On a user-defined bridge network, containers resolve each other by name, not IP.
  5. Step 5: Code is version-controlled and pushed to GitHub over SSH.
Network topology
Multi-container
Isolated runtime
100%
Version control workflow
Git + SSH

Why it matters

Ends dependency drift between laptops, test environments and servers. Isolated, repeatable runtimes and name-based networking make every deployment easier to reproduce.

The problem in detail

Software frequently breaks when moved across environments due to missing dependencies, conflicting runtimes and inconsistent OS libraries — the classic 'it works on my machine' problem.

What I built

  1. 01

    Wrote structured, layered Dockerfiles using FROM, WORKDIR, COPY, RUN and CMD to create repeatable, cache-efficient builds.

  2. 02

    Built a clean local web application service and wrapped it inside an isolated container runtime.

  3. 03

    Built the image from source, managed container lifecycles, published ports and verified execution locally.

  4. 04

    Created a custom user-defined Docker bridge network and attached independent containers to enable inter-container communication via container names instead of brittle IP addresses.

  5. 05

    Initialized a Git repository, managed branches and configured SSH keys for secure remote authentication and GitHub collaboration.

Evidence

01 / 04
Stage 01 — app.py connecting to the MySQL container by container name (host="mydb") via Docker's internal DNS.

Stage 01 — app.py connecting to the MySQL container by container name (host="mydb") via Docker's internal DNS.