Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

Yesterday, Docker made a series of announcements on their blog around Docker 1.12. The previously-announced Windows and Mac versions of Docker are now in open beta, and now there's a version for AWS and Azure that is also in beta. The biggest news, however, is around Docker's new orchestration features.

Orchestration

The big news around Docker 1.12 is the introduction of built-in orchestration to the core Docker software. It is now easier to manage containers and hosts across infrastructure by creating and managing swarms of containers through the CLI. According to Docker, their users described the current orchestration landscape as the choice between a home-built solution, or getting tied to a vendor like Amazon, so introducing orchestration to the Docker Engine, rather than forcing users to rely on Docker Swarm's standalone solution, was the best move.

Whether the swarm commands in Docker, combined with Docker Swarm, will overtake tools like Kubernetes and Mesosphere in the market remains to be seen. However, it's clear that Docker's move in avoiding vendor lock-in is to make tools like Kubernetes less necessary when Docker has these kinds of features built-in, even if they aren't as robust. It may not be strict Docker lock-in, but it will likely make other options less tempting until more users can share their experiences.

Distributed Application Bundles

Another tool Docker introduced to make orchestration more effective is their "experimental" format for bundling artifacts needed to deploy multi-container apps, called Distributed Application Bundles (DAB). From Docker's blog:

...a DAB contains a description of all the services required to run the application and details images to use, ports to expose, and the networks used to link services.

DABs aim to make orchestrating the starting and stopping of containers more efficient and make deploying containerized apps easier. A containerized app can be built and tested, run through CI, and then package the artifacts together into one file. Then, ops can deploy just that one .dab file, which doesn't introduce variability in production. No "it worked fine in dev" excuses. :)

Docker has shared some tutorials on these features on their blog and in their documentation: