Docker 17.11 changes the runtime state that Live Restore depends on

Keeping a process alive is insufficient if its manager can no longer identify it. Docker 17.11 makes that problem explicit in its upgrade instructions. The release adopts containerd 1.0 beta, and Docker warns that containers started by earlier versions will not be recognized after the upgrade. With Live Restore, those processes can remain running outside the new daemon's management.

The 17.11.0-ce release notes, dated 20 November, require Live Restore users to stop all containers before upgrading. This is a specific compatibility boundary in runtime state. It should not be read as a statement that existing application images become unusable, or that every daemon restart has the same restriction.

I value Docker's transferable image model because it separates an application's environment from a particular running process. This upgrade illustrates why the distinction matters. The image can remain a useful artifact while the engine's relationship to an already running container changes underneath it.

The runtime now represents containers and tasks separately

The containerd README vendored into this Docker release describes a container as a metadata object. It can have an OCI runtime specification, an image and a root filesystem attached to it. Turning that object into a runnable process requires creating a task.

A task represents the runnable object within containerd. The README's example creates a task from the container, obtains its process identifier, starts the process and waits for its exit. This separation gives the implementation identities for both the persistent description and the associated execution.

That model matters to a management client because loading a container object and finding its running task are different operations. An engine must reconnect the two when it reconstructs its view after a restart. Knowing the image that originally supplied the filesystem does not by itself establish which process belongs to a container that is still running.

Docker's runtime client in the release tag reflects the distinction. Its internal container structure holds both a containerd container and a task. It also keeps a map of additional processes. The integration has to track those objects together to implement Docker's process-management operations.

Restoring management begins with loading known state

The client's restore function first asks containerd to load a container by identifier. If that lookup fails, restore returns an error. If it succeeds, the client asks the container for its task and arranges process input and output attachment. It then obtains task status and a process identifier where a task exists.

This sequence explains what management requires without speculating about every detail of the old state format. The new client depends on the runtime being able to load the expected object. A live operating-system process alone cannot satisfy that lookup. The release warning establishes that containers started through the older integration do not meet the new release's recognition requirements.

After obtaining the objects, Docker inserts them into its own container map. That local map is part of subsequent operations, including signal delivery and process status inspection. The code's process lookup distinguishes an unknown container from a known container without a running task, which gives different errors for two different states.

Those checks are ordinary bookkeeping with important consequences. A manager cannot safely send lifecycle operations to arbitrary processes merely because they resemble containers. It needs the identities and runtime state that its interface recognizes. The upgrade restriction concerns maintaining that relationship across the change in integration.

Process survival can conceal a management failure

Live Restore changes the visible symptom because the process can survive the daemon transition. An application may continue responding while Docker no longer manages the container that owns it. The release notes state this outcome directly, including that the older containers remain running unmanaged on the system.

This makes process availability an incomplete success criterion for this upgrade. A reachable application does not prove that the new daemon can stop it or observe its lifecycle through the expected runtime objects. These are separate properties, and an upgrade can preserve one while losing the other.

The documented remedy is to stop the containers before crossing the version boundary. It is not an instruction to rely on the new daemon rediscovering every surviving process. The warning also does not provide a general migration command for converting those running containers into the new runtime's state model.

For a service owner, this affects the continuity model of the upgrade. A plan that depends on uninterrupted execution through Live Restore conflicts with the documented requirement here. The interruption needs to be handled at the application's deployment level, where the service can account for a stopped instance and its replacement.

Event delivery also depends on recognized identities

The runtime client subscribes to containerd events filtered by namespace and task-related topics. It decodes events for task creation, start and exit, as well as additional-process and pause operations. The resulting information includes identifiers that Docker uses to relate runtime activity to its own container state.

When the event loop encounters an identifier missing from its container map, it logs an unknown-container warning and continues. That behavior demonstrates another reason that a live process is not sufficient for management. Observation needs an association between the event's identity and the object the engine knows.

The exit path also tracks whether an event belongs to an additional process, with cleanup for that process's runtime object and I/O resources. A runtime integration therefore has ongoing responsibilities after initial creation. It translates events into the engine's model and releases resources when execution ends.

This is why switching a runtime client can be operationally significant even if the familiar Docker commands remain. The commands depend on a chain of state and event translation beneath them. Compatibility has to hold across that chain for a surviving process to remain manageable.

The embedded runtime has a broader scope

The vendored README describes image transfer and storage alongside execution and supervision. It also describes namespaces that allow multiple consumers to share content while separating their containers and images. These capabilities explain the reusable-runtime direction that Docker announced when it began separating containerd from the wider platform.

Namespaces here identify consumers within containerd. They should not be confused with the operating system's namespace mechanisms or assumed to establish every security property a platform needs. The README's claim is about sharing one daemon without consumers conflicting over container and image state.

The same document describes root filesystems managed through snapshotters, with built-in overlayfs and btrfs support. Preparing a writable root filesystem and associating it with a container are separate operations in its examples. This is more of the lifecycle that an embedding platform can obtain from containerd.

I find the expanded component model useful because it offers other platforms concrete operations to reuse. Docker's integration still has to translate those operations into its own behavior. This release's upgrade warning is evidence that adopting a reusable component includes responsibility for existing runtime state, as well as adding a new dependency.

A beta dependency is the milestone available today

The release notes call this containerd 1.0 beta. That qualification should remain attached to the change. Adopting the beta in Docker is a concrete integration milestone, but it is not an announcement that a final containerd 1.0 release has already happened.

Other fixes in Docker 17.11 concern the same operational path. The notes include a Live Restore process-identifier panic fix and changes for Linux Containers on Windows following the new containerd integration. Those items show that the runtime transition has several platform-specific consequences, without establishing that one fix removes the separate compatibility warning.

The client source provides a precise way to understand the required management relationship. Docker loads a container by identifier, obtains its task and reconstructs local state before later process operations can work. The public upgrade instructions establish where that relationship does not carry across older running containers.

For an installation using Live Restore, the immediate requirement remains to stop those containers before upgrading. The application image and deployment description can supply the inputs for subsequent execution, while the new daemon establishes runtime objects it recognizes. The release changes how Docker manages execution, and that change has to be accounted for even when the application code and image contents have not changed.