What Is New in Docker Engine 1.7
Docker Engine 1.7 introduces significant networking, storage, and security enhancements. This release focuses on building a more robust and production-ready container runtime. The key updates are summarized in the table below.
| Category | Key Changes |
|---|---|
| Networking | Multi-host networking, Network management API endpoints |
| Storage & Volumes | Volume management API, Volume drivers |
| Security | User Namespaces support, SELinux improvements |
| API & Client | New API version (v1.19), Docker CLI improvements |
| Runtime & Orchestration | Improved docker logs, Container restart policies |
How did Docker networking improve in 1.7?
The headline feature is the introduction of multi-host networking, a game-changer for connecting containers across different hosts. This native capability eliminates the need for complex third-party overlay networks for many use cases.
You can now create virtual networks and attach containers to them, regardless of which physical machine they're running on. The new Network API endpoints (/networks) give you full control to create, inspect, list, and delete these networks programmatically.
What storage features were added?
Docker 1.7 formalized volume management with a dedicated Volume API. This allows you to create and manage volumes independently of containers, making data lifecycle management much cleaner.
The volume driver plugin system was enhanced, enabling storage vendors to provide advanced features like encrypted volumes, snapshots, and integration with cloud storage backends. In practice, this means you're no longer limited to the local disk driver for persistent data.
Were there any security upgrades?
Yes, User Namespaces support graduated from experimental to a fully supported feature. This allows you to remap container root users to a non-root user on the host system, drastically reducing the impact of a container breakout.
SELinux labeling also received improvements for better isolation between containers and the host. These changes are crucial for multi-tenant environments where you need strong boundaries between workloads.
What changed for developers using the API and CLI?
The Docker API moved to version 1.19, introducing the new networking and volume endpoints. This is a mandatory update if you're building tools that interact directly with the Docker daemon.
The CLI gained several quality-of-life improvements, including better feedback for network and volume operations. The docker logs command became more reliable with improved handling for large log outputs and follow modes.
FAQ
Is multi-host networking production-ready in 1.7?
It's a solid foundation but considered a first-generation implementation. For complex production workloads, many teams still used it alongside orchestration tools like Swarm (which also saw updates in this release) for complete service discovery and load balancing.
Do I need to rewrite my scripts for the new API version?
Probably not for basic container operations. The new v1.19 API is largely additive. However, to use the new network and volume features, you will need to update your tools and scripts to call the new endpoints.
How do I enable User Namespaces?
You need to configure the daemon with the --userns-remap flag. This is a host-level setting, so all containers on that daemon will run with user namespace isolation once it's enabled. Be aware that it changes how volumes are mapped and can break some path assumptions.
Can I use both the new Docker networks and my existing --link?
Yes, but it's not recommended. The new networking model provides service discovery via embedded DNS, which is more powerful and flexible than the legacy --link functionality. For new projects, you should default to using the native networks.
What happens to my existing volumes after upgrading?
They remain fully accessible. The new volume management API provides a way to interact with them, but the underlying data is untouched. The new system is backward compatible with volumes created by earlier Docker versions.