TL;DR

  • Cel: Poznanie ewentualnych problemów przy aktualizacji
  • Wynik: Udana aktualizacja wraz bez utraty danych
  • Największa pułapka: Czytanie dokumentacji tylko na stronie projektu
  • Jeśli robisz to pierwszy raz: Backup, backup i jeszcze raz backup

Kontekst

W wielu źródłach piszą, że to bardzo duży problem z uruchomieniem i utrzymaniem serwera poczty na własnej maszynie, a wielkie korporacje blokują, uniemożliwiając poprawnie działania. Na podstawie powyższego jedną z pierwszych aplikacji, po nabyciu domeny, jaką uruchomiłem był serwer poczty - wychodzącej i przychodzącej. Przeglądając różne opcje m.in. docker-mail - nawet podjąłem próby uruchomienia - porażka… wybrałem ostatecznie Stalwart - mail-server czytając dokumentację i potem konfigurując aplikację - cały ten proces był sprawny i przemyślany.

Stalw.art czyli serwer poczty, który używam od ponad roku, bardzo dobrze i bez inwazyjnie przechodził aktualizacje. Do tej pory to była jedna z tych aplikacji, w której po skonfigurowaniu zapomninam, że istnieje. Przy migracji serwera poczty na główny serwer, nie mogłem pobrać jak wcześniejszej obrazu dockera… i zaczęła się kolejna przygoda…

Założenia i zakres

Zakładam, że masz:

  • docker, docker-compose
  • dostęp do terminala minimum po ssh
  • stalwartlabs/mail-server:latest lub v0.11.x

Poza zakresem (świadomie):

  • pierwsza konfiguracja stalwartlabs/mail-server
  • stalwartlabs/mail-server: -> wersje poniżej v0.11 - nie wykryłem żadnych anomalii przy aktualizacji do nowszych wydań

Przygoda - aktualizacja stalwartlabs/mail-server:latest/(v0.11.8) do stalwartlabs/stalwart:latest/(v0.15.3)

Przygotowania

Stosując dobrą praktykę najpierw zatrzymałem aplikację, następnie spakowałem do .tar.gz, poniżej użyta komenda na serwerze czyli wykonanie backupu zgodne z opisem dokumentacji, dane aplikacji trzymam w docker volume.

docker run --rm \ # docker uruchom, a po wykonaniu usuń kontener
  -v stalwart_data:/volume \ # nazwa volume z danymi aplikacji stalwart, zamontuj wewnątrz kontenera jako /volume
  -v /srv/backup:/backup \ # fizyczna lokalizacja na dysku, do utworzenia backup, zamontuj wewnątrz kontenera jako /backup
  alpine \ # obraz kontenera, który obsłuży komendę tar, alpine jest lekki (>4 MB)
  tar czf /backup/stalwart_data.tar.gz -C /volume . # komenda tar c - create, z - gzip,
        # f - filename, lokalizacja pliku i nazwa, -C - zmień folder,
        # . - wszystko co zawiera folder

Aktualizacja docker-compose, poniżej jak wyglądał mój docker compose w wersji stalwart v0.11.8.

services:
  stalwart-mail:
    image: stalwartlabs/mail-server:latest
    volumes:
      - stalwart_data:/opt/stalwart-mail
    restart: unless-stopped
    ports:
      #- 443:443
      - 8080:8080
      - 25:25
      - 587:587
      - 465:465
      #- 143:143
      - 993:993
      - 4190:4190
      #- 110:110
      #- 995:995
    networks:
      - frontend
volume:
  stalwart_data:
networks:
  fronend:
    driver: bridge

Najpierw podjąłem próbę od razu do wersji v0.15, z docker-compose jak niżej:

services:
  stalwart-mail:
    image: stalwartlabs/stalwart:latest # inna nazwa obrazu, v0.15
    volumes:
      - stalwart_data:/opt/stalwart-mail # tutaj błąd #1 - brak zmiany folder wewnątrz kontenera
    restart: unless-stopped
    ports:
      #- 443:443
      - 8080:8080
      - 25:25
      - 587:587
      - 465:465
      #- 143:143
      - 993:993
      - 4190:4190
      #- 110:110
      #- 995:995
    networks:
      - frontend
volume:
  stalwart_data:
networks:
  fronend:
    driver: bridge

Wg dokumentacji proces jest prosty: zatrzymaj, zrób backup ustawień, dane skopiuj, ściągnij nowy obraz i odpal, po zalogowaniu się do webadmin, wykonaj aktualizację Update Webadmin.

Brak możliwości zalogowania, a w logach pojawiło się login i hasło -> czyli brak danych konfiguracyjnych. Sprawdziłem jeszcze raz jak powinien wyglądać docker-compose, zorientowałem się, że wewnątrz kontenera jest inny folder główny.

volumes:
  - stalwart_data:/opt/stalwart # już teraz bez -mail

Podejście #2, przywróciłem kopię zapasową, uruchomiłem kontener, zalogowałem się do Webadmin, wykonałem krok Update Webadmin, a danych brak, ustawienia serwera były obecne. Poszukując rozwiązania, wszedłem przez Komodo na service, zakładka Terminal, zmiana na bash, ls, następnie ‘cat etc/config.toml’ i po chwili przeglądania:

  • store.rocksdb.path = "/opt/stalwart-mail/data" - stara ścieżka
  • tracer.log/path = "/opt/stalwart-mail/logs" - jak wyżej wewnątrz kontenera nie ma nano, vi, więc wybór padł na sed:
sed -i 's|^store.rocksdb.path =.*|store.rocksdb.path = "/opt/stalwart/data"|; s|^tracer.log.path =.*|tracer.log.path = "/opt/stalwart/logs"|;' etc/config.toml

Podejście #3. przywróciłem kopię zapasową, uruchomiłem kontener, zalogowałem się do Webadmin i aktualizacja, a pomimo to konta użytkowników były puste - ilość się zgadzała - sytuacja jak opisana Issues#2534.

Zmiana podejścia, próba z etapowania aktualizacji, najpierw do wersji v0.13 - taki pomysł. Czyli w docker-compose.yaml.

image: stalwartlabs/stalwart:v0.13

Podejście #4. przywróciłem kopię, uruchomiłem kontener, poprzez Komodo wejście do terminala kontenera, wykonanie polecenia sed - zmiana ścieżek. Restart kontenera, zalogowałem się do Webadmina, aktualizacja i bajka - pomyślna migracja z v0.11.x do v0.13 - jest mały sukces!

Wykonałem kopię zapasową (komenda jak wyżej) z oznaczeniem v13 - aby nie nadpisać kopii poprzedniej, w razie W;). Przed przystąpieniem do kolejnej próby, czyli do przejścia na najnowszą wersję, poczytałem jeszcze na githubie, jak wykonać aktualizację rozpisane dla każdej wersji, dla v0.15 -> do przeczytania tutaj, co prawda opisane jest to dla aktualizacji z v0.14 do v0.15, ale po tylu próbach spróbowałem przejść z v0.13 na v0.15. Aktualizacja docker-compose.yaml:

image: stalwartlabs/stalwart:v0.15

Podejście #5. Uruchomiłem kontener, zalogowałem do Webadmin, aktulizacja Webadmin oraz zasad spamu, zgodnie z opisem w dokumentacji. Wszystko działa, sukces - konta użytkowników widoczne, rozmiary się zgadzają, brak dziwnych zachowań.

Schemat migracji:

Wersja v0.11.x
  |
Wersja v0.13
+zmiana docker-compose, config.toml
  |
Wersja v0.15

Wnioski

Migracja Stalwart nie jest trudna, ale nie jest też „jednym docker pull”. Najbezpieczniejsza ścieżka to aktualizacja etapami i weryfikacja zmian opisanych w repozytorium projektu, nie tylko w dokumentacji i do znudzenia backup na każdym kroku.

Następne w serii stalwart

W kolejnym poście o stalwart, opiszę ustawienia części collaboration czyli kalendarz, kontakty, udostępnianie plików - w stalwart od wersji v0.14.