What Is New in Docker Engine 17.03
Docker Engine 17.03.0-ce is the inaugural release of the new monthly-based release cycle, focusing on smaller, more frequent updates. This version delivers key enhancements in multi-stage builds, orchestration, and networking.
| Category | Key Changes |
|---|---|
| New Features | Multi-stage build support, DAB (Distributed Application Bundle) validation |
| Orchestration | Swarm mode service rolling updates, node drain/availability management |
| Networking | MAC address specification for containers, --attachable flag for swarm scoped networks |
| Runtime & Build | Build secrets experimental support, --squash experimental flag |
| Deprecations | Deprecated the old string syntax for container links |
How do multi-stage builds change Dockerfile creation?
Multi-stage builds are a complete game-changer for creating lean production images. You can now use multiple FROM statements in a single Dockerfile, each starting a new build stage.
This allows you to separate your build-time dependencies from your final runtime image. You copy only the necessary artifacts from one stage to another, leaving behind all the compilers and build tools. In practice, this eliminates the need for hacks like manually cleaning up apt-get caches in the same layer, resulting in significantly smaller and more secure images.
Here's a quick example of building a Go app without the entire Go toolchain in the final image:
FROM golang:1.20 AS builder
WORKDIR /src
COPY . .
RUN go build -o /app .
FROM alpine:latest
COPY --from=builder /app /app
CMD ["/app"]
What swarm mode improvements were introduced?
Swarm mode got smarter with more granular control over service updates and node management. The docker service update command now supports --update-parallelism and --update-delay flags, giving you precise control over rolling update deployment speed.
You can also now manage node availability with docker node update --availability drain. This is crucial for planned maintenance; it gracefully stops tasks on a node and reschedules them elsewhere in the swarm without service interruption. It makes the orchestration lifecycle feel much more production-ready.
Can I assign a MAC address to a container now?
Yes, this release adds the --mac-address flag to the docker run command. This allows you to set a static MAC address for a container's network interface, which is a niche but critical requirement for certain legacy applications that use MAC-based licensing or network filtering.
Remember that the MAC address must be a valid unicast address. This isn't a feature most developers will use daily, but it's a lifesaver when you need to containerize older, less flexible software that has specific network hardware expectations.
FAQ
Is Docker 17.03 a stable release?
Yes. The 17.03 release marks the start of the Monthly release channel. Releases in this channel are considered stable and production-ready, receiving security patches and critical bug fixes for the first month after release.
How do I use the new multi-stage build feature?
You use multiple `FROM` instructions in your Dockerfile. Each `FROM` begins a new stage. You can name stages with `FROM golang AS builder` and copy files from previous stages using `COPY --from=builder /app /app`. The final `FROM` instruction defines your production image.
What does the `--attachable` flag do for a swarm network?
By default, overlay networks created in swarm mode are only for swarm services. The `--attachable` flag allows standalone containers to connect to this overlay network, enabling a mix of services and standalone containers on the same network fabric.
How are build secrets implemented?
Build secrets are an experimental feature accessed with `--secret` in the Dockerfile syntax. They allow you to pass sensitive information (like private keys) during the build process without baking them into the final image layers, using a dedicated `/run/secrets` directory.
What was deprecated in this version?
The old string-based syntax for container links (e.g., `--link redis:redis`) is now deprecated. You should use user-defined networks instead, which provide a more robust and discoverable service linking mechanism through embedded DNS.