Czy jest jakaś wymagana lub oficjalnie wspierana wersja rke2, czy też można użyć najnowszej, czyli teraz v1.33.X?
Na pewno działa 1.28.3
Z punktu widzenia bezpieczeństwa to jest słabe.
podbijam temat, czy ktoś dokonywał aktualizacji rke2 z 1.28 do najnowszej i udało mu się to bez przygód? Mam wrażenie, że prędzej czy później i tak trzeba się będzie z tym zmierzyć.
Z mojego doświadczenia wynika że absolutnie nie należy czegokolwiek aktualizować po stronie Ubuntu na której działa tzw. „instalacja testowa”, czyli rke2 i pozostałe elementy. EZDRP wewnętrznie przywiązane jest do konkretnej wersji rabbitmq i erlanga - po ich aktualizacji za pomocą zwykłego ‘apt dist-upgrade’ nagle wszystko przestaje działać. Nawet taki pozornie neutralny komponent jak redis miał ostatnio problemy z licencją co może skutkować zmianami w nazwach pakietów i konieczność ręcznych ingerencji. Samo RKE2 w nowszej wersji chyba działa dobrze, ale proponowałbym jednak nie ruszać tylko po prostu maksymalnie ograniczyć dostęp do aplikacji tak, aby nikt niepowołany nie miał dostępu do panelu logowania ranchera.
Też się naciąłem na nową wersję Rabbita przy aktualizacji z apt-get. Skończyło się na stawianiu całego Rabbita od nowa 
.
Co nie zmienia faktu, że podejście na zasadzie “działa to działa, nie dotykaj” jest dość krótkowzroczne. Utrzymywanie wersji HA on premise, gdzie jest tyle komponentów i zależności wymaga opracowania przemyślanej strategii aktualizacji, przecież EZD RP jest projektem który ma działać długie lata, a rolowanie długu technologicznego w końcu skończy się małym dramatem.
Podnoszenie rke2 już teraz wymaga robienia tego etapami, tzn. nie można skoczyć bezpośrednio 1.28 → 1.33, a co dopiero będzie za kilka lat?
Dodatkowo, za chwilę wychodzi Ubuntu 26.04, podczas gdy większość pewnie ma oryginalne środowiska stawiane na 22.04, a kwiecień 2027 to już za rok.
Tego tematu nie da się zamieść pod dywan na dłuższą metę.
Zgadza się, chyba że Nask bierze pod uwagę jeszcze wsparcie rozszerzone (ESM/Pro) do kwietnia 2032.
W tym wątku pojawiło się szereg różnych kwestii niezależnych od siebie.
Chciałbym to uporządkować:
- zgodnie z: Instrukcja instalacji EZD RP – środowisko produkcyjne – Podręcznik użytkownika systemu EZD RP obecnie rekomendujemy instalację na Ubuntu 24.04 z RKE2 w wersji v1.34.1. Zmiana naszych rekomendacji musi wiązać się z szeregiem testów aplikacji oraz elementów zależnych.
- obecne wersje Redisa, RabbitMQ, PostgreSQL są określone w ramach instalacji skryptem Ansible i te wersje, dane repozytorium które są w playbookach Ansible są przez NASK rekomendowane; Problem związany z erlang jest związany z zależnością od wykorzystywanego repozytorium z którego RabbitMQ jest aktualizowany;
- każde podniesienie wersji środowiska, komponentu środowiska lub aplikacji powinno wiązać się z wykonaniem kopii bezpieczeństwa, jest to operacyjny standard dla aplikacji działających produkcyjnie;
- przed wykonaniem zmian na środowisku produkcyjnym zalecane jest wykonanie analogicznych prac i operacji na środowisku testowym by zweryfikować działanie środowiska po aktualizacjach komponentów/aplikacji;
- zwracamy uwagę na cykl życia i EOL danych komponentów zewnętrznych, po stronie odpowiednich zespołów są wykonywane odpowiednie analizy, prace i testy które mają weryfikować działanie aplikacji na wyższych wersjach danych komponentów;
Jeszcze do niedawna rekomendowaną wersją było Ubuntu 22.04. Czy w takim przypadku podnosić wersje serwera do 24.04? Da się to zrobić (że w ogóle się da, wiem) bez strat dla EZDRP?
Decyzja o podnoszeniu wersji Ubuntu jest decyzją jednostki. Rekomendacje zostały zmienione z racji cyklu życia Ubuntu 22.04.
Tak jak pisałem:
-
każde podniesienie wersji środowiska, komponentu środowiska lub aplikacji powinno wiązać się z wykonaniem kopii bezpieczeństwa, jest to operacyjny standard dla aplikacji działających produkcyjnie;
-
przed wykonaniem zmian na środowisku produkcyjnym zalecane jest wykonanie analogicznych prac i operacji na środowisku testowym, by zweryfikować działanie środowiska po aktualizacjach komponentów/aplikacji;
Proces podnoszenia wersji Ubuntu bez szkody dla EZD RP jest oczywiście możliwe, rekomendowane jest oczywiście wykonywanie takiego procesu na wyłączonym (wyskalowanym do 0) systemie EZD RP. Czasem są potrzebne zmiany w konfiguracji danego silinika bazodanowego (np. zmiany jakichś parametrów, kwestia erlanga), ale nie jest to zależne od dostawcy aplikacji EZD RP.
Dziękuję za informację. A nie można by gdzieś zapisać tego procesu jako instrukcji? Kiedyś przecież wszyscy będą musieli przejść na wyższe wersje systemów.Nie chodzi mi o instrukcję aktualizacji Ubuntu, tylko o wyłączenie (wyskalowanie do 0) samego EZD, kolejność aktualizacji/włączania tych maszyn po aktualizacji, co zapewne też ma znaczenie.
Skalowanie oparte jest o polecenia kubectl: kubectl scale deployment --all --replicas=0 -n ezd (polecenie dostosowane do namespace: ezd, nazwe należy dostosować do posiadanej na środowisku - nalezy wpisać taki namespace w jakim działa aplikacja EZD RP). Potem wyskalowanie do 1: kubectl scale deployment --all --replicas=1 -n ezd.
Prawidłowość backupowania/wyłączania maszyn:
Master1/Master2/Master3
Baza/Redis/RabbitMQ
NFS
Bez znaczenia jeżeli chodzi o kolejność to Rancher i HAProxy.
Przywracanie/Włączanie maszyn to odwrotna kolejność.
Dziękuję bardzo, Panie Aleksandrze. Najpierw spróbuję na wersji testowej, jak się uda to fajnie. Pozdrawiam serdecznie.