Wersja beta ZimaOS 1.7 zmieniła sposób edytowania adresu URL aplikacji w kafelku: użytkownicy mogli zmieniać protokół, port i ścieżkę, ale nazwa hosta była powiązana z adresem panelu ZimaOS. Nie uniemożliwiało to niezależnego udostępniania niestandardowej domeny przez Nginx Proxy Manager ani lokalny DNS.
Odpowiedź zespołu IceWhale potwierdziła wówczas, że edytowanie nazwy hosta nie było dostępne w edytorze wizualnym, oraz zapowiedziała przywrócenie tej funkcji. Obecna wersja ZimaOS 1.7.1 usprawnia ustawienia portu adresu URL aplikacji Docker i obsługę adresów URL, ale opublikowany dziennik zmian nie informuje wprost o przywróceniu możliwości edytowania dowolnej nazwy hosta w formularzu wizualnym.
Co faktycznie zmieniła wersja beta 1.7
Użytkownik miał konfigurację lokalnego DNS i odwrotnego proxy, na przykład https://app.example.net/. W edytorze wersji beta nie można już było skonfigurować samego kafelka aplikacji tak, aby otwierał tę niestandardową nazwę hosta.
Reprodukcja problemu przez społeczność wykazała, że ręczne ustawienie x-casaos.hostname mogło pozostać w YAML-u, podczas gdy formularz i kafelek aplikacji nadal korzystały z adresu IP panelu. Pracownicy IceWhale potwierdzili następnie, że wizualne pole nazwy hosta było tymczasowo niedostępne.
Odwrotne proxy nadal może korzystać z niestandardowej domeny
Opisane w wątku ograniczenie dotyczyło adresu URL otwieranego przez kafelek aplikacji ZimaOS, a nie tego, czy Nginx Proxy Manager, AdGuard Home lub inny stos DNS i odwrotnego proxy może kierować niestandardową nazwę hosta do opublikowanego portu aplikacji.
Jeśli Twoje proxy już przekierowuje domenę na właściwy adres IP ZimaOS i port aplikacji, zachowaj tę konfigurację proxy niezależnie od ustawień kafelka panelu. Przewodnik po odwrotnym proxy HTTPS w ZimaOS opisuje tę architekturę.
Co potwierdza ZimaOS 1.7.1
Oficjalny dziennik zmian ZimaOS 1.7.1 wymienia bardziej elastyczną konfigurację portu adresu URL oraz ulepszoną obsługę adresów URL Dockera. Nie dokumentuje jednak wprost przywrócenia starego edytora nazwy hosta.
Aktualna dokumentacja metadanych aplikacji ZimaOS opisuje pola port_map, scheme i index używane w adresach URL wejściowych aplikacji. Przed przebudową działającej konfiguracji proxy na podstawie zachowania starszej wersji beta przetestuj aktualny stabilny edytor.
Czy trzeba wrócić z wersji beta do starszej wersji?
W przypadku tego konkretnego problemu rada na forum była taka, aby nie spieszyć się z wycofaniem aktualizacji, ponieważ niestandardowe domeny nadal działały za pośrednictwem odwrotnego proxy. Obecnie najlepszym pierwszym krokiem jest przejście na bieżącą stabilną wersję ZimaOS, wykonanie kopii zapasowej konfiguracji aplikacji i sprawdzenie działania kafelka aplikacji w tej wersji.
Jeśli importujesz plik YAML aplikacji lub naprawiasz jego zawartość, przewodnik po niestandardowym Docker Compose będzie bezpieczniejszym źródłem informacji niż bezpośrednie kopiowanie obejścia problemu z czasów wersji beta.
