Pull to refresh

Comments 27

Я постараюсь описать идеальные варианты настройки тестового веб-севера, хотя понимаю, какой бардак на них обычно творится.

Тестовый стенд не должен быть идеальным, он должен архитектурно соответствовать продакту. А маленький срачЪ в qa env — всегда соответствует большой «помойке» на проде.

Да и вообще, вы всю дорогу тёплое и мягкое путаете.
Если есть несколько независимых команд, то нужно поставть балансировщик, прописать upstream's, и для особо буйных команд сливать реквесты а) в контейнеры или б) на выделенные хосты, а уже там должны сидеть ваши *cgi и ci-agent, да билдить и управлять всей хурмой из vcs's.

И отдельным пунктом хотелось бы отметить, что virtualenv дальше компа разработчика уходить не должен. Надо стороннюю библиотеку на сервере — соберите пакет и используйте локальную репу для деплоя, а с setuptools, pip и gcc обращаться надо осторожно, а лучше вообще не дружить.
Про контейнеры понимаю, но вот про

virtualenv дальше компа разработчика уходить не должен

как-то первый раз слышу. И вообще, часто встречаю virtualenv в продакшне, и мне он там вполне нравится.

Не могли бы вы обосновать этот пункт поподробнее или ссылочкой кинуть?
А теперь добавьте туда ruby с его менеджером пакетов, nodejs, и еще пяток интерпретаторов, накатите по 10 — 15 пакетов в каждом, а потом попробуйте понять, что у вас лежит на сервере. И как его собрать заного. Все что запускается на сервере должно устанавливаться из пакетов, иначе вы получаете помойку, которая не может поддерживаться без вечно устаревающей документации и человека обладающего божественным знанием как его собрать.
Не понимаю, чем знание
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.
pip install может не вызывать gcc каждый раз, а ставить пакеты из wheel-кэша. Wheels можно собирать и на другом сервере.

Хотя я ещё не настолько параноик, чтобы удалять gcc с сервера. Я вообще не помню ни одной массово эксплуатируемой уязвимости с участием gcc.
А dpkg не скажет? Pip хотя бы может тянуть из репа, который может быть вашим, и расположен в том месте, за которое можете сами ручаться.

Компилятора на сервере быть не должно из-за того, что злоумышленник придет и скомпилирует что-нибудь? Можно и статические библиотеки принести.
А потом вам понадобится срочно еще какая-то либа на racket, для какого-то скрипта, немножко php что в пакетах не было, и еще что-нибудь, главное чтоб у него свой менеджер пакетов был, а может и инсталлятор в виде скрипта, в хомяк аль в opt положит мину.
В документацию записать забудут сей факт, человечек который это сделал станет не доступен.

И однажды вам понадобится развернуть сервис на новом железе (и очень срочно).
Развернете вы (debian | red-hat | sled), накатите пакеты менеджером, потом pip, потом bower, в общем все по доке.
Вот только не получится каменный цветочек. А начальство шумит, пальчиком грозится. И в думу вы погрузитесь, печальную. ))

И не вспоминайте про chef, puppet, salt, это по сути один из способов документирования ваших сервисов.
Решение этой проблемы, если я вас правильно понял − создать собственный deb-репозиторий и добиться того, чтобы проект можно было развернуть только при помощи этого репозитория, без использования иных пакетных менеджеров, кроме apt?

Спасибо, но я с тем же успехом упакую проект целиком, со всеми незадокументированными вовремя какашками, в 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 — неделю назад. У каждого языка своя инфраструктура, вы их все тащите на прод? В общем это дело хозяйское, но мой опыт в администрировании склоняет меня в сторону пакетирования. Это потом сильно проще, и обеспечивает заменяемость людей.
github.com/jordansissel/fpm

Спасибо за наводку, не знал про эту штуку. Надо будет иметь в виду. Наверное, я изменю своё мнение насчёт сборки OS-targeted пакетов.
Про 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'ами на других серверах).

если учесть, что apache обрабатывает каждый запрос в отдельном процессе/потоке

Уже нет. Как сейчас помню:
  • в версии 2.0 код, отвечающий за запуск обработчиков запросов, выделили в отдельные модули (mpm_*),
  • в 2.2 появился мультипотоковый обработчик mpm_worker,
  • в 2.4 стабилизировался mpm_event, который на том графике внизу, рядом с nginx.
Ваша ссылочка на Performance от 2012 года, да и моя не надолго от вас ушла.
Свежих тестов не нашел, самому гонять — не до этого, да и уже не мой профиль.Так что останемся при своих, на днях еще буду шерстить, если что сюда отпишусь.
Для затравки http://habrahabr.ru/post/210950/
В любом случае, спасибо за стью, плюс.
Здорово, отписывайтесь. А то и отдельную статью пишите.
А не проще ли будет взять какой-нибудь Docker? Тогда и окружение будет стандартизированным везде, и на dev и на prod.
Docker, как я понимаю, оперирует содержимым контейнеров LXC или OpenVZ? Возможно, стоит попробовать. Либо написать свои скрипты для деплоя в контейнеры.

Но беспокоит вопрос использования дискового пространства. Серверные диски желательно экономить.
docker как раз для вашего случая
Не совсем так. Напилите kvm и поиграйтеь с докер — поймёте в чём «прикол»!
Докер использует copy-on-write на файловых системах, можно развернуть 100 одинаковых контейнеров и места они будут занимать как один.
Sign up to leave a comment.

Articles