My Fourth Week Exploring DevOps: Docker, Networking, and Persistence

In Week 4, I went deeper into containerization with Docker, focusing on real-world backend services, networking, and data persistence. The goal was to move beyond basic containers and understand how production-grade Docker setups actually work.

What I Worked On This Week

1. Dockerized a Backend Application (Single-Stage and Multi-Stage Builds)

I dockerized my .NET backend application using a single-stage and multi-stage Dockerfile and orchestrated services with Docker Compose, including:

• .NET API (built via Dockerfile)
• MySQL
• Redis

I compared image sizes to understand optimization trade-offs:

• Single-stage build: 749 MB
• Multi-stage build: 102 MB

This helped me understand how multi-stage builds reduce runtime image size by 86.38%, by excluding build dependencies.

GitHub Link: View Script

Image built using Single-Stage Dockerfile

Image built using Multi-Stage Dockerfile

Dockerized Backend Application

Docker Images for Backend and Frontend Applications pushed to DockerHub

2. Docker Networking Deep Dive

I created and tested different Docker networks to understand container communication:

• Bridge network
• Custom bridge network
• Host network

This clarified:

• How containers discover and communicate with each other
• When to isolate services vs expose them to the host
• The impact of network choice on security and performance

Creating a user-defined bridge network and attaching the containers c1 and c2 to it

Communication between the two containers through Bridge Network

Creating a user-defined custom bridge network and attaching the container c3 to it

Isolation of container c3 (custom bridge network) from the containers c1 and c2 (bridge network)

Container attached to the Host network

3. Docker Volumes & Bind Mounts

I explored volumes and bind mounts to persist data across container restarts.

To make this practical, I:

• Created a Docker volume for MySQL database persistence
• Ensured database data survived container recreation

This reinforced why containers are ephemeral but data should not be.

Persistence of Docker Volumes even after the removal/deletion of containers

Key Challenges I Faced & How I Resolved Them

1. Network Deletion Errors

• Challenge: Couldn’t delete Docker networks while containers were still attached.
• Cause: Stopped and removed containers before deleting associated networks.

Error deleting the network due to running containers

Network deletion successful after stopping and deleting associated containers

2. Data Loss on Container Restart

• Challenge: Database schema and tables were lost after every container restart.
• Cause: Implemented Docker volumes to persist MySQL data across restarts.

Data persistence due to volumes across the restarts

Key Takeaways

• Multi-stage Docker builds are critical for smaller, production-ready images.
• Docker networking determines service communication and isolation.
• Volumes are essential for stateful services like databases.
• Understanding Docker internals prevents common runtime issues.