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_PASSWORD nie 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 Host i X-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:

KontenerMetoda sprawdzeniaOkres startowyInterwał
rtcloud-appHTTP GET /health90 sekund30 sekund
rtcloud-mysqlmysqladmin ping30 sekund10 sekund
rtcloud-keycloakHTTP GET :9000/health/live120 sekund30 sekund

Kontenery z nieudaną kontrolą stanu zdrowia są automatycznie restartowane zgodnie z ustawieniem RESTART_POLICY (domyślnie: unless-stopped).

Czy ta strona była pomocna?