Comments 9
Процедура деплоя выглядит адовенько. А как обновлять приложение? Есть инфраструктура вокруг контейнера с приложением но внутри какой-то production-driven development. Вы бы лучше сделали поддержку docker-контейреров, которые можно было встраивать в вашу инфраструктуру, масштабировать и ставить за балансировщик.
Мы показали деплой 2х видов. Простой способ оставили на конец статьи в разделе «Развертывание существующего приложения Django». Идея про Docker просто отличная, очень совпадает с нашим видением будущих обновлений платформы Infobox Jelastic (это мы так пытаемся уйти от комментария на эту тему раньше времени, но намекнуть :) )
Процедура вполне стандарта для python приложений, requirements.txt есть почти во всех популярных приложениях. В этом случае происходит автоматическое разворачивание приложения.
Приложение обновляется по очереди на каждой ноде, если деплоить с дашборда, через ssh тоже никто не мешает, производить деплой на каждой ноде, предварительно остановив Application server, в этом случае на него не будут идти запросы. Как в случае с docker-контейнерами вы будет производить обновление?
Приложение обновляется по очереди на каждой ноде, если деплоить с дашборда, через ssh тоже никто не мешает, производить деплой на каждой ноде, предварительно остановив Application server, в этом случае на него не будут идти запросы. Как в случае с docker-контейнерами вы будет производить обновление?
Процедура деплоя выглядит адовенько.
ну это не совсем процедура деплоя, а скорее создание приложения с нуля уже в контейнере, используя утилиты из проекта django-cms, сам же деплой можно сделать и в один клик, как было тоже указано в посте
А как обновлять приложение?
в джеластике есть обновление с VCS (git/svn), при том автоматическое, что куда более удобно и быстрее чем перезаливать весь контейнер через докер
Вы бы лучше сделали поддержку docker-контейреров, которые можно было встраивать в вашу инфраструктуру, масштабировать и ставить за балансировщик.
и это не за горами, есть PoC, который работает, всему свое время ))
Поправьте меня если я не прав, но mod_wsgi это же что-то очень древнее и неразвивающееся с массой ограничений. Почему не uWSGI?
Вот у меня был подобный же вопрос, но как-то я его не задал. Почему Apache + wsgi, почему не Gunicorn?
В mod_wsgi почти каждую неделю коммиты, почти каждый месяц релиз новый, и какие там ограничения? Все то же вроде умеет, что и другие способы развертывания. Может, с mod_python путаете?
Простите, но Вы таки не правы, последняя версия вышла 18 дней назад
проект нормально себе развивается, еще позвольте уточнить о каких именно ограничениях Вы говорите?
проект нормально себе развивается, еще позвольте уточнить о каких именно ограничениях Вы говорите?
Sign up to leave a comment.
Python на облачном хостинге Infobox Jelastic: запускаем Django CMS