Container networking in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the network mode for a Docker container.

Microservices

docker run --network=[1] myapp

Drag options to blanks, or click blank then click option'

Anone

Bhost

Cbridge

Doverlay

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'host' mode when isolation is needed

Confusing 'overlay' with default network mode

The bridge network mode is the default Docker network mode that allows containers to communicate on a private internal network.

2fill in blank

medium

Complete the code to expose a container port to the host machine.

Microservices

docker run -p [1]:80 myapp

Drag options to blanks, or click blank then click option'

A8080

B80

C443

D3000

Attempts:

3 left

💡 Hint

Common Mistakes

Mapping the same port on host and container causing conflicts

Using a port not allowed by firewall rules

Port 8080 on the host is mapped to port 80 inside the container, allowing external access.

3fill in blank

hard

Fix the error in the Docker Compose service network configuration.

Microservices

services:
  web:
    image: myapp
    networks:
      - [1]
networks:
  frontend:
    driver: bridge

Drag options to blanks, or click blank then click option'

Afrontend

Bbackend

Cdefault

Dhost

Attempts:

3 left

💡 Hint

Common Mistakes

Using a network name not defined in the networks section

Using 'host' network driver incorrectly

The service must connect to the defined network frontend to communicate properly.

4fill in blank

hard

Fill both blanks to create a Docker network and connect a container to it.

Microservices

docker network [1] mynet

docker run --network=[2] myapp

Drag options to blanks, or click blank then click option'

Acreate

Bbridge

Cmynet

Dhost

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'bridge' as a command instead of a network type

Mismatching network names between creation and usage

First, create the network named mynet using create. Then run the container connected to mynet.

5fill in blank

hard

Fill all three blanks to define a Kubernetes Pod with two containers sharing a network.

Microservices

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: app
    image: myapp
    ports:
    - containerPort: [1]
  - name: sidecar
    image: sidecar
    ports:
    - containerPort: [2]
  [3]

Drag options to blanks, or click blank then click option'

A80

B8080

CshareProcessNamespace: true

DhostNetwork: true

Attempts:

3 left

💡 Hint

Common Mistakes

Using the same port for both containers causing conflicts

Omitting hostNetwork when needed for host-level networking

The app container listens on port 80, the sidecar on 8080. Setting hostNetwork: true allows both containers to share the host network.

Practice

1. What is the main purpose of container networking in microservices?

easy

A. To allow containers to communicate with each other

B. To store container data persistently

C. To build user interfaces for containers

D. To monitor container CPU usage

Solution

1. Step 1: Understand container networking role

   Container networking connects containers so they can send data and messages to each other.

2. Step 2: Compare with other options

   Storing data, building interfaces, and monitoring CPU are not related to networking.

3. Final Answer:

   To allow containers to communicate with each other -> Option A

4. Quick Check:

   Container networking = communication [OK]

Hint: Networking means communication between containers [OK]

Common Mistakes:

• Confusing networking with storage
• Thinking networking builds UI
• Mixing monitoring with networking

2. Which Docker command creates a user-defined network named mynet?

easy

A. docker create network mynet

B. docker network create mynet

C. docker network new mynet

D. docker net create mynet

Solution

1. Step 1: Recall Docker network creation syntax

   The correct command is docker network create <name>.

2. Step 2: Match options with syntax

   Only docker network create mynet matches the correct syntax exactly.

3. Final Answer:

   docker network create mynet -> Option B

4. Quick Check:

   docker network create = correct syntax [OK]

Hint: Remember: 'docker network create' is the right command [OK]

Common Mistakes:

• Swapping 'create' and 'network' order
• Using 'new' instead of 'create'
• Shortening 'network' to 'net' incorrectly

3. Given two containers web and db connected on a user-defined network mynet, what happens when web tries to ping db by container name?

medium

A. Ping succeeds because containers can resolve names on the same user-defined network

B. Ping fails because container names are not resolvable

C. Ping succeeds only if IP addresses are used, not names

D. Ping fails because containers cannot communicate on user-defined networks

Solution

1. Step 1: Understand user-defined network DNS resolution

   User-defined Docker networks provide automatic DNS resolution of container names.

2. Step 2: Apply to ping scenario

   Since both containers are on mynet, web can ping db by name successfully.

3. Final Answer:

   Ping succeeds because containers can resolve names on the same user-defined network -> Option A

4. Quick Check:

   User-defined network = name resolution works [OK]

Hint: User-defined networks enable container name resolution [OK]

Common Mistakes:

• Assuming container names are never resolvable
• Thinking IP addresses are always required
• Believing user-defined networks block communication

4. You created two containers on the default bridge network but they cannot communicate by container name. What is the likely cause?

medium

A. Container names must be IP addresses on default bridge

B. Containers must be on different networks to communicate

C. Default bridge network does not support automatic container name resolution

D. Docker daemon is not running

Solution

1. Step 1: Recall default bridge network limitations

   The default bridge network does not provide automatic DNS for container names.

2. Step 2: Analyze communication failure

   Without name resolution, containers cannot reach each other by name on default bridge.

3. Final Answer:

   Default bridge network does not support automatic container name resolution -> Option C

4. Quick Check:

   Default bridge = no name resolution [OK]

Hint: Default bridge lacks container name DNS [OK]

Common Mistakes:

• Thinking containers must be on different networks to communicate
• Confusing container names with IP addresses
• Assuming Docker daemon is stopped without checking

5. You want to isolate microservices into separate networks for security but allow only the api service to communicate with db. Which design best achieves this?

hard

A. Create separate networks but connect all containers to all networks.

B. Connect all services to a single network and use firewall rules inside containers.

C. Use the default bridge network for all containers and rely on container names.

D. Create two networks: api-net and db-net. Connect api to both networks, db only to db-net.

Solution

1. Step 1: Understand network isolation and selective communication

   Separating services into different networks isolates traffic. Connecting api to both networks allows it to talk to db while others cannot.

2. Step 2: Evaluate options for security and communication

   Create two networks: api-net and db-net. Connect api to both networks, db only to db-net. isolates db and allows only api access. Other options either lack isolation or allow unwanted access.

3. Final Answer:

   Create two networks: api-net and db-net. Connect api to both networks, db only to db-net. -> Option D

4. Quick Check:

   Separate networks + selective connection = secure communication [OK]

Hint: Use multiple networks and connect only needed containers [OK]

Common Mistakes:

• Putting all containers on one network without isolation
• Connecting all containers to all networks
• Relying on default bridge network for security