Docker Swarm（ドッカースウォーム）は、Docker社が開発したコンテナクラスタリングおよびオーケストレーション機能です。2014年12月のDockerCon Europeでソロモン・ハイクスが初期版を発表し、2016年6月のDocker Engine 1.12でSwarm modeとしてDocker本体に統合されました。「dockerコマンドだけでクラスタが組める」というシンプルさを売りに、当時急成長していたGoogleのKubernetesと真っ向から競合しましたが、2017年以降のKubernetes一強体制の確立により実質的な敗北に終わり、現在はメンテナンスモードでひっそりと生き延びる立場となっています。
この記事の目次
- シンプル・統合・mTLSの三本柱
- 登場から事実上の敗北まで
- 現在のSwarmの典型的な立ち位置
- Kubernetesとの比較
- まとめ
シンプル・統合・mTLSの三本柱
Docker Swarmの設計哲学はとにかく「簡単さ」でした。クラスタ構築はdocker swarm initをマネージャノードで実行し、出力されたトークンを使って各ワーカーノードでdocker swarm joinを打つだけで完了します。Kubernetesがkubeadm・etcd・CNIなど複数のコンポーネントを設定する必要があったのに対し、Swarmは「Docker Engineを入れる＝Swarmが使える」状態を最初から実現していました。サービスのデプロイもdocker service create、docker stack deployといった既存のdockerコマンド延長で扱えます。
セキュリティ面では、ノード間通信が自動的にmTLS（相互TLS）で暗号化されるのが大きな特徴でした。Swarmはクラスタ初期化時にPKIをセットアップし、各ノードに証明書を配布、定期的にローテーションする仕組みを内蔵していたため、Kubernetes初期のように「TLS設定で詰まる」現象がほぼ起きませんでした。オーバーレイネットワーク、サービスディスカバリ、ロードバランシング、ヘルスチェック、ローリングアップデートといった機能も標準装備で、「小規模ならSwarmで十分」という評価は2010年代後半まで根強く残っていました。
登場から事実上の敗北まで
Docker Swarmの歴史は、コンテナオーケストレーション戦争の歴史でもあります。Dockerが2014年12月にSwarm v1を発表したとき、競合は同年6月にGoogleが公開したKubernetesと、Mesos+Marathonの組み合わせでした。2016年6月のDocker 1.12でSwarm modeとして再設計され、Docker Engineに完全統合された当時、多くの観測筋は「DockerはSwarmで勝ち切る」と見ていました。しかし2017年に入るとKubernetesがCNCFの旗艦プロジェクトとして勢いを増し、Red Hat OpenShift、Google GKE、Microsoft AKSなど大手クラウドが続々とKubernetesベースのマネージドサービスを開始しました。
2017年10月、DockerCon EuropeでDocker社はDocker Enterprise Edition上でKubernetesを正式サポートすると発表し、事実上の白旗となりました。Swarmは依然としてDocker Engineの一部として残されましたが、新機能の開発は緩やかになり、企業ユーザーはKubernetesへ続々と移行しました。2019年11月、Docker社はエンタープライズ事業をMirantisに売却し、2020年からはMirantisがDocker Swarmのメンテナンスを継続する体制となりました。Mirantisは「Swarmは引き続きサポートする」と公約しつつも、戦略の中心はKubernetesに移り、現在は限定的なバグ修正中心の保守体制が続いています。
現在のSwarmの典型的な立ち位置
Swarmは敗北したとはいえ、消滅したわけではありません。「Kubernetesほどの複雑さは要らないが、複数ホストにまたがるコンテナ管理は欲しい」というニッチには今も適しています。例えばVPSを3台借りて、WordPressサイト一式とPostgreSQL、Redisを冗長配置したい場合、docker stack deploy -c docker-compose.yaml mystackの一行で本番投入できる手軽さは、Kubernetesでは得難いものです。
Composeファイルとの高い互換性も健在で、ローカル開発で使ったdocker-compose.yamlをほぼそのままSwarmへデプロイできます。中小企業の社内ツール、レガシーアプリのコンテナ化、教育用クラスタなどの用途では、未だにSwarmが現役で動いているケースが少なくありません。ただし、新規プロジェクトでSwarmを選ぶ判断は慎重に行うべきです。コミュニティの活発度、求人需要、ドキュメント整備、エコシステムの広がりを考えると、Kubernetes（特にk3sやk0sといった軽量ディストリビューション）を選ぶ方が将来性は高い、というのが2025年時点の一般的な見方です。
Kubernetesとの比較
Swarmとkubernetesは設計思想からして対照的でした。Swarmはdockerコマンド体系をそのまま延長し、最低限の概念で運用できることを優先しました。Kubernetesは抽象度を上げ、Pod・Service・Deployment・StatefulSet・DaemonSet・Job・CronJob・Ingressなど多層の概念を導入する代わりに、大規模・複雑な要求にも応えられる柔軟性を獲得しました。結果として、シンプルさはSwarm、拡張性はKubernetes、という対比が成立しています。
しかし市場の選択は明確で、CNCF Cloud Native Survey 2023ではコンテナオーケストレーションのうちKubernetesが約96%を占め、Swarmは10%未満（複数回答）の存在感に留まりました。クラウド事業者のマネージドサービス、CI/CDツール、モニタリングプラットフォーム、書籍・チュートリアル、求人需要、いずれを取ってもKubernetes中心の世界となっています。Docker Swarmは「シンプルなオーケストレーターの理想形」を示しつつも、エコシステム戦争に敗れた歴史的事例として、コンテナ時代を語る上で欠かせない存在となりました。
まとめ
Docker Swarmは2014年にDocker社が発表し、2016年にEngineへ統合した純正クラスタリング機能です。Kubernetesとの競合に敗れ、2019年のMirantis買収以降はメンテナンスモードで運用されています。シンプルさと既存Docker資産の流用性は今も魅力ですが、新規採用ではKubernetesベースの選択肢が主流であり、コンテナオーケストレーション戦争の象徴的な敗者として記憶されるツールです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント