Aktualizacja platformy
Dokument opisuje przejście działającej instalacji na nowsze wydanie platformy testto. Procedurę wykonujesz samodzielnie, ze stacji wdrożeniowej - tej samej, z której przeprowadzono instalację.
Aktualizacja obejmuje także system operacyjny
Ten sam przebieg, który podmienia usługi platformy, aktualizuje pakiety systemu Rocky Linux i restartuje serwer (sekcja 6). Zaplanuj okno serwisowe.
Procedura Aktualizacja systemu operacyjnego służy do zaktualizowania samego systemu, bez zmiany wersji platformy.
Przejście na nową linię wydań? Sprawdź paczkę migracyjną
Gdy linia, na którą przechodzisz, ma w Historii wydań przypisaną paczkę migracyjną, użyj jej zamiast tej strony - patrz Paczka migracyjna.
Wydanie aplikacyjne? Jest szybsza droga
Gdy Historia wydań podaje przy wydaniu klasę aplikacyjne, wystarczy podmiana samych obrazów usług - bez aktualizacji systemu i bez restartu serwera, w kilka minut. Patrz Aktualizacja obrazów aplikacji.
Taka aktualizacja nie wymaga żadnych zmian w konfiguracji: nie przenosisz katalogu
inventories/, nie uzupełniasz nowych pól i nie pobierasz nowej paczki instalacyjnej.
Jedyne, co podajesz, to numer wydania.
Ta strona opisuje pełny przebieg, wymagany przy wydaniach infrastrukturalnych oraz wtedy, gdy chcesz przy okazji zaktualizować system operacyjny.
1. Kiedy pojawia się nowe wydanie
O nowym wydaniu informuje zespół Testto. Serwer aplikacyjny nigdy nie sprawdza dostępności aktualizacji samodzielnie i nie nawiązuje w tym celu żadnych połączeń - w instalacji odciętej od internetu byłoby to zresztą niemożliwe.
Każde opublikowane wydanie jest przeznaczone do wdrożenia. Zakres zmian, klasę wydania - która wyznacza procedurę - oraz paczki do pobrania podaje Historia wydań.
2. Sprawdzenie zainstalowanej wersji
Zanim cokolwiek zrobisz, ustal, z jakiej wersji startujesz. Wersję niosą znaczniki obrazów uruchomionych usług:
ssh uzytkownik@<adres-serwera> \
"docker service ls --format '{{.Name}}\t{{.Image}}' | grep dashboard"
W odpowiedzi, po dwukropku, zobaczysz numer wydania - na przykład
quay.io/testto/dashboard:1.8.4. Ten sam numer widnieje w Historii wydań,
dzięki czemu widzisz, ile wydań dzieli Cię od bieżącego.
Pełny przegląd wersji wszystkich usług
ssh uzytkownik@<adres-serwera> \
"docker service ls --format '{{.Name}}\t{{.Image}}\t{{.Replicas}}'"
3. Przygotowanie
3.1. Pobranie nowej paczki
Nową paczkę pobierzesz z Historii wydań. Hasło do archiwum jest to samo, co przy instalacji - patrz Dostęp do skryptów.
3.2. Przeniesienie konfiguracji
Katalog inventories/ przenosisz ze starej paczki - nie uzupełniasz od nowa
Nowa paczka zawiera inventories/klient/ z wartościami DO_UZUPELNIENIA i nowo
wygenerowanymi hasłami. Użycie ich zamiast Twoich obecnych rozjedzie konfigurację
z tym, co faktycznie stoi na serwerze - usługi nie zalogują się do bazy danych ani do
magazynu sekretów.
Rozpakuj nową paczkę obok starej i przenieś katalog konfiguracji:
# w katalogu nowej paczki; <stara-paczka> to katalog poprzedniej instalacji
rm -rf inventories/klient
cp -a ../<stara-paczka>/inventories/klient inventories/
Przenosi się cały katalog, wraz z podkatalogiem ssl/ (certyfikat TLS, certyfikat CA
proxy) oraz plikiem z hasłami.
Zrób kopię przed przeniesieniem
tar czf ~/testto-inventories-$(date +%Y%m%d).tar.gz \
-C ../<stara-paczka> inventories
3.3. Nowe pola konfiguracji
Wydanie może wprowadzić nowe pola. Po przeniesieniu katalogu sprawdź, czego brakuje:
diff <(grep -o '^[a-z_]*:' inventories/klient/group_vars/all/all.yml | sort -u) \
<(unzip -p ../<nowa-paczka>.zip '*/all.yml' \
| grep -o '^[a-z_]*:' | sort -u)
Pola wymagane, których brakuje, zgłosi też playbook sprawdzający z sekcji 5. Zakres nowych pól każdego wydania podaje Historia wydań.
3.4. Środowisko Ansible
Wydanie może podnieść wymagania wobec kolekcji Ansible. Zainstaluj je z nowej paczki:
~/.venvs/ansible-testto/bin/ansible-galaxy collection install \
-r collections/requirements.yml --upgrade
Stacja wdrożeniowa za proxy
Zmienne proxy trzeba ustawić ponownie w bieżącej powłoce, zanim uruchomisz powyższe polecenie - patrz Instalacja za proxy, sekcja 2.
4. Backup przed aktualizacją
Wykonaj oba zabezpieczenia
- Snapshot maszyny w panelu dostawcy infrastruktury - przywraca cały dysk i jest jedyną ścieżką powrotu przy nieudanej migracji struktury danych. Patrz Snapshot i zasady bezpieczeństwa.
- Backup aplikacyjny - bazy danych, magazyn plików, magazyn sekretów i konfiguracja usług. Patrz Backup.
Upewnij się, że archiwum backupu zostało pobrane na lokalny dysk, a nie leży wyłącznie na serwerze.
Backup nie wykona się sam
Playbook instalacyjny nie robi kopii zapasowej przed wdrożeniem. Oba zabezpieczenia wykonujesz ręcznie, przed uruchomieniem aktualizacji.
5. Sprawdzenie konfiguracji
Playbook sprawdzający weryfikuje kompletność konfiguracji, niczego nie zmieniając na serwerze:
~/.venvs/ansible-testto/bin/ansible-playbook preflight.yml
Kontroluje to samo co przy instalacji: pozostawione znaczniki DO_UZUPELNIENIA, spójność
ustawień certyfikatu, otwieralność pliku .p12, osiągalność proxy i zewnętrznej bazy
danych, ważność licencji oraz zakres wdrażanych usług.
Zgodność wersji sprawdzasz sam
Playbook nie porównuje wersji zainstalowanej z wersją w paczce. Przed uruchomieniem aktualizacji upewnij się, że numer odczytany w sekcji 2 jest starszy od wydania, które wgrywasz - instalator nie powstrzyma Cię przed cofnięciem wersji.
6. Uruchomienie aktualizacji
Aktualizację wykonuje ten sam playbook, co instalację - uruchomiony ponownie, z nową paczką i Twoją dotychczasową konfiguracją. Role wykrywają, co jest już na serwerze, pobierają obrazy w wersjach z nowego wydania i wdrażają usługi na nowo.
~/.venvs/ansible-testto/bin/ansible-playbook testto.yml
Jeżeli plik z hasłami jest zaszyfrowany, dołóż --ask-vault-pass.
Playbook aktualizuje system operacyjny i restartuje serwer
Przebieg wykonuje dnf update wszystkich pakietów systemu, a następnie
restartuje maszynę i czeka na jej powrót. Dotyczy to każdego uruchomienia
playbooka, także aktualizacji. Zaplanuj okno serwisowe - orientacyjnie od
kilkunastu minut do godziny, zależnie od liczby zaległych pakietów.
Z tego samego powodu aktualizacja platformy obejmuje przy okazji aktualizację systemu operacyjnego. Osobna procedura Aktualizacja systemu operacyjnego przydaje się wtedy, gdy chcesz zaktualizować sam system, bez zmiany wersji platformy.
Zalecany jest przebieg próbny przed właściwym - pokazuje, co się zmieni, niczego nie zmieniając:
~/.venvs/ansible-testto/bin/ansible-playbook testto.yml --check --diff
Przerwa w pracy platformy
Usługi są podmieniane kolejno, więc krótkie przerwy w dostępności są normalne. Do tego dochodzi restart serwera, w trakcie którego platforma jest niedostępna w całości.
7. Weryfikacja po aktualizacji
Wersja i stan usług - wszystkie z pełną liczbą replik i nowym znacznikiem wersji:
ssh uzytkownik@<adres-serwera> \
"docker service ls --format '{{.Name}}\t{{.Image}}\t{{.Replicas}}'"
Usługi platformy powinny mieć znacznik odpowiadający wydaniu, które właśnie wgrałeś.
Usługa poczty wstaje wolniej
Stack mail-relay potrzebuje około 3 minut na przejście kontroli stanu - przejściowe
0/1 zaraz po aktualizacji nie jest błędem.
Aplikacja - zaloguj się do https://dashboard.<domena> i uruchom jeden znany scenariusz
lub automatyzację, żeby potwierdzić, że działa cała ścieżka: panel, broker i aplikacja
wykonawcza robota.
8. Powrót do poprzedniego stanu
Gdy aktualizacja nie powiedzie się albo platforma nie działa poprawnie:
| Sytuacja | Działanie |
|---|---|
| usługi nie wstają, dane nietknięte | Restore z backupu aplikacyjnego wykonanego przed aktualizacją |
| migracja struktury danych przebiegła częściowo | przywróć snapshot maszyny w panelu dostawcy - restore aplikacyjny nie cofnie zmian struktury |
| nie masz pewności, co się stało | przywróć snapshot i powiadom zespół Testto, dołączając wyjście playbooka |
Restore przywraca również wersję z archiwum
Backup zawiera konfigurację usług z momentu jego wykonania, więc restore cofa instalację do wersji sprzed aktualizacji. Po restore sprawdź znaczniki obrazów poleceniem z sekcji 2 - jeśli nie odpowiadają wersji wyjściowej, powiadom zespół Testto przed kolejną próbą.
9. Gdy dzieli Cię kilka wydań
Nie trzeba przechodzić wydań pojedynczo - playbook wdraża docelowy stan niezależnie od tego, z jakiej wersji startujesz.
Przy większym przeskoku uzgodnij termin z zespołem Testto
Niektóre wydania wnoszą zmiany, których samo ponowne wdrożenie usług nie wykona - na przykład migrację struktury danych albo zmianę sposobu uwierzytelniania. Takie przypadki opisują strony wydań, do których prowadzi Historia wydań.
Jeżeli dzieli Cię więcej niż jedno wydanie, skontaktuj się z zespołem Testto przed aktualizacją - potwierdzimy, czy przejście wymaga dodatkowych kroków.
10. Czego aktualizacja nie obejmuje
| Element | Dlaczego i co zrobić |
|---|---|
| System operacyjny | jest aktualizowany przy okazji - playbook wykonuje dnf update i restartuje serwer (sekcja 6) |
| Licencja | plik na serwerze nie jest nadpisywany. Nowa licencja wymaga usunięcia starego pliku przed przebiegiem - zespół Testto uprzedza, gdy to konieczne |
| Konfiguracja uwierzytelniania | ustawienia wprowadzone ręcznie w panelu uwierzytelniania pozostają nietknięte; zmiany wnoszone przez wydanie są opisane w Historii wydań |
| Certyfikat TLS | wymiana certyfikatu to osobna procedura; aktualizacja nie rusza istniejącego |
| Twoja konfiguracja | inventories/klient/ przenosisz sam (sekcja 3.2) - żadne wydanie go nie nadpisuje |