Docker 17.12 makes execution directories explicit and retires registry v1

A process's working directory is an input even when the command line does not mention it. Relative paths depend on that directory, which means a diagnostic command started inside a container can behave differently from the same command started elsewhere. Docker 17.12 adds an API field for selecting the working directory of an exec process, making the dependency explicit at process creation.

The 17.12.0-ce release notes date the release to 27 December. Alongside the working-directory change, Docker adopts containerd 1.0 and disallows legacy registry v1 access. The common operational concern is the relationship between declared inputs and behavior that otherwise depends on inherited state or compatibility fallbacks.

I value Docker's ability to describe an environment in a repeatable form. That requires more than copying the right files into an image. Process settings and image acquisition rules also determine what happens when the environment is used, and both receive concrete changes in this release.

An exec process can choose its own directory

Nicolas De Loof's working-directory patch adds WorkingDir to the exec configuration accepted by the engine API. The field names a directory inside the container for the additional process. It is separate from the working directory originally configured for the container.

The daemon stores the requested value when it creates the exec configuration. If the value is empty, it copies the container's configured working directory. Later, when building the process specification, it uses the exec configuration's directory. If that still yields an empty value, the process directory defaults to the root directory.

These steps establish a clear precedence. A supplied exec directory wins, an omitted value inherits the container setting, and a remaining empty value becomes /. That is a more precise contract than requiring every exec process to use the container's original directory regardless of its task.

An API request can therefore contain fields of this shape:

{
  "AttachStdout": true,
  "Cmd": ["pwd"],
  "WorkingDir": "/tmp"
}

This is an exec-creation payload, not a complete HTTP request or a command for creating a new container. It assumes the target container exists and contains the requested executable and directory. The API's process settings determine where the command starts within that existing environment.

The test distinguishes inherited and requested state

The patch's integration test creates a container whose configured working directory is /root. It then creates an exec process with WorkingDir set to /tmp and an extra environment variable. The process prints its environment, and the test checks that its working directory and environment reflect the exec request.

The difference between the two directories is important to the test. A test using the same directory for both could pass while the implementation ignored the new field. Here the requested value has to override the inherited container setting for the expected result to appear.

This also clarifies what the feature does not change. The original container configuration remains the fallback for other exec operations that do not supply a directory. One additional process can select its own starting directory without requiring the container's main process or every later command to adopt that choice.

The patch changes the process specification's Cwd assignment, which is where the selected value reaches execution. It is not implemented by prepending a shell command that changes directories. That keeps directory selection available as process configuration, independent of whether the requested executable is a shell.

Registry v1 loses its compatibility override

The release also closes a compatibility path that had remained available after an earlier default change. Sebastiaan van Stijn's registry patch states that v1 interaction was deprecated in Docker 1.8.3 and disabled by default in 17.06. Docker 17.12 now rejects attempts to enable it again.

The distinction between default-disabled and unsupported is operationally significant. An installation could previously carry a setting that restored v1 access. Keeping that configuration no longer preserves the behavior after this upgrade. The daemon reports that interaction with legacy registries is no longer supported.

The patch explicitly checks the deprecated command-line flag on non-Windows systems. It also rejects a daemon configuration that sets the legacy-registry disabling option to false. The resulting errors identify the removed option. This can stop daemon startup before an application has attempted to pull an image.

The implementation note says the old v1 code still exists at this point and will be removed separately. Unsupported behavior does not require every corresponding source file to have disappeared in the same commit. The important released behavior is that the configuration no longer permits enabling the path.

Authentication errors can become more accurate

The registry change also updates tests involving authentication and logout. One test previously expected an image-not-found error after the daemon fell back to v1. With that fallback removed, the expectation becomes a missing-credentials error. The same failed operation can therefore report a different cause because Docker no longer takes the legacy path.

This is a useful detail for systems that classify command failures. An error message produced after protocol fallback may obscure the first failure. Removing the fallback changes both compatibility and the diagnostic information visible to the caller. Scripts that interpret the old wording need to account for the actual authentication failure.

I prefer explicit failure when the configured protocol is no longer supported. A silent compatibility path can make two apparently identical image operations depend on different registry behavior. Rejecting the obsolete setting gives the administrator a concrete configuration problem to resolve.

The runtime dependency reaches its final version

Docker 17.12's release notes also update containerd to v1.0.0. The prior Docker release had used containerd 1.0 beta, so the final-version qualification is now appropriate. The notes additionally include namespace convention changes and fixes involving process handling and container state.

These are runtime integration changes beneath the application image. They accompany the per-exec process configuration field without making that field responsible for all runtime behavior. Containerd supplies execution machinery, while Docker's API and daemon choose the process settings submitted through that machinery.

The release therefore changes several specific inputs and compatibility rules. An exec request can name a working directory independent of the container default. A legacy registry override can no longer restore v1 access. The engine uses the final containerd 1.0 release. Each change belongs to a concrete interface that determines how the same application artifact is obtained or executed.