Обновить фреймворк в продакшн

[Dmitry Agafonov]

Привет!

Понятно, что при разработке всё равно, но в работающей системе как
обновляете фреймворк?
Интересен опыт и подходы.

Банально мне новичку кажется, что достаточно заменить код и перезапустить.
В моём случае uwsgi в режиме императора замечает touch ini вассалов и
перезапускает.
Но секунд 10 (на слабом vds, правда) получается перерыв. И это не
учитывая полуручную миграцию базы через south.

Что посоветуют профи?

--
Dmitry Agafonov ~ http://agafonov.pp.ru/

[Pavel Reznikov]

Обновляй, когда наименьшее количество посетителей. Или на слабом VDS у тебя просто миллионами народ тусуется?

Предупреждай пользователей, что будет обновление с такого-то по такое-то время

//wbr Pavel Reznikov <pashka....@gmail.com>

2012/8/1 Dmitry Agafonov <agafono...@gmail.com>

[Dmitry Agafonov]

1 августа 2012 г., 10:18 пользователь Pavel Reznikov
<pashka....@gmail.com> написал:

> Обновляй, когда наименьшее количество посетителей. Или на слабом VDS у тебя
> просто миллионами народ тусуется?
> Предупреждай пользователей, что будет обновление с такого-то по такое-то
> время

Меня не административная сторона интересует, а техническая :)
Более того, я уверен, что можно легко организовать плавное обновление
фреймворка в работающем приложении (как и плавное обновление самого
приложения) без перерывов в обслуживании.
Вопрос именно в том, насколько это уже проработанный и вообще насущный
ли вопрос.

[Метасов Артур]

Наверное, можно выпендриться и в режиме fastcgi сначала запускать новую версию с другим сокетом,
потом править конфиг веб-сервера и делать ему reload.

Должно быть быстрее.

1 авг. 2012, в 08:42, Dmitry Agafonov <agafono...@gmail.com> написал(а):

[Pavel Reznikov]

Остановил приложение. Показал пользователю сообщение, что ведутся работы, закончатся во столько-то. Спокойно все обновил. Запустил приложение. Это же не каждые пол часа происходит.

В 99% случаев не вижу смысла в каких-то плавных обновлениях.

//wbr Pavel Reznikov <pashka....@gmail.com>

2012/8/1 Dmitry Agafonov <agafono...@gmail.com>

1 августа 2012 г., 10:18 пользователь Pavel Reznikov

[Serge I Korotkin]

Конфиги поменять легко и nginx с его upstream в этом случае вообще как валерьянка для кота.
Если нужен 99% uptime и менялась схема базы,  придется потратить время на скрипты для миграции данных, которые пользователи успели ввести/изменить. Хорошо, если есть ресурсы для создания копии базы, на которую после переключитесь. Иначе - whiteboard и миграция модулей одного за  другим вручную.

--
С уважением,
Сергей Иванович Короткин

ICQ: 176-575-373   Skype:serge.i.korotkin

[Serge Matveenko]

2012/8/1 Dmitry Agafonov <agafono...@gmail.com>:

> Меня не административная сторона интересует, а техническая :)
> Более того, я уверен, что можно легко организовать плавное обновление
> фреймворка в работающем приложении (как и плавное обновление самого
> приложения) без перерывов в обслуживании.
> Вопрос именно в том, насколько это уже проработанный и вообще насущный
> ли вопрос.

Таки, обновляем сам Django. Тогда основная задача - обеспечить
совместимость приложения с новой версией. Если апгрейд на новую
минорную версию, то, используя virtualenv, тупо:
1. pip install --upgrade Django<1.5 # предполагаем, что у нас 1.4.х,
на всякий случай ограничиваем, чтобы не установилась новая мажорная
2. рестарт wsgi или что у вас там, чтобы загрузить приложение с новым
фреймворком, у меня сие сильно меньше 10 секунд занимает

А вот, если мы обновляемся на новую мажорную версию, то для начала -
тестировать, тестировать, тестировать свое приложение, а потом уже
обновлять тем же путем примерно.

Само обновление приложения тоже не должно сильно занимать много времени.
1. Залили новый код (тут можно разными способами, сам справишься)
2. Обновили staticfiles
3. Рестарт wsgi.

Технически операции на сервере можно автоматизировать, например с
помощью fabric или сборкой своих deb-ок, например. В этих случаях
можно автоматизировать и шаги по выкладыванию "затычки" про "ой-ой-ой
у нас технические работы".

--
Serge Matveenko
se...@matveenko.ru
http://www.ohloh.net/accounts/lig
http://ru.linkedin.com/in/sergematveenko

[Serge Matveenko]

2012/8/1 Serge I Korotkin <korot...@gmail.com>:

> Конфиги поменять легко и nginx с его upstream в этом случае вообще как
> валерьянка для кота.
> Если нужен 99% uptime и менялась схема базы, придется потратить время на
> скрипты для миграции данных, которые пользователи успели ввести/изменить.
> Хорошо, если есть ресурсы для создания копии базы, на которую после
> переключитесь. Иначе - whiteboard и миграция модулей одного за другим
> вручную.

Миграцию схемы, кстати, тоже вполне можно автоматизировать, только для
начала надо сделать ручками на тестовой машине, написать
соответствующие автоматизирующие процесс скрипты (тут инструметария
полно, тот же south), а потом и их протестировать, тогда миграция
должна пройти нормально в автоматическом режиме. По факту, так
получается не всегда, поэтому хорошо бы написать на это дело тестов и
запускать их на продакшене (можно так же автоматически) после
миграции.

[Nikolay Fominykh]

Чтобы супер-плавно обновиться - ставиться haproxy, в него добавляется сервер со старой версией кода. После этого проводим обновление django и добавляем сервер с новой версией кода. После этого старый убираем и тестируем новый. Если что-то пойдет не так - можно почти моментально переключиться на старый.

Такая схема позволяет безболезненно менять мощности инстансов на амазоне с ~нулевым даунтаймом(haproxy перезапускается быстрее nginx). 

Ну а так, если у проекта один маленький VDS - то следует понимать, что скорее всего на судьбу этого проекта даже 3х дневный простой не повлияет.

З.Ы.: Все злее отношусь к действиям, которые требуют ручного участия. Любое действие должно совершаться одной командой. Fabric в этом плане рулит.

1 августа 2012 г., 11:15 пользователь Serge Matveenko <se...@matveenko.ru> написал:

[Метасов Артур]

1 авг. 2012, в 10:46, Nikolay Fominykh <niko...@gmail.com> написал(а):

> З.Ы.: Все злее отношусь к действиям, которые требуют ручного участия. Любое действие должно совершаться одной командой. Fabric в этом плане рулит.

$sudo make-all-awesome

[Dmitry Agafonov]

> Ну а так, если у проекта один маленький VDS - то следует понимать, что
> скорее всего на судьбу этого проекта даже 3х дневный простой не повлияет.

Как оказывается, django+uwsgi+nginx [+mysql] живут на мааленьком VDS
очень неплохо и могут сделать очень много работы.

И, как говорится, зачем платить больше? :)

[Serge Matveenko]

2012/8/1 Dmitry Agafonov <agafono...@gmail.com>:
> django+uwsgi+nginx

а у нас --в квартире газ-- т.е. django+gunicorn+supervisord+lighttpd :)

[Михаил Степанов]

не в тему конечно но у меня связка  django+gunicorn+supervisord+nginx странно тормозила. обновил nginx и перешел на uwsgi и все стало нормально. так и не смог понять причину

среда, 1 августа 2012 г., 12:06:50 UTC+4 пользователь Serge Matveenko написал:

[iddqd]

оффтоп:

т.е. у вас стало Django+uWsgi и nginx под статику, я правильно понимаю? или все таки supervisord все равно нужен?

среда, 1 августа 2012 г., 15:06:33 UTC+6 пользователь Михаил Степанов написал:

[Михаил Степанов]

именно. супервайзер не нужен

среда, 1 августа 2012 г., 13:37:20 UTC+4 пользователь iddqd написал:

[Nikolay Fominykh]

Почему не нужен? Удобно же. :)

1 августа 2012 г., 13:39 пользователь Михаил Степанов <gm...@gorazio.com> написал:

[Dmitry Agafonov]

>> т.е. у вас стало Django+uWsgi и nginx под статику, я правильно понимаю?
>> или все таки supervisord все равно нужен?

> именно. супервайзер не нужен

Это вы про режим императора или нет?
И динамику гонять напрямую в uwsgi или через nginx?

[Serge Matveenko]

2012/8/1 Dmitry Agafonov <agafono...@gmail.com>:

> И динамику гонять напрямую в uwsgi или через nginx?

Напрямую, только через вебсервер, типа nginx:)

[pooh]

В Срд, 01/08/2012 в 02:39 -0700, Михаил Степанов пишет:
> именно. супервайзер не нужен

Но с ним удобнее, когда крутиться несколько проектов

--
С уважением Олег.

[Михаил Степанов]

дык оно перезапускается через  тач скрипта указанного в конфиге. для чего оно тогда нужно?

среда, 1 августа 2012 г., 13:41:59 UTC+4 пользователь Nikolay Fominykh написал:

[Михаил Степанов]

это я да. про режим императора

среда, 1 августа 2012 г., 13:43:12 UTC+4 пользователь Agafonov написал:

[Ilya]

Заливаю новый бренч с обновленным кодом приложения на сервер, делаю
fast-forward merge, мигрирую БД (south, и, если нужно, мигрирую данные
скриптом), делаю рестарт uwsgi. Есть небольшая задержка во время
рестарта, но это не критично.

[Иван Земцов]

virtualenv + gunicorn + nginx

Обновляю код из git, применяю миграции, делаю рестарт gunicorn. Перерыва практически нет, но если удаляются поля из БД, то до момента перезапуска могут быть ошибки, но чаще поля именно добавляются, поэтому все происходит быстро и без перерывов.

2012/8/6 Ilya <u53...@gmail.com>

--
С уважением, Иван

[Dmitry Agafonov]

И снова здравствуйте!

Я несколько педантичен, простите ;)

Типично: "обновляю код из git|svn"... У вас там рабочая копия или "экспорт"?
Если рабочая, то не плохо ли это?
Если экспорт, то не боитесь ли сбоя при замене кода (как вы это делаете в git?)

[Ilya]

2012/8/6 Dmitry Agafonov <agafono...@gmail.com>:
> рабочая копия или "экспорт"

А что это такое, можно пояснить?

Если я правильно понял вопрос, то гит, например, не даст сделать push
в текущую активную ветку (с настройками по умолчанию). Поэтому я делаю
изменения в другой ветке, а потом обновляю активную ветку в продакшне.

[Serge Matveenko]

2012/8/6 Dmitry Agafonov <agafono...@gmail.com>:

> Типично: "обновляю код из git|svn"... У вас там рабочая копия или "экспорт"?
> Если рабочая, то не плохо ли это?

Рабочая. Только отдельная специальная ветка, а не master, конечно.