Advanced

A Compose file with a models: section runs an AI application out of the box on a laptop. Shipping the same stack to Kubernetes used to mean writing the model server’s Deployment, Service, ConfigMap, and PVC by hand, and remembering to point your application’s environment variables at the right place. Compose Bridge now does that for you, in two distinct topologies. This is the final post of the Compose Bridge Deep Dive series. Parts 1 and 2 covered the fundamentals and customization. This one focuses on a concrete, end-to-end scenario built on top of the new model-runner support in the default transformers. ...

The defaults shipped with Compose Bridge produce sensible Kubernetes manifests, but every organisation has its own rules: which labels are required, which ingress class to use, which securityContext is mandatory, which Pod Security Standard applies. Hard-coding all of that in every Compose file gets old fast. The clean way to bake those rules in is a custom transformer. This is the second post of the Compose Bridge Deep Dive series. Part 1 explained the transformer concept. This post shows how to fork the default templates, plug your rules in, and use the x-* extension fields to keep your Compose files clean. ...

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: ...