Повторное использование кода флагов python на нескольких разных сайтах

0 Jimmy [2013-09-10 17:59:00]

У меня есть настройка, в которой у меня будет около 50 сайтов с использованием одного и того же кода, настроенных несколько иначе. Вместо того, чтобы развернуть один и тот же код снова и снова, дублироваться в разных папках и репозиториях, есть ли способ в Flask для централизации рабочего кода сайта, как какой-то библиотеки?

В Django у них есть что-то вроде этого:

https://docs.djangoproject.com/en/dev/ref/contrib/sites/

Некоторые идеи

  1. Разверните 50 экземпляров UWSGI, дублируя один и тот же код и другую конфигурацию

  2. Разверните 50 экземпляров UWSGI с добавлением кода python как своего рода модуля или расширения, поэтому есть только один экземпляр кода: http://flask.pocoo.org/docs/extensiondev/

  3. Разверните 1 экземпляр UWSGI, который имеет только один экземпляр кода и обрабатывает разные имена хостов: http://flask.pocoo.org/docs/patterns/appdispatch/

Код, который я дублирую, предназначен для запроса API и отображения результатов. Различия между сайтами в два раза:

  1. Templating - Хотя сайты будут выглядеть одинаково, они не будут одинаковыми. Они будут иметь немного разные CSS и изображения.

  2. Запрос API. Большинство небольших объектов предназначено для городов и поселков. Это означает, что запрос API с этих сайтов будет слегка изменен, чтобы возвращать результаты только в этой области.

    • sitelondon.com может запросить api для предметов только в Лондоне по умолчанию
    • sitehtml.com может запрашивать api для элементов, у которых есть ключевое слово "html" по умолчанию

Фокус на моем конце - это производительность для пользователя. Я буду запускать их первоначально на сервере с 2 ГБ оперативной памяти, который должен быть много. Любая помощь или идеи будут высоко оценены, спасибо.

performance python django flask wsgi

Оригинал вопроса (на английском)

2 ответа

2 Решение Paolo Casciello [2013-09-10 18:15:00]

Обычно для этих типов сценариев в приложении встроена логика "ведет себя по-разному на основе хоста".

Поэтому лучшим решением является №3, но мое предложение состоит в том, чтобы не использовать диспетчер приложений.

Создайте логику, чтобы получить конфигурацию имени hostname непосредственно в главном приложении (например, вы можете загрузить специализированные конфигурации в обработчике @before_request и использовать один экземпляр DB). Если вы планируете использовать только один небольшой сервер, как вы сказали, это решение легко освещает ресурс.

50 различных экземпляров uWSGI со своими собственными процессами заполнят вашу память и легко переключаются между собой.

Оригинал ответа (на английском)

1 Miguel [2013-09-10 19:27:00]

Я согласен с @Paolo, что №3 - ваш лучший вариант.

Вы можете еще больше упростить его с помощью перезаписи URL-адресов на вашем веб-сервере. Если вы переписываете URL-адреса таким образом, чтобы запрос для http://sitelondon.com/example стал http://sitelondon.com/london/example, а запрос для http://sitehtml.com/example стал http://sitehtml.com/html/example то вы можете легко получить сайт по маршрутам:

@app.route('/<site>/example')
def example(site):
    return render_template(site + '/example.html')

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

Надеюсь, это поможет!

Оригинал ответа (на английском)