Краткая история о том, как развернуть веб-сервер Flask в docker контейнере

[andreymal]

Очень жаль, что в посте так и не продемонстрирована эта самая проблема «настройки окружения для разработки». Для проекта в том виде, в котором он здесь показан, просто поставить питон и просто запустить pip install гораздо проще, чем вся эта возня с докером.

А учитывая, что многие проекты в принципе ничего кроме pip install и не требуют — стороннему наблюдателю так и останется неочевидно, зачем вообще нужен докер, да и контейнеры в принципе.

[DuMoH112]

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

[AlexGluck]

Вот в среду как раз пытался проделать трюк с pip install. Пришлось ставить с десяток пакетов из репы, подключать отдельную репу, потом делать pip install и получалось, что у меня в системе оставались сборочные тулы, которых там быть не должно. Не все проекты такие простые, докер действительно экономит время на настройку окружения.

[DuMoH112]

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

[bDrwx]

poetry должна решить эту проблему.

[andreymal]

Это говорит о том, что кто-то в цепочке разработчиков безответственно относится к своей работе. Нормальным Python-проектам не требуется ставить никакие сборочные тулы. Докер здесь будет костылём, затыкающим симптом, а настоящее решение проблемы — повышение дисциплины разработчиков.

[JTG]

В мире python иной раз и сам python собирать приходится с нужными флагами, а уж пакеты-то и подавно. Не всё можно в wheel засунуть.

[andreymal]

Для среднестатистического формошлёпства на фласках и прочих джангах подобное не требуется, а всё, что обычно может понадобиться (Pillow, lxml, numpy и прочие такие радости жизни) уже давно засунуто в wheel.

[danny_briskin]

Вот почему сегодня статья, а не вчера? Вчера полдня убил на это ;-)

Насколько я понимаю, они(flask) советуют в продуктиве не flask сервер а waitress использовать.
Имеет смысл?

[DuMoH112]

Я хотел её вчера выложить, но получилось только сегодня =)
За waitress ничего не знаю, мне больше gunicorn приглянулся по возможностям. Но никто не говорит, что waitress нельзя использовать)

[1van-s]

Спасибо за статью!

Возможно, будет полезно оговориться, что создание Flask app с помощью функции — это паттерн Application Factory. Для докеризации проекта или использования Application server (gunicorn etc.) он не является обязательным.

Application Factory подразумевает, что конфиг приложения производится при инициации приложения, именно поэтому app.config.update находится внутри функции создания приложения.

После добавления в проект gunicorn (который, кстати, насколько я знаю требует установки пакета — и как следствие, добавление в requirements.txt) app/main.py по сути становится не нужным, т.к. локально мы можем также запускать проект с помощью gunicorn.

Кстати, использование Application factory, позволяет не указывать HOST и PORT в коде/вместо явного указания в docker-compose.yml, а менеджерить их на уровне конфига приложения.

Кроме плюшек, Application factory накладывает и ограничения. Например, некоторые дополнения для Flask подразумевают явное указание app при инициации (пример — ORM Peewee). Как результат, нужно или изобретать костыли (в случае с Peewee — DatabaseProxy()) или использовать проекты, где реализованы Extentions с функцией someextention.init_app(app) для вызова внутри Application factory.

Необходимость Flask Blueprints здесь оправдывается из-за того, что для регистрации роута в явном виде необходимо указывать приложение — но ту же проблему можно было бы решить функцией add_url_rule, если приложение пока не модульное и в будущем потребность может возникнуть. Тогда вместо blueprint было бы что-то такое:

def hello_world():
    return "<h1>Hello, World!<h1>"

def route(app):
    app.add_url_rule("/", view_func=hello_world)