Docker: Docker Swarm
最終更新：2026-08-26
単一の Docker インスタンスではトラフィックを捌ききれない——そんなとき Swarm なら 1 台から 3 台へスケールし、ゼロダウンタイムで新バージョンをデプロイできます。
1. 学べること
- Swarm クラスターのアーキテクチャと初期化
- サービスとコンテナの違い
- ローリングアップデートとロールバック戦略
- シークレットと設定管理
- 複数ノードのネットワークルーティング
2. EC 運用者のストーリー
(1) 悩み: 1 台ではトラフィックを捌けない
Charlie の EC サイトのトラフィックが急増し、単一の Docker インスタンスでは処理しきれません——ピーク時には CPU 使用率が 100% に達し、API レスポンスがタイムアウトし、ユーザーからの苦情が殺到しました。複数サーバーへスケールする必要がありますが、3 台のサーバーに手動でコンテナを起動するのは複雑すぎます。
(2) Docker Swarm クラスターによるソリューション
Charlie は 3 ノードの Swarm クラスターを初期化し、API を 5 レプリカにスケールし、ローリングアップデートでゼロダウンタイムの新バージョンデプロイを実現しました。
BASH
# Swarm クラスターを初期化
docker swarm init --advertise-addr 10.0.0.1
# 5 レプリカでサービスをデプロイ
docker service create --replicas 5 --name api -p 8080:80 myapp:v2
# v3 へローリングアップデート
docker service update --image myapp:v3 api
(3) 効果: 単一マシンからクラスターへ、わずか 5 分
3 台のサーバーがクラスターとして結合され、API は 5 レプリカへ自動分散、ゼロダウンタイムでローリングアップデートが実行されました。単一サーバーからクラスターへの移行はわずか 5 分で完了しました。
3. Swarm のアーキテクチャ
(1) ノードロール
graph TB
MGR1["マネージャーノード 1<br/>リーダー"] --- MGR2["マネージャーノード 2<br/>スタンバイ"]
MGR1 --- MGR3["マネージャーノード 3<br/>スタンバイ"]
MGR1 --> WRK1["ワーカーノード 1"]
MGR2 --> WRK2["ワーカーノード 2"]
MGR3 --> WRK3["ワーカーノード 3"]
| ロール | 役割 | 台数 | コンテナ実行 |
|---|---|---|---|
| マネージャー | クラスター管理、スケジューリング、API | 奇数(3 / 5 / 7) | ✅ 任意 |
| ワーカー | タスク実行、コンテナ実行 | 任意 | ✅ 必須 |
(2) サービス vs コンテナ
| 比較項目 | コンテナ | サービス |
|---|---|---|
| 作成方法 | docker run |
docker service create |
| レプリカ数 | 1 | レプリカ数を指定可能 |
| セルフヒーリング | 再起動ポリシーが別途必要 | ✅ レプリカ数を自動維持 |
| 負荷分散 | なし | ✅ ルーティングメッシュ |
| ローリングアップデート | 手動 | ✅ 組み込み |
| ユースケース | 単一マシン開発 | クラスター本番 |
4. Swarm の初期化
▶ サンプル: swarm init で初期化 (難易度: ⭐⭐)
BASH
# マネージャーノードで: Swarm を初期化
docker swarm init --advertise-addr 10.0.0.1
# 出力にワーカー参加用トークンが含まれる
# docker swarm join --token SWMTKN-xxx 10.0.0.1:2377
BASH
# ワーカーノードで: Swarm に参加
docker swarm join --token SWMTKN-xxx 10.0.0.1:2377
# 全ノードを一覧表示
docker node ls
💻 出力:
TEXT
📖 参照専用
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
abc123 * manager1 Ready Active Leader
def456 worker1 Ready Active
ghi789 worker2 Ready Active
5. サービスの管理
▶ サンプル: service create でデプロイ (難易度: ⭐⭐)
BASH
# 3 レプリカのサービスを作成
docker service create \
--name web \
--replicas 3 \
--publish 80:80 \
nginx:1.25-alpine
# サービスを一覧表示
docker service ls
# サービスのタスク(コンテナ)を確認
docker service ps web
▶ サンプル: サービスのスケール (難易度: ⭐⭐)
BASH
# 5 レプリカにスケール
docker service scale web=5
# 確認
docker service ps web
▶ サンプル: service update でローリングアップデート (難易度: ⭐⭐⭐)
BASH
# ローリングアップデート: 一度に 2 コンテナずつ、30 秒間隔で更新
docker service update \
--image nginx:1.26-alpine \
--update-parallelism 2 \
--update-delay 30s \
--update-failure-action rollback \
web
# アップデートの状態を確認
docker service inspect web --format='{{.UpdateStatus.State}}'
(1) ローリングアップデート戦略
| パラメーター | デフォルト | 説明 |
|---|---|---|
--update-parallelism |
1 | 一度にいくつのタスクを更新するか |
--update-delay |
0s | バッチ間の待機時間 |
--update-failure-action |
pause | 失敗時の動作(pause / rollback / continue) |
--update-monitor |
5s | アップデート後の監視時間 |
▶ サンプル: サービスのロールバック (難易度: ⭐⭐)
BASH
# 前バージョンへロールバック
docker service rollback web
6. シークレットと設定管理
▶ サンプル: Docker Secret の作成と利用 (難易度: ⭐⭐⭐)
BASH
# ファイルからシークレットを作成
echo "my_super_secret_password" | docker secret create db_password -
# サービスで利用
docker service create \
--name api \
--secret db_password \
-e DB_PASSWORD_FILE=/run/secrets/db_password \
myapp:1.0
🔒 セキュリティ: シークレットはマネージャーノードの Raft ログに(暗号化されて)保存され、サービスを実行中のワーカーにのみ送信されます。コンテナ内では
/run/secrets/<name> ファイル経由でアクセスし、環境変数には露出しません。**
7. ルーティングメッシュ
(1) ネットワークルーティングの仕組み
Swarm のルーティングメッシュにより、任意のノードの任意のポートが、そのサービスの任意の(現在ノードにいなくても)レプリカへルーティングできます。
graph LR
A["ノード 1<br/>:80"] -->|"リクエスト"| B["ルーティングメッシュ"]
C["ノード 2<br/>:80"] --> B
B -->|"ラウンドロビン"| D["レプリカ 1<br/>ノード 1"]
B --> E["レプリカ 2<br/>ノード 2"]
B --> F["レプリカ 3<br/>ノード 3"]
| パターン | 構文 | 説明 |
|---|---|---|
| VIP(デフォルト) | --publish 80:80 |
仮想 IP + 負荷分散 |
| DNSRR | --endpoint-mode dnsrr |
DNS ラウンドロビン、VIP なし |
8. Swarm と Compose の比較
| 比較項目 | Docker Compose | Docker Swarm |
|---|---|---|
| ノード数 | 単一ノード | マルチノードクラスター |
| 高可用性 | ❌ | ✅ マネージャー冗長化 |
| サービスセルフヒーリング | 再起動ポリシー | ✅ レプリカ数を維持 |
| ローリングアップデート | 手動 | ✅ 組み込み |
| 負荷分散 | Nginx / DNS ラウンドロビン | ✅ ルーティングメッシュ |
| シークレット | 環境変数 | ✅ 暗号化保存 |
| デプロイ方法 | docker compose up |
docker stack deploy |
▶ サンプル: stack deploy で Compose ファイルを Swarm へデプロイ (難易度: ⭐⭐⭐)
BASH
# Compose ファイルをスタックとしてデプロイ
docker stack deploy -c docker-compose.yml mystack
# スタック一覧
docker stack ls
# スタック内のサービス一覧
docker stack services mystack
# スタックを削除
docker stack rm mystack
9. 完全なサンプル: 3 ノードクラスターのデプロイ
BASH
# ============================================
# 完全なウォークスルー: 3 ノード Swarm クラスター
# 内容: init、join、service、scale、update
# ============================================
# --- マネージャー (10.0.0.1) にて ---
# 1. Swarm を初期化
docker swarm init --advertise-addr 10.0.0.1
# 2. ワーカー参加トークンを取得
docker swarm join-token worker
# --- ワーカー (10.0.0.2、10.0.0.3) にて ---
# 3. Swarm に参加(ステップ 2 のトークンを貼る)
docker swarm join --token SWMTKN-xxx 10.0.0.1:2377
# --- マネージャーにて ---
# 4. クラスターを確認
docker node ls
# 5. web サービスを 5 レプリカでデプロイ
docker service create \
--name web \
--replicas 5 \
--publish 80:80 \
--restart-condition on-failure \
nginx:1.25-alpine
# 6. ノード間の分散を確認
docker service ps web
# 7. v1.26 へローリングアップデート
docker service update \
--image nginx:1.26-alpine \
--update-parallelism 2 \
--update-delay 30s \
web
# 8. ノード障害をシミュレート
docker node update --availability drain worker1
docker service ps web # レプリカが再スケジュールされる
# 9. ノードを復旧
docker node update --availability active worker1
# 10. スケールダウン
docker service scale web=2
# 11. クリーンアップ
docker service rm web
docker swarm leave --force # マネージャーにて
❓ よくある質問
Q Swarm に必要な最小サーバー台数は?
A 開発・テスト用途なら 1 台でも動作します。本番環境では 3 台以上のマネージャー(奇数、Raft 合意は多数決を必要とするため)+ N 台のワーカーを推奨します。マネージャーは最低 1 台必須ですが、1 台ではそのマネージャーが落ちた時点でクラスターが管理不能になります。
Q Swarm のデータはどこに保存されますか?
A マネージャーノードの Raft ログ(
/var/lib/docker/swarm/)に保存されます。ここにはクラスターの状態、サービス定義、シークレットなどが含まれます。マネージャーノードが故障した場合、他のマネージャーノードが Raft プロトコルで新リーダーを選出します。Raft ログの定期バックアップを推奨します。Q ルーティングメッシュはどのように負荷分散しますか?
A Swarm の VIP(Virtual IP)モード: 各サービスに仮想 IP が割り当てられます。リクエストが VIP に到達すると、カーネルの IPVS 負荷分散が各レプリカへ分散します。すべてのノードが公開ポートをリッスンするため、任意ノード宛のリクエストを任意ノードのレプリカへルーティングできます。
Q Swarm の TLS を設定するには?
A Swarm には mTLS(相互 TLS)が組み込まれており、ノード間の通信を自動的に暗号化します。証明書は初期化時に自動生成されるため手動設定は不要です。マネージャー間、マネージャーとワーカー間の通信はすべて暗号化されます。
Q Compose から Swarm への移行で必要な変更は?
A ほとんどの
docker-compose.yml はそのまま docker stack deploy で使えます。重要な注意点: ① build を image に置き換える(Swarm は build 非対応); ② volumes は名前付きボリュームと NFS のみサポート; ③ depends_on は started のみ対応(service_healthy は未対応); ④ deploy ブロックを追加して replicas と update 戦略を設定する。📖 まとめ
- Swarm = Docker 組み込みのコンテナオーケストレーション: マネージャーがスケジューリング、ワーカーがコンテナを実行
- コンテナではなくサービス: レプリカ数を指定し自動セルフヒーリング、組み込みの負荷分散
- ローリングアップデート:
--update-parallelism+--update-delayでペースを制御 - ルーティングメッシュ: 任意ノードのポートがサービスの全レプリカへ自動ルーティング
- シークレットの暗号化保存: 環境変数には露出せず、コンテナ内ではファイルから読み取る
docker stack deploy -c compose.ymlで Compose ファイルを Swarm へそのままデプロイ可能
📝 練習問題
- 基本練習 (難易度 ⭐): 単一マシンで Swarm を初期化し、Nginx サービスを 3 レプリカで作成、
docker service psでレプリカの分散を確認してください。 - 応用練習 (難易度 ⭐⭐): ローリングアップデート(nginx: 1.25 → 1.26)を実施し、
docker service psでアップデートの過程を観察してください。 - 挑戦 (難易度: ⭐⭐⭐): 3 台の仮想マシンで Swarm クラスターを構築し、API サービスを 5 レプリカでデプロイ、ワーカーノードの障害をシミュレートして、レプリカが他ノードへ自動移行することを確認してください。
