Docker Stackは、1つ以上のサービスをまとめて管理・デプロイするための仕組みです。Composeファイル(YAML)でアプリケーションの「あるべき姿」を定義し、それをSwarmクラスタに展開します。
なぜDocker Stackを使うのか?
単一ホスト用の docker-compose とは異なり、StackはSwarm Modeに特化しています。
- 宣言的(Declarative)な管理: 「コンテナを5つ動かしたい」とファイルに書くだけで、Dockerが自動でその状態を維持します。
- 高可用性の確保: 複数のノード(サーバー)にまたがってコンテナを自動配置します。
- ダウンタイムなしの更新: サービスを止めずに1つずつコンテナを入れ替える「ローリングアップデート」が標準機能として備わっています。
Docker Compose と Docker Stack の比較
| 特徴 | Docker Compose | Docker Stack |
| 主な用途 | 開発環境・単一ホスト | 本番環境・マルチホスト(Swarm) |
| デプロイ単位 | プロジェクト単位 | スタック(サービスの集合体) |
| スケーリング | 手動 (--scale) | YAML内でレプリカ数を定義 |
| ネットワーク | ブリッジ / ホスト | オーバーレイ(ノード間通信) |
ハンズオン:Docker StackでWebアプリをデプロイ
ここでは、Nginx(Web)とRedis(DB)を連携させたスタックを、2台以上のSwarmクラスタに展開する手順を体験しましょう。
前提条件
- Dockerオーケストレーション入門(Swarm編) を完了し、Swarmクラスタが構築済みであること。
- Managerノードで操作を行います。
ステップ1:Composeファイル(docker-compose.yml)の作成
Managerノードに my-stack ディレクトリを作成し、その中に以下の内容で docker-compose.yml を作成します。
YAML
version: '3.8'
services:
# Webサーバーサービス
web:
image: nginx:latest
ports:
- "8080:80"
networks:
- app-net
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
restart_policy:
condition: on-failure
# キャッシュ用データベース
db:
image: redis:alpine
networks:
- app-net
deploy:
placement:
constraints:
- "node.role == worker" # Workerノードにのみ配置する制約
networks:
app-net:
driver: overlay
ポイント:
deployセクションがStackの肝です。ここでレプリカ数や配置の制約、アップデートのルールを定義します。
ステップ2:スタックのデプロイ
以下のコマンドを実行して、スタック名 my-web-app としてデプロイを開始します。
Bash
docker stack deploy -c docker-compose.yml my-web-app
ステップ3:稼働状況の確認
デプロイされたサービスがどのノードで動いているか確認します。
Bash
# スタック内のサービス一覧を表示
docker stack services my-web-app
# サービスごとのタスク(コンテナ)配置を表示
docker stack ps my-web-app
複数のノードに、指定したレプリカ数(Nginxが3つ、Redisが1つ)が分散されていれば成功です。
ステップ4:ダウンタイムなしのスケールアウト
トラフィックが増えたと仮定して、Webサーバーを5つに増やしてみましょう。
docker-compose.ymlのreplicas: 3を5に書き換えます。- 同じデプロイコマンドを再実行します。
Bash
docker stack deploy -c docker-compose.yml my-web-app
Dockerは「現在の状態」と「YAMLに書かれた理想の状態」を比較し、不足している2つのコンテナだけを追加します。
ステップ5:後片付け
検証が終わったら、スタックを削除します。ネットワークやボリュームも含め、一括でクリーンアップされます。
Bash
docker stack rm my-web-app
まとめ
Docker Stackを活用することで、複雑なコンテナ構成も「設定ファイルひとつ」で本番環境にデプロイできるようになります。これは Infrastructure as Code (IaC) の実践そのものであり、運用の自動化への第一歩です。
さらに大規模で複雑なオーケストレーションが必要な場合は、業界標準の Kubernetes(k8s)へのステップアップを検討しましょう。
コメントを残す