Docker Machine, Swarm, and Compose make containerized workloads easier to pack, deploy, and manage across local environments and remote clouds Docker’s flagship app containerization product is joined by a cadre of tools to expand on its functionality. Docker Machine, Swarm, and Compose, previously announced last December and now released for public use, ease the jobs of assembling, deploying, and managing containers across all environments. They’ve been built to not only simplify the jobs of dev and ops folks, but also to demonstrate Docker’s commitment to making and keeping an open ecosystem. Where Docker is about running an app in a container, Docker Machine (in beta) is about deploying the packaged app on a supported target infrastructure. Docker lists support for 12 infrastructures out of the box — Amazon EC2, Digital Ocean, Google Cloud Platform, IBM Softlayer, Microsoft Azure, Microsoft Hyper-V, OpenStack, Rackspace Cloud, VirtualBox, VMware Fusion, VMware vCloud Air, and VMware vSphere — and notes its community “has generated 10 other pull requests for incremental drivers.” The GitHub project for Machine lists pull requests for support for Linode, Cloudstack, and several others under discussion. Docker Swarm (also in beta), the container clustering tool, is the embodiment of a philosophy Docker has described as “batteries included, but swappable.” If Docker’s clustering or scheduling system isn’t a fit, users can provide another, by way of drivers available for Swarm. Also, a number of cloud providers (Amazon, IBM, Joyent, and Microsoft, for starters) are preparing drivers to allow Swarm integration with their container management systems. Docker Compose, the most straightforward tool of the three, allows multicontainer applications to be assembled and linked together with a description file. The resulting composite container can be moved freely across multiple environments — developer’s machine, staging machine, production cloud — and maintain its integrity in each. Compose is also the one tool in the list considered a full-blown point release (1.1) and not a beta version, since it was derived from Fig, a software tool Docker acquired with its purchase of Orchard. “The ecosystem has definitely spoken in terms of understanding the value of each of these tools,” said David Messina, Docker’s vice president of marketing, in a phone call. “Why people like the model that we have, is that they’re actually three discrete tools, with their own unique aspect of the problem space to be solved around orchestration.” Much of the ongoing criticism of Docker centers on several conceits. It’s too closely tied to its toolset; the project itself is too tightly bound to its owners; networking containers requires a lot of heavy lifting; and container security isn’t what it could be. Docker has set out to address each in turn by providing more detailed documentation of the API set and the client implementation, by restructuring itself to better deal with managing the project, by performing design sprints for networking functionality that include efforts from third-party projects, and by incrementally adding features to make containers more securable. The new tools are meant to be taken in the same vein. By creating individual tools for each “problem space,” as Messina put it, Docker is trying to avoid arousing the sentiment that its tools are too monolithic or dedicated. Software Development