Welcome! I’m Guillaume Lours, Docker Compose maintainer, passionate about containerization and developer tools.
I’m currently Software engineer at Docker working on Compose and Docker Sandboxes.
Exploring the iterative world of software engineering, Docker, and the art of building things that sometimes break.
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: ...
When using dynamic port mapping or multiple services, it’s not always obvious which host port maps to which container port. docker compose port tells you exactly. Basic usage # Which host port maps to container port 80 on the web service? docker compose port web 80 # Output: 0.0.0.0:8080 Why dynamic ports matter When you let Docker assign ports automatically, the host port changes on every docker compose up: services: web: image: nginx ports: - "80" # Dynamic host port, container port 80 docker compose port web 80 # Output: 0.0.0.0:55432 (assigned dynamically) This is common in CI or when running multiple instances of the same project. ...
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. ...
Build args and environment variables both pass values to your containers, but they work at different times and serve different purposes. Mixing them up is a common source of confusion. Build args: build-time only Build args are available during docker build and are not present in the running container: services: app: build: context: . args: NODE_VERSION: "20" APP_VERSION: "2.1.0" In the Dockerfile, they’re consumed with ARG: ...
Multi-stage Dockerfiles let you define multiple build stages. With the target option in Compose, you can choose which stage to build — giving you different images from the same Dockerfile. A multi-stage Dockerfile # Stage 1: dependencies FROM node:20-slim AS deps WORKDIR /app COPY package*.json ./ RUN npm ci # Stage 2: development (with dev dependencies and tools) FROM deps AS dev RUN npm install --include=dev COPY . . CMD ["npm", "run", "dev"] # Stage 3: build FROM deps AS build COPY . . RUN npm run build # Stage 4: production (minimal) FROM node:20-slim AS production WORKDIR /app COPY --from=build /app/dist ./dist COPY --from=deps /app/node_modules ./node_modules CMD ["node", "dist/index.js"] Targeting stages in Compose Use target to pick which stage to build: ...