Docker swarm create与docker swarm init命令的差异及权衡参数咨询

Great question! These two commands come from entirely different Docker Swarm implementations, so their use cases, capabilities, and support status are night and day. Let’s break down the key tradeoffs and differences:

1. Core Implementation & Version Compatibility #

• docker run swarm create: This belongs to the standalone SwarmKit, a separate, containerized tool that predates Docker’s native clustering. It only works with Docker versions before 1.12 (released in 2016). After that, Docker folded Swarm functionality directly into the daemon.
• docker swarm init: This is the built-in Docker Swarm Mode, introduced in Docker 1.12+. It’s native to the Docker daemon—no extra containers required to manage the cluster.

2. Cluster Setup & Discovery #

• Standalone Swarm (docker run swarm create):
  • You’d first spin up a Swarm manager container to generate a cluster token, then use that token to join workers/other managers with docker run swarm join.
  • Relied on external discovery services (like Consul, etcd, or Docker Hub’s hosted tool) to track cluster nodes, adding extra complexity to setup.
  • Used a separate swarm CLI for cluster operations, not the standard Docker commands you know.
• Swarm Mode (docker swarm init):
  • Running this command turns the current node into a swarm manager, and it automatically generates secure join tokens for workers and additional managers.
  • Uses an internal raft-based distributed store to maintain cluster state—no external tools needed. This makes setup far simpler and the cluster more resilient.
  • All cluster management uses native Docker commands (e.g., docker service create, docker node ls), so you don’t have to learn a new toolset.

3. Feature Set & Capabilities #

• Standalone Swarm:
  • Offers basic service orchestration but lacks modern essentials: no built-in service load balancing, no rolling updates with rollbacks, no secret management, and no default encrypted overlay networks.
  • High availability for managers required manual setup of the external discovery service, which was error-prone.
• Swarm Mode:
  • Full-featured orchestration: rolling updates, automated rollbacks, easy service scaling, and built-in DNS load balancing for services.
  • Security-first design: auto-generated TLS certificates for node communication, secret management for sensitive data, and encrypted overlay networks by default.
  • Out-of-the-box high availability: support for up to 7 manager nodes, ensuring the cluster stays operational even if multiple managers fail.

4. Deprecation & Support #

• docker run swarm create: The standalone Swarm project is officially deprecated and no longer maintained. You won’t get bug fixes, security patches, or new features, and it’s incompatible with modern Docker releases.
• docker swarm init: This is Docker’s actively supported, recommended way to set up a swarm cluster. While Kubernetes has become the dominant orchestration tool, Swarm Mode is still fully supported for simpler, lightweight use cases.

5. Ideal Use Cases #

• Standalone Swarm: Only makes sense if you’re stuck on a legacy Docker version (pre-1.12) and can’t upgrade. There’s zero reason to use it for new clusters today.
• Swarm Mode: Perfect for small-to-medium clusters where you want a simple, integrated orchestration solution that fits seamlessly into your existing Docker workflow. It’s quicker to set up than Kubernetes for basic orchestration needs.

内容的提问来源于stack exchange，提问作者Manish Kumar