永続的なTailscaleコンテナは、ZimaOSの再起動やアプリの編集後も、Tailscale管理コンソール上で同じマシンとして表示されるはずです。2025年9月の元スレッドでは、Composeファイルにすでにマウント設定があったにもかかわらず、そうなっていませんでした。再起動や再デプロイのたびに、別のTailscaleノードが作成されていました。 /var/lib/tailscale 永続的なZimaOS AppDataへ。
最終的な回答は、原因を絞り込むうえで重要です。元の投稿者は永続ストレージがすでに正しく設定されており、継続的に指定されていた認証キーの環境変数を削除することだけが必要だったと述べています。その後、TailscaleのノードIDは保持されました。
Tailscaleには永続的なマシン状態が必要です
Tailscaleは、状態ディレクトリ内にノードID、キー、接続状態を保存します。Dockerでは、一般的に次の設定でパスを構成します。
TS_STATE_DIR=/var/lib/tailscaleこのディレクトリが使い捨てのコンテナファイルシステム内にしか存在しない場合、コンテナを再作成すると新しいTailscale IDが生成されます。
元の構成では状態ディレクトリがすでにマウントされていました
元のComposeファイルには次の設定が含まれていました。
/DATA/AppData/tailscale:/var/lib/tailscaleならびに TS_STATE_DIR=/var/lib/tailscale、ホストネットワーク、 NET_ADMIN, NET_RAW、および /dev/net/tun。理論上は、これで状態が保持されるはずです。
認証キーは登録用であり、必ずしも再起動のたびに必要なものではありません
Composeファイルには次の設定も含まれていました。 TS_AUTHKEY コンテナを起動するたびに。コミュニティの回答者は、既存のノード状態が期待どおりに再利用されない場合、再認証によって新しいマシンが作成される可能性があると説明しました。
回答者は、最初の起動時に再利用可能な非エフェメラル認証キーを使用し、管理コンソールにノードが表示されるまで待ってから、認証キーの行を削除して再デプロイする方法を提案しました。これにより、保存されたマシン状態がIDの情報源になります。
元の投稿者は、認証キーを削除することで問題が解決したことを確認しました
最終的な回答では、他の永続化設定はすでに整っており、削除が必要だったのは認証キーの環境変数だけだったと述べられています。その後、マシン名は再起動後も保持されました。
この確認は、権限についての一般的な推測よりも確かなものです。この構成では、認証が繰り返されることが実際のトリガーでした。
現在のTailscaleはTS_AUTH_ONCEを提供しています
最新のTailscale Dockerデプロイでは、次の設定を使用できます。 TS_AUTH_ONCE=true。永続状態がすでに存在する場合、コンテナの起動時に毎回再ログインを強制しないようにします。
2025年のComposeファイルを変更せずに再利用する前に、現在のTailscale Dockerの状態および認証パラメーターを確認してください。
状態用に専用のホストフォルダーを使用する
Tailscale AppDataや状態フォルダーなどの専用ホストディレクトリを使うと、再デプロイ後もマシンキーが保持されることを確認しやすくなります。元の回答者は、Tailscaleの状態を保存するプロセスがそのフォルダーに書き込めることも確認するよう推奨していました。
ボリュームを正しくマウントしても、プロセスがそのファイルを更新できない場合があるため、権限が重要です。その場合、Tailscaleは再利用可能な状態がマシンにないかのように動作することがあります。
永続的なサーバーではエフェメラル認証キーを避ける
Tailscaleは、一時的に使用するエフェメラルノードをサポートしています。短時間のCIジョブや使い捨てコンテナには便利ですが、永続的なZimaOSサーバーに必要なものとは正反対です。
認証情報を作成するときは、意図したライフサイクルに合っていることを確認してください。永続的なホームサーバーでは通常、意図的に失効または置き換えるまで同じIDを保持する必要があります。
TS_HOSTNAMEはマシンIDを定義しない
元のコンテナでは TS_HOSTNAME=zimaos。この設定はtailnetに表示される分かりやすい名前を制御しますが、同じホスト名文字列を保持しても、暗号学的なマシンIDは保持されません。新たに認証された2台のマシンが似た名前を使おうとしても、それらは別々のノードのままです。
再起動とアプリの再デプロイの両方をテストする
元の問題は、OS全体の再起動後とZimaOSアプリの編集後の両方で発生しました。したがって、正しい修正は次の両方に耐えられる必要があります。
- Tailscaleコンテナを再起動する。
- 状態ボリュームを変更せずにアプリを編集して再デプロイする。
- ZimaOSを再起動する。
- Tailscale管理コンソールで、同じマシンがオンラインのままであることを確認します。
これらの操作のいずれか1つだけの後に重複が現れる場合は、その特定のライフサイクル操作中に状態ディレクトリで何が起きているかを比較してください。
Tailscaleの永続化に関するFAQ
なぜ再起動するたびに新しいTailscaleマシンが作成されたのですか？
元のケースでは、状態ボリュームはすでに存在しており、認証キーの繰り返し使用が残された実際的な問題でした。
どのパスを永続化する必要がありますか？
で設定されるパス TS_STATE_DIR一般的には /var/lib/tailscale コンテナ内。
TS_AUTHKEYは環境変数に永久に残しておくべきですか？
必ずしもそうではありません。元のケースでは、登録後にこれを削除することで重複ノードを解消しており、現在のTailscaleにも次の機能があります TS_AUTH_ONCE.
TS_HOSTNAMEはノードのIDを保持しますか？
いいえ。IDを保持するのは、保存されたTailscaleのマシン状態です。
