После недели поисков решения для установки Discourse рядом с Apache я вынужден обратиться за советом относительно дальнейших шагов, так как, судя по всему, включение SSL для Discourse за Apache практически невозможно из-за ориентации Discourse на Nginx.
Текущая структура моей хостинговой среды:
Droplet за $10 от Digital Ocean
Ubuntu 18.04
Apache с SSL Let’s Encrypt для главной HTML-страницы
PHP, MySQL и phpMyAdmin
Webmin (без SSL)
Discourse
Я хотел бы сохранить возможность установки WordPress, поэтому не уверен, что Nginx — правильный выбор, так как, как я читал, Apache обеспечивает лучшую совместимость с WordPress.
Моя цель: включить SSL для всего домена, включая Discourse, без необходимости выделять для Discourse отдельный Droplet. Если для этого потребуется ограниченное использование Nginx — это допустимо. Мне просто нужно понять, какие руководства стоит изучить, чтобы разобраться в этой ситуации.
Я ищу что-то подобное, но вы уже продвинулись дальше в процессе. У меня есть несколько вопросов по вашей конфигурации, на которые я не уверен в ответах, если вы не против ответить.
У вас есть обратный прокси?
Обеспечивает ли обратный прокси SSL?
Не используют ли другие серверы SSL и полагаются ли они на обратный прокси для его обеспечения, или вы применяете стратегию «защита в глубину» (defense in depth), где каждый сервер самостоятельно обеспечивает SSL?
Осуществляется ли связь между обратным прокси и серверами исключительно через сокеты, а не порты?
К сведению: я провёл обширное тестирование как с Apache2, так и с nginx в роли обратных прокси-серверов перед Discourse в продакшене (с использованием unix-сокетов), и nginx не оказывается «значительно быстрее».
В такой конфигурации nginx работает «немного быстрее», но разница в скорости незаметна для пользователя.
Кроме того, тесты Google PageSpeed в инструментах для вебмастеров (LightSpeed), усреднённые по времени, не показывают каких-либо существенных различий между двумя обратными прокси-серверами.
Это замечание «к сведению» основано не на теории и не на повторении того, что писали другие, а на реальных тестах в продакшене.
Мы запускаем все наши экземпляры Discourse за обратными прокси-серверами Apache2 (изначально они были nginx), потому что нам удобно размещать множество веб-сайтов (виртуальных хостов) на наших серверах, где уже работают LAMP-приложения.
Любой, кто захочет использовать Apache2 в качестве обратного прокси вместо nginx, будет полностью доволен! Этот факт делает Discourse легко доступным для широкого круга пользователей и хостинг-провайдеров (как Apache2, так и nginx).
@fzngagan Я не начинаю заново, и этот учебник предназначен для CentOS, тогда как я чётко указал в своём посте, что использую Ubuntu.
@EricGT Посмотрите решение, которое я опубликовал в своей же теме, потому что найти поддержку, если вы используете что-то кроме Nginx или CentOS, практически невозможно — что подтверждается этой темой, где на мой вопрос не было получено ни одного ответа, а вместо этого развернулась не по теме дискуссия о сравнении Apache и Nginx.
Это вполне может быть так, но Apache имеет более широкую поддержку. Discourse — это единственное форумное программное обеспечение, которое фактически навязывает своим пользователям Nginx. Именно поэтому я предпочитаю остаться на Apache, так как он более распространён, проще для новых пользователей, и поддержку найти гораздо легче. «Настройка» (tuning) — это не то, что меня интересует.
Однако сообщество Discourse активно отговаривает от этого и отказывается предоставлять поддержку тем, кто хочет использовать Apache, за исключением ссылок на неподдерживаемые учебники. Я создал несколько тем и задал ещё больше вопросов, но только вы хоть отдалённо подошли к оказанию поддержки (в другой теме), поделившись своей конфигурацией, и от новичка ожидалось, что он сам разберётся и применит её к своей системе. Всё остальное сводилось к «посмотрите этот устаревший учебник» или не по теме перепалкам.
Как мы неоднократно чётко указывали, из-за ограничений по времени и сохранению рассудка у нас есть предел того, что мы можем поддерживать бесплатно. Вот почему у нас есть стандартизированная установка, которая отлично работает для 95% пользователей, которые её пробуют, и мы полностью её поддерживаем.
Если вы хотите рассмотреть варианты платной поддержки для кастомизированных установок, рекомендую канал Marketplace.
Этот форум в значительной степени работает по принципу «равный — равному», поэтому ваше заявление не имеет никакого смысла. Более того, я ещё не задавал сложных вопросов, лишь запрашивал уточнения или обновления существующих руководств, на которые постоянно ссылаются, несмотря на их устарелость или некорректность. Мне пришлось обратиться за помощью в DigitalOcean, хостинг-провайдере, чтобы настроить правильный обратный прокси. Это поражает воображение, даже для программного обеспечения с открытым исходным кодом.
Ваш ответ создаёт впечатление, что «поддержка» здесь — это лишь показуха для навязывания платных услуг.
Во-первых, мы используем Discourse в продакшене за обратным прокси Apache2 (в нескольких экземплярах) и не столкнулись с какими-либо проблемами при его настройке, кроме обычного «погуглить, если нужна помощь», что делает каждый без колебаний.
Во-вторых, я никогда не просил команду Discourse или кого-либо на meta поддерживать Apache2 в качестве нашего обратного прокси, поскольку эта конфигурация официально не поддерживается. Насколько мне известно, Discourse не «официально» поддерживает многоконтейнерные конфигурации, обратные прокси (Apache2), Kubernetes, Docker Swarm и бесчисленное множество других конфигураций. Это понятно и правильно, что команда Discourse, которая бесплатно предоставляет это замечательное программное обеспечение и открывает весь исходный код, каждый коммит на Github, ограничивает свои «официально поддерживаемые конфигурации». Я считаю, что Джефф очень точно и правильно это сформулировал:
Ну, как мы неоднократно четко заявляли, из-за ограничений по времени и нервам существует предел тому, что мы можем поддерживать бесплатно здесь. — Джефф А.
В-третьих, Discourse предоставляет ряд руководств для «неподдерживаемых» конфигураций, например, для Apache2 в качестве обратного прокси; однако настройка обратного прокси сама по себе не является «задачей Discourse». Настройка обратного прокси — это «общая задача системного администратора», которая по сути одинакова для любого бэкенд-приложения, включая Discourse.
Мы используем Apache в качестве обратного прокси перед множеством веб-приложений, включая Discourse, Docker Registry и другие Docker-контейнеры и приложения. Использование Apache2 (или nginx) в качестве обратного прокси не имеет прямого отношения к Discourse. Это общая задача системного администратора.
В-четвертых. В интернете множество информации о том, как настроить Apache2 в качестве обратного прокси для приложения. Абсолютно бессмысленно и бесполезно для вашего дела запугивать команду Discourse по этому поводу. Запугивание людей и использование таких терминов, как «фарс», неточно и не помогает вашему делу (или никому здесь).
Итак, чтобы подытожить для вас, @OrbitStorm (это мой последний пост в вашей теме, поэтому, пожалуйста, прочитайте внимательно), что было сказано ранее, включая добрые и терпеливые слова Дж. А., у вас есть много вариантов.
Вы можете легко найти в интернете информацию о том, как настроить Apache2 в качестве обратного прокси (мы так и сделали), и это увлекательно и бесплатно — научиться выполнять эту общую задачу системного администратора.
Вы можете нанять кого-то, кто сделает это за вас, если вы не хотите учиться, не можете «разобраться» самостоятельно или у вас нет времени.
Вы можете написать здесь, ругаться и кричать, называя meta и этот форум «фарсом», и оскорблять всех, пытаясь запугать их и заставить поддержать вас лично в неподдерживаемой конфигурации.
Как пользователь Discourse и системный администратор с многолетним стажем, я настоятельно рекомендую вам не выбирать вариант №3 (запугивание и давление не сработают с командой meta, я могу вас в этом завершить); и рассмотреть вариант №1, если вы не хотите тратить деньги на помощь.
Настройка Apache2 в качестве обратного прокси для Discourse на самом деле довольно проста. Есть несколько постов на meta Discourse на эту тему (некоторые актуальные, некоторые устаревшие), и в интернете бесчисленное количество руководств о том, как настроить Apache2 в качестве обратного прокси для веб-приложения. Техника одна и та же. Я рекомендую использовать unix-сокет при работе в режиме обратного прокси.
Честно говоря, настраивать Apache2 в качестве виртуального хоста-обратного прокси для Discourse — это увлекательно. Зачем делать это стрессовым и писать оскорбления людям, которые создали это замечательное программное обеспечение и дарят его бесплатно? Discourse — это бесплатный подарок! Если вы хотите настроить Discourse иначе, чем в официально поддерживаемых конфигурациях, никто вас не остановит!
В заключение, @OrbitStorm, я настоятельно рекомендую вам (говоря как пользователь Discourse, а не член команды) изменить свой подход к запугиванию meta ради поддержки. Как я уже сказал, я использую Discourse в «неофициально поддерживаемых» конфигурациях и публиковал здесь обновления и код, чтобы помочь другим (возвращая долг этому замечательному сообществу). Я уже опубликовал рабочий код, который легко следовать для настройки Apache2 в качестве обратного прокси, как и многие до меня.
Пожалуйста, выберите либо вариант №1 (сделайте это сами), либо вариант №2 (наймите кого-то, кто сделает это); и прекратите ваш текущий подход №3 (запугивание, давление и оскорбления команды meta). Если вы хотите выбрать вариант №3, идите и пишите на наших форумах по Unix и Linux, и вы можете запугивать меня там, сколько захотите
Вы написали этот простыню текста в ответ, так и не затронув исходную тему, в тщетной попытке выступить в роли белого рыцаря за то, что даже не подвергается нападению. Вы фактически назвали меня «буллом» (lol?), потому что я ответил на вне темный бред от парня, который сыпал на меня оскорблениями в адрес моего интеллекта и превратил эту ветку в трибуну для обсуждения Nginx (комментарии, которые удобно удалили, чтобы скрыть доказательства токсичной среды, которую этот форум создает для новых пользователей). Ваш первый пост был не лучше: вы ответили на мой вопрос, но по сути не ответили на него. Вы — часть проблемы.
Вы постоянно говорите об обязательствах, а сами упорно отвечаете на мои темы только для того, чтобы спорить (как это делал Стивен). Я не знал, что существует правило, запрещающее мне просить поддержки для популярной конфигурации хостинга (ранее упоминался W3Techs, и там показано 67% доля Apache). Вы могли бы просто оставить мои темы без ответа, если бы не одобряли их, но вы выбрали быть агрессивными и сорвать обсуждение.
Вы намеренно искажаете мои слова, потому что я не подчиняюсь статусу-кво, который требует принять устаревший учебник и больше никогда не возвращаться — именно это является причиной того, что практически все ветки, касающиеся этой настройки, остаются нерешенными (т. е. травля со стороны таких парней, как вы). Вы действительно думаете, что я не провел должную проверку перед публикацией? Я ожидал того, что знал, но надеялся, что другие, кто может оказаться в моей ситуации (как EricGT), предложат что-то ценное, прежде чем это будет затоптано в пыль высокомерными «ответами».
Я занимаюсь разработкой игр уже 16 лет и никогда не сталкивался с таким безумным уровнем непрофессионализма и мелочности, как здесь, всего за пять коротких дней. Это какой-то уровень Reddit-ной глупости; абсолютный позор.
Мне не понятно, почему конфигурация SSL должна как-то влиять на приложения за прокси , если шаблон SSL отключён в app.yml? Nginx, Apache, HAProxy или Traefik — у всех есть схожая концепция snippet/serverblock/virtualhost, где вы просто указываете включение SSL, путь к сертификатам на хосте и несколько параметров SSL; здесь могут быть подводные камни.
Думаю, решение, которое вы ищете, связано не с Discourse, а с Apache. Я считаю, что любая рабочая конфигурация SSL Apache с виртуальным хостом «из коробки» будет нормально работать с Discourse, как это уже было с другими обратными прокси, но, возможно, я слишком оптимистичен .
Хотя помню, что у меня возникали проблемы, возможно, с шифрами; убедитесь, что вы аккуратно скопировали/вставили (строка очень длинная) те, что используются внутри Docker-контейнера.
Насчёт этого скользкого склона: думаю, это скорее катание вне трассы — здорово, но спасатели на горе это крайне не одобряют. И я признаю, что это выглядит совсем иначе, когда ты падаешь в овраг, ещё только учась кататься, а не будучи опытным лыжником.
Пожалуйста, профессионал вы или нет, будьте добры к
, если шаблон SSL отключён в app.yml? Nginx, Apache, HAProxy или Traefik — у всех есть схожая концепция snippet/serverblock/virtualhost, где вы просто указываете включение SSL, путь к сертификатам на хосте и несколько параметров SSL; здесь могут быть подводные камни.
.