Docker Desktop 2.2 brings Compose applications into the dashboard

A container list is an incomplete view of an application made from several services. The developer needs to understand which containers belong together and read their output in that context. Docker Desktop 2.2, released today, addresses that problem with an integrated dashboard for local containers and Compose applications. Ben De St Paer-Gotch describes a common interface across Mac and Windows in the release announcement. Docker also plans to archive Kitematic during 2020 and replace it with this dashboard.

I value Docker primarily for making environments transferable through an image and a repeatable build description. A desktop interface deserves attention when it makes that environment easier to understand without becoming another place to define it. The useful question for this release is how much of the application model the interface preserves. A collection of independent start buttons would leave most of the reasoning to the person operating them.

An application has a lifecycle

The Mac release notes specify that the dashboard can start and stop existing Compose applications and show their combined logs. It also presents container details and resource use. This makes the Compose application a useful unit of interaction, alongside the individual container. The word existing matters here. The announced capability concerns managing applications already described and created through Compose.

That scope fits the way a declarative application description should relate to an interactive tool. The description should remain understandable without reproducing a sequence of clicks. Once it exists, a visual view can reduce the effort of answering an immediate question about its running instances. Those are different jobs, and both are useful. Keeping the application description available for inspection also gives another developer something concrete to discuss when the local environment behaves unexpectedly.

The release notes identify a limitation in application grouping. A Compose application and a Docker App with the same name appear as one application, with both sets of containers underneath it. That makes the application name operationally significant in this interface. A grouping label cannot by itself prove that every displayed container belongs to the intended deployment. The issue is narrow, but it helps explain why a dashboard needs a precise account of application identity.

I prefer a view that exposes those relationships because the build file alone does not explain the current running state. The image describes an artifact. The dashboard concerns a particular execution of an application. Confusing the two makes a local environment harder to reproduce, even when the visual controls are convenient.

A common interface needs controlled backends

Docker announced the redesigned WSL 2 backend in October 2019. The original preview ran Docker inside a user distribution. Docker reported networking conflicts involving other software and competing daemons changing iptables rules. The replacement runs its LinuxKit environment in an isolated namespace, with separate bootstrapping and data-store distributions. It reuses components shared with the Mac and Hyper-V implementations.

This architecture explains part of the work behind a common desktop interface. A user-controlled distribution offers flexibility, but it also leaves the desktop product responsible for failures caused by unrelated changes in that distribution. An isolated environment gives the maintainers a more specific system to diagnose. That is a practical tradeoff for software whose purpose includes managing the container environment on the developer's behalf.

The architecture also uses cross-distribution mounts and an API proxy to translate user-distribution paths into paths accessible to the LinuxKit environment. File access still needs an explicit mechanism across that isolation boundary. Namespace separation does not make the developer's source tree available automatically. The design must preserve access to the working files while controlling the environment in which Docker itself runs.

Today's announcement still calls WSL 2 a technical preview and requires a compatible Windows preview build. Installing a stable Docker Desktop release therefore does not make every bundled integration generally available. The distinction belongs in any explanation of the release because the dashboard and the WSL backend have different adoption requirements.

Source files are part of the desktop problem

The Windows file-sharing work addresses another boundary between the developer's machine and its Linux container environment. Docker's file-sharing explanation describes replacing Samba with a design based on FUSE and gRPC. File operations cross the boundary through the sharing implementation. That is a separate concern from displaying containers in a dashboard, even though both affect the same development session.

The distinction matters when judging local container usability. A clear application view can help identify which service is running. It cannot compensate for source-file changes that the running process cannot observe as intended. Conversely, an improved sharing mechanism does not explain which service produced an error. These changes address different parts of the developer's work, so it is reasonable for a desktop release to contain both.

The release announcement identifies support for Linux inotify events in the new Windows sharing implementation. Reloading tools that depend on filesystem notifications have a specific reason to care about that change. This is more informative than treating file sharing as a single performance number. Correct notification behavior affects whether an edit reaches the next stage of the development process at all.

Application output and desktop diagnostics

Application logs are only part of the evidence needed when the desktop environment fails. David Scott's 17 January description of Desktop logging explains that the LinuxKit virtual machine has isolated components of its own. Its startup includes sequential on-boot actions followed by concurrent services. A logging service started too late could miss the earlier output.

Docker addresses that ordering problem with memlogd, which starts before the on-boot actions and buffers output in memory. A later downloader can persist the output once storage is available. The bounded buffer drops the oldest lines when full. This separates early capture from persistent storage without requiring storage to be ready before the first startup action runs.

I find this distinction useful when assessing the dashboard. Combined application logs answer questions about application behavior. Desktop diagnostics must also account for the environment that starts and hosts those applications. The new interface makes local application state easier to inspect, while the logging design explains how evidence about the hosting environment can survive its own startup sequence. A developer investigating a failure needs to identify which of those systems produced the evidence before drawing a conclusion from it.