Проблемы с входом в Patreon, принудительным HTTPS и S3 CDN (три проблемы)

Поддержка Самостоятельное хостинг
1

Возможно, мне придется разделить это на три отдельных сообщения, но они связаны, поэтому я начну с одного.

Несколько дней назад я использовал этот учебник (How to Scale a Discourse Deployment with a Load Balancer and Managed Database Cluster | DigitalOcean) практически слово в слово и перенес свой отдельный Droplet с Discourse на Digital Ocean на два Droplet внутри балансировщика нагрузки. Пока всё хорошо.

Затем я прошел по этому руководству (Configure an S3 compatible object storage provider for uploads), но после пересборки Discourse из командной строки мой сайт Discourse отображал только пустой экран. Я проверил в инспекторе браузера и обнаружил, что браузер блокирует весь мой контент, так как он предоставляется через HTTP, а не HTTPS. Вероятно, это связано с тем, что балансировщик нагрузки выполняет SSL-терминацию, поэтому весь внешний трафик идет по HTTPS, но сами серверы работают на HTTP.

На этом этапе я снова полностью сломал свои серверы, пытаясь заставить их работать с HTTPS внутри балансировщика нагрузки, но это оказалось просто невозможным. Я не мог заставить Digital Ocean Space/CDN работать с S3/CDN согласно этому руководству (Configure an S3 compatible object storage provider for uploads). Я внимательно изучил его, проверив каждый аспект несколько раз, но ничего не получилось. Единственный способ заставить Discourse пересобраться — удалить параметр DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com из файла app.yml, но даже после успешной сборки сервер не отвечал. Я получал либо ошибку 503 (сервер не отвечает), либо обычную ошибку браузера «сервер не отвечает» или «сервер отключился». Это зависело от настроек балансировщика нагрузки и DO Space/CDN, которые я пробовал. Я перепробовал все возможные комбинации настроек, но ни одна из них не позволяла отобразить страницу.

Когда я оставил параметр DISCOURSE_S3_ENDPOINT, во время пересборки Discourse возникла следующая ошибка, которая исчезла, когда я закомментировал параметр S3_ENDPOINT:
Aws::S3::Errors::InvalidAccessKeyId: Aws::S3::Errors::InvalidAccessKeyId

Все мои файлы были синхронизированы с S3, поэтому я считаю, что ключ доступа был в порядке, и проблема была вызвана каким-то образом параметром S3_ENDPOINT.

Сегодня я отказался от попыток заставить предыдущую попытку работать, восстановил резервную копию своих Droplet, которые просто балансировали нагрузку только через HTTP, и наконец снова заставил всё работать, выполнив это руководство (Set up file and image uploads to S3), но на этот раз я изменил настройки S3 через панель администратора Discourse, а не редактировал файл app.yml с настройками, рекомендованными в учебнике. В конце концов всё заработало, но важное отличие заключается в том, что я намеренно пропустил настройки CDN S3. Я подтвердил, что изображения, загруженные в сообщения, хранятся на S3, и я могу делать резервные копии Discourse напрямую в S3, и это всё, что мне нужно. Однако теперь у меня есть три проблемы, которые меня беспокоят: одна критическая, а две другие можно игнорировать, хотя я бы хотел подтвердить это здесь, если возможно.

Итак, критическая проблема заключается в том, что пользователи больше не могут входить в систему с помощью кнопки входа Patreon на странице входа Discourse. Отображается следующее сообщение:
К сожалению, произошла ошибка при авторизации вашей учетной записи. Пожалуйста, попробуйте снова.

URL-адрес выглядит так:
https://mbp.community/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fmbp.community%2Flogin&strategy=patreon

Мне очень пригодится совет о том, что можно попробовать, чтобы заставить это работать, но снова задаюсь вопросом, не связано ли это с тем, что внутри серверы не работают на HTTPS. Как видно из URL-адреса, внешне они используют HTTPS, поэтому точно сказать сложно. Надеюсь, кто-то здесь имеет опыт работы с балансировкой нагрузки Digital Ocean и Discourse.

Две другие проблемы сейчас отмечаются в консоли администратора следующим образом:

Некоторые рекомендации на основе текущих настроек вашего сайта

Так что я не против попробовать включить force_https, но боюсь, что это заблокирует мне доступ к серверу, поскольку внутри балансированные серверы не работают на HTTPS, и из-за проблем, с которыми я столкнулся вчера, я не хочу тратить еще двенадцать часов, биться головой о стену, наблюдая за бесконечными 15-минутными пересборками Discourse, которые ни к чему не приводят. Если кто-то знает, что безопасно включить force_https с моими конфигурациями, пожалуйста, сообщите об этом.

Что касается второй проблемы, то она также не удалась при добавлении параметров в файл app.yml, поэтому я не хочу пробовать это снова. Можете ли вы подтвердить, что это будет Essentially то же самое, что и параметры, добавленные в файл app.yml? Если да, то я просто проигнорирую это второе сообщение. И наоборот, если это безопасно попробовать по какой-то причине, дайте знать, и я сделаю резервную копию и попробую.

Извините за длинный пост. Надеюсь, вы поймете, в чем я нуждаюсь в совете.

2

Тогда вам действительно нужно обратиться за помощью туда, потому что здесь поддерживается только стандартная установка.

Ожидаете ли вы более 200 тысяч просмотров страниц в день? Если нет, то один Droplet с 8 ГБ ОЗУ и CDN будет гораздо проще в управлении и, вероятно, дешевле. И, насколько я могу судить, в тех инструкциях есть как минимум пара моментов, из-за которых они, скорее всего, не сработают для кого угодно.

Во-первых, настроили ли вы внешний Redis, как описано в шаге 5? Если нет, то я бы ожидал, что хотя бы кое-что будет работать некорректно. В инструкции подразумевается, что использование «липких» сессий (sticky sessions) «исправит» это, но на самом деле это не так. Поэтому вы можете столкнуться со сложными в диагностике случайными ошибками. Кроме того, в инструкции не указано, как убедиться, что все ваши экземпляры работают на абсолютно одинаковой версии Discourse, что тоже, скорее всего, приведёт к проблемам.

Вам следовало сделать это в первую очередь, иначе, на самом деле, такая настройка не может работать, потому что некоторые загрузки будут находиться на одном сервере, а некоторые — на другом. В тех инструкциях вообще не упоминается слово «загрузка» (upload), поэтому я предполагаю, что если вы использовали это дольше, чем для тестов, то у вас сейчас полный хаос, и вам нужно будет синхронизировать загрузки между вашими несколькими Droplet.

В нём конкретно указано, что CDN Digital Ocean не работает с Discourse.

Использовали ли вы другой CDN, как и рекомендуется? Bunny.net довольно легко и просто настроить.

3

О боже, я не знаю, кто написал это руководство, но точно не тот, кто хорошо разбирается в масштабировании Discourse.

В последнем шаге говорится, что можно добавлять дополнительные бэкенды к балансировщику нагрузки, используя функцию снимков Droplet. Однако, поскольку в руководстве не упоминается использование Object Storage для загрузки файлов, такое действие полностью сломает загрузку файлов пользователями. Кроме того, если следовать этому руководству, обновления станут нетривиальной задачей.

Мой совет @Martin_Bailey: не следуйте ничему из этого руководства. Это приведёт только к неработоспособной установке, как вы уже убедились.

Пожалуйста, следуйте нашему официальному руководству по установке, если хотите быстро и правильно развёрнуть Discourse. Отклонение от этого пути может быстро превратиться в работу на полную ставку.

4

Забавно. Я оставил там комментарий, в котором изложил некоторые проблемы и дал ссылку на пост Рафаэля, но его удалили.

5

Вау! Ладно, я думал, что всё прошло хорошо, хотя я заметил несколько ошибок. Но у меня теперь установка с балансировкой нагрузки. Конечно, первым делом я обнаружил, что загрузка изображений не работает, поэтому я использовал S3 для хранения изображений.

В текущем состоянии возвращение к одному серверу потребует огромного объёма работы. Так что, есть ли что-то, что я могу сделать с проблемой входа через Patreon? Остальные две проблемы я проигнорирую.

В любом случае спасибо за помощь. Вы здесь отлично справляетесь.

6

Привет, Джей, спасибо за помощь. В ответ на ваши вопросы…

Я не ожидаю большого числа пользователей, так как это закрытое сообщество Patreon. Моя главная цель заключалась в том, чтобы обновлять один сервер без остановки сайта. Я фактически подтвердил, что это возможно, поэтому меня устроила такая настройка. Да, я выполнил пятый шаг, поэтому состояние сохраняется на внешнем Redis-сервере (droplet).

Другая проблема, которую мне пришлось решить и которая долго сдерживала меня, заключалась в том, что мне также нужно было добавить следующий параметр в app.yml; в противном случае пересборка постоянно завершалась неудачей, так как система пыталась подключиться к Postgres на порту по умолчанию, несмотря на указание реального порта в параметре DISCOURSE_DB.

DISCOURSE_DB_BACKUP_PORT: 25060

Я не задумывался об загрузках, пока не настроил всё согласно первому руководству. Изначально попытка настроить S3 всё сломала, но это произошло потому, что настройки CDN DigitalOcean Space, которые вы здесь предоставляете, не работают.

В частности, указано, что CDN DigitalOcean не работает с Discourse.

Я знаю, но затем в руководстве нас просят добавить следующее:
DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com

Это же относится к DO Space, верно? Судя по всему, что я прочитал в этих руководствах, я не понимаю, как работать с другим CDN, но сейчас меня это не беспокоит, как я объясню ниже.

Нет, я не использовал другой CDN. Мне вполне подходит вариант без CDN. Я оставлю настройки CDN пустыми. В качестве дополнительного обновления: основываясь на советах, которые вы все так любезно предоставили, я собирался откатиться к резервной копии прошлой недели, но решил сначала попробовать включить опцию force_https. Включение этой опции решило проблему входа через Patreon, как я и предполагал. На серверах ничего не менялось, поэтому проблема с входом через Patreon, вероятно, была вызвана какой-то внутренней логикой Discourse, хотя я также осознаю (теперь), что делаю то, что вы не рекомендуете и не поддерживаете.

Итак, на данный момент моя настройка практически соответствует рекомендациям первого руководства, но изображения и резервные копии сохраняются в S3 без использования CDN. Всё работает отлично. Я понимаю, что вы рекомендуете использовать standalone-установку, но останавливать сайт на 15 минут при каждом обновлении — это действительно болезненно. Только вчера я нашёл ваши ссылки на data.yml и web_only.yml для настройки нескольких серверов, но не смог понять, что именно нужно делать, поэтому отказался от этой идеи.

Я пока буду работать с тем, что у меня есть. Спасибо за вашу помощь и за всё, что вы делаете.

7

Ладно, ребята, вы победили. :slight_smile:

Я снова начал замечать проблемы с загрузкой изображений, потому что их иногда передавали по HTTP, а не по HTTPS. Вы правы, это полный хаос.

Я почти полностью отказался от этой схемы: оставил базу данных PostgreSQL, но вернулся к одному серверу Droplet, без балансировщика нагрузки, а изображения и Redis теперь хранятся локально. Однако я оставил S3 для резервных копий сайта. Мне нравится, насколько плавно это работает.

Похоже, я снова вернулся к пятнадцатиминутным простоям при каждом обновлении, но я уже потратил на это в общей сложности около пяти полных дней, и больше времени тратить не могу. Поэтому я рад, что вы все смогли меня поправить насчет того первоначального руководства, которому я следовал. Чувствуется, будто они просто хотят, чтобы люди платили за больше Droplets. :slight_smile:

Ещё раз спасибо за помощь.

8

На самом деле, если можно, подскажите: есть ли руководство, которое поможет настроить Discourse так, чтобы избежать 15-минутного простоя при каждом обновлении? Я видел заметку о файлах data.yml и web_only.yml, но не имею ни малейшего представления, что именно нужно сделать, чтобы этого добиться.

9

Разделение на отдельные файлы data и web_only связано с двухконтейнерной настройкой:

10

Это сработает и решит некоторые проблемы. И если вы вдруг по какой-то (другой) причине окажетесь заблокированы, вы всегда сможете вернуться, выполнив launcher enter app, и переключить настройку сайта обратно из консоли Rails.

Как уже говорили другие, однако, лучше следовать другому руководству.

11

Привет, ребята,

Я написал статью про DigitalOcean, но, похоже, допустил несколько ошибок — извините!

Хотел бы обновить статью, чтобы исправить эти недочеты.

Поэтому хочу задать несколько вопросов, чтобы убедиться, что в исправленной версии всё будет верно.

В статье я указал, что можно опционально использовать управляемый экземпляр Redis. На тот момент я полагал, что использование sticky-сессий позволит применять встроенный Redis в образе Discourse. Правильно ли это? Возможно, этого недостаточно, и внешний экземпляр Redis должен быть обязательным требованием.

Я согласен с комментарием @Falco относительно Object Storage — это упущение с моей стороны. Я могу обновить статью и добавить инструкции по использованию DigitalOcean Spaces для обработки загрузки изображений.

Подозреваю, что решение проблемы с установкой заключается в полном удалении состояния с Droplets. Я надеялся, что внешний Redis не обязателен благодаря sticky-сессиям, но, возможно, я ошибаюсь.

Также согласен, что это усложняет обновление установки Discourse. Однако, если удалить все данные с Droplets, можно обновить один Droplet, создать его снапшот, а затем заменить остальные Droplets новыми, созданными на основе этого снапшота (немного похоже на Kubernetes Deployments, но процесс развертывания выполняется вручную).

Согласен также, что, вероятно, существуют более эффективные способы масштабирования Discourse. Тем не менее, я всё же хочу исправить статью, чтобы те, кто захочет, могли следовать ей.

Спасибо,
Фрэнсис

12

Я — довольный клиент DigitalOcean, и у меня есть панель управления, где мои клиенты вводят API-ключи и имя хоста, после чего автоматически создаётся Droplet, настраивается Mailgun, ожидается настройка DNS-записей, а затем устанавливается Discourse.

Это вообще не работает так, как вы предлагаете. Я связался с DigitalOcean через ваш форум (другого способа я не нашёл), чтобы сообщить об этом, но моё сообщение было удалено. Затем, через 9 месяцев, вы отвечаете здесь.

Сделать это правильно — довольно сложная задача, а случаи, когда это было бы полезно, довольно надуманны. У меня есть сайт с 100 тысячами просмотров страниц в день на Droplet с 8 ГБ оперативной памяти. Как вы думаете, кто является целевой аудиторией этого руководства?

Да, вам нужны внешние Redis, PostgreSQL и бакеты S3 с CDN, но CDN от DigitalOcean не работает, поэтому ваше руководство должно было бы пошагово объяснять настройку CDN от другой компании. Не думаю, что вы хотите этого. И это только начало настройки. Если затем кто-то захочет выполнить обновление, это потребует совершенно другого набора процедур, с которыми никто, кроме вас, на всей планете не сможет помочь.

Лучшее, что вы могли бы сделать, — удалить это руководство целиком. Если вы хотите стать настоящим героем, вы могли бы исправить установку в один клик, чтобы она не использовала ваш собственный проприетарный скрипт для настройки почты и так далее, чтобы это была стандартная установка. Довольно запутанно, что нужно использовать Control-C, чтобы добраться до Discourse, и поскольку пользователи, использовавшие установку в один клик, не применяли стандартные инструменты Discourse, они не знают, как ими пользоваться, когда приходит время для обновления через командную строку. Было бы действительно, действительно здорово, если бы вы могли это сделать.

Здесь вы можете увидеть людей, которые использовали эту установку и сталкивались с проблемами: Search results for 'digital ocean one-click' - Discourse Meta

13

Нет, поскольку Redis — это не просто кэш, он обрабатывает множество операций подсчёта, ограничения скорости, фоновые задачи, публикацию и подписку (pub/sub). Наличие нескольких экземпляров Redis приведёт к повреждению данных счётчиков и сбоям в работе.

Это действительно решило бы проблему, но добавление управляемого Redis, управляемого PostgreSQL, управляемого балансировщика нагрузки, объектного хранилища и реестра контейнеров также обойдётся дороже, чем просто оплата нашего стандартного хостинга, и потребует значительно больше усилий для поддержки.

В таком случае пересечение между людьми, которые готовы платить сотни долларов в месяц и не возражают, если их сервис упадёт из-за единой точки отказа (SPOF), становится очень небольшим, и такая конфигурация больше напоминает хобби-проект, чем то, что мы рекомендуем администраторам форумов.