Dzień dobry,
Mam problem z zainstalowaniem środowiska testowego w wersji 26.106.11.
Z nieznanych przyczyn nie może uruchomić się pod “cloudadmin”, który nie generuje żadnych błędów w logach. Zatrzymuje się on na “EZD_NOWE_LOGOWANIE_KUIP_WEB”, po czym uruchamia ponownie. Mogę jedynie powiedzieć, że nie uruchamia się również pod “filerepo-api” wyświetlając komunikat “One or more errors occurred. (Connection refused (cloudadmin:2000))”
Na ten moment próbowałem:
-
Upewnić się że maszyna na której jest aplikacja ma połączenie z bazą danych i NFS
-
Zainstalować poprzednie wersje: wersja 21.15.13 uruchamia się, ale baza jest niekompatybilna
-
Z wersji 21.15.13 po kolei aktualizować do nowszych: od 21.18.7 ten sam błąd pojawia się ponownie
-
Zbudować całe środowisko od nowa (maszyny wirtualne, rke2, rancher)
-
Zwiększyć wartości “readinessdealy” oraz “livenessdelay” dla poda “cloudadmin” (zgodnie z sugestią w innym wątku)
-
Dodać do sekretów registry - git.eadministracja.nask.pl (zgodnie z sugestią w innym wątku)
-
Upewnić się, że serwer DNS poprawnie przekierowuje zapytania na odpowiednie serwisy
W każdym przypadku instalacja kończy się niepowodzeniem i komunikatem “context deadline exceeded”
“context deadline exceeded” to tylko niezakończenie procesu instalacji/aktualizacji w standardowe 10 minut.
Do szerszej analizy na forum potrzebny byłby szerszy kawałek logów dla stanu instalacji czy weryfikacja ustawionych Feauture Flags w YAMLu
Standardowo w Environment Variables EZD_NOWE_LOGOWANIE_KUIP_WEB jest na off tak jak u Pana. Wykonywałem testy instalacyjne wersji 26.106.11 i nie spotkałem takiego problemu.
Jest Pan pewien, że w Rancher wykonał Pan wszystkie kroki zgodnie z instrukcją? Nic dodatkowo nie włączył/wyłączył itp. itd?
Cała instalacja przebiegła zgodnie z instrukcją.
Wydarzyła się jednak ciekawa sytuacja: Po utworzeniu w Proxmox snapshot’a maszyny na której znajduje się aplikacja, cloudadmin uruchomił się poprawnie a za nim reszta podów. W ramach testu z zakładce Deployments dałem “Redeploy” cloudadmina i problem powrócił. Tym razem ponowne utworzenie snapshota nie rozwiązało problemu.
Sugeruje to, że rozwiązaniem jest tymczasowe zatrzymanie poda w odpowiednim momencie czasu?
Teraz jestem w sytuacji, gdzie każdy pod jest uruchomiony z wyjątkiem cloudadmina, który ponownie zatrzymuje swój status na Crashloopbackoff.
Sugeruje to, że rozwiązaniem jest tymczasowe zatrzymanie poda w odpowiednim momencie czasu?
Tak, zablokowanie na pewien czas cloudadmin’a spowodowało że się uruchomił. Co pozwoliło na wykonanie kroków z instrukcji “Zarządzanie podmiotami w EZD RP i KUiP z poziomu administratora”
Logi poda “cloudadmin”:
Pytanie jednak czy nie spowoduje to niestabilności systemu w przyszłości?
Obawiam się, że może powodować to niestabilność systemu, a opisana sytuacja jest niestandardowa.
