Advanced

Linux isolates containers using kernel namespaces. Sometimes you need the opposite: two containers that can see each other’s processes or share memory. The pid and ipc directives give you that escape hatch. Sharing a PID namespace pid: service:<name> lets a container see and act on processes inside another service: services: app: image: myapp debugger: image: alpine pid: service:app cap_add: - SYS_PTRACE command: sleep infinity The debugger container’s ps, strace, and /proc all reflect app’s processes. Combined with cap_add: SYS_PTRACE, you can attach strace or gdb to a running production-style container without baking debug tools into its image. ...

Not everything in your stack is a container. Managed databases, SaaS APIs, VPN tunnels, Kubernetes intercepts, all sit outside Docker but still need to be wired into your local environment. Compose 2.36 introduced provider services to declare and manage these alongside your containers. The syntax A provider service replaces image: with a provider: block: services: api: image: my-api:latest tunnel: provider: type: telepresence options: namespace: avatars service: api port: 5732:api-80 Two parts: ...

Compose can orchestrate more than just Linux containers. By combining platform and runtime, you can run traditional containers alongside WebAssembly (Wasm) modules in the same stack. The platform key The platform key at service level tells Docker which platform the service targets: services: # Regular Linux container (default) web: image: nginx platform: linux/amd64 # WebAssembly module api: image: wasmedge/example-wasi-http runtime: io.containerd.wasmedge.v1 Mixing Linux and Wasm services Here’s a practical stack where a traditional nginx reverse proxy sits in front of a Wasm-based API: ...

A sidecar is a helper container that runs alongside your main application, adding capabilities without modifying the application itself. Compose has specific features to make sidecars work seamlessly. Shared network namespace with network_mode Use network_mode: service:<name> to share the network stack with another container, they share the same IP address and can communicate over localhost: services: app: image: myapp # No ports needed — proxy handles public traffic proxy: image: nginx network_mode: service:app ports: - "443:443" volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro - ./certs:/etc/nginx/certs:ro Since both containers share the same network namespace, nginx can proxy to localhost:3000 without any DNS resolution. The app doesn’t need to know about TLS at all, the proxy sidecar handles it. ...

The real power comes from using all three mechanisms together, each doing what it does best. The scenario A team maintaining a web application with: Shared infrastructure (database, monitoring) reused across projects Common service configuration (logging, labels) applied to all services Different settings for local development vs CI vs production Project structure my-project/ ├── compose.yml # Main entry point ├── compose.override.yml # Local dev overrides ├── compose.ci.yml # CI-specific overrides ├── base/ │ └── service-base.yml # Shared service config (extends) └── infra/ ├── database.yml # Postgres stack (include) └── monitoring.yml # Prometheus + Grafana (include) Step 1: Shared service config with extends Define common configuration once: ...