Sidecar container pattern in Docker - Step-by-Step Execution

Process Flow - Sidecar container pattern

Main Application Container

↓

Sidecar Container

↓

Shared Resources

↓

Communication & Support

The main container runs the app, the sidecar container runs helper tasks, both share resources and communicate to support the app.

Execution Sample

Docker

version: '3.8'
services:
  app:
    image: myapp:latest
    volumes:
      - shared-data:/data
  sidecar:
    image: log-collector:latest
    volumes:
      - shared-data:/data
volumes:
  shared-data: {}

This Docker Compose file runs an app container and a sidecar container sharing a volume for communication.

Process Table

Step	Action	Container	Resource Used	Result
1	Start main app container	app	shared-data volume	App container running, volume mounted
2	Start sidecar container	sidecar	shared-data volume	Sidecar running, volume mounted
3	App writes logs to /data/log.txt	app	shared-data volume	Log file created in shared volume
4	Sidecar reads /data/log.txt	sidecar	shared-data volume	Sidecar collects logs for processing
5	Sidecar sends logs to external system	sidecar	network	Logs forwarded outside
6	Both containers running	app & sidecar	shared-data volume	App supported by sidecar helper
7	Stop containers	app & sidecar	shared-data volume	Containers stopped, resources freed

💡 Containers stopped after sidecar completes support tasks

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
shared-data volume content	empty	log.txt created	log.txt read	logs sent out	log.txt remains
app container state	stopped	running	running	running	stopped
sidecar container state	stopped	running	running	running	stopped

Key Moments - 3 Insights

Why do both containers share the same volume?

They share the volume to exchange data like logs; the app writes logs there, and the sidecar reads them (see execution_table steps 3 and 4).

Does the sidecar container run the main app?

No, the sidecar runs alongside the main app to support it, not replace it (see execution_table steps 1 and 2).

What happens if the sidecar stops before the app?

The app keeps running but loses sidecar support like log collection; sidecar and app states are tracked separately (see variable_tracker).

Visual Quiz - 3 Questions

Look at the execution table, at which step does the sidecar container start running?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Check the 'Container' and 'Result' columns in execution_table rows for when sidecar is running

According to variable_tracker, what is the state of the app container after step 3?

A stopped

B starting

C running

D paused

💡 Hint

Look at the 'app container state' row under 'After Step 3' in variable_tracker

If the shared-data volume was not shared, what would change in the execution table?

A Sidecar could not read logs at step 4

B App would not start at step 1

C Sidecar would send logs earlier at step 3

D Containers would stop immediately at step 2

💡 Hint

Check the role of shared-data volume in steps 3 and 4 in execution_table

Concept Snapshot

Sidecar container pattern runs a helper container alongside the main app.
They share resources like volumes to communicate.
Sidecar supports tasks like logging or monitoring.
Both containers run independently but cooperate.
Use shared volumes or network for data exchange.

Full Transcript

The sidecar container pattern runs two containers together: the main application and a helper sidecar. The main app container starts first and mounts a shared volume. Then the sidecar container starts and mounts the same volume. The app writes logs into the shared volume. The sidecar reads these logs and sends them outside. Both containers run independently but share data through the volume. When done, both containers stop and free resources. This pattern helps add features like logging without changing the main app container.