こんにちは！インフラ・SREの世界を駆け抜けてきた先輩エンジニアの私です。
日々のインフラ運用、お疲れ様です。
「コンテナを複数台のサーバーで動かしたい！」と思ったとき、真っ先に頭に浮かぶのは何でしょうか？そう、Kubernetes（K8s）ですよね。業界のデファクトスタンダードであり、求人票でも見かけない日はないほどのバケツ一杯の万能選手です。
しかし、こう思ったことはありませんか？
「いや、うちのシステム、そこまでの規模必要か…？ YAML地獄と複雑な概念（Pod, Service, Ingress, PVC…）に心が折れそうなんだけど……」
わかります。その悩み、痛いほどよく分かります。たった3台の小さな仮想マシンでWebアプリを冗長化したいだけなのに、学習に何ヶ月も費やすのは本末転倒です。
そこで今回ご紹介するのが、隠れた名作、いや、「知る人ぞ知る最強の省エネ・オーケストレータ」こと、Docker Swarmです。
これをマスターすれば、あなたの週末の当番待機は劇的に減り、複雑なマニフェストを書くストレスから解放されますよ。さあ、一緒に扉を開けてみましょう！
—
1. Docker Swarmってなに？（基本概念とアーキテクチャ）
Docker Swarmは、Docker社が公式で提供しているコンテナオーケストレーションツールです。「オーケストレーション」と聞くと難しく聞こえますが、要するに「複数のDockerホストをまとめて、1つの巨大なDockerサーバーのように扱えるようにする仕組み」です。
Kubernetesとの最大の違い：「足し算」か「掛け算」か
よく「KubernetesとDocker Swarmのどちらが良いですか？」と聞かれますが、これは「大型トラック」と「軽トラ」を比べるようなものです。用途が全く違います。
| 比較項目 | Docker Swarm | Kubernetes (K8s) |
| :— | :— | :— |
| 学習コスト | 極めて低い（Dockerの知識の延長でいける） | 非常に高い（独自の概念が多すぎる） |
| セットアップ | `docker swarm init` の1コマンド | 数時間〜数日（K3sなどを使ってもそれなりに大変） |
| リソース消費 | 軽量（コントロールプレーンも省メモリ） | 重い（etcdやAPIサーバー等で常に数十MB〜GBを消費） |
| 向いている規模 | 小〜中規模（数台〜数十台のノード） | 大規模（数百〜数千ノード、マルチクラウド） |
Kubernetesは「数万台のコンテナを、世界中の巨大なインフラでミリ秒単位で制御する」ための宇宙船です。
一方でDocker Swarmは、「普段使い慣れたDockerの延長線上で、最小限の手間で高可用性（HA）を手に入れるための俊敏なスポーツカー」なのです。
Swarmの美しいアーキテクチャ
Docker Swarmの構造は驚くほどシンプルです。役割は大きく分けて2つだけ。
1. Manager（マネージャーノード）: 指令塔。クラスタの状態を管理し、どこでコンテナを動かすかを決定します（可用性を考慮して奇数台、通常は3台構成が基本）。
2. Worker（ワーカーノード）: 実働部隊。マネージャーからの指示を受けてコンテナを実際に動かします。
これらをつなぐ通信はDocker Daemonに標準装備されており、追加の複雑なミドルウェアをインストールする必要は一切ありません。これが「美しさ」の正体です。
—
2. なぜ今、あえてDocker Swarmを選ぶべきなのか？
「時代はKubernetesなのに、今さらSwarm？」と思ったそこのあなた。SREの視点から、あえてSwarmを推す明確な理由が3つあります。
1. 「作ること」より「動かし続けること」に集中できる
インフラエンジニアの仕事は、複雑なYAMLを書くことではありません。ビジネスの価値を止めることなく、安定してアプリケーションを届けることです。Swarmは設定ファイル（Composeファイル）がそのまま使えるため、認知負荷が圧倒的に低いです。
2. エッジコンピューティングや小規模構成での圧倒的強さ
IoTデバイスや、各拠点のオンプレミスサーバーなど、「リソースが限られており、現地に専任のK8sエンジニアがいない」環境において、Swarmの「勝手に動き続け、壊れても勝手に復旧する（自己修復性）」能力は神がかっています。
3. Docker Composeとのシームレスな統合
普段ローカルで使っている `docker-compose.yml` を、そのままプロダクションのクラスタにデプロイできる（`docker stack deploy`）この快感を一度知ると、もう戻れなくなります。
—
3. 最速セットアップ：今すぐ動かすハンズオン
百聞は一見に如かず。実際に手を動かして、2台のノード（今回はローカル環境を想定して1台でも概念は同じですが、マルチホストを前提に解説します）でSwarmクラスタを組み、アプリを動かしてみましょう。
Step 1: マネージャーノードの初期化
まずは、クラスタの頭脳となるマネージャーノードで以下のコマンドを実行します。
マネージャーとして初期化
–advertise-addr には、他のノードから通信できる自身のIPアドレスを指定します
docker swarm init –advertise-addr 192.168.1.10
実行すると、次のような出力が表示されます（この中の `docker swarm join …` のトークンが重要です）。
Swarm initialized: current node (1a2b3c4d) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join \
–token SWMTKN-1-4999d2… \
192.168.1.10:2377
Step 2: ワーカーノードの参加
別のサーバー（ワーカーノード）にログインし、先ほどコピーしたコマンドを実行するだけです。
マネージャーから発行されたjoinコマンドをそのまま実行
docker swarm join –token SWMTKN-1-4999d2… 192.168.1.10:2377
たったこれだけで、クラスタの構築は完了です。マネージャー側で確認してみましょう。
docker node ls
すべてのノードが `Ready` 状態になっていれば成功です！美しすぎて涙が出そうですね。
—
4. 精度高い「HelloWorld」：Stackによる宣言的デプロイ
Docker Swarmの真骨頂である Docker Stack を使って、高可用なWebアプリをデプロイしてみましょう。
今回は、アクセスするたびにコンテナのホスト名を表示してくれる、お馴染みのNginxベースのアプリを3つのレプリカ（冗長化）でデプロイします。
設定ファイルの作成（`docker-compose.yml`）
プロジェクトディレクトリを作り、以下の設定ファイルを記述します。コメントに注目してください。
version: ‘3.8’
services:
web:
image: nginx:alpine
# 冗長化のキモ：3つのコンテナインスタンスをクラスタ全体に分散配置する
deploy:
replicas: 3
restart_policy:
condition: on-failure
update_config:
parallelism: 1
delay: 10s
# ポートフォワーディング：クラスタ内のどのノードの80番にアクセスしても自動ルーティングされる
ports:
- “80:80”
networks:
- webnet
networks:
webnet:
driver: overlay # 複数ホスト間を安全につなぐSwarm標準のオーバーレイネットワーク
デプロイの実行
Kubernetesでいう `kubectl apply` に相当するのが、このコマンドです。
‘my-web-app’ という名前のスタックとしてデプロイ
docker stack deploy -c docker-compose.yml my-web-app
これだけで、裏側で自動的にコンテナが各ノードに分散配置され、ロードバランシングの準備も整います。
動作確認と自己修復性の体感
現在動いているサービスの状態を確認します。
docker service ls
出力結果の `REPLICAS` が `3/3` になっていることを確認してください。
ここで、Docker Swarmの「自己修復性」を体験してみましょう。動いているコンテナの一つを、強制的に破壊（削除）してみます。
現在動いているコンテナのIDを確認
docker ps
1つ強制終了してみる
docker stop
普通ならこれでサービスが縮退しますが、Swarmのマネージャーは「常にレプリカ数は3でなければならない」という状態（Desired State）を監視しています。
数秒後に再度 `docker service ls` を実行してみてください。
docker service ls
REPLICAS は瞬時に ‘3/3’ に戻っているはずです！
マネージャーが自動的に「あ、1つ足りないな。新しいコンテナを別のノードに生やすか」と判断し、自動復旧してくれたのです。これが、私たちがインフラ自動化に求めるロマンであり、実用性です。
—
5. まとめと先輩からのメッセージ
いかがでしたでしょうか？
Docker Swarmは、決して「古い技術」ではありません。「複雑すぎる現代のインフラに対する、洗練されたアンチテーゼ」であり、小〜中規模のシステムや、開発効率を最優先したいチームにとって、今なお最強の選択肢の1つです。
- 学習コストは最小限（Dockerの知識だけでOK）
- 1コマンドでクラスタ構築
- 面倒な設定なしでロードバランスと自己修復を実現
「まずは手堅く、確実にマルチホストでコンテナを動かしたい」
そう感じたなら、迷わずDocker Swarmを選んでみてください。きっと、あなたの毎日のインフラ運用が劇的に楽になりますよ。
それでは、素晴らしいコンテナライフを！質問があれば、いつでもコメント欄でお待ちしています。