Paczka migracyjna

Przejście na nową linię wydań (1.8.x → 1.9.x) bywa związane z jednorazową zmianą w istniejącej instalacji, której samo podniesienie wersji usług nie wykona. Dostarczamy ją wtedy jako paczkę migracyjną - osobne archiwum przypisane do tej linii.

Procedura uruchomienia jest zawsze taka sama - między liniami zmienia się wyłącznie paczka. Trwa kilka minut, nie aktualizuje systemu operacyjnego i nie restartuje serwera.

Czy Twoje wydanie wymaga migracji

Decyduje Historia wydań - paczka migracyjna prowadzi na nową linię wydań i jest wymieniona przy niej w tabeli Linie wydań. Wydania wewnątrz linii, na której już jesteś, wdrażasz zwykłą procedurą: Aktualizacją obrazów aplikacji przy wydaniach aplikacyjnych albo Aktualizacją platformy przy infrastrukturalnych.

1. Czego potrzebujesz

Paczka migracyjna - do pobrania z Historii wydań, z tabeli Linie wydań, z wiersza linii, na którą przechodzisz. Nie jest zabezpieczona hasłem, bo nie zawiera żadnych danych Twojej instalacji.

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

2. Przygotowanie

1. Sprawdź, z jakiej wersji startujesz:

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

3. Wykonanie

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

ansible-playbook -i testto-credentials/ \
    testto-migrate-<wersja>/testto-migrate-<wersja>.yml --ask-vault-pass

W miejsce <wersja> wpisz numer z nazwy paczki. Dokładne nazwy katalogu i playbooka podaje README dołączone do paczki.

Każda paczka migracyjna przebiega tak samo:

1. odczyt stanu instalacji i ustalenie, które kroki są potrzebne,
2. sprawdzenie warunków wstępnych - przerwanie na tym etapie zostawia instalację nietkniętą,
3. kopie plików usług (<plik>.bak-<data>),
4. zmiany wymagane przez nową linię oraz podniesienie wersji usług,
5. zapis znacznika wersji instalacji w /etc/testto-release.

Procedura jest bezpieczna do powtórzenia

Uruchomiona drugi raz na zmigrowanej instalacji nie zmienia niczego i kończy się komunikatem, że nie ma czego robić. Jeżeli nie masz pewności, czy przebieg doszedł do końca, po prostu uruchom go ponownie.

Instalacja o zawężonym zakresie

Jeżeli część usług nie została u Ciebie wdrożona, procedura pominie odpowiadające im kroki z komunikatem - to nie jest błąd.

4. Weryfikacja

Znacznik wersji instalacji:

ansible testto-srv -i testto-credentials/ \
    -m shell -a "cat /etc/testto-release" --become --ask-vault-pass

Powinien podawać numer wydania, na które wprowadziła Cię paczka, oraz wersję obrazów usług.

Stan usług:

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.

Usługa poczty wstaje wolniej

Stack mail-relay potrzebuje około 3 minut na przejście kontroli stanu - przejściowe 0/1 zaraz po migracji 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.

5. Po migracji

Kolejne wydania wdrażasz już zwykłymi procedurami - Aktualizacją obrazów aplikacji przy wydaniach aplikacyjnych albo Aktualizacją platformy przy infrastrukturalnych.