Sidecar container pattern in Docker - Commands & Configuration

Introduction

Sometimes an application needs extra helper tasks like logging or data syncing. The sidecar container pattern solves this by running a small helper container alongside the main app in the same pod or environment, sharing resources but keeping tasks separate.

When you want to add logging or monitoring to an app without changing its code

When you need to sync files or data between the app and external storage

When you want to add a proxy or security layer alongside your main app

When you want to keep helper tasks isolated but tightly coupled with the main app

When you want to update or restart the helper without affecting the main app

Config File - docker-compose.yml

docker-compose.yml

version: '3.8'
services:
  app:
    image: nginx:1.23
    ports:
      - "8080:80"
    volumes:
      - app-data:/usr/share/nginx/html
  sidecar:
    image: busybox
    command: ["sh", "-c", "while true; do echo 'Sidecar running' >> /data/log.txt; sleep 5; done"]
    volumes:
      - app-data:/data
volumes:
  app-data:

This docker-compose file defines two services: app and sidecar.

The app service runs an Nginx web server exposing port 8080 and uses a shared volume app-data for its web files.

The sidecar service runs a lightweight BusyBox container that writes a message to a log file every 5 seconds inside the shared volume app-data. This simulates a helper task running alongside the main app.

The shared volume app-data allows both containers to access the same files, enabling cooperation without mixing their processes.

Commands

This command starts both the main app and the sidecar containers in the background, creating the shared volume and linking them as defined in the docker-compose.yml file.

Terminal

docker-compose up -d

Expected Output

Creating network "default" with the default driver

Creating volume "app-data" with default driver

Creating sidecarpattern_app_1 ... done

Creating sidecarpattern_sidecar_1 ... done

→

-d - Run containers in detached mode (in the background)

This command lists the running containers started by docker-compose, showing their status and ports.

Terminal

docker-compose ps

Expected Output

    Name                     Command               State           Ports         

--------------------------------------------------------------------------------

sidecarpattern_app_1     nginx -g 'daemon off;'    Up      0.0.0.0:8080->80/tcp

sidecarpattern_sidecar_1 sh -c while true; do ec... Up      

This command reads the log file created by the sidecar container inside the shared volume to verify the sidecar is running and writing data.

Terminal

docker exec sidecarpattern_sidecar_1 cat /data/log.txt

Expected Output

Sidecar running

Sidecar running

Sidecar running

Sidecar running

Sidecar running

This command stops and removes the containers and network created by docker-compose, cleaning up the environment.

Terminal

docker-compose down

Expected Output

Stopping sidecarpattern_sidecar_1 ... done

Stopping sidecarpattern_app_1 ... done

Removing sidecarpattern_sidecar_1 ... done

Removing sidecarpattern_app_1 ... done

Removing network default

Key Concept

If you remember nothing else from this pattern, remember: a sidecar container runs alongside your main app to add helper tasks without changing the app itself.

Common Mistakes

Not sharing a volume between the main app and sidecar containers

Without a shared volume, the containers cannot exchange files or data, so the sidecar cannot assist the main app effectively.

Define a shared volume in the docker-compose file and mount it in both containers at appropriate paths.

Running the sidecar container with a command that exits immediately

If the sidecar container stops right after starting, it won't provide continuous helper functionality.

Use a command that keeps the sidecar container running, like a loop or a long-running process.

Summary

Use docker-compose to run a main app container and a sidecar container together.

Share a volume between containers to allow data exchange and cooperation.

Keep the sidecar container running with a continuous command to provide helper tasks.

Practice

1. What is the main purpose of the sidecar container pattern in Docker?

easy

A. To run containers only during the build process

B. To replace the main application container with a smaller one

C. To create multiple copies of the main application for load balancing

D. To run helper containers alongside the main application to add features

Solution

1. Step 1: Understand the sidecar pattern concept

   The sidecar pattern involves running a helper container alongside the main app container to provide additional features without modifying the main app.

2. Step 2: Identify the purpose of sidecar containers

   Sidecar containers commonly handle logging, monitoring, or proxy tasks to support the main app.

3. Final Answer:

   To run helper containers alongside the main application to add features -> Option D

4. Quick Check:

   Sidecar pattern = helper containers alongside main app [OK]

Hint: Sidecar means helper container runs with main app [OK]

Common Mistakes:

• Thinking sidecar replaces the main app container
• Confusing sidecar with load balancing
• Believing sidecar runs only during build

2. Which of the following is the correct way to define a sidecar container in a Docker Compose file?

easy

A. Define multiple services in the same docker-compose.yml file, where one service is the main app and another is the sidecar

B. Use the depends_on key to run containers sequentially

C. Run two containers with the same image name in separate Compose files

D. Use docker run --sidecar command to start a sidecar container

Solution

1. Step 1: Review Docker Compose structure for multiple containers

   Docker Compose allows defining multiple services in one file, each representing a container.

2. Step 2: Understand sidecar container definition

   Sidecar containers are defined as separate services alongside the main app service in the same Compose file.

3. Final Answer:

   Define multiple services in the same docker-compose.yml file, where one service is the main app and another is the sidecar -> Option A

4. Quick Check:

   Sidecar in Compose = multiple services in one file [OK]

Hint: Sidecar containers are separate services in one Compose file [OK]

Common Mistakes:

• Using a non-existent --sidecar flag in docker run
• Running containers in separate Compose files without linking
• Misusing depends_on for sidecar definition

3. Given this Docker Compose snippet, what will happen when you run docker-compose up?

version: '3'
services:
  app:
    image: myapp:latest
  logger:
    image: logcollector:latest
    depends_on:
      - app

medium

A. Only app container starts; logger is ignored

B. logger starts before app container

C. Both app and logger containers start; logger waits for app to start first

D. Docker Compose throws an error due to missing networks

Solution

1. Step 1: Analyze the Compose file services and dependencies

   There are two services: app and logger. The logger service depends on app.

2. Step 2: Understand depends_on behavior

   depends_on ensures app starts before logger, but both start when running docker-compose up.

3. Final Answer:

   Both app and logger containers start; logger waits for app to start first -> Option C

4. Quick Check:

   depends_on means start order, both containers run [OK]

Hint: depends_on controls start order, not exclusion [OK]

Common Mistakes:

• Thinking depends_on skips starting dependent container
• Assuming logger starts before app
• Expecting error due to missing networks (default network is created)

4. You have a sidecar container for logging, but logs are not appearing as expected. Which of these is the most likely cause?

medium

A. Docker Compose file version is set to '2' instead of '3'

B. The sidecar container does not share the same volume or network with the main app

C. The main app container image is missing

D. The sidecar container is defined as a separate Dockerfile

Solution

1. Step 1: Identify how sidecar containers share data

   Sidecar containers usually share volumes or networks with the main app to access logs or data.

2. Step 2: Check common causes for missing logs

   If volumes or networks are not shared, the sidecar cannot access the main app's logs, causing missing logs.

3. Final Answer:

   The sidecar container does not share the same volume or network with the main app -> Option B

4. Quick Check:

   Shared volumes/networks needed for sidecar access [OK]

Hint: Sidecar needs shared volumes or network to access data [OK]

Common Mistakes:

• Blaming Compose file version for logging issues
• Confusing missing image with logging problem
• Thinking sidecar must be in same Dockerfile

5. You want to add a monitoring sidecar container to your existing app without changing the app code. Which approach best follows the sidecar pattern?

hard

A. Add a new service in your Docker Compose file that runs the monitoring container sharing the app's network and volumes

B. Modify the app container image to include monitoring tools inside it

C. Run the monitoring container separately on another host

D. Add monitoring commands inside the app's Dockerfile entrypoint script

Solution

1. Step 1: Understand sidecar pattern goal

   The sidecar pattern adds features by running helper containers alongside the main app without modifying the app itself.

2. Step 2: Evaluate options for adding monitoring

   Adding a new service in Compose that shares network and volumes with the app fits the sidecar pattern perfectly.

3. Step 3: Exclude options that modify app or separate hosts

   Modifying app image or running monitoring separately breaks sidecar principles.

4. Final Answer:

   Add a new service in your Docker Compose file that runs the monitoring container sharing the app's network and volumes -> Option A

5. Quick Check:

   Sidecar = helper container alongside app, no app code change [OK]

Hint: Sidecar means add helper container, no app code change [OK]

Common Mistakes:

• Modifying app image instead of adding sidecar
• Running monitoring on separate host breaks sidecar
• Embedding monitoring commands inside app entrypoint