Docker Composeで複数コンテナを1台のホストで動かすことに慣れてくると、次に直面するのが「マルチノードでの冗長化」という課題です。Composeはシングルホストの仕組みなので、ホストが落ちれば全サービスが落ちます。複数のサーバーにまたがってコンテナを管理する仕組み——オーケストレーション（orchestration）——が必要になる瞬間です。
この記事では、Dockerに付属するオーケストレーション機能「Docker Swarm」が今も現場で選択肢になりうるかを、Kubernetesとの違いを「冗長化の粒度」「運用負荷」「学習コスト」「撤退容易性」の4軸で整理します。マネージドKubernetesではなく3台規模のオンプレサーバーを前提とした判断基準を示すので、自分の状況に当てはめながら読んでください。動作確認環境はDocker Engine 26.1.3 / Rocky Linux 9.4（manager 1台 + worker 2台）です。
この記事のポイント
・docker swarm initとswarm joinだけで最小クラスターが構成できる
・SwarmはKubernetesより習得コストが低く小規模オンプレに向く
・Kubernetesは本番スケールの運用機能が豊富だが学習・維持コストが高い
・3ノード以下なら撤退容易性の観点でもSwarmが合理的な選択肢になる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Docker Composeの次にくる「マルチノード」の壁
Docker Composeは便利な仕組みですが、その設計は1台のホスト上でコンテナをまとめることを前提にしています。開発環境や検証環境にはまったく問題ありませんが、本番環境で「ホストが落ちてもサービスを続けたい」「負荷が増えた時にコンテナを増やしたい」という要件が出てきたとき、Composeだけでは対応できません。オーケストレーションツールが担う主な役割は以下の3つです。
・スケジューリング：どのノードにコンテナを配置するかを自動で決める
・ヘルスチェックと自己修復：コンテナやノードが落ちたら自動で再起動・再配置する
・スケーリング：レプリカ数を増やしてコンテナを複数ノードに分散する
このオーケストレーターとして現在2強の位置にあるのがDocker SwarmとKubernetesです。Swarmは「Dockerに付属している」「compose.ymlと文法が近い」という理由で使い始めやすく、Kubernetesは「業界標準」「本番機能が豊富」という理由で企業案件で選ばれる傾向があります。
2016年頃はSwarm対Kubernetesの競争が激しかったのですが、現在はKubernetesが事実上の業界標準になっています。ただし「業界標準」と「自分のケースに最適」は別の話です。3ノードのオンプレサーバーでシンプルなWebサービスを動かすだけなら、Swarmは今も有効な選択肢です。
Docker Swarmの仕組み — managerとworkerノードの役割
SwarmはDockerに組み込まれているため、追加インストールが不要です。既存のDockerホストに対してコマンドを1つ叩くだけでクラスターを構成できます。Swarmでは「managerノード」と「workerノード」という2種類の役割があります。・managerノード：クラスターの制御面（コントロールプレーン）を担う。サービスのスケジューリング・ヘルスチェック・ノードの管理を行う。奇数台（1・3・5台）が推奨
・workerノード：実際にコンテナを動かすデータプレーン。managerの指示に従ってサービスを実行する
managerは自分でもコンテナを実行できますが、本番では役割を分けることが多いです。
1. swarm initでクラスターを初期化する
managerにしたいサーバーで以下を実行します。# manager予定のサーバーで実行（sv01: 192.168.1.10） $ docker swarm init --advertise-addr 192.168.1.10 Swarm initialized: current node (9f2xkab7wqna8zpl...) is now a manager. To add a worker to this swarm, run the following command: docker swarm join --token SWMTKN-1-3oom7wb5m9...xqp3k 192.168.1.10:2377 To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
--advertise-addr は他のノードがこのmanagerへ接続するために使うIPアドレスです。サーバーにNICが複数ある場合は必ず指定してください。2. workerノードをjoinさせる
初期化時に表示されたdocker swarm join コマンドを他のサーバーで実行します。# worker予定のサーバーで実行（sv02, sv03） $ docker swarm join --token SWMTKN-1-3oom7wb5m9...xqp3k 192.168.1.10:2377 This node joined a swarm as a worker.
docker node ls で確認します。$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION 9f2xkab7wqna8zpl * sv01 Ready Active Leader 26.1.3 b4mhst6pqkyz3eqr sv02 Ready Active 26.1.3 cxtye8l2rjq9na7m sv03 Ready Active 26.1.3
Ready になっていれば問題ありません。MANAGER STATUS の Leader がクラスター操作を受け付けるノードです。3. docker stack deployでサービスを展開する
SwarmにサービスをデプロイするにはStackという単位を使います。compose.ymlを流用できますが、build セクションは無視されます（事前にビルドしたイメージを使う必要があります）。# compose.yml（Swarm対応版） version: "3.8" services: web: image: nginx:1.27 ports: - "80:80" deploy: replicas: 3 restart_policy: condition: on-failure
$ docker stack deploy -c compose.yml myapp Creating network myapp_default Creating service myapp_web $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS r7kpqzwmnxty myapp_web replicated 3/3 nginx:1.27 *:80->80/tcp
REPLICAS 3/3 は「3レプリカ要求・3レプリカ起動中」を意味します。3台のノードに1つずつ配置されています。4軸で比べる — SwarmとKubernetesの実際
冗長化の粒度
SwarmとKubernetesは、どちらもコンテナの冗長化（レプリカを複数ノードに分散）をサポートしています。違いが出るのは制御の細かさです。Swarmの冗長化は「サービスのレプリカ数を指定するだけ」という割り切った設計です。Swarmが空きノードにコンテナを配置します。細かい配置制御には
placement constraints を使いますが、Kubernetesほど豊富ではありません。Kubernetesはより細かい制御ができます。
・PodDisruptionBudget（PDB）：ローリングアップデート中に最低N個のPodを生かし続ける
・Affinity / Anti-affinity：同一ノードへの集中を防ぐ・特定ノードに寄せるなどの詳細ルール
・Taints & Tolerations：特定のワークロードだけ特定ノードで動かす排他制御
数ノード規模でシンプルに「1コンテナずつ3台に分散」というレベルであれば、SwarmのシンプルなAPIで十分です。ゾーン分散や優先順位付きスケジューリングが必要になってくるとKubernetesの機能が生きてきます。
運用負荷
Swarmの大きな利点は「コントロールプレーンをDockerが面倒みてくれる」点です。etcdのような外部データストアは不要で、raftアルゴリズムでmanagerノード間の状態が自動同期されます。Kubernetesをオンプレで運用するには、コントロールプレーン（kube-apiserver・etcd・kube-scheduler・kube-controller-manager）の管理が加わります。kubeadmを使えばセットアップは自動化できますが、etcdのバックアップ・証明書の更新・バージョンアップが別途必要です。
3ノードのオンプレ環境でKubernetesのコントロールプレーンを自力で運用するのは、アプリケーションの冗長化よりインフラ管理の比重が大きくなりやすいです。AWSのEKSやGKEのようなマネージドKubernetesを使えばこの負荷は大幅に下がりますが、オンプレ前提では選択肢から外れます。
学習コスト
Swarmの学習コストが低い理由は「compose.ymlの延長で書けること」と「コマンドセットが小さいこと」です。docker swarm・docker stack・docker service の3グループを押さえれば日常運用はほぼカバーできます。Kubernetesは習得すべき概念が多いです。Pod・ReplicaSet・Deployment・Service・Ingress・ConfigMap・Secret・Namespace・PersistentVolume......これらを理解してyamlで記述する必要があります。
kubectl の操作に慣れるだけでも一定の時間がかかります。一方、チームが将来Kubernetesを使う見込みがあるならSwarmで時間を使うのはもったいない、という考え方もあります。Kubernetesの知識はクラウドプロバイダーを問わず移植性があり、求人市場での価値も高いです。
撤退容易性
「もしやめたくなった時にどれくらい簡単か」という観点です。Swarmからの撤退はシンプルです。
docker swarm leave --force でクラスターを解散すれば、各サーバーはただのDockerホストに戻ります。compose.ymlはそのまま流用できます。# Swarmからの撤退（全managerで実行） $ docker swarm leave --force Node left the swarm.
どちらを選ぶか — 規模と運用体制で決まる
比較をまとめると、「規模が小さく・チームが小さく・K8sの知見がない」ならSwarmが合理的です。逆に「スケールアウトの余地があり・チームにK8s経験者がいる・マネージドK8sが使える」ならKubernetesを選ぶほうが長期的なコストが下がります。特にオンプレサーバー3台という条件では、SwarmはKubernetesよりも「インフラ管理に使うCPU・メモリ・人的コスト」が小さく、同じサーバーリソースをアプリケーションに集中させやすいというメリットがあります。
1つ整理しておくと、Swarmは「開発が止まった」わけではありません。Docker EngineにSwarm機能は同梱され続けており、docker stack deployで動くサービスは今も本番で使われています。ただしKubernetesほどエコシステム（監視ツール・CI/CDとの統合・コミュニティ事例）が広くない点は事実です。
Swarmトラブルシュート：よく詰まる3つのポイントと対処
1. managerが1台だけだとクラスター操作が止まる
managerが1台の構成では、managerが落ちるとクラスター全体の操作（サービスのスケールや更新）ができなくなります。workerは動き続けますが、新しいスケジューリングができません。注意：本番環境でmanagerを1台のまま運用することは危険です。managerが落ちると新規サービスのデプロイやスケーリングが一切できなくなります。
対処：本番ではmanagerを3台以上（奇数）にしてquorumを維持してください。3台managerならば1台が落ちても残り2台でクラスター操作が続けられます。
2. buildセクションがstack deployで無視される
compose.ymlのbuild: セクションはSwarmでは無視されます。Swarmはイメージレジストリからpullする設計のため、先にイメージをビルドしてDocker HubやプライベートレジストリにpushしてからStackをデプロイする必要があります。# 正しい手順 $ docker build -t myapp:1.0 . $ docker tag myapp:1.0 registry.example.com/myapp:1.0 $ docker push registry.example.com/myapp:1.0 $ docker stack deploy -c compose.yml myapp
3. swarm join後にworkerがReadyにならない
ファイアウォールの設定が原因の場合がほとんどです。SwarmはTCP 2377（クラスター管理）・TCP/UDP 7946（ノード間通信）・UDP 4789（overlay network）の3ポートを使います。# Rocky Linux 9 の場合（firewalld） $ firewall-cmd --add-port=2377/tcp --permanent $ firewall-cmd --add-port=7946/tcp --permanent $ firewall-cmd --add-port=7946/udp --permanent $ firewall-cmd --add-port=4789/udp --permanent $ firewall-cmd --reload # ポート開放確認 $ firewall-cmd --list-ports 2377/tcp 7946/tcp 7946/udp 4789/udp
本記事のまとめ
SwarmとKubernetesの違いを4軸でまとめます。| 比較軸 | Docker Swarm | Kubernetes（オンプレ） |
|---|---|---|
| 冗長化の粒度 | シンプルなレプリカ分散 | 細かいスケジューリング制御が可能 |
| 運用負荷 | 低（Dockerに組み込み・外部DBなし） | 高（etcd・コントロールプレーン管理が別途必要） |
| 学習コスト | 低（compose.ymlの延長で書ける） | 高（多数のリソース概念・kubectlの習得が必要） |
| 撤退容易性 | 高（docker swarm leaveで元に戻る） | 中（Workload定義の書き直しが必要） |
| 推奨規模 | 3～10ノード・シンプル要件のオンプレ | スケールアウトが見込める・マネージドK8s利用可の場合 |
| 業界標準度 | 低下傾向（開発・同梱は継続中） | 事実上の業界標準 |
どちらのツールも「コンテナを複数ホストで動かす」という問題を解くものです。自分の環境のノード数・チームの技術スタック・運用体制を基準にして判断してください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、DockerやKubernetesを含むコンテナ運用スキルをまとめて学べるDocker実践講座（docker.linuxmaster.jp）をご覧ください。現役エンジニアが現場目線で教えるDockerの基礎から本番運用まで、ハンズオン形式で学べます。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Docker Swarmのボリューム設計｜localドライバがノードをまたげない理由と共有ストレージの選び方
- この記事の属するカテゴリ：Dockerへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます