Загальні команди

Використовуйте ці команди регулярно для управління контейнерами rtCloud. Запускайте їх з директорії, що містить docker-compose.production.yml.

  # Перевірити статус і здоров'я всіх контейнерів
docker compose -f docker-compose.production.yml ps

# Переглянути журнали в режимі реального часу (всі сервіси)
docker compose -f docker-compose.production.yml logs -f

# Переглянути журнали лише застосунку
docker compose -f docker-compose.production.yml logs -f rtcloud

# Перезапустити один контейнер
docker compose -f docker-compose.production.yml restart rtcloud

# Зупинити всі сервіси
docker compose -f docker-compose.production.yml down

# Запустити всі сервіси
docker compose -f docker-compose.production.yml up -d

# Відкрити оболонку всередині контейнера застосунку
docker compose -f docker-compose.production.yml exec rtcloud bash
  

Оновлення

Оновлення rtCloud розповсюджуються як нові теги Docker-образу. Оновлення завантажує останній образ та перестворює контейнер застосунку. Міграції бази даних запускаються автоматично при запуску.

1. Завантажте останній образ:

  docker compose -f docker-compose.production.yml pull
  

2. Перестворіть контейнер застосунку:

  docker compose -f docker-compose.production.yml up -d
  

Docker замінює лише контейнери, образ яких змінився. Контейнер MySQL та всі іменовані томи не зачіпаються.

Закріплення версії

Щоб оновитись до конкретної версії замість latest, оновіть RTCLOUD_IMAGE у .env:

  RTCLOUD_IMAGE=rtawebteam/rta-smartsurvey:1.2.3
  

Потім виконайте docker compose pull та up -d, як описано вище.

Відкат

Відкат загалом не рекомендується, оскільки міграції бази даних не можна скасувати. Якщо відкат необхідний, відновіть з резервної копії бази даних, зробленої перед оновленням.


Резервне копіювання та відновлення

Резервне копіювання бази даних

Виконайте цю команду для експорту бази даних застосунку в 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
  

Файл резервної копії записується до вашої поточної директорії на хості.

Відновлення бази даних

  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
  

Резервне копіювання завантажених файлів

Відправлення опитування часто включають завантажені файли (фотографії, аудіо, документи), що зберігаються в іменованих томах Docker. Робіть їх резервні копії окремо від бази даних:

  # Резервна копія завантажень
docker run --rm \
  -v rtcloud_uploads:/data \
  -v "$(pwd):/backup" \
  alpine tar czf /backup/uploads-$(date +%Y%m%d).tar.gz -C /data .

# Резервна копія аудіозаписів
docker run --rm \
  -v rtcloud_audios:/data \
  -v "$(pwd):/backup" \
  alpine tar czf /backup/audios-$(date +%Y%m%d).tar.gz -C /data .
  

Замініть rtcloud_uploads та rtcloud_audios фактичними назвами томів (з префіксом COMPOSE_PROJECT_NAME), якщо ви змінювали значення за замовчуванням.

Відновлення завантажених файлів

  docker run --rm \
  -v rtcloud_uploads:/data \
  -v "$(pwd):/backup" \
  alpine tar xzf /backup/uploads-20240101.tar.gz -C /data
  

Автоматизовані щоденні резервні копії

Додайте cron-задачу на хості для автоматичного запуску резервних копій. Відредагуйте crontab root за допомогою crontab -e:

  # Щоденна резервна копія бази даних о 2:00, зберігати 30 днів
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
  

Усунення несправностей

Контейнер застосунку не запускається

Перевірте журнали контейнера на наявність повідомлень про помилки:

  docker compose -f docker-compose.production.yml logs rtcloud
  

Поширені причини:

  • Відсутні або недійсні змінні середовища в .env
  • MySQL ще не готовий (зачекайте 60 секунд та перевірте знову)
  • Конфлікт портів — інший процес вже використовує APP_PORT

MySQL не здоровий

  docker compose -f docker-compose.production.yml logs mysql
  

Поширені причини:

  • MYSQL_ROOT_PASSWORD не встановлено в .env
  • Пошкоджений том даних (рідко — перевірте місце на диску за допомогою df -h)

MySQL може зайняти 30–60 секунд для ініціалізації при самому першому завантаженні. Зачекайте та перевірте знову перед тим, як вважати це збоєм.

Порт вже використовується

Змініть APP_PORT або SHINY_PORT у .env на вільний порт, потім перестворіть контейнери:

  docker compose -f docker-compose.production.yml up -d --force-recreate
  

Щоб знайти, що використовує порт на хості:

  lsof -i :8080
  

400 CSRF Token Could Not Be Verified

Ця помилка з’являється в локальних середовищах або середовищах зворотного проксі, де джерело запиту не відповідає очікуваному хосту. Вимкніть перевірку CSRF лише для локальної розробки:

  CSRF_VALIDATION_ENABLED=false
  

Потім перезапустіть застосунок:

  docker compose -f docker-compose.production.yml up -d --force-recreate rtcloud
  

Не вимикайте перевірку CSRF у виробництві. Якщо ця помилка виникає у виробництві, переконайтеся, що ваш зворотний проксі пересилає правильні заголовки Host та X-Forwarded-For.

Забули пароль адміністратора

Скиньте пароль адміністратора безпосередньо в базі даних. Підключіться до контейнера MySQL та оновіть хеш пароля:

Крок 1 — Згенеруйте новий хеш пароля. Замініть newpassword своїм бажаним паролем:

  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;
"
  

Крок 2 — Оновіть хеш у базі даних:

  docker compose -f docker-compose.production.yml exec mysql \
  mysql -u root -p"${MYSQL_ROOT_PASSWORD}" smartsurvey \
  -e "UPDATE ss_user SET password='<hash_from_step_1>' WHERE username='admin';"
  

Контейнер постійно перезапускається

Перевірте, чи не провалюється перевірка здоров’я:

  docker compose -f docker-compose.production.yml ps
docker inspect rtcloud-app --format '{{json .State.Health}}'
  

Перевірка здоров’я застосунку викликає кінцеву точку /health. Якщо вона постійно провалюється, перевірте журнали застосунку на наявність помилок при запуску.

Диск заповнений

Визначте, що займає місце:

  # Перевірити використання диска на хості
df -h

# Перевірити використання диска Docker (образи, контейнери, томи)
docker system df

# Видалити невикористовувані образи та зупинені контейнери (безпечно виконувати)
docker system prune
  

Не використовуйте docker system prune --volumes, оскільки це видалить дані застосунку.


Перевірки здоров’я

Кожен сервіс має автоматичну перевірку здоров’я. Статус контейнера відображає результат:

КонтейнерМетод перевіркиПочатковий періодІнтервал
rtcloud-appHTTP GET /health90 секунд30 секунд
rtcloud-mysqlmysqladmin ping30 секунд10 секунд
rtcloud-keycloakHTTP GET :9000/health/live120 секунд30 секунд

Контейнери з невдалою перевіркою здоров’я автоматично перезапускаються відповідно до налаштування RESTART_POLICY (за замовчуванням: unless-stopped).

Чи була ця сторінка корисною?