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.
