Docker for Mac removes AUFS in its first 2.0 beta
Docker's Mac beta adopts a desktop version number and removes AUFS and OS X 10.11 support. The storage change requires separating replaceable image artifacts from local state before resetting an older disk image.
An image format can be portable while the local storage holding those images remains specific to a runtime installation. Docker for Mac's first 2.0 beta makes that distinction operationally important by removing AUFS support. The September 14 release entry names the build 2.0.0.0-beta1-mac75, introduces a new version scheme, and removes support for OS X 10.11 as well.
The storage change had an earlier warning. The July edge notes on the same page deprecated AUFS and said that an AUFS installation could remain on the 18.06 desktop series. Moving to the next major update would require resetting the disk image. September is therefore the point where a previously announced local storage restriction becomes part of the new beta's supported configuration.
I value Docker's layered images because they make built environments transferable. A local storage-driver transition is a reminder to distinguish the transferable artifact from the particular disk representation that a desktop runtime uses to keep it. Treating those as the same thing makes an upgrade harder to reason about.
The desktop version is separate from the engine version
The beta's component list names Docker 18.09.0-ce-beta1 and Linux kernel 4.9.125. Its own version begins with 2.0.0.0. These identifiers refer to different parts of the installation, so the desktop version no longer gives the engine version directly through the same numbering pattern.
That separation has a practical documentation consequence. Reporting only that an installation uses Docker 2.0 would omit the engine identity listed by the release. Reporting only the engine version would omit the desktop package carrying the Mac-specific support changes. An investigation of a host integration issue needs the desktop build, while an engine behavior question may need the bundled engine version as well.
The notes explicitly call this a new version scheme. They do not describe a new image format associated with the number 2.0. It would therefore be misleading to infer that images must adopt a new format simply because the desktop application's major version changes. The stated incompatibility concerns AUFS support and the host operating system requirement.
This matters for readers comparing the beta to the preceding Mac release. The preceding edge entry uses the engine-derived 18.06.1-ce-mac74 name. September's entry changes that naming relationship while also moving the bundled engine forward. Those are related packaging facts, but they remain separate from the content of a particular application image.
Removing OS X 10.11 support establishes another boundary outside the image itself. An application artifact can remain unchanged while the desktop package requires a different supported host. A release inventory should therefore record the Mac operating system alongside the desktop and engine identifiers when deciding whether this beta fits an existing workstation. The support change is a property of the installation running the images.
Local storage state needs a deliberate transition
The July deprecation entry tells AUFS users to reset their disk image before the next major update and points separately to image saving and volume backup. That separation is significant. Images and application data have different preservation mechanisms, and the existence of an image archive is not evidence that every local application's state has been preserved.
The contemporary Docker save documentation describes a tar archive containing an image's parent layers and selected repository tags. Its examples show writing the archive to a file for later use with docker load. This is an image-oriented operation, appropriate for preserving a locally available artifact across a change to its local storage representation.
For an image that already exists locally, the command can name the exact tag to retain. The reference below is illustrative and must identify an image present in the installation being preserved.
docker save --output service-image.tar service:release
This command does not describe all the state associated with running the service. It records the selected image and its layers as documented. Its purpose is different from copying a database's volume data or recording deployment configuration. The AUFS migration warning points to those concerns separately because a reset concerns the local disk environment, not just one image tag.
The contemporary export documentation makes another important distinction. docker export produces a container filesystem archive but excludes associated volume contents. When a volume covers an existing directory, export records the underlying directory instead. Substituting export for a volume backup would therefore preserve the wrong data for that purpose.
Earlier startup failures show why driver state matters
An April startup report in issue 2804 contains a daemon diagnostic that found both aufs and overlay2 as valid graphdrivers under /var/lib/docker. The daemon asked for cleanup or explicit driver selection and failed to start. That report is not the September removal, but it is contemporary evidence that existing local driver state affects startup independently of application image names.
The reporter recovered by resetting to factory defaults. That observation should not be expanded into a claim that every storage-driver problem has the same cause or recovery. Its relevance is the daemon's explicit confusion over local driver state. The storage directory carried implementation-specific information that could prevent the engine from reaching the point where application containers start.
September's beta removes AUFS support instead of attempting to support every preceding arrangement indefinitely. For an AUFS installation, the earlier release note supplies the supported transition requirement. The image-saving and volume-backup references explain why preserving local contents must account for both artifacts and independently stored application data.
I prefer small final service images with explicit build instructions, because those artifacts are straightforward to reconstruct or transfer. Local development data can have a different lifetime and may not be reconstructible from a Dockerfile. The beta's storage change makes that distinction relevant before the runtime changes, while the separate desktop version makes the package carrying that requirement identifiable in an upgrade record.