Przejdź do treści

Aktualizacja obrazów aplikacji

Szybka ścieżka aktualizacji: podmienia wersje usług platformy bez aktualizacji systemu operacyjnego i bez restartu serwera. Trwa kilka minut zamiast okna serwisowego.

Czego potrzebujesz

Paczka z procedurą (testto-update-images.zip) - do pobrania z Historii wydań, z kolumny Aktualizacja przy wydaniu; bez hasła. Jest niezależna od wydania - pobierasz ją raz, przy kolejnych aktualizacjach zmieniasz wyłącznie numer wersji.

Dane dostępowe Twojej instalacji (credentiale i hasło do Ansible Vault) otrzymujesz osobnym mailem od zespołu Testto - patrz Dostęp do skryptów.

Kolekcja community.docker na stacji wdrożeniowej. Jeżeli wykonywałeś stąd instalację lub inne procedury administracyjne, już ją masz; w razie potrzeby:

ansible-galaxy collection install -r collections/requirements.yml

1. Kiedy tej procedury użyć

Zmiana linii wydań? Najpierw migracja

Ta procedura podmienia wyłącznie wersje usług, w obrębie linii, na której już jesteś. Jeżeli przechodzisz na linię mającą w Historii wydań paczkę migracyjną, wdrażasz ją tą paczką - podnosi ona także wersje usług, więc wykonujesz ją zamiast tej procedury, nie oprócz niej.

Poza tym decyduje klasa wydania, podana przy każdej pozycji w Historii wydań:

Klasa wydania Procedura Restart serwera
aplikacyjne ta strona nie
infrastrukturalne Aktualizacja platformy - pełny przebieg z paczki instalacyjnej tak

Przy wydaniu infrastrukturalnym ta procedura nie wystarczy

Podmienia wyłącznie znaczniki wersji obrazów w plikach usług leżących już na serwerze. Nie wnosi zmian w samej konfiguracji usług ani nie aktualizuje komponentów infrastruktury (baza danych, uwierzytelnianie, broker, magazyn plików, warstwa wejściowa, centralne logowanie). Jeżeli w Historii wydań widnieje klasa infrastrukturalne, użyj pełnej procedury.

Czego ta procedura nie wymaga

Przy wydaniu aplikacyjnym nie zmieniasz niczego w konfiguracji: nie pobierasz nowej paczki instalacyjnej, nie przenosisz katalogu inventories/ i nie uzupełniasz nowych pól. Jedynym parametrem jest numer wersji.

2. Przygotowanie

  1. Sprawdź w Historii wydań numer wydania i jego klasę.

  2. Odczytaj wersję zainstalowaną obecnie:

    ansible testto-srv -i testto-credentials/ \
    -m shell -a "docker service ls --format '{{.Name}}\t{{.Image}}'" --ask-vault-pass

  3. Wykonaj backup aplikacyjny. Procedura tworzy wprawdzie kopie plików usług przed ich zmianą, ale nie obejmuje danych.

Sprawdzenie stanu przed aktualizacją

Krok opcjonalny, wymaga paczki skryptów administracyjnych (testto-ops.zip) - to inne archiwum niż paczka z tej strony.

ansible-playbook -i testto-credentials/ testto-ops/testto-healthcheck.yml --ask-vault-pass
Wszystkie komponenty powinny pokazać status [OK]. Aktualizacja uruchomiona przy niesprawnej usłudze utrudni ocenę, co poszło nie tak.

3. Wykonanie

Rozpakuj paczkę obok katalogu z danymi dostępowymi, a następnie:

ansible-playbook -i testto-credentials/ \
    testto-update-images/testto-update-images.yml \
    -e testto_update_version=<wersja> --ask-vault-pass

W miejsce <wersja> wpisz numer z Historii wydań, na przykład 1.9.2. Numer jest obowiązkowy - bez niego procedura przerwie się od razu, nie zmieniając niczego.

Playbook wykonuje kolejno:

  1. korektę systemowego limitu otwartych plików (fs.file-max) - patrz niżej,
  2. sprawdzenie, które usługi są obecne na tej instalacji,
  3. zapisanie bieżących wersji,
  4. pobranie wszystkich nowych obrazów - brak któregokolwiek w rejestrze przerywa procedurę, zanim cokolwiek zostanie zmienione,
  5. kopię plików usług (<plik>.bak-<data>),
  6. podmianę wersji, wraz z obrazem aplikacji wykonawczej robotów,
  7. wdrożenie usług i oczekiwanie na ich gotowość.

Korekta limitu otwartych plików

Instalacje wykonane wcześniejszymi wersjami instalatora mają systemowy limit otwartych plików ustawiony na 65536. Po kilkunastu dniach pracy usługi platformy potrafią go wyczerpać, a serwer traci wtedy połączenie sieciowe. Procedura podnosi limit do 2097152 - zmiana działa od razu, bez restartu usług ani serwera, i jest zapisywana trwale w /etc/sysctl.conf. Wartości wyższej, ustawionej wcześniej przez Ciebie, nie zmienia.

Instalacja o zawężonym zakresie

Jeżeli część usług nie została wdrożona, procedura pominie je z komunikatem - to nie jest błąd.

4. Weryfikacja

ansible testto-srv -i testto-credentials/ \
    -m shell -a "docker service ls --format '{{.Name}}\t{{.Image}}\t{{.Replicas}}'" --ask-vault-pass

Usługi platformy powinny mieć znacznik nowej wersji i pełną liczbę replik. Komponenty infrastruktury zachowują własne, niezależne numery wersji - to normalne.

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.

Na koniec zaloguj się do aplikacji i uruchom jeden znany scenariusz lub automatyzację - potwierdza to działanie całej ścieżki, razem z aplikacją wykonawczą robota w nowej wersji.

5. W przypadku problemów

Sytuacja Działanie
usługa nie wstaje po aktualizacji przywróć plik z kopii <plik>.bak-<data> i wdróż ponownie (niżej)
dane wyglądają niepoprawnie restore z backupu wykonanego przed aktualizacją
nie masz pewności, co się stało powiadom zespół Testto, dołączając wyjście playbooka

Powrót do poprzedniej wersji jednej usługi:

ssh uzytkownik@<adres-serwera>
cd ~/stacks/backend/<usluga>
ls *.bak-*                          # wybierz kopię sprzed aktualizacji
cp <usluga>.yaml.bak-<data> <usluga>.yaml
docker stack deploy -c <usluga>.yaml <nazwa-stacku>

Powrót nie zawsze wystarczy

Jeżeli nowa wersja zdążyła zmienić strukturę danych, samo cofnięcie obrazu nie przywróci działania - potrzebny jest restore albo snapshot maszyny. Wydania niosące takie zmiany są oznaczone w Historii wydań.