Чем деплоить php проекты?

Question

[Леонид Корсаков]

Кто-нибудь использует системы деплоя приложений на боевые сервера? В чем основные отличия от простого pull стабильной ветки в системе контроля версий? Есть ли резон в их использовании?

Answer 1

[Дмитрий Энтелис]

Часто для деплоя требуется
а) совершить некие действия: скомпилировать css, собрать js, накатить миграции базы итд...
б) в процессе деплоя протестировать что получилось и решить стоит ли вообще деплоить (+ дать по башке автору комита который провалил тесты)
Все эти задачи и должен делать сервер CI.

Comments

[Леонид Корсаков]

Накатить миграцию это здорово. Но что касается сборки статики разве это не должно быть до деплоя?

[Сергей Протько]

Леонид Корсаков: да, это происходит на этапе сборки приложения, как и прогон тестов. Результат этого дела - билд. Но сделать git pull на серваке уже не выйдет. В итоге нам нужен еще один таск в CI сервере который запускает капифони всякие или чего еще там вы можете использовать и заливает архив на сервак и запускает миграции и т.д. У меня вот дистрибьюция проекта идет в deb архивчиках с пост-инстал скриптами который ставится через ansible с предварительным провиженингом сервера. Но правда откат на предыдущую версию я пока не предусматриваю к сожалению.

Answer 2

[Сергей Протько]

Не забудьте про rsync как средство деплоя.

Вообще все просто, при деплое через git pull у вас перестает работать текущая версия сайта. И время простоя зависит от сложности деплоя. Например вам нужно установить вендоры - пока будет работать composer install мы ждем. Затем мы чистим кеш - опять простой. Затем миграции. Снова ждем, а миграции могут выполняться долго в зависимости от сложности... хотя они редко выполняются дольше пары минут.

А всякие тулзы типа капифони и т.д. имеют возможность версионизации. То есть пока у вас поднимается новая версия - старая обрабатывает запросы. Как только миграции будут накачены, капифони просто поменяет симлинки и релоаднет nginx (не перезагрузит, а только реалоаднет).

А когда приходится при каждой выкатке на сервер еще и за окружением следить вход пускают еще и ansible/puppet. Так же есть еще и Docker.

Comments

[Дмитрий Энтелис]

Я может быть параноик, но я не рискнул бы при деплое использовать загрузку чего либо из composer.
Мне кажется проще загрузить 1 раз и положить в репозиторий.

Также не очень понял почему все будет лежать при прямой выкладке из репозитория.
Делаем git fetch, накатываем миграции (тут простой есть, но без геммороя никуда от него не денешься), потом сразу же git merge.
Да, это чуть медленнее чем замена симлинка, но вряд ли у кого то настолько большие объемы изменяемого кода что это критично. Особенно в ситуации с CI

[Сергей Протько]

Дмитрий Энтелис: ну как бы да, при деплоее через git придется коммитить вендоры. Не суть собственно. Просто рекомендованный подход их в игнор ложить. У меня на старых проектах вендоры закомичены только по одной простой причине, когда вся эта канитель с composer только начиналась люди массово любили удалять/переименовывать пакеты.

А как после git fetch миграции накатить? Я может чего не знаю, поделитесь. При git fetch до мерджа/ребейза у нас же нету новых миграций. нет? Можете раскрыть это по подробнее?

и да, CI никакого отношения к деплою не имеет. Ну мол... CI это CI, он таски выполняет. У вас может быть таск деплоймента, но какое это имеет отношение непосредственно к загрузке билда на сервер?

[Сергей Протько]

Дмитрий Энтелис: мне очень нравится идея деплоймента с docker. Это удобно, не нужно париться на счет окружения, даунтайма почти нет (как переключение симлинков только переключаем мы хосты, то есть просто все новые запросы пойдут уже на новый контейнер). Так как это LXC то оверхэд минимален, база данных в отдельном контейнере и шарится между контейнерами приложенек... И с откатом все просто - просто переключаемся на предыдущий контейнер. И провиженинг на CI сервере мгновенный.

[Дмитрий Энтелис]

Сергей Протько: пощупаю docker, спасибо. Я по ощущениям понимаю что это наверное более правильно чем решение в лоб, но руки все не доходят.
CI я имел в виду саму практику разработки, а не конкретный сервер.
Да, про миграции я не подумал, прошу прощения ) Лежать будет, да)

Answer 3

[Александр Кубинцев]

Как вариант phing.
У нас проект разворачивается на 3 разных по назначению сервера, включая БД.
Можно сделать и откат версии. Для миграционников это в принципе и так очевидная операция, а для версий кода используется переключение симлинка на папку с другим деплоем и перезагрузка кэша.
pull также не удобен и по причине безопасности - надо каждый сервер прописывать в вайт-лист для сервера git.

Comments

[Сергей Протько]

phing это аналог ant-а или make на xml. Ужасная отвратительная хрень. Она нужна для сборки, не для деплоя.

[Александр Кубинцев]

Сергей Протько: для сборки тоже используется. В общем-то инструмент гибкий. Но мне не сильно нравится из-за xml. Делали 2 года назад, docker ещё не был известен.

[Сергей Протько]

Александр: это task раннер, не более.