【入門編】Docker Swarmの「スタック(Stack)」と「Composeファイル」完全ガイド:実務で使える記述の極意 – インフラ構成管理(IaC)活用バイブル

こんにちは!インフラエンジニアの先輩です。

今回は、Dockerのオーケストレーション機能の一つである「Docker Swarm」のスタック(Stack)とComposeファイルについて、現場で即座に使える実践的なノウハウをたっぷりとお伝えします。

「Kubernetes(K8s)はちょっとオーバースペックだけど、複数のコンテナを安全に、かつ簡単にクラスタ管理したい……」そんな現場で、Docker Swarmは今でも最強の選択肢の一つとして現役でバリバリ活躍しています。

これをマスターすれば、複雑なマルチコンテナの本番環境デプロイが驚くほどシンプルに、そして美しく自動化できるようになりますよ。一緒にその極意を紐解いていきましょう!

—

1. なぜ「Docker Swarm スタック」なのか?

Dockerを使った開発では、おなじみの `docker-compose.yml` を使ってローカル環境を立ち上げることが多いですよね。
しかし、それをそのまま本番の複数台サーバー(クラスタ)環境に持っていこうとすると、こんな壁にぶつかります。

  • 「どのコンテナをどのサーバーで動かすべきか手動で管理できない」
  • 「コンテナが落ちたときに、自動で別のサーバーで再起動(自己修復)させたい」
  • 「ロードバランシングやスケールアウトをスマートに行いたい」

ここで登場するのが Docker Swarm です。そして、Swarm環境に対して `docker-compose.yml`(バージョン3形式)をそのまま流し込んで、複数のコンテナ群をひとまとめの「スタック(Stack)」として一括管理できる仕組みが Swarmスタック です。

通常の `docker-compose up` が「単体のマシンのため」のものであるならば、Swarmスタックは「クラスタ全体を統括する魔法の呪文」だと思ってください。

—

2. 開発環境の準備:Swarmの初期化(Hello Worldへの第一歩)

まずは、手元のDocker環境をSwarmモードに切り替えるところから始めましょう。
実は、Dockerがインストールされていれば、特別な追加ツールのインストールは一切不要です。ここがSwarmの素晴らしいところ。

ターミナルを開き、以下のコマンドを叩くだけで、あなたのマシーンがSwarmの「マネージャー(司令塔)」になります。

Docker Swarmの初期化(ローカルのIPを指定する場合は –advertise-addr を使います)
docker swarm init

実行成功すると、以下のようなメッセージが表示されます。

Swarm initialized: current node (abc123xyz…) is now a manager.

To add a worker to this swarm, run the following command:
docker swarm join –token SWMTKN-1-xxxxxxxx 192.168.x.x:2377

おめでとうございます!これであなたのマシンは立派なSwarmクラスタになりました。
(※今回は学習用なので1台のマネージャーノードだけで「シングルノード・クラスタ」として動かしますが、複数台ある場合は上記の `docker swarm join` コマンドでワーカーノードを追加していきます)

—

3. 実践!Swarm対応Composeファイルの書き方(極意と構文ルール)

それでは、Swarmスタックの心臓部である `docker-compose.yml` を書いていきましょう。
Swarmでスタックをデプロイする場合、Composeファイルのバージョンは `version: “3”` 形式(またはそれ以降)を使用します。

ここに、実運用でそのまま使えるWeb&データベース構成のサンプルを用意しました。コード内のコメントをじっくり読んでみてください。

version: “3.8”

services:
# Webアプリケーション層
web:
image: nginx:alpine
# 【極意1】デプロイの設定(Swarm特有のディレクティブ)
deploy:
mode: replicated
replicas: 3 # 常に3つのコンテナをクラスタ内に維持する(ロードバランスされる)
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
resources:
limits:
cpus: ‘0.50’
memory: 512M
ports:

  • “80:80”

networks:

  • webnet

# 【極意2】ローリングアップデートの設定
update_config:
parallelism: 1
delay: 10s

# データベース層(永続化の例)
db:
image: postgres:15-alpine
deploy:
mode: replicated
replicas: 1 # DBは通常1つのインスタンスで動かす
placement:
constraints:

  • node.role == manager # マネージャーノードだけに配置する制約

environment:
POSTGRES_DB: myapp
POSTGRES_USER: user
POSTGRES_PASSWORD_FILE: /run/secrets/db_password # セキュリティを考慮した秘密情報管理
volumes:

  • db-data:/var/lib/postgresql/data

networks:

  • webnet

secrets:

  • db_password

【極意3】複数ホスト間で安全に通信するためのオーバーレイネットワーク
networks:
webnet:
driver: overlay

【極意4】データを安全に保持するボリューム
volumes:
db-data:

【極意5】機密情報の安全な管理(Docker Secrets)
secrets:
db_password:
external: true # 事前に docker secret create で作成したものを使う

押さえておくべき「5つの極意」

1. `deploy` セクションの活用:
通常の `docker-compose up` では無視される `deploy` キーこそが、Swarmスタックの主役です。ここでレプリカ数(コンテナの数)や再起動ポリシーを宣言的に定義します。
2. `replicas: 3` による自動負荷分散:
「3つにしておきなさい」と書くだけで、Swarmが自動的にコンテナを監視し、常に3つ稼働するように保ちます。ユーザーからのアクセスは、Dockerの内蔵ルーティングメッシュによって、これら3つのコンテナに自動で分散(ロードバランシング)されます。
3. `driver: overlay` ネットワーク:
複数台の異なる物理サーバー(またはVM)にまたがってコンテナを配置する場合でも、`overlay` ネットワークを使えば、まるで同じマシン上にあるかのようにコンテナ同士が安全に通信できます。
4. 配置制約(Placement Constraints):
`node.role == manager` のように書くことで、「このコンテナは必ず特定の能力を持つノードに配置する」といった制御が可能です。
5. Docker Secrets の活用:
データベースのパスワードなどを平文で環境変数に書くのはセキュリティのご法度。Swarmには強力な Secret 管理機構が標準備蓄されています。

—

4. デプロイと動作確認:スタックを打ち上げる

ファイルができあがったら、いよいよSwarmクラスタへデプロイ(スタックの立ち上げ)を行います。
コマンド一発で、先ほど定義した世界が構築されます。

スタックのデプロイ(スタック名: mystack, ファイル指定: -c)
docker stack deploy -c docker-compose.yml mystack

たったこれだけです!
それでは、本当に意図した通りに動いているか、以下のコマンドで確認してみましょう。

デプロイされたスタックの一覧確認
docker stack ls

スタック内で動いているサービスの一覧確認
docker stack services mystack

各コンテナ(タスク)の稼働状況を詳細に確認
docker stack ps mystack

`docker stack ps mystack` を実行すると、3つの `web` コンテナと1つの `db` コンテナが、どのノードで、どんな状態(Running)で動いているかが一覧表示されます。感動の瞬間です。

—

5. 運用を楽にする実戦テクニック

① スケールアウトはコマンドで一瞬

アクセスが急増して、「Webサーバーを急遽5台に増やしたい!」となった時も、Composeファイルを書き換える必要はありません。以下のコマンドで即座に反映(スケール)できます。

docker service scale mystack_web=5

これだけで、Swarmが瞬時に残り2台のコンテナを追加し、ロードバランスの輪に加えてくれます。

② スタックの削除とクリーンアップ

検証が終わったら、スタックごと綺麗にリソースを削除するのも簡単です。

docker stack rm mystack

これだけで、紐づくサービスやネットワークが安全に片付けられます(※ボリュームなどの永続データは保護されます)。

—

おわりに

いかがでしたでしょうか?
Docker SwarmのスタックとComposeファイルを使えば、複雑なマルチコンテナ環境の構築・スケーリング・運用管理が、驚くほど「宣言的」かつ「エレガント」に行えるようになります。

Kubernetesを学ぶ前のステップとしても、あるいは中小規模の本番環境を堅牢に運用するメインのツールとしても、Swarmはあなたの強い味方になってくれます。

「これをマスターすれば、毎日のデプロイ作業が劇的に楽になりますよ!」
ぜひ今日の開発環境や検証サーバーで試してみてくださいね。それでは、快適なインフラライフを!

タイトルとURLをコピーしました