Stały kontener Tailscale powinien pozostać tą samą maszyną w konsoli administracyjnej Tailscale po ponownym uruchomieniu ZimaOS lub edycji aplikacji. W wątku źródłowym z września 2025 roku tak się jednak nie działo: przy każdym ponownym uruchomieniu lub ponownym wdrożeniu tworzony był kolejny węzeł Tailscale, mimo że plik Compose już montował /var/lib/tailscale do trwałego katalogu AppData w ZimaOS.
Końcowy wynik źródłowy jest istotny, ponieważ zawęża przyczynę. Autor wpisu stwierdził, że pamięć trwała była już prawidłowo skonfigurowana; jedyną zmianą, której potrzebował, było usunięcie stale dostarczanej zmiennej środowiskowej z kluczem uwierzytelniającym. Od tego momentu tożsamość węzła Tailscale była zachowywana.
Tailscale potrzebuje trwałego stanu maszyny
Tailscale przechowuje tożsamość węzła, klucze i stan połączenia w swoim katalogu stanu. W Dockerze ścieżkę zazwyczaj konfiguruje się za pomocą:
TS_STATE_DIR=/var/lib/tailscaleJeśli ten katalog istnieje wyłącznie w efemerycznym systemie plików kontenera, ponowne utworzenie kontenera tworzy nową tożsamość Tailscale.
Źródło już montowało katalog stanu
Oryginalny plik Compose zawierał:
/DATA/AppData/tailscale:/var/lib/tailscalewraz z TS_STATE_DIR=/var/lib/tailscale, sieć hosta, NET_ADMIN, NET_RAW, a także dostęp do /dev/net/tun. Teoretycznie powinno to zachowywać stan.
Klucz uwierzytelniający służy do rejestracji, niekoniecznie do każdego ponownego uruchomienia
Plik Compose dostarczał również TS_AUTHKEY przy każdym uruchomieniu kontenera. Osoba odpowiadająca ze społeczności wyjaśniła, że ponowne uwierzytelnianie może utworzyć nową maszynę, gdy istniejący stan węzła nie jest ponownie wykorzystywany zgodnie z oczekiwaniami.
Osoba odpowiadająca zasugerowała użycie przy pierwszym uruchomieniu wielokrotnego użytku, nieefemerycznego klucza uwierzytelniającego, odczekanie, aż węzeł pojawi się w konsoli administracyjnej, a następnie usunięcie wiersza z kluczem uwierzytelniającym i ponowne wdrożenie, aby zapisany stan maszyny stał się źródłem jej tożsamości.
Autor wpisu potwierdził, że usunięcie klucza uwierzytelniającego rozwiązało problem
Końcowa odpowiedź źródłowa stwierdza, że pozostałe elementy zapewniające trwałość były już skonfigurowane i wystarczyło usunąć zmienną środowiskową z kluczem uwierzytelniającym. Nazwa maszyny zaczęła wtedy zachowywać się po ponownym uruchomieniu.
To potwierdzenie jest mocniejsze niż ogólne przypuszczenie dotyczące uprawnień. W przypadku tej konkretnej instalacji powtarzające się uwierzytelnianie było praktyczną przyczyną problemu.
Obecnie Tailscale udostępnia TS_AUTH_ONCE
Nowoczesne wdrożenia Tailscale w Dockerze mogą korzystać z TS_AUTH_ONCE=true. Gdy trwały stan już istnieje, informuje to kontener, aby nie wymuszał ponownego logowania przy każdym uruchomieniu.
Przed ponownym użyciem niezmienionego pliku Compose z 2025 roku zapoznaj się z aktualnymi parametrami stanu Tailscale i uwierzytelniania w Dockerze.
Użyj dedykowanego folderu na hoście do przechowywania stanu
Dedykowany katalog na hoście, taki jak folder AppData/stanu Tailscale, ułatwia sprawdzenie, czy klucze maszyny przetrwają ponowne wdrożenie. Autor odpowiedzi ze źródła zalecił również upewnienie się, że folder jest zapisywalny przez proces przechowujący stan Tailscale.
Uprawnienia mają znaczenie, ponieważ wolumin może być prawidłowo zamontowany, a proces nadal może nie mieć możliwości aktualizowania jego plików. W takiej sytuacji Tailscale może zachowywać się tak, jakby maszyna nie miała stanu możliwego do ponownego użycia.
Unikaj efemerycznych kluczy uwierzytelniających na stałym serwerze
Tailscale obsługuje węzły efemeryczne, które są celowo tymczasowe. Jest to przydatne w przypadku krótkotrwałych zadań CI lub jednorazowych kontenerów, ale jest przeciwieństwem tego, czego potrzebuje stały serwer ZimaOS.
Podczas tworzenia poświadczenia sprawdź, czy odpowiada ono zamierzonemu cyklowi życia. Trwały serwer domowy powinien zwykle zachowywać tę samą tożsamość, dopóki celowo jej nie unieważnisz lub nie zastąpisz.
TS_HOSTNAME NIE OKREŚLA TOŻSAMOŚCI MASZYNY
Kontener ze źródła używał TS_HOSTNAME=zimaos. To ustawienie określa przyjazną nazwę prezentowaną w tailnecie, ale zachowanie tego samego ciągu nazwy hosta nie zachowuje kryptograficznej tożsamości maszyny. Dwie nowo uwierzytelnione maszyny mogą próbować używać podobnych nazw, a mimo to nadal pozostawać oddzielnymi węzłami.
Przetestuj ponowne uruchomienie i ponowne wdrożenie aplikacji
Pierwotny problem występował zarówno po pełnym ponownym uruchomieniu systemu operacyjnego, jak i po edycji aplikacji ZimaOS. Dlatego prawidłowe rozwiązanie powinno przetrwać oba:
- uruchom ponownie kontener Tailscale;
- edytuj i ponownie wdroż aplikację bez zmieniania woluminu stanu;
- ponownie uruchom ZimaOS;
- sprawdź w konsoli administracyjnej Tailscale, czy ta sama maszyna pozostaje online.
Jeśli duplikat pojawia się po tylko jednym z tych zdarzeń, porównaj, co dzieje się z katalogiem stanu podczas tej konkretnej operacji cyklu życia.
Najczęstsze pytania dotyczące trwałości stanu Tailscale
Dlaczego po każdym ponownym uruchomieniu tworzona była nowa maszyna Tailscale?
W opisanym przypadku wolumin ze stanem już istniał, a wielokrotne używanie klucza uwierzytelniającego było pozostałym praktycznym problemem.
Która ścieżka musi być trwała?
Ścieżka skonfigurowana przez TS_STATE_DIR, zazwyczaj /var/lib/tailscale wewnątrz kontenera.
Czy TS_AUTHKEY powinien na zawsze pozostać w środowisku?
Niekoniecznie. Użytkownik ze źródła usunął ten parametr po uwierzytelnieniu, aby naprawić problem z duplikatami węzłów, a obecny Tailscale również zapewnia TS_AUTH_ONCE.
Czy TS_HOSTNAME zachowuje tożsamość węzła?
Nie. To zapisany stan maszyny Tailscale zachowuje jej tożsamość.
