Docker 1.13 deploys Compose applications through Swarm

A description of an application is more useful when the deployment system can consume it directly. Docker 1.13 brings Compose files into docker stack deploy, connecting a familiar application description to services distributed across a Swarm. The important change is the relationship between the file and the service API. An application can describe its component services together while the cluster manages their execution.

The 1.13.0 release notes date the release to 18 January and identify Compose support in pull request 27998. This sits beside changes to image identification, service health and resource management. Together they make the distinction between a reusable image and a running deployment more explicit. The image remains an input, while the deployment describes how the cluster should use it.

I value Docker for making an environment transferable through a repeatable build description. Compose deployment extends that usefulness beyond building an image. It gives the application description a direct route into the cluster without making a collection of individual service commands the only record of the intended deployment.

A stack creates cluster services

The command documentation shipped with 1.13.0 says that stack deployment creates or updates a stack from a Compose file or a Distributed Application Bundle. The command must target a manager node. Compose input must use file version 3.0 or above, so an existing file is not automatically suitable merely because a local Compose installation accepts it. The invocation names both the file and the stack. The command documentation supplies this form for Compose input:

docker stack deploy --compose-file docker-compose.yml my-stack

The stack name groups the resulting application resources. The versioned documentation shows the command creating networks followed by services, and then uses docker service ls to inspect them. That output makes the execution model visible. A successful request has created service objects that the cluster will reconcile, rather than a sequence of local containers managed only by the command that launched them.

The same example prints a warning that it is ignoring the unsupported links option. This is a significant compatibility detail. Supporting Compose input does not mean implementing every behavior that a developer associates with a local Compose workflow. A deployment description has to express relationships in terms the service API can represent. An ignored option deserves attention because the command can still create the rest of the application.

For automation, the difference affects what counts as completion. The documented service listing contains desired and current replica counts, which are separate from the fact that deployment accepted the file. An application description can be valid while its services have not yet reached the requested state. The manager owns that continuing work after the deployment command has submitted the request.

An image reference becomes a deployment decision

The release adds digest pinning for service creation and updates. It also avoids pulling an image again when the image is pinned by digest. These changes connect the service definition to the content-addressed artifact that Docker will run. The service listing in the versioned stack example includes image references with sha256 digests, making the selected artifact inspectable.

A tag is convenient when a person chooses an image, but a deployment needs an answer to which contents that name identifies. Resolving and retaining the digest gives the service a concrete image identity. The release note describes that behavior specifically for service create and update, which matters when a stack produces several services that can change independently.

This is consistent with the part of Docker I find most useful. A build description explains how to produce an environment, and an image digest identifies the result. The deployment layer should preserve that identity when it asks multiple machines to execute the application. Otherwise the readable configuration leaves an important input implicit.

Docker 1.13 also adds content trust for services. That is a separate release-note item from digest pinning. Identifying bytes and deciding whether to trust their origin address different questions, even when both affect the image admitted into a service. Treating them separately makes the deployment's dependencies easier to describe without attributing every image property to one mechanism.

Service health affects traffic

Swarm gains health-aware load balancing and DNS records in this release. The service commands also accept health check options and an option to disable health checks. These changes allow the health declaration to participate in the cluster's behavior instead of leaving it as information that only a person inspecting a container might notice.

This is a concrete extension of the service abstraction. A desired replica count describes how many tasks should exist, while health information describes whether a running task can perform the work expected of it. A deployment can satisfy the first condition without satisfying the second. Connecting health to routing makes the distinction relevant to traffic reaching the application.

The release adds controls for update monitoring and the maximum failure ratio, alongside rollback support in service update. Those controls belong to deployment policy. A Dockerfile cannot describe whether a particular sequence of service replacements is acceptable for an application, because that depends on the running deployment. The stack input and service API give that policy a place outside the image build.

Service log aggregation also appears, but the release notes label docker service logs experimental. The qualification belongs in any account of what 1.13 delivers. A command's presence in the client does not imply that it carries the same status as established container commands. The daemon now has an experimental flag, replacing the need for a separate experimental build, which makes this distinction a runtime configuration question as well.

Local resources now have explicit accounting

Docker 1.13 introduces docker system df and docker system prune, plus prune commands for individual resource types. A host accumulates resources whose lifetimes differ from the lifetime of a particular deployment command. Giving those resources named inspection and cleanup operations is useful because disk consumption is otherwise difficult to connect to the application objects a person recognizes. The accounting command provides a starting point without changing the host. Its output concerns Docker's own managed resources:

docker system df

Cleanup is a different operation. The release also exposes docker container prune, docker image prune, docker volume prune and docker network prune. Keeping the resource type visible in the command makes the intended scope reviewable. A volume has a different relationship to application data from an image that can be fetched again, even when both occupy storage managed by Docker.

These commands accompany a reorganization of the client around objects. The release adds docker image and docker container command groups for consistency. That makes inspection and lifecycle operations easier to relate to the object they affect. The command hierarchy now communicates part of the resource model instead of requiring every operation to remain a top-level verb.

Defaults and compatibility still shape the upgrade

The release notes change default storage-driver selection on Linux distributions that previously defaulted to devicemapper. Docker now selects overlay2 or overlay when the kernel supports it. Explicit configuration remains available through the daemon option or the storage-driver setting in daemon.json. The condition matters because this is not a statement that every Linux host will select overlay2.

Storage defaults affect the engine's local implementation, while stack deployment affects application scheduling. They belong to the same upgrade but require different explanations. The former depends on host support and daemon configuration. The latter depends on the service description and the manager receiving it. Keeping those responsibilities distinct helps explain why identical client commands do not describe every relevant property of the machines executing them.

Managed plugins also change API relative to the experimental implementation in 1.12. Docker instructs users to uninstall those experimental plugins before upgrading and reinstall them afterwards. That warning puts a practical limit on treating all existing engine extensions as transparent dependencies. The release has promoted plugins out of experimental status while changing the interface that the earlier implementation used.

Client compatibility improves in another direction. The notes add support for a client talking to an older server. That is useful when one workstation manages machines with different engine versions, but it does not make an older server implement stack or service behavior added here. The versioned deployment documentation still defines the input accepted by this release. A Compose file, the service objects it creates and the host configuration that executes them remain separate parts of the resulting application.