Docker Swarm、Traefikを利用したサーバー管理
はじめに
個人プロジェクトを運営しながら複数のサービスを管理するようになり、そのために毎月発生するAWSの費用がますます負担になってきた。収益がない初期段階では固定費を減らすことが重要だったため、比較的安価なミニサーバー3台を直接購入してセルフホスティング環境を整えることにした。
これまでは単一サーバー上でDocker Composeだけでサービスを構成してきたが、サーバーが複数台になるとCompose方式には明確な限界があった。特にCPUとメモリの使用量を基準にコンテナを手動で配置しなければならず、拡張性や管理面でも非効率だった。
これを解決するために導入したのがDocker Swarmだ。Swarmは複数のサーバーを1つのクラスターのように構成できるようにし、サービス単位で柔軟な展開と拡張をサポートする。ここにTraefikを併用すれば、各サービスごとにNginxの設定を個別に行う必要がなく、HTTPS証明書も自動的に発行・更新されるため、運用負担が大幅に軽減される。
一人で開発し、運用を並行して行う私にとって、Docker SwarmとTraefikは複雑なインフラを簡潔に保つための良い選択肢だった。この記事では実際にどのように構築したか、その過程を整理しようと思う。
ハードウェア構成
ミニサーバーの仕様紹介
今回構築したサーバーはAsrock DeskMini X300ベアボーンをベースに構成されたミニPC3台です。サイズは小さいが、サーバー用として十分な性能を発揮できるため、セルフホスティング環境に適した選択でした。
各サーバーの主な仕様は以下の通りです。
- モデル:Asrock DeskMini X300
- CPU:Ryzen 5600G
- RAM:64GB
- HDD:1TB SSD
- クーラー:[NOCTUA] NH-L9a-AM4(低騒音クーラー)
この構成は個人サービス10〜20個程度をコンテナで実行するには十分な性能を提供し、RAMとSSDの容量が豊富で重いサービスも余裕を持って運用できます。3台を購入しました。24時間家で運用される状況を考慮して低騒音クーラーを購入して取り付けました。(以前に会社でサーバーを運用していた経験が役立ちました。なんて騒々しかったんだろう..)
消費電力も一般デスクトップに比べて少ないため、24時間常にオンになっているホームサーバーとしても適しています
ネットワーク機器の紹介
現在使用しているインターネット回線はKT ギガインターネットであり、KTの特徴の1つはモデムの各LANポートごとに独自のグローバルIPを提供することです。これを活用して、サーバー3台をそれぞれ独立して外部からアクセス可能に構成しました。
ネットワーク機器は以下のようなTP-Link Omadaシリーズで構成されています:
-
ルーター: TP-Link ER605
-
スイッチ: TP-Link TL-SG2210P(2.5Gbps対応、PoE)
-
コントローラー: TP-Link OC200
-
無線AP: TP-Link EAP650(Wi-Fi 6)
これらの機器はすべてOmada SDNシステムで統合管理され、VLAN構成やトラフィックモニタリング、ポート単位の制御が可能な環境を提供します。
サーバー1台
-
KTモデムに直接接続してグローバルIPを割り当て
-
Harbor Dockerレジストリ、DB、ドキュメントシステムなどの固定サービスを運用
サーバー2台
- Docker Swarmでクラスターを構築
- 複数の個人サービスをコンテナ単位で分散運用
この構成により、Harborでイメージを管理しながら、他のサーバーでは柔軟にサービスの展開/拡張/管理を行う構造を完成させました。
最初は3台すべてをクラスターとして構成してすべてのサービスとインフラを統合しようとしましたが、Harborなどの複雑なサービスをDocker Swarm環境で安定して運用するには制約があり、より柔軟な構成を目指して現在のように役割を分離することになりました。
利点
Traefikを使用した簡単なトラフィック管理
Traefikを導入することで、トラフィック管理がはるかに簡単になったことが最も便利でした。従来は各サービスごとにNginx設定を手動で作成し、SSL証明書も手作業で取得する必要がありました。しかしTraefikは次のような機能を自動で処理してくれます:
- Let’s Encryptを通じたHTTPS証明書の自動発行と更新
- docker-compose.ymlのラベル設定だけでドメインの接続、リダイレクト、ポート指定が可能
- デフォルトで提供されるダッシュボードで現在のルーティング状態とサービス状態を視覚的にモニタリング可能
1人の開発者として、設定を繰り返す必要がない点が非常に大きな利点でした。
簡単な拡張
Docker Swarmを使用すると、新しいサービスを展開したり拡張したりする際にはるかに簡単です。新しいワーカーノードをクラスターに登録するだけで、Swarmが自動的にコンテナを利用可能なリソースに応じて分配してくれます。
つまり、「このサービスはこのサーバーで動かすべきだ」と悩む必要はなく、Swarmが自動でコンテナを展開しリソースを分散してくれます。
無停止デプロイ(Rolling Update)
update_config設定を使用して、既存のサービスを停止せずに新しいバージョンに置き換えることができます。Swarmは既存のコンテナを下ろす前に新しいコンテナをまず起動し、正常に動作を確認した後に既存のインスタンスを終了します。
services:
my-app:
image: myapp:v1
deploy:
replicas: 1
update_config:
order: start-first
parallelism: 1
delay: 5s
サーバーが2台以上の場合、新しいコンテナを他のノードに先に配置するため、実際のサービス利用者は全く気づかずにデプロイが行われます。
サービスの分離とロールバック機能
各サービスは独立したコンテナで実行されるため、問題が発生した特定のサービスを迅速に修正したりロールバックしたりすることができます。たとえば、イメージを更新した後に問題が発生した場合は、以下の1行のコマンドで前の状態に戻すことができ、迅速かつ安全な運用が可能です。
docker service rollback my-service
Traefikベースのダイナミックルーティング
TraefikはDockerラベルを基にして自動的にルーティングを構成してくれます。docker-compose.ymlに数行追加するだけで、ドメイン、パス、HTTPS適用まで自動で処理されます。
これは手動設定が多いNginxとは異なり、サービスが追加されたり名前が変わってもルーティング構成を再度手を加える必要がないという点で大きな利点です。
まとめ
一人で開発し、運用を全て担当しなければならない1人開発者にとって最も重要なのは、複雑なインフラをシンプルに保つことだと考えます。
今回Docker SwarmとTraefikを活用してサーバーを構築する際に感じたのは、わざわざ複雑なツールやクラウド環境でなくても自分で十分にうまく動作するインフラを構築できる自信でした。
もちろん最初に構築する際には試行錯誤もあり、特にDocker Swarmに関する実践的な情報が多くなかったために迷った部分もありましたが、直接構築しテストしながら積み重ねた経験はどんなドキュメントよりも強力な基盤となってくれました。
誰かは「わざわざDocker Swarmを使うか」と言うかもしれませんが、開発からデプロイ、運用まで一人でやらなければならない状況では、簡潔さ、自動化、保守性が最大の利点であり武器だと思います。
