【ITニュース解説】Docker Engine 29.7's overlay networking breaks every Swarm task without IPv6

Docker Engineの特定のバージョンで、Docker Swarm環境におけるオーバーレイネットワークの動作に深刻な問題が発生していることが報告された。この問題は、特にサーバーがIPv6という次世代のインターネット通信プロトコルをサポートしていない、または無効化している環境で顕著に現れる。システムエンジニアを目指す上で、このようなネットワークの挙動はコンテナ化されたアプリケーションのデプロイと運用において非常に重要なため、この問題とその影響を理解することは必須である。

まず、Docker Engineとは、コンテナと呼ばれる軽量な仮想環境を作成・実行するための基本的なソフトウェアだ。アプリケーションとその動作に必要なすべてのものを「コンテナ」という独立した箱にまとめることで、どこでも同じように動作させられるのが大きなメリットとなる。そして、Docker Swarmは、複数のDocker Engineが稼働するサーバー（ホスト）を一つにまとめ、まるで一つの巨大なコンピューターのように扱えるようにする機能だ。これにより、アプリケーションのコンテナを複数のサーバーに分散配置したり、障害発生時に自動的に別のサーバーで再起動させたりといった高度な管理が可能になる。

このSwarm環境で、複数のサーバーにまたがるコンテナ同士が通信できるようにするために使用されるのが「オーバーレイネットワーク」だ。これは仮想的なネットワークであり、あたかも同じ物理的なネットワークに接続されているかのようにコンテナ間でデータをやり取りすることを可能にする。今回の問題は、まさにこのオーバーレイネットワークが機能しなくなるというものだ。

筆者の検証によると、Docker Engineのバージョン29.6.2では、Swarmのサービスをデプロイし、オーバーレイネットワークを介して複数のレプリカ（同じコンテナの複製）を起動させると、指定した数通りにコンテナが正常に動作し、相互に通信もできた。しかし、バージョン29.7.0以降、そして最新の29.8.2に至るまで、まったく同じコマンドでサービスをデプロイしても、要求したレプリカの数が起動せず、「0/X」という表示になる現象が確認された。つまり、コンテナが一つも起動しないのだ。

この問題が発生した際、docker service psコマンドでタスクの状態を確認すると、「network sandbox join failed: subnet sandbox join failed for "10.0.1.0/24": overlay: cannot determine address family of transport: the local data-plane address is not currently known」というエラーメッセージが表示される。このメッセージの核心は、「cannot determine address family of transport」（トランスポートのアドレスファミリーを判断できない）という部分だ。これは、Docker Engineがオーバーレイネットワーク上で通信を行う際に、それがIPv4を使うべきか、IPv6を使うべきかを判別できない、と訴えていることを意味する。

筆者の環境を詳しく調べたところ、問題が発生したホストにはIPv6のスタック（IPv6を処理するためのソフトウェア基盤）が完全に存在しないことが判明した。古いバージョンである29.6.2では、IPv6がないことを認識しつつも、問題なくIPv4でオーバーレイネットワークを構築して通信できていた。しかし、29.7.0以降のバージョンでは、IPv6がない環境でオーバーレイネットワークに参加しようとすると、アドレスファミリーの判断ができずに処理が停止し、コンテナの起動に失敗するようになったのだ。

この問題は、通常のDockerコンテナの動作や、単一ホスト内でコンテナ同士を接続するブリッジネットワークには影響しない。純粋にDocker Swarmのオーバーレイネットワークに限定された問題である。筆者は、オーバーレイネットワーク作成時に明示的に--ipv6=falseというフラグを指定してIPv6を無効化する試みも行ったが、結果は同じエラーで、解決には至らなかった。

また、この問題の厄介な点は、サービスが起動しない状態が続いても、Docker EngineのCPU使用率が異常に高くなることはないという点だ。コンテナの起動失敗後、Docker Swarmはしばらくリトライを試みるが、数回失敗するとそれ以上は試行せず、「Assigned」という状態で停止してしまう。このため、システム監視ツールでCPUやメモリの使用状況を見ているだけでは、サービスが実は全く動いていないという事態に気づきにくい可能性がある。

この問題に気づくための最も確実な方法は、定期的にdocker service lsコマンドを実行し、デプロイしたサービスの「REPLICAS」欄が「0/X」（要求したX個のレプリカのうち0個しか起動していない）となっていないかを確認することだ。もしデプロイツールが、docker service createコマンドがエラーコード0で終了したことだけを確認している場合、サービスは正常に作成されたと誤解してしまう可能性があるため、必ずレプリカの稼働数まで確認することが重要となる。

この報告から得られる教訓は、IPv6が無効な環境でDocker Swarmを運用している場合、Docker Engineをバージョン29.7.0以降にアップグレードする際には、本番環境に適用する前に必ずテスト環境で十分な動作検証を行う必要があるということだ。特に、docker service lsコマンドでオーバーレイネットワークを使用するサービスのレプリカ数が正常に起動していることを確認することが不可欠となる。これはシステムエンジニアとして、ソフトウェアのアップグレードがもたらす予期せぬ影響を事前に発見し、トラブルを未然に防ぐための重要なプロセスである。