Docker Swarm の基礎
Docker Swarm は、Docker にビルトインされているコンテナオーケストレーションツールです。複数の Docker ホストをまたいで、Docker アプリケーションの管理とスケーリングを可能にします。
本章では、Docker Swarm の基本コンセプトやアーキテクチャ、そしてコンテナ化されたアプリケーションのデプロイとスケーリングをいかに簡素化するかを紹介します。Swarm クラスタのキーコンポーネントや、クラスタ内でサービスを管理するための基本的なコマンドについて探求していきます。これにより、後の章で扱うより高度なトピックに向けた確固たる基盤を築くことができます。
1. コンテナオーケストレーションの理解
コンテナオーケストレーション（Container Orchestration）とは、コンテナ化されたアプリケーションの管理、スケジューリング、コーディネーション、そしてスケーリングを自動化することを指します。マシンのクラスタ全体でアプリケーションをデプロイし実行する際の複雑さを処理し、高可用性、フォールトトレランス（耐障害性）、そして効率的なリソースの活用を保証します。
1.1 なぜコンテナオーケストレーションが必要なのか？
コンテナオーケストレーションがなければ、大量のコンテナを管理することは極めて困難になります。数十個のコンテナを複数のサーバーへ手動でデプロイし、スケーリングさせ、ヘルスステータスをモニタリングし、それらが正しくネットワーキングされているか確認する作業を想像してみてください。ここで、Docker Swarm のようなコンテナオーケストレーションツールが真価を発揮します。これらのタスクを自動化することで、インフラストラクチャの管理ではなく、アプリケーションの開発そのものにリソースを集中させることができます。
実際のユースケース：
- ECプラットフォーム： ある E コマース企業では、Web サーバー、データベースサーバー、およびキャッシュサーバーの管理にコンテナオーケストレーションを利用しています。ショッピングのピークシーズンには、急増するトラフィックに対応するため、オーケストレーションツールが自動的に Web サーバーコンテナの数をスケールアウトします。仮に1台のサーバーに障害が発生した場合、ツールは自動的に別の健全なサーバー上でコンテナを再起動させます。
- ストリーミングサービス： ある動画ストリーミング配信企業では、動画のエンコーディングおよび配信インフラの管理にコンテナオーケストレーションを活用しています。優先度やリソースの要件に応じて、オーケストレーションツールが動的に異なるエンコーディングタスクへリソースを割り当てます。また、ストリーミングサーバーのヘルスステータスを常にモニタリングし、障害発生時には自動的に再起動を行います。
想定シナリオ：
あるスタートアップ企業が、マイクロサービスアーキテクチャに基づくアプリケーションを開発しています。各マイクロサービスは個別の Docker コンテナとしてパッケージ化されています。同社はビジネスの急速な成長を見込んでおり、複数のサーバーをまたいでアプリケーションを容易にデプロイ、スケーリング、そして管理できる手法を求めています。コンテナオーケストレーションがない場合、各コンテナを手動で管理しなければならず、時間もかかりヒューマンエラーも発生しやすくなります。コンテナオーケストレーションを導入すれば、アプリケーションの期待される状態（例：レプリカ数、リソース要件など）を定義するだけで、オーケストレーションツールが自動的に期待通りの稼働状態を維持してくれます。
1.2 コンテナオーケストレーションのコアな利点
- 高可用性： 失敗したコンテナを自動的に再起動し、アプリケーションの継続的なオンライン状態を保証します。
- スケーラビリティ（Scalability）： ニーズに応じてアプリケーションのスケールアウト（増強）やスケールイン（縮小）を容易に実行できます。
- リソース最適化： マシンのクラスタ内でコンピューティングリソースを極めて効率的に活用します。
- デプロイの簡素化： デプロイメントのプロセスを自動化し、エラー発生率と複雑さを低減します。
- ローリングアップデート（Rolling Updates）： ゼロダウンタイムでのアプリケーションのアップデートを実現します。
2. Docker Swarm の概要
Docker Swarm は、Docker ネイティブのコンテナオーケストレーションソリューションです。Docker ホストのクラスタを管理し、その上でコンテナ化アプリケーションをデプロイするためのシンプルで使いやすいアプローチを提供します。Swarm は Docker Engine に直接インテグレートされているため、すでに Docker に慣れ親しんでいるユーザーにとっては最も自然な選択肢となります。
2.1 コアコンセプト
- ノード (Nodes)： Swarm クラスタに属する物理マシンまたは仮想マシンを指します。ノードには2つのタイプが存在します：
- マネージャーノード (Manager nodes)： Swarm クラスタ全体の管理を担います。サービスのスケジューリング、クラスタ状態の管理、API リクエストへの応答などのタスクを処理します。
- ワーカーノード (Worker nodes)： マネージャーノードから割り当てられたタスクの実行を担います。アプリケーションを構成する実際のコンテナを実行します。
- サービス (Services)： アプリケーションの期待される状態を定義します。使用するコンテナイメージ、実行するレプリカの数、ネットワーキングのコンフィギュレーション、その他の関連設定を指定します。
- タスク (Tasks)： サービスにおける単一のコンテナインスタンスを指します。サービスを定義すると、Swarm は指定されたレプリカ数に基づいて対応するタスクを作成します。
- ロードバランシング (Load Balancing)： Swarm はビルトインのロードバランシング機能を提供し、サービス内の各タスクへネットワークトラフィックを自動的にルーティング（分散）させます。
3. Swarm アーキテクチャ
Swarm クラスタは、1つ以上のマネージャーノードと、ゼロ個以上のワーカーノードで構成されます。マネージャーノード間ではリーダー（Leader）が選出され、クラスタの状態に関する意思決定を担当します。ワーカーノードは Swarm に参加し、マネージャーノードから割り当てられたタスクを実行します。
マネージャーノードは Raft コンセンサスアルゴリズム を使用してクラスタ状態の一貫性を維持します。これにより、1つまたは複数のマネージャーノードに障害が発生した場合でも、Swarm クラスタが正常に機能し続けることが保証されます。
アーキテクチャ図解：
+-------------------+ +-------------------+ +-------------------+
| マネージャーノード 1 |----| マネージャーノード 2 |----| マネージャーノード 3 |
+-------------------+ +-------------------+ +-------------------+
| | |
| (リーダー) | |
| | |
+-----------------+ +--------------------+ +-------------------+
| ワーカーノード 1 | | ワーカーノード 2 | | ワーカーノード 3 |
+-----------------+ +--------------------+ +-------------------+
| | |
| (タスク1, タスク2) | (タスク3) | (タスク4, タスク5)
| | |
+-----------------------------------------------------------------------+
| ロードバランサー (トラフィックを各タスクに分散) |
+-----------------------------------------------------------------------+上の図は、3つのマネージャーノードと3つのワーカーノードを含む Swarm クラスタを示しています。
- マネージャーノードのうちの1つがリーダー (Leader) として選出されています。
- ワーカーノードはタスク (Tasks)、つまりコンテナのインスタンスを実行する責任を持ちます。
- ロードバランサーが外部からのトラフィックをこれらのタスクに分散させます。
4. Docker Swarm クラスタの構築
より高度なコンセプトへ深く踏み込む前に、まずは Docker Swarm の基本的な構築プロセスを実演してみましょう。これにより、基本コマンドの実践的な経験を得ることができます。この例では、Docker がインストールされたマシンが少なくとも2台必要です。これらは仮想マシン、クラウドサーバー、または Docker Desktop を実行しているローカルマシンのいずれでも構いません（ただし、独立したマシンを使用する方が現実世界の構成に近い形となります）。
4.1 Swarm の初期化（マネージャーノード）
マネージャーノードとして指定したいマシン上で、以下のコマンドを実行します：
docker swarm init --advertise-addr <MANAGER-IP><MANAGER-IP> の部分は、他のノードがこのマネージャーノードに接続するために使用する IP アドレスに置き換えてください。コマンドを実行した後の出力には、ワーカーノードとして Swarm に参加するためのコマンドが含まれています。このコマンドは保存しておいてください。
例：
docker swarm init --advertise-addr 192.168.1.100
# 出力結果：
Swarm が初期化されました：現在のノード (xxxxxxxxxxxxxxxxxxxxxxxx) はマネージャーノードになりました。
この Swarm にワーカーノードを追加するには、以下のコマンドを実行してください：
docker swarm join --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 192.168.1.100:2377
この Swarm にマネージャーノードを追加するには、'docker swarm join-token manager' を実行し、プロンプトの指示に従ってください。4.2 Swarm への参加（ワーカーノード）
ワーカーノードとして指定したい各マシン上で、先ほどマネージャーノードの初期化時に出力された docker swarm join コマンドを実行します。
例：
docker swarm join --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 192.168.1.100:23774.3 クラスタ状態の検証
マネージャーノードに戻り、以下のコマンドを実行して現在 Swarm クラスタに参加しているノードを確認します：
docker node lsこれにより、各ノードの ID、ホスト名 (HOSTNAME)、状態 (STATUS: Ready または Down)、可用性 (AVAILABILITY: Active, Pause, Drain)、そしてマネージャーノードであるかどうかのステータスが含まれたノードリストが出力されます。
出力例：
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
xxxxxxxxxxxxxxxxxxxxxxxx manager1 Ready Active Leader 20.10.7
yyyyyyyyyyyyyyyyyyyyyyyy worker1 Ready Active 20.10.7
zzzzzzzzzzzzzzzzzzzzzzzz worker2 Ready Active 20.10.75. Swarm へのサービスのデプロイ
Swarm クラスタの構築が完了したので、シンプルなサービスをデプロイしてみましょう。例として nginx イメージを使用します。
5.1 サービスの作成
マネージャーノード上で以下のコマンドを実行し、サービスを作成します：
docker service create --name web --publish 80:80 --replicas 3 nginxこのコマンドは web という名前のサービスを作成し、ホストマシンのポート 80 をコンテナのポート 80 へマッピング（パブリッシュ）します。また、nginx コンテナのレプリカを 3つ 実行するように指定しています。
5.2 サービスの検証
以下のコマンドを実行して、Swarm 内で実行中のサービスを確認します：
docker service lsこれにより、サービスの ID、名前、レプリカ数、および使用されているイメージなどのリストが出力されます。
出力例：
ID NAME MODE REPLICAS IMAGE PORTS
xxxxxxxxxxxxxxxx web replicated 3/3 nginx:latest *:80->80/tcp5.3 タスク状態の確認
以下のコマンドを実行すると、web サービスに属する具体的なタスクが現在どこで実行されているかを確認できます：
docker service ps webこれにより、タスクの ID、実行されているノード、期待される状態 (DESIRED STATE)、現在の状態 (CURRENT STATE)、およびエラー情報が含まれたタスクリストが出力されます。
出力例：
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
xxxxxxxxxxxxxxxx web.1 nginx:latest worker1 Running 5分前稼働 (Running)
yyyyyyyyyyyyyyyy web.2 nginx:latest worker2 Running 5分前稼働 (Running)
zzzzzzzzzzzzzzzz web.3 nginx:latest manager1 Running 5分前稼働 (Running)5.4 サービスへのアクセス
Web ブラウザを開き、Swarm クラスタ内の任意のノードの IP アドレスにアクセスしてください。デフォルトの nginx ウェルカムページが表示されるはずです。これは、ビルトインのロードバランサーがトラフィックを各 nginx コンテナに正常にルーティングしていることを証明しています。
6. サービスのスケーリング
Docker Swarm の中核となる強みの一つは、サービスを極めて容易にスケールアウト（拡張）またはスケールイン（縮小）できることです。web サービスを 5つのレプリカへとスケールアウトしてみましょう。
6.1 スケールアウト・スケールイン操作
マネージャーノード上で以下のコマンドを実行します：
docker service scale web=5このコマンドは、web サービスを更新して 5つのレプリカを実行するように Swarm へ指示します。
6.2 スケーリングの検証
再度 docker service ls および docker service ps web コマンドを実行し、サービスが 5つのレプリカへ正常に拡張されたかを検証します。
docker service ls の出力において REPLICAS カラムが 5/5 と表示され、docker service ps web の出力において 5つのタスクが Running (稼働中) 状態になっていることが確認できるはずです。
7. サービスの削除
サービスが不要になった場合は、docker service rm コマンドを使用して削除できます。
7.1 サービスの削除操作
マネージャーノード上で以下のコマンドを実行します：
docker service rm webこのコマンドにより、web サービスが完全に削除されます。
7.2 削除の検証
もう一度 docker service ls コマンドを実行し、該当のサービスがリストから消えていることを検証してください。