One of the nifty features of the original \"Docker Swarm\" was that it:
turns a pool of Docker hosts into a single, virtual Docker host
That's a correct interpretation. You will longer manage a Swarm as you have done with a single engine, the commands to manage and schedule in the Swarm are changing. Using docker run
and docker-compose
will target a single host. Using docker service
is needed to schedule on the swarm. The compose is moving to bundles that you docker deploy
and manage with docker stack
. I'd say one huge plus of the new design is not forgetting when you're managing the swarm vs a single node because you didn't check your setting of $DOCKER_HOST
.
Migration has been considered with docker-compose bundle
, and there's nothing preventing you from running the old swarm container implementation on the 1.12 platform and accessing it as you always have. You just won't get the orchestration benefits of the 1.12 Swarm.