Konserwacja
Codzienna konserwacja samodzielnie hostowanej instancji rtCloud: aktualizowanie, tworzenie kopii zapasowych, przywracanie i rozwiązywanie typowych problemów.
Typowe polecenia
Używaj tych poleceń regularnie do zarządzania kontenerami rtCloud. Uruchamiaj je z katalogu zawierającego docker-compose.production.yml.
# Sprawdź status i stan zdrowia wszystkich kontenerów
docker compose -f docker-compose.production.yml ps
# Wyświetl dzienniki na żywo (wszystkie usługi)
docker compose -f docker-compose.production.yml logs -f
# Wyświetl dzienniki tylko aplikacji
docker compose -f docker-compose.production.yml logs -f rtcloud
# Uruchom ponownie jeden kontener
docker compose -f docker-compose.production.yml restart rtcloud
# Zatrzymaj wszystkie usługi
docker compose -f docker-compose.production.yml down
# Uruchom wszystkie usługi
docker compose -f docker-compose.production.yml up -d
# Otwórz powłokę wewnątrz kontenera aplikacji
docker compose -f docker-compose.production.yml exec rtcloud bash
Aktualizowanie
Aktualizacje rtCloud są dystrybuowane jako nowe tagi obrazów Docker. Aktualizacja pobiera najnowszy obraz i odtwarza kontener aplikacji. Migracje bazy danych uruchamiają się automatycznie przy starcie.
1. Pobierz najnowszy obraz:
docker compose -f docker-compose.production.yml pull
2. Odtwórz kontener aplikacji:
docker compose -f docker-compose.production.yml up -d
Docker zastępuje tylko kontenery, których obraz się zmienił. Kontener MySQL i wszystkie nazwane wolumeny są niezmienione.
Przypinanie wersji
Aby zaktualizować do konkretnej wersji zamiast latest, zaktualizuj RTCLOUD_IMAGE w .env:
RTCLOUD_IMAGE=rtawebteam/rta-smartsurvey:1.2.3
Następnie uruchom docker compose pull i up -d jak powyżej.
Obniżanie wersji
Obniżanie wersji generalnie nie jest zalecane, ponieważ migracje bazy danych nie mogą być cofnięte. Jeśli obniżenie wersji jest konieczne, przywróć z kopii zapasowej bazy danych wykonanej przed aktualizacją.
Kopia zapasowa i przywracanie
Kopia zapasowa bazy danych
Uruchom to polecenie, aby wyeksportować bazę danych aplikacji do pliku SQL:
docker compose -f docker-compose.production.yml exec mysql \
mysqldump -u root -p"$(grep MYSQL_ROOT_PASSWORD .env | cut -d= -f2)" smartsurvey \
> backup-$(date +%Y%m%d-%H%M%S).sql
Plik kopii zapasowej jest zapisywany w bieżącym katalogu na hoście.
Przywracanie bazy danych
docker compose -f docker-compose.production.yml exec -T mysql \
mysql -u root -p"$(grep MYSQL_ROOT_PASSWORD .env | cut -d= -f2)" smartsurvey \
< backup-20240101-120000.sql
Kopia zapasowa przesłanych plików
Odpowiedzi ankiet często zawierają przesłane pliki (zdjęcia, audio, dokumenty) przechowywane w nazwanych wolumenach Docker. Twórz kopie zapasowe oddzielnie od bazy danych:
# Kopia zapasowa przesłanych plików
docker run --rm \
-v rtcloud_uploads:/data \
-v "$(pwd):/backup" \
alpine tar czf /backup/uploads-$(date +%Y%m%d).tar.gz -C /data .
# Kopia zapasowa nagrań audio
docker run --rm \
-v rtcloud_audios:/data \
-v "$(pwd):/backup" \
alpine tar czf /backup/audios-$(date +%Y%m%d).tar.gz -C /data .
Zastąp rtcloud_uploads i rtcloud_audios rzeczywistymi nazwami wolumenów (poprzedzonymi COMPOSE_PROJECT_NAME), jeśli zmieniłeś domyślne.
Przywracanie przesłanych plików
docker run --rm \
-v rtcloud_uploads:/data \
-v "$(pwd):/backup" \
alpine tar xzf /backup/uploads-20240101.tar.gz -C /data
Automatyczne codzienne kopie zapasowe
Dodaj zadanie cron na hoście, aby automatycznie uruchamiać kopie zapasowe. Edytuj crontab roota przy użyciu crontab -e:
# Codzienne kopie zapasowe bazy danych o 2:00, przechowuj przez 30 dni historii
0 2 * * * cd /opt/rtcloud && docker compose -f docker-compose.production.yml exec -T mysql \
mysqldump -u root -p"$(grep MYSQL_ROOT_PASSWORD .env | cut -d= -f2)" smartsurvey \
> /backups/db-$(date +\%Y\%m\%d).sql && \
find /backups -name "db-*.sql" -mtime +30 -delete
Rozwiązywanie problemów
Kontener aplikacji nie startuje
Sprawdź dzienniki kontenera pod kątem komunikatów o błędach:
docker compose -f docker-compose.production.yml logs rtcloud
Typowe przyczyny:
- Brakujące lub nieprawidłowe zmienne środowiskowe w
.env - MySQL jeszcze nie gotowy (poczekaj 60 sekund i sprawdź ponownie)
- Konflikt portów — inny proces już używa
APP_PORT
MySQL niezdrowy
docker compose -f docker-compose.production.yml logs mysql
Typowe przyczyny:
MYSQL_ROOT_PASSWORDnie ustawione w.env- Uszkodzony wolumen danych (rzadko — sprawdź miejsce na dysku przez
df -h)
MySQL może potrzebować 30–60 sekund na inicjalizację przy bardzo pierwszym uruchomieniu. Poczekaj i sprawdź ponownie przed założeniem awarii.
Port już używany
Zmień APP_PORT lub SHINY_PORT w .env na wolny port, a następnie odtwórz kontenery:
docker compose -f docker-compose.production.yml up -d --force-recreate
Aby znaleźć, co używa portu na hoście:
lsof -i :8080
Błąd 400 — token CSRF nie mógł być zweryfikowany
Ten błąd pojawia się w środowiskach lokalnych lub za odwrotnym proxy, gdzie origin żądania nie odpowiada oczekiwanemu hostowi. Wyłącz walidację CSRF tylko podczas lokalnego tworzenia:
CSRF_VALIDATION_ENABLED=false
Następnie uruchom ponownie aplikację:
docker compose -f docker-compose.production.yml up -d --force-recreate rtcloud
Nie wyłączaj walidacji CSRF w środowisku produkcyjnym. Jeśli ten błąd pojawia się w produkcji, upewnij się, że odwrotny serwer proxy przesyła prawidłowe nagłówki
HostiX-Forwarded-For.
Zapomniane hasło administratora
Zresetuj hasło administratora bezpośrednio w bazie danych. Połącz się z kontenerem MySQL i zaktualizuj hash hasła:
Krok 1 — Wygeneruj nowy hash hasła. Zastąp newpassword żądanym hasłem:
docker compose -f docker-compose.production.yml exec rtcloud php -r "
\$salt = trim(shell_exec(\"mysql -h mysql -u root -p\\\"\${MYSQL_ROOT_PASSWORD}\\\" \${MYSQL_DATABASE} -se \\\"SELECT salt FROM ss_user WHERE username='admin';\\\"\"));
echo md5(\$salt . 'newpassword') . PHP_EOL;
"
Krok 2 — Zaktualizuj hash w bazie danych:
docker compose -f docker-compose.production.yml exec mysql \
mysql -u root -p"${MYSQL_ROOT_PASSWORD}" smartsurvey \
-e "UPDATE ss_user SET password='<hash_z_kroku_1>' WHERE username='admin';"
Kontener ciągle się restartuje
Sprawdź, czy kontrola stanu zdrowia kończy się niepowodzeniem:
docker compose -f docker-compose.production.yml ps
docker inspect rtcloud-app --format '{{json .State.Health}}'
Kontrola stanu zdrowia aplikacji wywołuje punkt końcowy /health. Jeśli wielokrotnie kończy się niepowodzeniem, sprawdź dzienniki aplikacji pod kątem błędów startowych.
Brak miejsca na dysku
Zidentyfikuj, co zużywa przestrzeń:
# Sprawdź użycie dysku hosta
df -h
# Sprawdź użycie dysku Docker (obrazy, kontenery, wolumeny)
docker system df
# Usuń nieużywane obrazy i zatrzymane kontenery (bezpieczne do uruchomienia)
docker system prune
Nie używaj docker system prune --volumes, ponieważ spowoduje to usunięcie danych aplikacji.
Kontrole stanu zdrowia
Każda usługa ma automatyczną kontrolę stanu zdrowia. Status kontenera odzwierciedla wynik:
| Kontener | Metoda sprawdzenia | Okres startowy | Interwał |
|---|---|---|---|
rtcloud-app | HTTP GET /health | 90 sekund | 30 sekund |
rtcloud-mysql | mysqladmin ping | 30 sekund | 10 sekund |
rtcloud-keycloak | HTTP GET :9000/health/live | 120 sekund | 30 sekund |
Kontenery z nieudaną kontrolą stanu zdrowia są automatycznie restartowane zgodnie z ustawieniem RESTART_POLICY (domyślnie: unless-stopped).