What Is New in Docker Engine 17.12
Docker Engine 17.12 CE introduces significant enhancements focused on builder features, networking, and runtime improvements. This release marks a shift towards more integrated and efficient container management workflows.
| Category | Key Changes |
|---|---|
| New Features | Docker Build --cache-from, LCOW (Linux Containers on Windows) preview, Overlay2 as default storage driver |
| Improvements | Docker Compose file version 3.5, Service discovery for Windows containers, Buildkit backend (experimental) |
| Runtime & Networking | Support for Kubernetes (experimental), Container live restore on Windows, Improved
docker system commands |
| Deprecations | AUFS storage driver, Legacy Docker Engine packages |
What are the major builder improvements?
The builder got a major boost with the --cache-from flag and an experimental new backend. The
--cache-from flag allows you to specify images to use as a cache source during a build. This is a
game-changer for CI/CD pipelines, enabling you to share build cache across different nodes.
Behind the scenes, the experimental Buildkit backend was introduced. This lays the groundwork for faster, more feature-rich builds with better caching and parallelization, though it wasn't the default yet. In practice, this means your Dockerfile builds start to feel noticeably quicker and more reliable.
How did networking and runtime evolve?
Runtime and networking saw cross-platform enhancements and deeper orchestration integration. A huge step for Windows developers was the introduction of service discovery for Windows containers, allowing them to connect to services by name just like Linux containers could.
On the orchestration front, Docker 17.12 began its initial experimental integration with Kubernetes. This meant
you could now manage a Kubernetes cluster alongside your Swarm cluster from the Docker CLI, signaling a major
strategic shift. The docker system commands also became more powerful for cleaning up disk space.
What about Windows container support?
Windows support took a massive leap forward with the preview of LCOW (Linux Containers on Windows). This feature allows you to run Linux containers directly on a Windows Server kernel, eliminating the need for a full Linux VM. It simplifies mixed-architecture environments significantly.
Additionally, the live restore feature, which lets containers keep running during a daemon restart, was extended to Windows containers. This matters because it brings feature parity with Linux and improves uptime for critical Windows-based services running in containers.
Were there any storage driver changes?
Yes, Overlay2 became the default storage driver for all supported Linux distributions. This driver offers better performance and more efficient use of inodes compared to the older AUFS driver. The change was mostly automatic but resulted in more stable and faster container operations.
Conversely, the AUFS storage driver was officially deprecated. If you were still using AUFS, you'd need to plan a migration to Overlay2 to stay supported in future releases. The devicemapper driver in production mode also got a deprecation warning.
FAQ
What does the --cache-from flag actually do for my CI builds?
It lets your build daemon pull
specific images and use their layers as cache. This is crucial for CI environments where the build host is
ephemeral; you can pull a previously built image from a registry to seed the cache, drastically cutting down
build times.
Is LCOW ready for production use?
No, the LCOW (Linux Containers on Windows) feature was
released as a preview in 17.12. It was intended for experimentation and development scenarios to gather
feedback, not for running critical production workloads.
How do I start experimenting with the Kubernetes integration?
You had to enable the
experimental features in the Docker daemon settings. Once enabled, you could initialize a single-node Kubernetes
cluster using the new docker system commands and start deploying pods alongside your Swarm
services.
My system uses AUFS; what should I do after upgrading?
You should migrate your storage driver
to Overlay2. The upgrade process likely handled this change for new installations, but existing systems might
need a manual migration. Back up your data and consult the docs for the specific procedure.
What was the main goal of the Buildkit integration?
The goal was to create a more powerful,
flexible, and performant build system. Buildkit aimed to solve long-standing builder issues like inefficient
cache utilization and provided a foundation for advanced features like building multiple images in parallel from
a single Dockerfile.