DOCKER MASTERY PART-2

BY NAVEED IBRAHIM A
WHAT YOU WILL LEARN

Advanced Composition: Mastering complex multi-service apps.

Networking Deep Dive: Bridges, overlays, and custom drivers.

Production Security: Non-root users and secrets management.

CI/CD Integration: Automating the build-push pipeline.

Optimization: Multi-stage builds and caching strategies.

DOCKER COMPOSE OVERVIEW
Docker Compose is a tool that lets you define and run multiple
Docker containers together as one application using a simple YAML
file ([Link]). Instead of manually running containers
one-by-one with long docker run commands, you describe
everything—containers, images, networks, volumes—in one file,
then start everything with a single command.

Automatic networking between containers

Define services in [Link].

Spin up all services with one command.

Isolated environments for development.

It’s like a remote control for multi-container apps. You click once,
and your app stack (web server + DB + cache + whatever) spins up,
connected and ready
YAML STRUCTURE
version: "3" # Version: Defines the file format version.
services: # Define containers here
SERVICE_NAME: #Services: The containers to run
#(e.g., naveed-app, db)
image: # Image to use
build: # Or build from Dockerfile
container_name: # Optional
ports: # Port mapping
environment: # Env variables
volumes: # Persistent storage / mounts
depends_on: # Startup dependency order
networks: # Custom networks
restart: # Restart policy

volumes: # Persistent data storage configurations.

networks: # Networks: Communication channels . .
| between services
COMPOSE EXAMPLE
version: "3" # Docker Compose file format version
services: # Section where we define all containers (services)
web: # Service name (you can name it anything)
image: nginx # Uses official NGINX image from Docker Hub
ports:
- "8080:80" # Maps host port 8080 -> container port 80
# So you access app using: [Link]
depends_on:
- db # Ensures 'db' container starts before 'web'

db: # Database service

image: mysql:5.7 # MySQL version 5.7 image
environment: # Environment variables for MySQL
MYSQL_ROOT_PASSWORD: root # Sets MySQL root password
volumes:
- dbdata:/var/lib/mysql # Attaches persistent storage:
# dbdata volume -> MySQL data directory
# So data is NOT lost if container stops
volumes:
dbdata: # Declares a named volume for persistent DB storage
KEY COMMANDS
# Start all services in background (detached mode)
● docker compose up -d
# Stop and remove containers, networks (keeps volumes)
● docker compose down
# Show status of running containers
● docker compose ps
# View and follow real-time logs
● docker compose logs -f
# Build/rebuild images from Dockerfile
● docker compose build
# Restart all running services
● docker compose restart
# Execute a command/shell inside a running container (example: 'web')
● docker compose exec web bash
# Validate and view the final resolved compose configuration
● docker compose config
DOCKER REGISTRIES
Docker registries are central repositories where Docker images are stored, shared,
pulled from, and pushed to — like GitHub but for container images

Docker Image
A Docker image is a read-only blueprint that contains everything needed to
run a container (code, runtime, libraries, configs)

Key Points
❖ Allow teams to share images easily
❖ Support versioning (tags)
❖ Can be public or private
❖ Used in DevOps CI/CD pipelines

Popular Docker Registries

Docker Hub: The default public registry.

ECR/GCR/ACR: Cloud provider private registries.

PUSHING IMAGES
1. AUTHENTICATE

2. TAG IMAGE

3. PUSH

Sample Docker Hub Image :

DOCKER VOLUMES
Docker Volume = A way to store data permanently outside the container so it doesn’t
get deleted when the container stops, restarts, or is recreated.
Containers are temporary. If they die, their internal data dies too. Volumes fix that by
giving containers persistent storage.
Either store the data from container to server or to share data from server to container

Named Volumes:
- You can create Volume named anything and attach it to containers main path
- Data survives even when container stop/remove
- Best for PROD databases. Fully managed by Docker itself

Bind Mounts:
- Directly maps a local host folder to a folder inside the container.

- Any change on host reflects instantly in container (and vice-versa).

- Best for development and testing where live file editing is needed.
VOLUME - 2 TYPES
1. Persistent Named Volume
docker run -d \
--name mysql-db \
-v mydata:/var/lib/mysql \
mysql:5.7 # MySQL image
# mydata = Docker named volume (Docker manages it)
# /var/lib/mysql = path inside container where DB stores data
# Even if container is deleted, data stays

2. Bind Mount
docker run -d \
--name webserver \
-v /home/user/site:/usr/share/nginx/html # Left side = local machine path

# Right side = container path(Seperated by “ :” <colon> )

# Whatever files you have locally will be visible in container
# Good for development because changes reflect instantly
nginx # MySQL image
 NETWORKING BASICS
● Docker Network lets containers communicate with each other, the host, and the internet.
● It works like a virtual LAN specially created for containers.
● Containers are isolated by default, and networking enables controlled & secure communication.
● Every container receives its own virtual IP address for internal communication.
● Containers on the same network can communicate easily using service/container names instead of IPs.
● Docker automatically creates, manages, and handles networking for containers.
● Networking improves security by isolating containers and preventing unwanted external access.
● It avoids IP conflicts and makes microservices communication smooth and reliable.

1. Bridge Network (MOST USED)

● Default network type when you run containers.
● Containers on the same bridge network can communicate internally but stay isolated from
others unless you expose a port ( Ex - 8080:80 ) .

2. Host Network
● Removes network isolation between host and container.
● Container shares host network directly → faster but less secure.
CUSTOM NETWORKS
# Create a custom bridge network (better than default bridge)
docker network create appnet # appnet = user-defined bridge network
# Run NGINX and connect to custom network
docker run -d \
--name web \
--network appnet \ # Attach to custom bridge network
-p 8080:80 \ # Expose container port 80 -> host port 8080
nginx # Web server container
# Run MySQL and connect to same network
docker run -d \
--name db \
--network appnet \ # Same network → containers can talk securely
-e MYSQL_ROOT_PASSWORD=root \
mysql:5.7
# Now 'web' can communicate with DB using name 'db' (not IP)
# Example inside app: db:3306
# Network = isolated, secure, has its own virtual IPs, DNS supported
RESOURCE CONSTRAINTS
● Resource constraints limit how much CPU, Memory, and other system
resources a container can use.
● Prevents one container from overloading or crashing the host system.
● Ensures fair resource sharing and stable performance in multi-container
environments.

docker run -d \
--name myapp \
--memory=512m \ # Limits container RAM to 512MB (Max Limit)
--cpus=1.5 \ # Limits CPU usage to 1.5 cores max
nginx # Sample container (NGINX)

✔ This container will not exceed 512MB RAM

✔ It can use up to 1.5 CPU cores only
✔ Protects host & ensures stability 😎
HEALTHCHECKS
● Docker Health Check is a feature used to monitor if a container is healthy or not while running.
● It runs a command periodically inside the container to verify if the app is responding properly.
● If the check fails repeatedly, Docker marks the container as unhealthy, which helps
with troubleshooting, monitoring, and automation
● Ensures traffic is only sent to healthy instances.

# Run health check every 30 seconds

# If command doesn’t respond within 3 sec, treat as failure
# curl -f = fail if HTTP status is 400+ or site not reachable
# exit 1 = marks container as UNHEALTHY
MULTI-STAGE BUILDS
● It is a Docker feature that lets you use multiple FROM images in one
Dockerfile so you build in one step and ship only what you need.

● It keeps final images small, clean, and secure by removing compilers,

build tools, and junk.

● Perfect for Go, Java, Node, Python builds where build

environment ≠ runtime.
.DOCKERIGNORE
● It tells Docker which files/folders NOT to copy into the image when building.

● It makes builds faster, lighter, and more secure by excluding junk

● Example :- (logs, temp files, secrets).

● Works just like .gitignore, but for Docker.

● Password or waste files can be ignored

.dockerignore
DOCKER LOGS
● It is used to view the output (stdout & stderr) of a running or stopped container.

● It helps in troubleshooting, debugging, and monitoring what’s happening inside a container.

● Works like checking application logs without going inside the container
EXEC INTO CONTAINER
docker exec is used to run a command inside a running container.
It lets you open a shell, debug, run utilities, or inspect what’s going on without restarting the container.
Basically: work inside a live container.
It is mostly used for getting inside the container.

docker exec -it <container_name> /bin/bash

This lets yo to go inside the container
LIFECYCLE COMMANDS
Command What it does

docker run Creates and starts a new container (most used)

docker create Creates container but doesn’t start it

docker start Starts a stopped container

docker stop Gracefully stops a running container

docker restart Stops and starts container again

docker pause Pauses container (freezes processes)

docker unpause Resumes paused container

docker kill Force-stop immediately (no grace)

docker rm Deletes a stopped container

docker ps Shows running containers

docker ps -a Shows all containers (running + stopped)

Docker <Command> { Container name or ID }

SYSTEM PRUNE
docker system prune is a cleanup command that removes all
unused containers, images, networks, and cache to free disk space,
but it doesn’t touch running containers—use it carefully because it
can delete things you still need.
SAVE & LOAD
● docker save and docker load are used to transfer Docker images without using
a registry like Docker Hub.
● They’re perfect for offline environments, secure networks, or air-gapped
systems where internet access is restricted.
● You literally export an image to a .tar file → copy it → import it on another
machine.
 EXPORT & IMPORT
● Docker export & import are used for containers, not images.
● They only save the container’s filesystem as a simple tar file and do NOT preserve
image layers, history, metadata, or environment settings.
● This creates a flat OS snapshot, meaning all Docker build information is lost.
● It’s mainly used for lightweight migration, creating a clean minimal image, or
stripping sensitive build history in secure environments.

Example:

docker export mycontainer > [Link]

docker import [Link] myimage:new

Export/Import: are used for running containers.

Save/Load: are used for Docker images.
 SECURITY BASICS
1⃣ Don’t run containers as root – always use non-root users.
2⃣ Use trusted & official base images – avoid random public images.
3⃣ Apply resource limits – prevent abuse using --memory, --cpus, --pids-limit.
4⃣ Harden network exposure – avoid exposing ports blindly, use custom networks.
5⃣ Use minimal images – Alpine / Distroless to reduce attack surface.
6⃣ Use read-only filesystem – --read-only when possible.
7⃣ Never store secrets in images or ENV – use Secrets Manager / Vault.
8⃣ Scan images regularly – use Trivy / Grype / Docker Scan.
9⃣ Drop unnecessary Linux capabilities – principle of least privilege.
🔟 Keep host, Docker, and dependencies updated – patch frequently.

Drop unnecessary Linux capabilities.

NON-ROOT USER
By default containers run as root, so if someone exploits your app they get access & can potentially harm the host.
Here we create a normal user (naveed) & run the container using that user instead of root.
This follows the least-privilege principle, meaning even if compromised, the attacker has limited permissions

1. FROM node:alpine – Uses a lightweight [Link] Alpine Linux image.

2. WORKDIR /app – Sets /app as the working directory inside the container.
3. COPY . . – Copies your project files from host into /app in the container.
4. RUN adduser -D naveed – Creates a new non-root user named naveed.
5. USER naveed – Switches to the naveed user so the container doesn’t run as root.
6. CMD ["node","[Link]"] – Starts your [Link] application safely as a non-root user.
DOCKER DESKTOP

The GUI application for managing Docker on Mac/Windows.

Visual container management.

One-click Kubernetes cluster.

Volume and image exploration.

Extension marketplace.
PROJECT: 2-TIER APP

Orchestrating a Python Flask app with a Redis database.

We will see detailed project in another post

CI/CD INTEGRATION
1⃣ Developer pushes code to GitHub – latest application changes committed.
2⃣ Jenkins auto-triggers pipeline – via Webhook / Poll SCM and pulls latest code.
3⃣ Jenkins builds the application & creates Docker image – packaging app into a container.
4⃣ Jenkins tests & optionally scans the image – ensures quality and security.
5⃣ Jenkins tags and pushes the Docker image to
Docker Hub/Registry – stores the deployable artifact.
6⃣ Jenkins triggers Ansible playbook – automation phase begins.
7⃣ Ansible deploys Docker container on target servers – pulls image,
runs updated app
8⃣ Now out app is running in Docker ready to scale in an
isolated environment.
BEST PRACTICES
1. Keep images small – prefer Alpine or Distroless to reduce size and attack surface.

2. Optimize layer caching – order Dockerfile instructions from least to most frequently changing.

3. Never bake secrets into images – use environment variables, secret managers, or Docker secrets.

4. One process per container – containers are meant to run a single primary service.

5. Use multi-stage builds – build in one stage, run in another to keep runtime image clean.

6. Pin versions – avoid latest; always specify image and dependency versions.

7. Run as non-root – drop root privileges using USER to reduce security risk.

8. Add healthchecks – let orchestrators detect unhealthy containers.

9. Use .dockerignore – exclude unnecessary files to reduce build context size.

10. Keep Dockerfiles clean and minimal – fewer layers, minimal packages, and clear comments.
 DOCKER SWARM
➢ Native clustering solution built directly into Docker.

➢ Simple setup and easier learning curve compared to Kubernetes.

➢ Supports rolling updates and rollback for services.

➢ Built-in load balancing across nodes and containers.

➢ Uses declarative service model with desired state management.

➢ Lightweight and efficient, works well for small to medium deployments.

➢ Supports secrets management and secure communication between nodes.

➢ Tight integration with Docker CLI, making it convenient for Docker users.

Kubernetes is preferred over Docker Swarm because it scales better, offers more advanced features,
has stronger reliability and automation, and is widely supported by cloud providers and enterprises,
making it more suitable for large, production environments.
 Hi Folks,
THANK YOU! Hit a Like &
Repost
Thank you for going through this Docker Advanced course.
Your effort shows real commitment to mastering
containerization and modern DevOps.
- Keep Practicing -
Don’t stop here. Build real projects, experiment with
networking, security, multi-stage builds, and orchestration.
Break things, fix them, and learn through hands-on work.

BY NAVEED IBRAHIM A