Общие тома в App.yml для настройки двух веб-сайтов

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

Я хотел бы изменить свой app.yml, чтобы запустить ещё один экземпляр Discourse (отдельный контейнер, отдельная база данных, всё, что только можно представить — для переносимости) на той же машине (работающей за nginx).

Итак, моя первая настройка выглядит так (важные части):

## app.yml для site01
volumes:
  - volume:
      host: /var/discourse_site01/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse_site02/shared/standalone/log/var-log
      guest: /var/log

.. и это работает отлично — экземпляр онлайн, всё в порядке. Теперь я хочу запустить ещё один экземпляр Discourse, для которого я подготовил общие тома следующим образом в другом app.yml:

## app.yml для site02
volumes:
  - volume:
      host: /var/discourse_site02/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse_site02/shared/standalone/log/var-log
      guest: /var/log

Есть ли какие-либо подводные камни в этой второй настройке? Я запускаю это на продакшн-машине, поэтому хотел перепроверить, что этот app.yml составлен правильно.

2

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

Можете ли вы подробнее рассказать об использовании nginx? Есть ли на этой же машине другие продакшн-сервисы?

3

@Stephen: nginx — это просто обратный прокси для первого экземпляра Discourse. Ничего сложного. На самом деле, настройка соответствует той, которую я следовал на meta.discourse, чтобы настроить nginx как фронтенд-сервер.

На машине не запущены никакие другие службы. Более того, поскольку это продакшн-сервер, я развернул всё в полностью отдельной папке хоста discourse_site02. Имеет ли это смысл?

Вы видите какие-либо проблемы в описанном мной app.yml? Или, по вашему мнению, что-то не так с моей конфигурацией?

4

Неужели нет причин не использовать мультисайтовую установку в двух контейнерах? Не думаю, что вы здесь теряете в переносимости: самый быстрый способ переноса экземпляров между серверами — это миграция резервной копии.

Если вам потребуется перенести экземпляр, вы просто поднимете новый сервер, пометите старый экземпляр как доступный только для чтения, перенаправите DNS и восстановите резервную копию. При использовании сервиса с низким TTL, такого как Cloudflare, для управления DNS, небольшой сайт можно мигрировать за несколько минут. Пользователи столкнутся лишь с кратковременным периодом доступа только для чтения, при этом никакой контент не будет потерян.

Такое разделение ресурсов гораздо эффективнее: вам не придётся запускать два сервера баз данных и два веб-сервера в отдельных контейнерах, а также полностью отпадает необходимость в обратном прокси-сервере nginx.

5

@Stephen: да, я видел ссылку, которую вы показали, но для простоты настройки (у нас небольшая команда с небольшим опытом) я хотел бы сделать это так, как я описал: в итоге получится две базы данных и два веб-сервера и т. д. Фактически это именно та конфигурация, которую я предпочитаю.

Кроме неэффективностей, на которые вы указали, есть ли какие-либо другие подводные камни?
Правильны ли два файла app.yml, которые я показал?

Спасибо за ваше время и за отличное программное обеспечение :smile:

С наилучшими пожеланиями

6

@Stephen: просто хотел уточнить, считаете ли вы, что моя конфигурация для настройки из двух контейнеров выглядит правильно?

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