Comments 27
Я постараюсь описать идеальные варианты настройки тестового веб-севера, хотя понимаю, какой бардак на них обычно творится.
Тестовый стенд не должен быть идеальным, он должен архитектурно соответствовать продакту. А маленький срачЪ в qa env — всегда соответствует большой «помойке» на проде.
Да и вообще, вы всю дорогу тёплое и мягкое путаете.
Если есть несколько независимых команд, то нужно поставть балансировщик, прописать upstream's, и для особо буйных команд сливать реквесты а) в контейнеры или б) на выделенные хосты, а уже там должны сидеть ваши *cgi и ci-agent, да билдить и управлять всей хурмой из vcs's.
И отдельным пунктом хотелось бы отметить, что virtualenv дальше компа разработчика уходить не должен. Надо стороннюю библиотеку на сервере — соберите пакет и используйте локальную репу для деплоя, а с setuptools, pip и gcc обращаться надо осторожно, а лучше вообще не дружить.
Про контейнеры понимаю, но вот про
как-то первый раз слышу. И вообще, часто встречаю virtualenv в продакшне, и мне он там вполне нравится.
Не могли бы вы обосновать этот пункт поподробнее или ссылочкой кинуть?
virtualenv дальше компа разработчика уходить не должен
как-то первый раз слышу. И вообще, часто встречаю virtualenv в продакшне, и мне он там вполне нравится.
Не могли бы вы обосновать этот пункт поподробнее или ссылочкой кинуть?
А теперь добавьте туда ruby с его менеджером пакетов, nodejs, и еще пяток интерпретаторов, накатите по 10 — 15 пакетов в каждом, а потом попробуйте понять, что у вас лежит на сервере. И как его собрать заного. Все что запускается на сервере должно устанавливаться из пакетов, иначе вы получаете помойку, которая не может поддерживаться без вечно устаревающей документации и человека обладающего божественным знанием как его собрать.
Не понимаю, чем знание
божественнее, чем, скажем
А если к этому добавить ещё и сборку в пакеты всех библиотек, которые есть в PyPy/Registry, но нет в репо целевой ОС (целевых ОС), управление частным репо, управление ключами… Оно действительно вам надо?
pip install -r requirements
bower install
божественнее, чем, скажем
sudo dpkg --set-selections < ~/Package.list
sudo dselect
А если к этому добавить ещё и сборку в пакеты всех библиотек, которые есть в PyPy/Registry, но нет в репо целевой ОС (целевых ОС), управление частным репо, управление ключами… Оно действительно вам надо?
Разница в том, что с dpkg вы используете бинарные пакеты, собранные один раз в правильном окружении, а pip install вызывает gcc и билдит модули при каждом деплое.
Кейсов тут несколько:
1. Если вы захардкорили версии зависимостей во избежании dependencies hell, то никто вам не гарантирует, что данный конкретный пакет будет доступен всегда. В один их тех самых доджливых вечеров в четверг, pip вам скажет, что нужного пакета нет.
2. Вы уверены, что все -devel файлы, которые используюся при компиляции — идентичны? И что unexpected behaviour на callback внешней функции в продакте не настигнет вас через 2 месяца после того самого дождливого четверга, а вы как на зло с семьей посредине средиземного моря на лайнере?
3. Компилятора на сервере быть не должно.
Да, поддерживать все это в приличном состоянии можно, стóит это неимоверных усилий, но моментально рассыпается под шаловливыми руками отдельно взятых личностей. Такие дела, и всё это уже сто раз проходили в связке perl + cpan.
Кейсов тут несколько:
1. Если вы захардкорили версии зависимостей во избежании dependencies hell, то никто вам не гарантирует, что данный конкретный пакет будет доступен всегда. В один их тех самых доджливых вечеров в четверг, pip вам скажет, что нужного пакета нет.
2. Вы уверены, что все -devel файлы, которые используюся при компиляции — идентичны? И что unexpected behaviour на callback внешней функции в продакте не настигнет вас через 2 месяца после того самого дождливого четверга, а вы как на зло с семьей посредине средиземного моря на лайнере?
3. Компилятора на сервере быть не должно.
Да, поддерживать все это в приличном состоянии можно, стóит это неимоверных усилий, но моментально рассыпается под шаловливыми руками отдельно взятых личностей. Такие дела, и всё это уже сто раз проходили в связке perl + cpan.
pip install может не вызывать gcc каждый раз, а ставить пакеты из wheel-кэша. Wheels можно собирать и на другом сервере.
Хотя я ещё не настолько параноик, чтобы удалять gcc с сервера. Я вообще не помню ни одной массово эксплуатируемой уязвимости с участием gcc.
Хотя я ещё не настолько параноик, чтобы удалять gcc с сервера. Я вообще не помню ни одной массово эксплуатируемой уязвимости с участием gcc.
А dpkg не скажет? Pip хотя бы может тянуть из репа, который может быть вашим, и расположен в том месте, за которое можете сами ручаться.
Компилятора на сервере быть не должно из-за того, что злоумышленник придет и скомпилирует что-нибудь? Можно и статические библиотеки принести.
Компилятора на сервере быть не должно из-за того, что злоумышленник придет и скомпилирует что-нибудь? Можно и статические библиотеки принести.
А потом вам понадобится срочно еще какая-то либа на racket, для какого-то скрипта, немножко php что в пакетах не было, и еще что-нибудь, главное чтоб у него свой менеджер пакетов был, а может и инсталлятор в виде скрипта, в хомяк аль в opt положит мину.
В документацию записать забудут сей факт, человечек который это сделал станет не доступен.
И однажды вам понадобится развернуть сервис на новом железе (и очень срочно).
Развернете вы (debian | red-hat | sled), накатите пакеты менеджером, потом pip, потом bower, в общем все по доке.
Вот только не получится каменный цветочек. А начальство шумит, пальчиком грозится. И в думу вы погрузитесь, печальную. ))
И не вспоминайте про chef, puppet, salt, это по сути один из способов документирования ваших сервисов.
В документацию записать забудут сей факт, человечек который это сделал станет не доступен.
И однажды вам понадобится развернуть сервис на новом железе (и очень срочно).
Развернете вы (debian | red-hat | sled), накатите пакеты менеджером, потом pip, потом bower, в общем все по доке.
Вот только не получится каменный цветочек. А начальство шумит, пальчиком грозится. И в думу вы погрузитесь, печальную. ))
И не вспоминайте про chef, puppet, salt, это по сути один из способов документирования ваших сервисов.
Решение этой проблемы, если я вас правильно понял − создать собственный deb-репозиторий и добиться того, чтобы проект можно было развернуть только при помощи этого репозитория, без использования иных пакетных менеджеров, кроме apt?
Спасибо, но я с тем же успехом упакую проект целиком, со всеми незадокументированными вовремя какашками, в wheel. Он гарантированно развернётся. Правда, обновления безопасности для компонентов я не получу. Но это в любом случае требует разработчика. Просто wheel-репозиторий требует Python-разработчика, а переупаковка всего проекта или библиотек, которых нет в системном репо или которые в нём устарели, в deb-пакеты требует Python-разработчика, умеющего dpkg-buildpackage и прочую чорную магию. Либо выделить отдельную человекоединицу для упаковки пакетов, а этого далеко не всякий бюджет выдержит. Проще обойтись толковым пайтонистом кмк.
Правда, тут ниже мне уже советуют использовать Docker. Я так понимаю, что установив проект со всеми его сюрпризами в контейнер LXC, можно при помощи Docker сохранить снимок этого контейнера и деплоить проект из этого снимка. Я не знаю подводных камней этого процесса, но выглядит всяко проще, чем создавать deb-пакет на каждый чих.
Спасибо, но я с тем же успехом упакую проект целиком, со всеми незадокументированными вовремя какашками, в wheel. Он гарантированно развернётся. Правда, обновления безопасности для компонентов я не получу. Но это в любом случае требует разработчика. Просто wheel-репозиторий требует Python-разработчика, а переупаковка всего проекта или библиотек, которых нет в системном репо или которые в нём устарели, в deb-пакеты требует Python-разработчика, умеющего dpkg-buildpackage и прочую чорную магию. Либо выделить отдельную человекоединицу для упаковки пакетов, а этого далеко не всякий бюджет выдержит. Проще обойтись толковым пайтонистом кмк.
Правда, тут ниже мне уже советуют использовать Docker. Я так понимаю, что установив проект со всеми его сюрпризами в контейнер LXC, можно при помощи Docker сохранить снимок этого контейнера и деплоить проект из этого снимка. Я не знаю подводных камней этого процесса, но выглядит всяко проще, чем создавать deb-пакет на каждый чих.
Не люблю магию, github.com/jordansissel/fpm, нарисуйте скрипты чтоб билдить все что вам нужно, привяжите их к бил серверу, артефакты автоматом на репозиторий. Добавьте puppet, salt, chef, bash, docker и тд для развертывания инфраструктуры целиком.
Как то так. Это в общем одна из задач системного администратора обеспечивающего поддержку разработки.
Менеджеров пакетов под разные языки куча, бывает что сервис работает, написан например на erlang, а разработчика нет. rebar, pecl, pip, lein, gem, cabal, stack и тд. С тем же pip я последний раз сталкивался 2 года назад, с rebar 4 года назад, lein вчера, gem пару месяцев назад, cabal — неделю назад. У каждого языка своя инфраструктура, вы их все тащите на прод? В общем это дело хозяйское, но мой опыт в администрировании склоняет меня в сторону пакетирования. Это потом сильно проще, и обеспечивает заменяемость людей.
Как то так. Это в общем одна из задач системного администратора обеспечивающего поддержку разработки.
Менеджеров пакетов под разные языки куча, бывает что сервис работает, написан например на erlang, а разработчика нет. rebar, pecl, pip, lein, gem, cabal, stack и тд. С тем же pip я последний раз сталкивался 2 года назад, с rebar 4 года назад, lein вчера, gem пару месяцев назад, cabal — неделю назад. У каждого языка своя инфраструктура, вы их все тащите на прод? В общем это дело хозяйское, но мой опыт в администрировании склоняет меня в сторону пакетирования. Это потом сильно проще, и обеспечивает заменяемость людей.
Про virtualenv — согласен. Но на дворе 2015, девелоперы привыкли, а у OPs появился докер. Это снимает проблему «чёрт знает что у нас требует хрен знает чего».
В качестве внешнего сервера можно использовать и Apache, но больше подходят на эту роль легковесные nginx
Тогда зачем вы рассматриваете монстра apache со стариком mod_wsgi?
Ну, я его особо и не рассматриваю в роли фронтенда. Хотя, с другой стороны, чем не фронтенд? Монструозность Apache сильно преувеличена, зато в его конфигурацию намного проще въехать, чем в конфиг того же nginx.
зато в его конфигурацию намного проще въехать, чем в конфиг того же nginx.
Не согласен, вы просто с ним не разобрались, что может быть проще?
пример конфига
upstream myappbackend {
server 127.0.0.1:14001 max_fails=3 fail_timeout=1s;
server 127.0.0.1:14002 max_fails=3 fail_timeout=1s;
server 127.0.0.1:14003 max_fails=3 fail_timeout=1s;
server 127.0.0.1:14004 max_fails=3 fail_timeout=1s;
}
server {
listen 4.5.6.7:80;
server_name example.com;
access_log /var/log/nginx/myapp.log main;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-Ip $remote_addr;
proxy_pass http://myappbackend/;
}
}
А насчет монструозности, можете посмотреть например это.
Примеров в сети хватает для любого python-приложения, у вас оно кстати на каком фреймворке?
что может быть проще?
Вы правы, наверное. Дело привычки.
Насчёт монструозности − там по ссылке автор приводит зачем-то конфигурацию железа, но вообще ничего не пишет про конфигурацию Apache и nginx. Скорее всего, он действительно сравнивает nginx с mpm-prefork, на что ему и попеняли в комментариях.
Вот, на мой взгляд, несколько более корректное сравнение. В нём, по крайней мере, говорится о том, какой модуль использовался. Стабильный mpm-event и nginx идут ноздря в ноздрю.
Фреймворк − чаще всего Django.
Ну на вкус и цвет… У меня apache ассоциируется только почему-то с php.
У tornado, например, есть замечательный балансировщик, который сам разбрасывает запросы по инстансам и ядрам, а как будет вести себя apache — мне очень интересно, если учесть, что apache обрабатывает каждый запрос в отдельном процессе/потоке, в отличие от nginx (поправьте если не прав).
Использование apache только как прокси для python-приложения скажется на производительности, — на пиках вы это увидите. В nginx вы эту проблему легко решите масштабированием (как простой пример, дополнительными upstream'ами на других серверах).
У tornado, например, есть замечательный балансировщик, который сам разбрасывает запросы по инстансам и ядрам, а как будет вести себя apache — мне очень интересно, если учесть, что apache обрабатывает каждый запрос в отдельном процессе/потоке, в отличие от nginx (поправьте если не прав).
Использование apache только как прокси для python-приложения скажется на производительности, — на пиках вы это увидите. В nginx вы эту проблему легко решите масштабированием (как простой пример, дополнительными upstream'ами на других серверах).
если учесть, что apache обрабатывает каждый запрос в отдельном процессе/потоке
Уже нет. Как сейчас помню:
- в версии 2.0 код, отвечающий за запуск обработчиков запросов, выделили в отдельные модули (mpm_*),
- в 2.2 появился мультипотоковый обработчик mpm_worker,
- в 2.4 стабилизировался mpm_event, который на том графике внизу, рядом с nginx.
Ваша ссылочка на Performance от 2012 года, да и моя не надолго от вас ушла.
Свежих тестов не нашел, самому гонять — не до этого, да и уже не мой профиль.Так что останемся при своих, на днях еще буду шерстить, если что сюда отпишусь.
Для затравки http://habrahabr.ru/post/210950/
В любом случае, спасибо за стью, плюс.
Свежих тестов не нашел, самому гонять — не до этого, да и уже не мой профиль.Так что останемся при своих, на днях еще буду шерстить, если что сюда отпишусь.
Для затравки http://habrahabr.ru/post/210950/
В любом случае, спасибо за стью, плюс.
-
А не проще ли будет взять какой-нибудь Docker? Тогда и окружение будет стандартизированным везде, и на dev и на prod.
Sign up to leave a comment.
Мысли о развёртывании веб-приложений на тестовом сервере