Я изменил имя, так как не могу отключить исходный сервер на несколько часов, пока не протестирую, что всё работает нормально, и не произведу замену серверов.
В этом нет необходимости. Если у вас есть wildcard-сертификат, вы можете просто внести локальные изменения DNS через файл Hosts, чтобы настроить всё и восстановить резервную копию.
Затем вы просто переключаете DNS публично.
Я не понимаю, что вы имеете в виду.
Мне нужно поддерживать работу a.domain.com, пока я провожу тесты.
И мне нужен доступ к интерфейсу Discourse копии, которую я восстанавливаю, чтобы проверить, всё ли в порядке.
Поэтому мне нужен другой URL для доступа к копии на другом сервере.
Так что я просто меняю имя хоста в Discourse и Nginx после восстановления.
Когда всё будет в порядке, я изменю имя на новом сервере на a.domain.com, остановлю старый сервер и перенаправлю DNS a.domain.com на новый сервер.
Вышеуказанное неверно. Вы можете заставить свой локальный компьютер подключиться к новому серверу, используя то же DNS-имя, либо изменив файл HOSTS на вашем локальном компьютере, либо прописав запись в локальный DNS.
У меня нет локальной машины.
Обе серверы находятся в интернете, это облачные серверы.
Я использую SSH с Windows-машины.
Может быть, я могу взять локальное имя хоста, чтобы задать IP-адрес машины, но это сложнее, чем изменить имя на серверах.
Как вы думаете, изменение имени хоста может быть проблемой?
Это не должно быть проблемой…
Да, мы снова начали сталкиваться с этой проблемой кастомных аватаров задолго после того, как процесс sidekiq успел пересобрать любые дополнительные изображения аватаров и профилей, но только в конфигурации с nginx reverse proxy к unix domain socket.
Маленькие иконки аватаров отображаются корректно, но они не работают на карточках профиля или на страницах профиля (если только они не были закэшированы ранее и кэш ещё не истёк).
Как только мы выполняем следующее:
nginx -s stop; ./launcher start web-only
Проблема с изображениями кастомных аватаров исчезает (для изображений, которые ранее не просматривались / не были закэшированы в браузере).
И сразу после выполнения этого:
./launcher stop web-only; nginx
Проблема с изображениями кастомных аватаров возвращается для изображений, которые ещё не просматривались / не были закэшированы.
Ошибок с HTTPS нет, и это точно не связано с force_https (полностью не относится к делу):
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
Мы подтвердили эту проблему на мобильных устройствах (iOS, последняя версия), на настольных компьютерах, в Chrome (последняя версия), в Safari (последняя версия) и т. д.
Что-то странное происходит при использовании nginx в качестве обратного прокси к unix socket, что влияет на изображения кастомных аватаров.
Пока что, к сожалению, @ariznaf, мы не можем изолировать проблему и не имеем решения.
«Ощущается», что в конфигурации nginx reverse proxy к unix socket приложение discourse (контейнер) не пересобирает эти изображения кастомных аватаров так, как это происходит в конфигурации без nginx в качестве обратного прокси к unix domain socket.
Возможно, sidekiq не любит конфигурацию nginx reverse proxy к unix socket и отказывается планировать или запускать этот процесс пересборки, LOL? @riking?
Странно.
Вот продолжение:
В конфигурации обратного прокси с использованием unix-сокетов, которую мы обсуждаем:
Однако при проверке force_https:
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
И, разумеется, как и ожидалось, в браузере нет ошибок сертификата (Chrome доволен):
Так что моё неподготовленное предположение состоит в том, что в этой конфигурации настройка/метод force_http не охватывает эти изображения; потому что всё остальное безупречно, кроме этих пользовательских аватаров (и изображения на странице профиля).
Это моё предположение, которое выше моей зарплаты в Discourse.
Обновление:
После дополнительных исследований выяснилось, что во всех наших конфигурациях nginx reverse proxy to unix socket отсутствовала большая часть файлов в /shared/uploads. Этот шаг отсутствовал в различных руководствах и инструкциях, которые я читал по этой теме, поэтому в следующий раз, когда я увижу вики-страницу на эту тему на meta, я обновлю руководство/вики/инструкцию, включив этот шаг.
Оставшаяся небольшая проблема — это ошибка с фавиконом:
Если у кого-то есть рекомендуемый способ исправить это, буду очень благодарен. Спасибо!
Перезагрузите это. Это самое быстрое решение.
Пользователи часто забывают, что при использовании сокета они отключили шаблон HTTPS, поэтому Discourse не знает, что он находится за SSL, если параметр force_https не включён вручную. Отсюда и моё предложение от вчера.
После включения force_https вы можете перезагрузить ресурсы, чтобы исправить их пути.
Я не отвечал ни на что из этого, потому что предположил, что какая-то неудачная передача данных на сервер (без использования встроенной функции резервного копирования) полностью исключила /uploads/, и я не знал, как объяснить это так, чтобы вы поняли.
Да… мы следовали этому руководству для настройки обратного прокси-сервера nginx, но оно было предназначено для автономной установки и не упоминало каталог uploads, так как в автономном режиме его перенос не требовался:
А мы следовали этому руководству для двух контейнеров, где также не упоминалось восстановление базы данных или перенос каталога с загрузками:
Я думаю, мы легко можем разобраться в вещах. Вот ключ, которого вам не хватало для объяснения, для справки:
Основные руководства по этой конфигурации упускают тот факт, что вам нужно либо восстановить базу данных, либо вручную перенести ваши загрузки в новый контейнер, так как мы этого не включили.
Конечно, теперь всё становится понятным, после того как мы сами во всём разобрались на 100% (опять!), потому что этого нет в руководствах. LOL
Всё становится легко, как только вы понимаете, в чём проблема.
PS: В заключение. Спасибо всем, кто написал различные руководства. Они очень помогли! Мы очень ценим это. С нашей стороны эта конфигурация завершена, и в будущем мы больше не будем использовать автономную конфигурацию ни на одном сайте Discourse. Нашим обычным «стандартом» будут два контейнера с обратным прокси-сервером, подключённым к unix-сокету. Это лучше всего подходит для обновления и переключения контейнеров в реальном времени с почти нулевым временем простоя. Отличная штука!!
Discourse — это ВЕЛИКОЛЕПНО!!
Отличная работа, Джефф @codinghorror и Сэм @sam! БРАВО!
Это довольно просто настроить, но, как я уже упоминал ранее, мы не используем S3 и другие облачные хранилища; мы предпочитаем держать вещи «простыми», поэтому наши резервные копии просто rsync-ятся на внешнее хранилище. Мы предпочитаем так… это одна вещь меньше для отладки и мы можем «обойтись» без S3,
Не знаю, насколько это полезно, но оптимизация изображений часто не работает, если задача, выполняющая оптимизацию, не может получить доступ к вашему серверу через его доменное имя в интернете.
Это может объяснить, почему в более сложной конфигурации обратного прокси-сервера всё работает не так, как ожидалось.
Спасибо, Кейн.
Я, как вы, вероятно, знаете, пробовал другие альтернативы стандартному методу резервного копирования через интерфейс в Discourse. Я пробовал это из-за проблем, возникавших каждый раз при попытке восстановления из резервной копии стандартным методом, всегда следуя инструкциям из официальных руководств на этом сайте.
В любом случае, я сразу отметил, что восстанавливал из резервной копии, созданной через интерфейс UI и по стандартной процедуре резервного копирования и рекомендованной процедуре восстановления.
Единственное отличие от стандартной установки автономного Discourse заключается в том, что мы используем nginx в качестве обратного прокси, подключенного к Discourse через сокет.
Основная проблема, с которой мы столкнулись, касалась аватаров, которые, казалось, были утеряны и заменены стандартным профилем.
Вы сказали мне, что их нужно перестроить с помощью фоновой задачи Sidekiq. Но эта задача, похоже, завершается мгновенно при запуске с успехом (статус OK), однако аватары остаются прежними.
Поскольку резервные копии для нас очень важны (кто может ими пренебречь?), я проведу дополнительные тесты, стараясь очень внимательно следовать инструкциям и пробуя другие идеи, предложенные здесь.
Мы довольны Discourse, нам он очень нравится. Мы просто хотим убедиться, что у нас есть надежная процедура восстановления, на случай, если мы столкнемся с какой-либо атакой (недавно у нас уже была одна) или сбоем сервера.
Если вы хотите, чтобы мы провели какие-то тесты для попытки исправить эту проблему или предоставили дополнительную информацию, я с радостью сделаю всё возможное и предоставлю эти данные.
Похоже, что система действительно не может получить доступ к миниатюрам аватаров.
Однако остальная часть форума отображается корректно: маршруты, SSL и всё остальное, насколько я могу судить, настроены правильно.
Если бы была какая-то ошибка в конфигурации, вы бы не смогли зайти на форум Discourse и увидеть остальной контент; скорее всего, вы получали бы ошибки 502 или что-то подобное.
@neounix
Мы используем S3, потому что это самый простой способ из интерфейса для хранения резервных копий вне сайта.
Возможно, S3 — не лучший вариант, я не знаю. В любом случае, где хранятся резервные копии, не связано с этой проблемой, так как проблема не в невозможности получить к ним доступ и выполнить восстановление. Восстановление выполняется корректно.
@stephan
В файле app.yml я закомментировал шаблон SSL, шаблон Let’s Encrypt и секцию expose с портами.
Часть SSL обрабатывается nginx, поэтому мне не нужно шифровать сокет, верно?
Неправильно ли это? Должен ли я всё равно использовать шаблон SSL?
Предполагаю, что если бы это была проблема, то после восстановления я бы не увидел ни одной части форума, а не только аватары, но кто знает…
Я проведу дополнительные тесты. Спасибо всем за помощь.
@ariznaf … привет!
Я решил эту проблему на двух разных серверах, вручную скопировав директорию /shared/uploads из исходной конфигурации в конфигурации socket-only, и после этого проблема исчезла.
Чтобы быстро проверить, я сравнивал размеры директории uploads следующим образом (предполагая, что вы находитесь в общей директории):
du -sh uploads
Сравнив их, я понял, в чём была проблема
Может быть, вы тоже сможете проверить? Надеюсь, это поможет вам локализовать вашу проблему.
PS: Я не против S3. Как говорится, на вкус и цвет товарищей нет…
Позвольте мне убедиться, что я правильно вас понял.
Когда я делаю резервные копии, я проверяю, что загруженные файлы также сохраняются (не эскизы, но я тестировал сохранение и эскизов; сейчас я сохраняю эскизы, поэтому вам не придется ждать их повторной генерации).
После восстановления загруженные файлы также восстанавливаются.
Вы имеете в виду, что восстановление загруженных файлов происходит некорректно и вам приходится делать это вручную?
Как вы восстанавливаете загруженные файлы вручную?
Вы скачали резервную копию и распаковали shared/standalone/uploads?
Если это так (я попробую), то мне кажется очевидным, что в задаче восстановления есть какая-то ошибка.
Спасибо.
Я ищу альтернативные способы создания резервных копий и их хранения, но представители Discourse настаивают на том, что единственный правильный способ — использование стандартной системы резервного копирования.
Привет, @ariznaf,
Мы не восстанавливаем данные через административный интерфейс (мы создаем резервные копии через веб-интерфейс, но не восстанавливаем из них). Мы передаем файл в контейнер по sftp (включая загрузки) и выполняем восстановление следующим образом:
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
Однако, когда я на днях настраивал новый nginx reverse proxy для unix-сокета, я не восстанавливал данные из базы данных, так как база данных уже присутствовала в контейнере data (как упоминалось в темах с инструкциями).
Именно поэтому мне пришлось вручную скопировать файлы загрузок в новый контейнер.
Ваша ситуация, похоже, отличается от нашей.
Надеюсь, это поможет.
Спасибо.
Кажется, вы выполняете через командную строку ту же процедуру, что и через интерфейс: включаете восстановление и восстанавливаете из tgz-файлов, содержащих базу данных и загрузки.
Но затем вы говорите, что для работы аватаров (с использованием сокетов и обратного прокси-сервера nginx) требуется второе восстановление только загрузок. Правильно ли я понял?
Привет, @ariznaf… не совсем так…
В начале у нас было отдельное приложение. Я разделил это приложение на два разных контейнера (для данных и только для веб-части), а затем выполнил восстановление из большого файла резервной копии с загрузками.
Всё прошло хорошо…
Затем я создал новый контейнер socket-only и настроил его на использование обратного прокси.
Я НЕ выполнял восстановление в новом контейнере socket-only (поскольку в контейнере данных уже были данные БД в целости), но забыл вручную скопировать загрузки (это была моя ошибка). Если бы я выполнил обычный процесс восстановления, это было бы не нужно.
Но нет причин снова выполнять ручное восстановление БД в новом контейнере, ведь именно для этого данные находятся в его собственном милом маленьком контейнере. Так что в этой ситуации загрузки нужно скопировать в новый контейнер. На самом деле всё сделано довольно аккуратно.
Помогло ли это?
Это не то, что я говорил. Я сказал, что бэкенд не может получить доступ к самому себе через фронтенд-nginx. То, что вы говорите, — это наоборот.
Для оптимизации загрузки Sidekiq-задача извлекает её по протоколу http(s).
Нет, вы можете отключить шаблон SSL, но потребуется вручную включить принудительное использование HTTPS.