Docker Swarm modeの基本設定｜クラスタ作成からservice・stackのデプロイ、更新とロールバックまで

Docker Swarm modeは、Docker Engineに組み込まれているクラスタ機能です。追加のソフトを入れずに、複数台のサーバーをまとめてコンテナを配置し、台数の維持、ローリング更新、ロールバック、シークレット管理を行えます。この記事では、docker swarm init でクラスタを作り、ノードを参加させ、docker service と docker stack deploy でアプリを動かすまでの基本設定と、WordPressを複数台で動かすときに詰まりやすい点を説明します。

Swarm modeは（2026年10月現在）Docker Engineに含まれており、引き続き使えます。ただし、周辺ツールや情報量はKubernetesのほうが多いため、小〜中規模で「Composeの延長で冗長化したい」場合に向いた選択肢と考えてください。

構成の考え方：マネージャーとワーカー

Swarmのノードには2つの役割があります。

• マネージャー：クラスタの状態を管理し、どのノードで何を動かすかを決める。マネージャーもコンテナを動かせる。
• ワーカー：マネージャーの指示でコンテナ（タスク）を動かす。

マネージャーはRaftという合意アルゴリズムで状態を共有するため、台数は奇数にします。3台なら1台、5台なら2台まで故障しても動き続けます。マネージャーが2台だと、1台止まっただけで過半数を失い、クラスタの管理操作ができなくなります。検証なら1台、本番の冗長構成なら3台のマネージャーが目安です。

事前に開けておくポート

ノード間で次の通信を許可します。ファイアウォールやクラウドのセキュリティグループで、クラスタ内のノード同士にだけ開け、インターネットには公開しません。

• TCP 2377：クラスタ管理（マネージャーへの参加・通信）
• TCP / UDP 7946：ノード間の通信
• UDP 4789：オーバーレイネットワークのデータ通信

クラスタを作る

1台目のサーバーでSwarmを初期化します。--advertise-addr には、他のノードから届くプライベートIPを指定します。

docker swarm init --advertise-addr 10.0.0.11

成功すると、ワーカーを参加させるためのコマンドが表示されます。あとから確認するときは次のとおりです。

docker swarm join-token worker
docker swarm join-token manager

2台目以降では、表示されたコマンドを実行して参加させます。

docker swarm join --token SWMTKN-1-xxxx 10.0.0.11:2377

参加用トークンはクラスタに入るための鍵なので、チャットやリポジトリに貼らないようにします。漏れた可能性があるときは docker swarm join-token --rotate worker で作り直せます。

マネージャーで状態を確認します。

docker node ls

MANAGER STATUS 欄に Leader と表示されるのが現在の主マネージャーです。ワーカーをマネージャーに昇格させるには docker node promote <ノード名> を使います。

serviceを動かす

Swarmでは、コンテナを直接起動する代わりに「サービス」を定義し、望ましい状態（イメージ、レプリカ数、公開ポート）をマネージャーに伝えます。

docker service create --name web --replicas 3 -p 8080:80 nginx:stable
docker service ls
docker service ps web

ノードが1台止まると、マネージャーが他のノードで不足分のタスクを起動し、レプリカ数を3に保ちます。

-p 8080:80 で公開したポートは、ルーティングメッシュという仕組みにより、どのノードのIPの8080番に来た通信も、いずれかのタスクに振り分けられます。そのため、前段のロードバランサーには全ノードを登録できます。

台数の変更は次のように行います。

docker service scale web=5

ローリング更新とロールバック

イメージを更新するときは、一度に入れ替える数と間隔を指定できます。

docker service update \
  --image nginx:stable-alpine \
  --update-parallelism 1 \
  --update-delay 10s \
  web

docker service rollback web

1つずつ入れ替えることで、全停止せずに更新できます。更新後に問題があれば rollback で直前の定義に戻せます。イメージにヘルスチェックを定義しておくと、起動に失敗したタスクを検出しやすくなります。

Composeファイルからstackとしてデプロイする

複数のサービスをまとめて扱うには、Composeファイルを docker stack deploy で読み込みます。Swarm固有の設定は deploy キーに書きます。

services:
  wordpress:
    image: wordpress:php8.3-apache
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_NAME: wp
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    ports:
      - "8080:80"
    deploy:
      replicas: 2
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure

  db:
    image: mariadb:11
    environment:
      MARIADB_DATABASE: wp
      MARIADB_USER: wp
      MARIADB_PASSWORD_FILE: /run/secrets/db_password
      MARIADB_RANDOM_ROOT_PASSWORD: "1"
    secrets:
      - db_password
    volumes:
      - db_data:/var/lib/mysql
    deploy:
      placement:
        constraints:
          - node.labels.role == db

secrets:
  db_password:
    external: true

volumes:
  db_data:

# パスワードは標準入力から登録（コマンド履歴に残さない）
openssl rand -base64 24 | docker secret create db_password -
docker node update --label-add role=db <DB用ノード名>
docker stack deploy -c compose.yaml wp
docker stack services wp

Composeとの違いで注意する点は次のとおりです。

• build は使えません。イメージは事前にビルドし、全ノードから取得できるレジストリに置きます。
• シークレットはタスクの中で /run/secrets/<名前> にファイルとして置かれます。公式のWordPressやMariaDBのイメージは、_FILE で終わる環境変数でファイルからパスワードを読めます（対応する変数は各イメージの説明で確認してください）。
• stack deploy は .env の自動読み込みなど、docker compose と挙動が異なる部分があります。デプロイ前に docker stack config -c compose.yaml で展開結果を確認できます（使えるかはDockerのバージョンによります）。

WordPressを複数台で動かすときの注意

Swarmでレプリカを増やすと、WordPressは別々のノードで動きます。ここで問題になるのが状態を持つデータです。

• データベース：ボリュームは各ノードのローカルに作られるため、DBのタスクが別ノードで起動すると空のデータベースになります。上の例のように配置制約で特定ノードに固定するか、マネージドのデータベースを使います。
• アップロード画像：wp-content/uploads がノードごとに分かれ、片方でアップロードした画像がもう片方では見えません。NFSなどの共有ストレージを使うか、メディアをオブジェクトストレージに置くプラグインを検討します。
• セッション・キャッシュ：ログイン状態は主にCookieで保たれますが、オブジェクトキャッシュを使う場合はRedisなど共有のキャッシュにします。

この3点を決めないままレプリカを増やすと、表示が不安定になる原因になります。構成変更の前にはデータベースとファイルのバックアップを取り、検証用のクラスタで試してから本番に反映してください。

運用で覚えておくコマンド

# メンテナンス前にノードからタスクを退避させる
docker node update --availability drain node2
docker node update --availability active node2

# マネージャーの鍵を暗号化して保護する（ロック解除キーは安全に保管）
docker swarm update --autolock=true

Swarmの状態はマネージャーの /var/lib/docker/swarm に保存されています。バックアップする場合は、Dockerを止めてからこのディレクトリを保存するのが基本です。autolockを有効にした場合、Dockerの再起動後に docker swarm unlock でキーを入力しないとマネージャーが動かないため、キーをなくすと復旧が難しくなります。

まとめ

• Swarm modeはDocker Engine内蔵のクラスタ機能。マネージャーは奇数台（本番は3台が目安）にする。
• ノード間でTCP 2377、TCP/UDP 7946、UDP 4789を許可し、外部には公開しない。
• docker service でレプリカ数・ローリング更新・ロールバックを扱い、複数サービスは docker stack deploy でまとめる。
• stackでは build が使えないので、イメージはレジストリに置く。パスワードは docker secret と _FILE 変数で渡す。
• WordPressを複数台にするなら、DBの配置、アップロード画像の共有、キャッシュの置き場所を先に決める。

• Docker Composeでのオーバーレイネットワーク
• Kubernetesの基本概念