Docker Networking

Containers are assigned an IP address when they are created. To check the IP address, we can use the following command:

docker inspect <container_id>

If we send a request from the host to the container's IP address, the container responds using its assigned IP address.

By default, Docker creates a bridge network. This bridge network allows:

• Communication between the host and the container (through port mapping).
• Communication between containers connected to the same bridge network.

With the default bridge network, containers generally communicate using IP addresses. To communicate using container names (hostnames), we can use a custom bridge network.

The main difference between the default bridge network and a custom bridge network is that containers on a custom bridge network can communicate using their container names (DNS resolution), making it suitable for production environments.

When to Use a Custom Bridge Network

A custom bridge network is useful when an application consists of multiple services running in separate containers. These containers can communicate with one another using their container names instead of IP addresses.

Create a Custom Bridge Network

docker network create mybridge

Create and Run Containers Inside the Network

docker run -it --network mybridge --name container1 busybox:1.36 sh

docker run -it --network mybridge --name container2 busybox:1.36 sh

Now, from container1, run:

ping container2

Similarly, from container2, run:

ping container1

If the ping is successful, it confirms that both containers can communicate because they are connected to the same custom bridge network.

Example Workflow for a Docker Bridge Network

Step 1: Build the Images

docker build -f Dockerfile -t flask_app:v1 .
docker build -f httpd.Dockerfile -t apache_container:v1 .

Step 2: Create the Network

docker network create bridge_app

Step 3: Run the Containers

docker run -d --name flask_new --network bridge_app flask_app:v1

docker run -d --name apache_new --network bridge_app apache_container:v1

Step 4: Verify the Network

docker network inspect bridge_app

Step 5: Test Communication

ping apache_new
ping flask_new

You can also use curl with the application's port to access another container's application.

Host Network

Suppose we run an application inside a Docker container.

If we do not expose the application port using -p, the application cannot be accessed through the host machine. It can only be accessed using the container's IP address (if reachable).

Example:

docker run flask_app:v1

If we expose the port:

docker run -p 5000:5000 flask_app:v1

Docker maps the host port to the container port, allowing the application to be accessed using the host machine's IP address.

Host Network Mode

docker run --network host flask_app:v1

In host network mode, the container shares the host's network stack. Therefore, the application can use the host's network directly without explicit port mapping.

Note: Host networking is supported on Linux. On Docker Desktop for Windows and macOS, host networking is limited and generally not recommended. Port mapping (-p) is the standard approach.

Docker Image Optimization

Why Is Image Optimization Needed?

• Smaller images start containers faster.
• Smaller images are easier to share.
• Smaller images consume less storage.
• Smaller images download faster.

1. Multi-Stage Builds

In a multi-stage build, the first stage builds the application, and the second stage copies only the required artifacts into the final image.

A single-stage build includes both build tools and runtime dependencies, making the image larger.

A multi-stage build keeps only the files required to run the application.

Single-Stage Build

FROM python:3.9-slim

COPY . /app

WORKDIR /app

CMD ["python", "main.py"]

Multi-Stage Build

FROM python:3.9-slim AS builder

WORKDIR /app

COPY main.py .

FROM python:3.9-slim AS runner

WORKDIR /app

COPY --from=builder /app/main.py .

CMD ["python", "main.py"]

Here:

• Builder stage prepares the application.
• Runner stage copies only the required files, resulting in a smaller final image.

2. Choose a Minimal Base Image

Using a lightweight base image reduces the final image size.

Examples:

FROM python:3.9-slim

This image contains only the essential Python packages.

FROM python:3.9-alpine

This image is even smaller and includes only minimal functionality. Additional packages must be installed separately.

It is not recommended to use:

FROM python

because Docker will pull the latest version, which may introduce compatibility issues. Always specify a version tag.

3. Layer Caching

Docker caches image layers.

If no changes occur in a layer or any previous layer, Docker reuses the cached layer, making builds much faster.

The order of Dockerfile instructions is important.

If COPY . /app is placed near the beginning of the Dockerfile, any source code change invalidates all subsequent layers.

Instead, place frequently changing instructions lower in the Dockerfile whenever possible.

Less Efficient

FROM python:3.9-slim

COPY . /app

WORKDIR /app

CMD ["python", "main.py"]

Better

FROM python:3.9-slim

WORKDIR /app

COPY . /app

CMD ["python", "main.py"]

This prevents Docker from rebuilding the WORKDIR layer unnecessarily.

4. Run Containers as a Non-Root User

By default, containers run as the root user.

A root user can create or modify files anywhere inside the container.

If the container is compromised, an attacker may gain elevated privileges.

Running the container as a non-root user improves security because that user has limited permissions.

Example (Windows Containers):

RUN icacls C:\app /grant ContainerUser:(OI)(CI)F

USER ContainerUser

Example (Linux Containers):

RUN useradd -m appuser

USER appuser

Running applications as a non-root user is considered a Docker best practice.

Interview Questions

Question 1

Which Docker network allows containers to communicate with each other without requiring port mapping on the host?

Answer: Bridge network.

Question 2

Which statement is true about Docker layer caching?

Answer:

Docker caches layers unless a previous layer has changed.

Question 3

Why is it considered best practice to run containers as a non-root user?

Answer:

It helps prevent attackers from gaining root privileges if the container is compromised.

Question 4

What is the purpose of using a multi-stage build in Docker?

Answer:

To reduce the size of the final Docker image.

Question 5

How do you specify a non-root user in Docker?

Answer:

Use the USER directive in the Dockerfile or the --user option when running the container.

Question 6

Which of the following can invalidate the Docker build cache for a layer?

Answer:

• Changing the base image version.
• Modifying files copied into that layer.
• Adding or changing an environment variable (ENV) or build argument (ARG) used by that layer.
• Changing the Dockerfile instruction itself.