Комментарии 149
Почему нет варианта «рабочая копия SVN (GIT) хранилища, которая расположена ВЫШЕ document_root».
Зачем держать корень репозитория в document_root если можно поднять его выше и обезопасить себя?
Зачем держать корень репозитория в document_root если можно поднять его выше и обезопасить себя?
видел такой вариант: держат в руте svn копию, когда надо сделать релиз делают svn up. А если делать хранилище ВЫШЕ document_root, то дальше какой алгоритм? svn up потом экспорт в папку с новым релизом?
А что вы подразумеваете под document_root?
То где лежит весь проект, или то что видно из броузера?
То где лежит весь проект, или то что видно из броузера?
Наверное я вас неправильно понял. Я имел в виду случай, когда мы имеем доступ ко всему дереву каталогов, и работаем через ssh например на VPS.
Тогда создаем каталог в который клонируем наш репозиторий. А в нем лежит каталог www на который и указывает виртуальный хост как на document_root.
С обычным хостингом это будет несколько сложнее.
Тогда создаем каталог в который клонируем наш репозиторий. А в нем лежит каталог www на который и указывает виртуальный хост как на document_root.
С обычным хостингом это будет несколько сложнее.
Для меня обычная методика на мелких сайтах — в /home/user лежит рабочая копия репозитория. /home/user/public — это document_root веб-сервера. Соотв. при коммите в интеграционный репозиторий срабатывает хук, который идет по ssh на продакшн сервер и делает git pull origin release.
Соотв. программисту достаточно запушить в ветку release на git-сервере.
Соотв. программисту достаточно запушить в ветку release на git-сервере.
Да там всё просто — в директории, отдаваемой веб-сервером, только всякая статика. Весь код недоступен веб-серверу, так как лежит в другом поддереве репозитория. Однако FastCGI-серверу, к которому обращается веб-сервер, доступно всё.
такую схему по-умолчанию предлагает Zend Framework, я правильно понял?
Не знаю. К счастью, с PHP уже лет 8 не работаю, пересел на django, а там такая схема деплоя единственно естественная (за исключением apache, который я тоже не использую). Впрочем, с некоторой версии там наружу отдаётся две директории со статикой (они отделили user-generated статику от той, что помещается в репозиторий), но это общую схему не меняет.
Я вообще считаю, что плоха любая технология, которая провоцирует код класть в директорию, которую отдаёт веб-сервер. В смысле усложнения выстреливания себе в ногу мне как раз нравится django, там все опасные вещи происходят явно — явно отключается экранирование при подстановке переменной в шаблон, явно отключается экранирование при подстановке значений в SQL, явно отключается защита от CSRF-атак в формах, и так далее.
Я вообще считаю, что плоха любая технология, которая провоцирует код класть в директорию, которую отдаёт веб-сервер. В смысле усложнения выстреливания себе в ногу мне как раз нравится django, там все опасные вещи происходят явно — явно отключается экранирование при подстановке переменной в шаблон, явно отключается экранирование при подстановке значений в SQL, явно отключается защита от CSRF-атак в формах, и так далее.
Я вообще считаю, что плоха любая технология, которая провоцирует код класть в директорию, которую отдаёт веб-сервер.
В традиционном (mod_php или php-fpm) использовании PHP сейчас рекомендуется (и провоцируется авторами многих продуктов, в частности тогже Зенда) класть в док-рут веб-сервера только один или несколько файлов в несколько строк, которые уже вызывают остальной код, веб-серверу недоступный.
мне как раз нравится django, там все опасные вещи происходят явно — явно отключается экранирование при подстановке переменной в шаблон, явно отключается экранирование при подстановке значений в SQL, явно отключается защита от CSRF-атак в формах, и так далее.
Это справедливо и для многих php-фреймворков (при условии использования не пхп-шаблонов).
Можно делать редирект запросов во дочернюю папку репозитория, где находится точка входа в приложение. Таким образом .svn/.git папки не доступны извне
dokku и деплой через git
capistrano
fabric
А почему нет варианта «я разрабатываю сразу на продакшене?»
НЛО прилетело и опубликовало эту надпись здесь
Они сами по себе этим не занимаются, почти всегда есть дополнительная приблуда (н-р copy плагины к jenkins) или просто дергаются скрипты из build шагов.
Хотя и нужно отдельно заметить про app сервера, которые поддерживают деплой как задачу.
Хотя и нужно отдельно заметить про app сервера, которые поддерживают деплой как задачу.
думал про них, но они сами по себе только предоставляют GUI, а так сказать транспорт для разливки, обычно более низкоуровневый или тот же bash скрипт или deb
+1
Заливать по SFTP не обязательно _вручную_ — это делает CI.
Заливать по SFTP не обязательно _вручную_ — это делает CI.
НЛО прилетело и опубликовало эту надпись здесь
opensuse build server + deb хранилище + chef
А у нас исторический тандем VСS+rsync
Где вариант «заливаем вручную через RDP»? Какой-то одноплатформенный опрос получился…
WebDeploy
capistrano с обновлением версии из гита + eye
деплой происходит одной командой cap production deploy
Хоть оно и на руби, но в целом является аналогом очень продвинутого баш-скрипта, мы используем во всех проектах вне зависимости от языка
деплой происходит одной командой cap production deploy
Хоть оно и на руби, но в целом является аналогом очень продвинутого баш-скрипта, мы используем во всех проектах вне зависимости от языка
Использовал capistrano, как для рельс, так и для java-проектов (для шаблонов фронтовой части, бэк деплоился либо через веб-интерфейс аппсервера, либо через scp/cp/mv в специальную директорию и деплоить его тем же скриптом не имело смысла).
> Хоть оно и на руби
Звучит, будто это что-то плохое.
Звучит, будто это что-то плохое.
Эта фраза не для меня, а для тех, кто думает, будто руби — что-то плохое :)
В сочетании с «во всех проектах вне зависимости от языка» звучит как «хоть и почти во все проекты вносим ещё одну зависимость», причём не только «физическую» (должно быть настроено окружение), но и «ментальную» (нужно хоть поверхностно знать ещё один ЯП с довольно оригинальным (читай — не Си-образным) синтаксисом). Обычно это минус.
НЛО прилетело и опубликовало эту надпись здесь
Посмотрите на fabric, если у вас python-среда.
НЛО прилетело и опубликовало эту надпись здесь
За корректность сборки можно грузить сервер CI. И по результату его работы делать необходимые действия для деплоя на test/stage/production/etc.
Fabric (capistrano или ещё какой-нибудь легковесный deployment framework) даст в таком случае небольшой фреймворк для удаленного выполнения, который несколько упростит написание этих самых самопальных python-скриптов. Принципиальных отличий от своих скриптов нет, просто нужно меньше писать boilerplate кода и можно подняться на более высокий уровень абстракции (уровень заданий, например, вместо отдельных команд).
Fabric (capistrano или ещё какой-нибудь легковесный deployment framework) даст в таком случае небольшой фреймворк для удаленного выполнения, который несколько упростит написание этих самых самопальных python-скриптов. Принципиальных отличий от своих скриптов нет, просто нужно меньше писать boilerplate кода и можно подняться на более высокий уровень абстракции (уровень заданий, например, вместо отдельных команд).
CI система выкачивает сорцы с репозитария на целевой продакшен сервер, выполняет миграции БД, выполняет деплой и миграционные скрипты для проекта как то: переделывает симлинки с директорий с данными, если нужно с некоторыми кешами, чистит кеш проекта, (возможно и apc | memcache), переключает симлинк document root директории на новую папку, прогоняет последний тест, что все завелось, если не завелось — откатывает симлинки, миграции и т. д.
Примерно так, с порядком может быть напутал, потому что писал по памяти, а реализацию писали больше 1.5 лет назад
Примерно так, с порядком может быть напутал, потому что писал по памяти, а реализацию писали больше 1.5 лет назад
НЛО прилетело и опубликовало эту надпись здесь
фактически проблемы периодически появляется, но с конкретными проектами… зависит и от задействованных фреймворков и от стека технологий. Но это не «проблемы», это сценарий деплоя проекта требует доработки. Я описал общее поведение системы деплоя, в него практически все вписывается… Кстати забыл: CI кроме выгрузки сорцов проекта выкачивает еще и настроеки проекта:
конфиги nginx — шаблон кастомных реврайтов настроек
настройки окружения — xml файл с настройками (использовать ssl или нет, делать ли редирект по умолчанию с домена на домен с www, на какие директории делать и куда делать симлинки, на какие директории нужно заново выставить какие то права), какую версию и какой пул php использовать, какие дополнительные домены парковать к этому сайту
конфиги cron
анализатор конфигов проекта — скрипты редактирующие/генерирующие конфиги проекта, в зависимости от окружения…
И генерирует на основе них файлы конфигурации для продакшен окружения удаляя старые…
Конечно же, иногда приходится дорабатывать под проект, конкретные стадии деплоя индивидуально
Некоторые проекты могут просить жесткий ребут php-fpm, можно сделать это мягко и использовать для проекта 2 пула php-fpm, перезагружая их по очереди, или может быть рестарт мемкешд, где то нужно прежде работать с composer, но это уже лирика…
Кстати, конкретно у нас есть еще система преддеплоя/тестирования, которая фактически делает тоже самое, но с дебаг режимом, логированием тестов и работает автоматически при каждом коммите в транк разворачивая все это на тестовом сервере, поэтому если что-то явно сломается или скрипты не отработают — будет видно сразу…
конфиги nginx — шаблон кастомных реврайтов настроек
настройки окружения — xml файл с настройками (использовать ssl или нет, делать ли редирект по умолчанию с домена на домен с www, на какие директории делать и куда делать симлинки, на какие директории нужно заново выставить какие то права), какую версию и какой пул php использовать, какие дополнительные домены парковать к этому сайту
конфиги cron
анализатор конфигов проекта — скрипты редактирующие/генерирующие конфиги проекта, в зависимости от окружения…
И генерирует на основе них файлы конфигурации для продакшен окружения удаляя старые…
Конечно же, иногда приходится дорабатывать под проект, конкретные стадии деплоя индивидуально
Некоторые проекты могут просить жесткий ребут php-fpm, можно сделать это мягко и использовать для проекта 2 пула php-fpm, перезагружая их по очереди, или может быть рестарт мемкешд, где то нужно прежде работать с composer, но это уже лирика…
Кстати, конкретно у нас есть еще система преддеплоя/тестирования, которая фактически делает тоже самое, но с дебаг режимом, логированием тестов и работает автоматически при каждом коммите в транк разворачивая все это на тестовом сервере, поэтому если что-то явно сломается или скрипты не отработают — будет видно сразу…
P.s. Чтобы было понятней приведу немного цифр. Специально глянул:
Cейчас в системе деплоя около 30 проектов, итого около 50 планов деплоя (на 1 проект, может быть несколько планов деплоя: в проектах может быть несколько сервисов: веб, апи, поддомены с бета версиями или лендингами/промо сервисами), которые постоянно выкатываются на продакшен. На раных проектах из языков/фреймворках используются: yii, symfony2, самописный фреймворк, node js, 1 веб сервис полностью на java. Различные хранилища и модули.
Cейчас в системе деплоя около 30 проектов, итого около 50 планов деплоя (на 1 проект, может быть несколько планов деплоя: в проектах может быть несколько сервисов: веб, апи, поддомены с бета версиями или лендингами/промо сервисами), которые постоянно выкатываются на продакшен. На раных проектах из языков/фреймворках используются: yii, symfony2, самописный фреймворк, node js, 1 веб сервис полностью на java. Различные хранилища и модули.
НЛО прилетело и опубликовало эту надпись здесь
на 3 проектах суммарная суточная аудитория около 1 100 000 уников, в момент деплоя в онлайне обычно 2-4 тыс. человек… на производительность сервера svn export и прочие дисковые операции обычно не влияют… проблемы могут быть если существуют тяжелые миграции (к примеру БД), которые могут вывести из строя работу сервера на длительное время… В этом случает делаем аккуратно, к примеру, если это тяжелое обновление БД, то накатывается вручную или через дополнительные таблицы или с перелючением на другой сервер БД, после догоняем сделанные изменения… или новое обновление может работать как со старой стуктурой, так и с новой, со временем обновляя данные… в этих случаях все индивидуально…
само переключением проходит для пользователя практически незаметно, потому что для проекта написаны скрипты так, что сервисы без необходимости не рестартятся, временные файлы необходимые для бесшовного переключения, остаются, сессии и прочее хранится в БД, а переключение симлинки проходит очень быстро…
само переключением проходит для пользователя практически незаметно, потому что для проекта написаны скрипты так, что сервисы без необходимости не рестартятся, временные файлы необходимые для бесшовного переключения, остаются, сессии и прочее хранится в БД, а переключение симлинки проходит очень быстро…
А кто использует deb пакеты, какими утилитами собираете?
Если говорить про sbt, то sbt-native-packager
dpkg-buildpackage
Пришлось свою написать, прям вот этими руками: github.com/punund/nodeb
спасибо за ответы
github.com/jordansissel/fpm/ весьма простой для простых вещей
dch; debuild && debclean && debrelease && debcommit
Я бы просто для смеха добавил вариант «А мы не деплоим, мы прямо на продакшене и пишем!»
Было бы смешно, если б не было так грустно…
А я вот скрипты по автоматизации своей квартиры пишу прямо на продакшен сервере, который у меня в чулане стоит. Без версионности, тестирования и деплоя. И в данном конкретном случае, считаю это нормальным.
В некоторых ситуациях работать на продакшене это приемлемо, хотя в большинстве случаев — это дикость.
В некоторых ситуациях работать на продакшене это приемлемо, хотя в большинстве случаев — это дикость.
Вы слишком серьёзно подошли к вопросу.
версионность не помешает сколь угодно малому проекту. всего лишь пара команд, чтобы подключить тот же git прямо локально, но моментально появившиеся дополнительные плюшки очень могут сэкономить времени. особенно на стадиях «блин, зря я так переделал, лучше вернуть как было».
Capifony для Symfony 2 проектов, вручную (пока) для всякой мелочи.
mina (легковесная single-server замена capistrano), на больших проектах — capistrano, но без simlink'ов, вместо этого git и его теги + правильно настроеный gitignore.
У git+тегов вместо симлинков проблема в том, что нужно быть абсолютно на 100% уверенным, что на сервере ничего не меняют руками.
Иначе может случиться такая ситуация, что в горячке накатили какой-то хотфикс из пары строк прямо по месту, а после очередного деплоя он необратимо исчезнет (если делать reset), или наоборот, сломает работающий код (если reset не делать).
Иначе может случиться такая ситуация, что в горячке накатили какой-то хотфикс из пары строк прямо по месту, а после очередного деплоя он необратимо исчезнет (если делать reset), или наоборот, сломает работающий код (если reset не делать).
Если случилась такая ситуация, что хотфикс надо делать на боевом сервере, то:
1) все последующие «регулярные» деплои блокируются до разбора полетов
2) хотфикс, если он заработал на боевом, в обязательном порядке (а зачастую сразу паралельно с редактированием «там») заносится в git и в самом высоком приоритете тестируется со всех сторон, заливается в мастер и выполняется деплой уже с хотфиксом в гите. После чего проверяем что всё применилось нормально. (Если нет — повторяем итерацию, но такое за 5 лет было только 1 или два раза)
3) вся команда собирается на разбор полетов, с выяснением (а) почему такой факап произошел, (б) почему его пропустили QA, (в) могли ли они вообще его заметить, и (г) что сделать чтобы такое не повторилось.
Как-то так. :)
1) все последующие «регулярные» деплои блокируются до разбора полетов
2) хотфикс, если он заработал на боевом, в обязательном порядке (а зачастую сразу паралельно с редактированием «там») заносится в git и в самом высоком приоритете тестируется со всех сторон, заливается в мастер и выполняется деплой уже с хотфиксом в гите. После чего проверяем что всё применилось нормально. (Если нет — повторяем итерацию, но такое за 5 лет было только 1 или два раза)
3) вся команда собирается на разбор полетов, с выяснением (а) почему такой факап произошел, (б) почему его пропустили QA, (в) могли ли они вообще его заметить, и (г) что сделать чтобы такое не повторилось.
Как-то так. :)
Не хватает возможности множественного выбора, на разных проектах разные методы.
Пробовали разные варианты, самым удобным оказалось деплоить продакшн ветку гитом и запускать скрипт миграции бд при необходимости.
Делаю пуш на нужный сервак, он все подхватывает и сам разворачивает среду и настраивает нжиникс
Мы используем маленький проект, который написал мой коллега: github.com/korchasa/zeus
Пакеты, пакеты и только пакеты. К сожалению, rpm. Время обновления тачки и ее пуска больше чем хотелось бы, поэтому во время обновления машина не видна пользователям.
Используем Gitlab + gitlab-ci (runner). Удобно. Runner проганяет тесты, делает билд, и если все ок — деплой. Срабатывает по тригеру пуша в мастер ветку GIT
Меня удивляет то, что 37% проголосовавших живет в каменном веке и выкладывает все руками! Больше трети!
Я думаю так голосует те, у кого:
— На один проект один девелопер.
— Проекты простые, что то типа простеньких сайтов.
— Нет версионности (Сляпал сайт за неделю, сдал работу и забыл.)
— Нет автоматизированного тестирования (а зачем оно для сайта визитки, где тестором выступает сам заказчик?)
— Разрабатывают под виндой (иначе бы, хотя бы пользовались bash, rsync и тп).
Да 80% веб-студий так работают, как я заметил.
— На один проект один девелопер.
— Проекты простые, что то типа простеньких сайтов.
— Нет версионности (Сляпал сайт за неделю, сдал работу и забыл.)
— Нет автоматизированного тестирования (а зачем оно для сайта визитки, где тестором выступает сам заказчик?)
— Разрабатывают под виндой (иначе бы, хотя бы пользовались bash, rsync и тп).
Да 80% веб-студий так работают, как я заметил.
«mvn package deploy -P production» из IDE по сути тоже является «выкладыванием руками», но в этом профиле «production» ещё столько скриптов запуститься, что мама не горюй
Да, так и есть, наверное.
У меня имеется проект приличный по размеру, но с одним разработчиком (мной). Git используется для синхронизации кода между несколькими рабочими компьютерами, а выкладывается все при коммите кода в рабочую ветку обычным PHPStorm.
У меня имеется проект приличный по размеру, но с одним разработчиком (мной). Git используется для синхронизации кода между несколькими рабочими компьютерами, а выкладывается все при коммите кода в рабочую ветку обычным PHPStorm.
Или просто нет времени/желания автоматизировать деплой.
— Разрабатывают под виндой (иначе бы, хотя бы пользовались bash, rsync и тп).
TFS уже давно умеет в:
Сильно зависит от платформы. В случае деплоя war (java) часто достаточно его скопировать в специальную директорию. Тогда деплой через ftp/sftp/scp/руками — суть одно и то же.
Проект синхронизируется между разработчиками через git или svn. В проекте имеется простенький bash скрипт, который через rsync синхронизирует рабочую версию на компе разработчика с продакшен сервером. Этот же скрипт может аптейтить базу данных на продакшен сервере, если есть необходимость. Например для какого-нибудь простого проекта, где при деплое можно просто поставить свежую версию поверх старой, это будет как то так.
rsync -rlptDvL \
/var/www/project_1 \
developer@production-server.com:/var/www/project_1
mysqldump --user=*** --password=*** --host=localhost --add-drop-table DATABASE | \
ssh developer@production-server.com \
mysql --user=*** --password=*** --host=localhost DATABASE
Разливаем через deb пакетыКроме DEB других пакетов нет что ли? Мы через RPM заливаем.
Заливаем через Tomcat Manager в билде (Java приложение).
В PHP проектах деплой просто выкладывается в новую папку, и инит проекта перегенерирует локальный nginx конфиг — это заведомо избавляет от проблем с кешем, позволяет действительно быстро откатываться и даёт действительно graceful reload сугубо командой nginx reload.
Используем Beanstalk.
GIT + хуки
1. Capistrano. Копирование и переключение симлинка.
2. Вызов rsync из puppet, который, в свою очередь, вызывается из jenkins.
PS: Не нравятся оба способа. В первом случае, долгое копирование на большое количество серверов плюс указанные глюки кешера. Во втором, в принципе, тоже. Файлы попадают на сервера не одновременно. Из-за чего приходится выводить их в maintenance.
PPS: Самый передовой способ деплоя — это «Чик-чик и в продакшен». Не важно чем.
2. Вызов rsync из puppet, который, в свою очередь, вызывается из jenkins.
PS: Не нравятся оба способа. В первом случае, долгое копирование на большое количество серверов плюс указанные глюки кешера. Во втором, в принципе, тоже. Файлы попадают на сервера не одновременно. Из-за чего приходится выводить их в maintenance.
PPS: Самый передовой способ деплоя — это «Чик-чик и в продакшен». Не важно чем.
Может я чего-то не понял в вариантах, но у нас TeamCity собирает архив из релизной версии и потом кладёт всё на FTP, откуда скрипты уже всё забирают и распаковывают на живой.
Использую Ansible.
У нас просто запускается билд в TFS, который берет нужную версию из VCS и заливает на соответствующий сайт с помощью MSDeploy.
Локально развернута на VMWare-инфраструктуре зеркальная копия production'ов (везде ubuntu 64 server 12.04). Включая OS, RAM, окружение, и даже хосты. Еще одна зеркальная копия там-же — dev сервера.
Переключение на dev рабочих местах через hosts.
После ручного пуша на локаль и всех тестов — rsync на продакшн + нужные кастомные sh скрипты на каждый деплой.
Всё остальное на практике либо не оправдывает затрат на настройку, либо избыточно для нашей небольшой команды и вполне себе больших проектов с кучей разных связей и тулз.
Исторически сложилась система проектов, которая плохо накладывается на паттерны работы с GIt и автосборщиками.
Никаких серьезных проблем при этом не испытываем. Разве что не так красиво это выглядит со стороны, как хотелось бы.
Переключение на dev рабочих местах через hosts.
После ручного пуша на локаль и всех тестов — rsync на продакшн + нужные кастомные sh скрипты на каждый деплой.
Всё остальное на практике либо не оправдывает затрат на настройку, либо избыточно для нашей небольшой команды и вполне себе больших проектов с кучей разных связей и тулз.
Исторически сложилась система проектов, которая плохо накладывается на паттерны работы с GIt и автосборщиками.
Никаких серьезных проблем при этом не испытываем. Разве что не так красиво это выглядит со стороны, как хотелось бы.
Разработка под SharePoint является веб-разработкой?
Ставим предназначенный для разворачивания WSP-пакет. Это такой контейнер, в котором содержится всё необходимое для развёртывания решения на сервере.
Ставим предназначенный для разворачивания WSP-пакет. Это такой контейнер, в котором содержится всё необходимое для развёртывания решения на сервере.
Последнее время использую git, каждый релиз новый тег + для некоторых проектов для упрощения выгрузки написан скриптик update.sh, который еще делает всякие дополнительные вещи (сброс кэша, метаобновления если есть и т.п.)
На одном из проектов еще сделана автоматическая выгрузка, в момент когда что-то пушится в ветку мастер.
На одном из проектов еще сделана автоматическая выгрузка, в момент когда что-то пушится в ветку мастер.
Maven с профилями + Tomcat
С гитом всё очень просто. Создаем страницу, которя при POST с определённого ip делает лишь —
и на случай перезапускаем инстансы (node.js) (file touch при разработке у нас вотчеры на весь проект, а при деплое только конфиги и index.js)
git fetch --all
git reset --hard origin/master
npm update
и на случай перезапускаем инстансы (node.js) (file touch при разработке у нас вотчеры на весь проект, а при деплое только конфиги и index.js)
fs.utimesSync('index.js', new Date(), new Date());
Check-In на TFS сервер, оттуда триггер на деплой на Staging Cloud Service в Azure, если все ок, свап VIP адресов со стейджинга на продакшен.
банк имеет свою систему которая копирует файлы с серверов на которых тестируют на продакшн
TEST — UAT — PROD
разработчики могут выложить версию только на TEST
PROD под контролем администраторов
в случае исправления ошибки весь цикл повторяется
TEST — UAT — PROD
разработчики могут выложить версию только на TEST
PROD под контролем администраторов
в случае исправления ошибки весь цикл повторяется
заливаю вручную с помощью rsync
chef
НЛО прилетело и опубликовало эту надпись здесь
capistrano, salt
bash-скрипт в кроне опрашивает Teamcity на предмет наличия новых версий приложения и складывает их в отдельную папочку. Само обновление выполняется вручную из папки, но с предварительным сравнением версий и diff-ами, чтобы убедиться, что заменяются нужные файлы. Деплоим java-приложения
На текущем проекте код лежит в репе (SVN), подтягивается на продакшен в отдельную папку (хомяк юзера deploy) через svn up/merge, потом сихронизируется локально через rsync, а потом вручную разбираются проблемы с миграциями (фреймворк не очень хорошо с ними работает если миграция создана раньше последней накатанной, но ещё не накатана). Можно было бы больше автоматизировать, но нет никакого желания — проект, как говорится, «на выброс» :(
Git стоит на CI-сервере (с Gitolite), через hook мониторится определённая ветка, обновление которой инициирует git pull на Production. Процесс инициации может отличаться, по умолчанию CI сам заходит через ssh и делает pull. Сервер всегда находится в точном соответствии с конкретной веткой git'а на CI.
Корень git'а при этом находится выше Document root.
Конфигурации серверов — отдельный репозиторий, находится в отдельном месте и управляется отдельным пользователем, обновляется таким же способом.
Исходный код самих серверов (они у нас тоже собираются из сорцов) — третий репозиторий…
Конфигурация CI, скрипты инициации и разделение прав пользователей — четвёртый…
Корень git'а при этом находится выше Document root.
Конфигурации серверов — отдельный репозиторий, находится в отдельном месте и управляется отдельным пользователем, обновляется таким же способом.
Исходный код самих серверов (они у нас тоже собираются из сорцов) — третий репозиторий…
Конфигурация CI, скрипты инициации и разделение прав пользователей — четвёртый…
До недавнего времени делали все по (S)FTP, но как-то это все утомило, сейчас с помощью GIT сервер синхронизируется с master веткой репозитория, а для автоматизации этого всего, как обновления так и для инстала на сервер используем deployer.in
1. С помощью кроновых PHP-скриптов авто-мержим задачи из таск-трекера* в ветку релиза (которая создается автоматически 2 раза в день)
2. В CI-системе** прогоняем юнит-тесты с помощью самописной «облачной» запускалки тестов на основе phpunit (запуск тестов осуществляется в 30-60 потоков на 4 серверах, и занимает от 50 секунд до 3 минут, в зависимости от загрузки)
3. Для этой ветки генерируем файлы с переводами (наш сайт мультиязычный) и заливаем статические файлы на наш CDN — тоже с помощью самописной системы
4. Из всего этого создаем т.н. «луп» — образ ФС размером 768 Мб, в которой находятся все файлы, включая автогенерированные переводы (всего около 100 000 мелких файлов)
5. Заливаем «луп» во все датацентры (в данный момент их 2,5 — один в Европе, другой в США, и один маленький ДЦ в Азии) с помощью самописной системы, которая умеет пересылать только разницу между этими «лупами»
6. Деплоим «луп» на staging — заливаем и монтируем «луп» в отдельную директорию и переключаем симлинк. При этом, к сожалению, возникают проблемы с кешом, причём во всех аккселераторах — APC, eAccelerator и opcache в PHP 5.5
7. Когда релиз стабилизирован, тот же самый «луп» (сжатый файл весит около 100 Мб) с помощью технологии UFTP заливается за 25 секунд на наши 1000 серверов и с помощью библиотеки libpssh на всех этих машинах происходит запуск соответствующих скриптов, которые монтируют «луп» и сбрасывают кеши
Процесс деплоя на staging занимает около 3-5 минут (с момента пуша в ветку до попадания кода на staging), при деплое на production — ещё около 2 минут с момента, когда изменения попали на staging.
* таск-трекер не имеет значения, мы им не слишком довольны, но он произведен компанией на букву A
** CI-система работает относительно хорошо, но некоторые задачи нам пришлось перенести на самописную систему, поскольку она не справлялась. Система произведена компанией на букву J
2. В CI-системе** прогоняем юнит-тесты с помощью самописной «облачной» запускалки тестов на основе phpunit (запуск тестов осуществляется в 30-60 потоков на 4 серверах, и занимает от 50 секунд до 3 минут, в зависимости от загрузки)
3. Для этой ветки генерируем файлы с переводами (наш сайт мультиязычный) и заливаем статические файлы на наш CDN — тоже с помощью самописной системы
4. Из всего этого создаем т.н. «луп» — образ ФС размером 768 Мб, в которой находятся все файлы, включая автогенерированные переводы (всего около 100 000 мелких файлов)
5. Заливаем «луп» во все датацентры (в данный момент их 2,5 — один в Европе, другой в США, и один маленький ДЦ в Азии) с помощью самописной системы, которая умеет пересылать только разницу между этими «лупами»
6. Деплоим «луп» на staging — заливаем и монтируем «луп» в отдельную директорию и переключаем симлинк. При этом, к сожалению, возникают проблемы с кешом, причём во всех аккселераторах — APC, eAccelerator и opcache в PHP 5.5
7. Когда релиз стабилизирован, тот же самый «луп» (сжатый файл весит около 100 Мб) с помощью технологии UFTP заливается за 25 секунд на наши 1000 серверов и с помощью библиотеки libpssh на всех этих машинах происходит запуск соответствующих скриптов, которые монтируют «луп» и сбрасывают кеши
Процесс деплоя на staging занимает около 3-5 минут (с момента пуша в ветку до попадания кода на staging), при деплое на production — ещё около 2 минут с момента, когда изменения попали на staging.
* таск-трекер не имеет значения, мы им не слишком довольны, но он произведен компанией на букву A
** CI-система работает относительно хорошо, но некоторые задачи нам пришлось перенести на самописную систему, поскольку она не справлялась. Система произведена компанией на букву J
Таски после теста мержатся в релизную ветку, а на сервере запускается shell-скрипт (или Teamcity со скриптом), который делает git pull, накатывает миграции, сбрасывает кэши, делает бэкап прошлой версии и т.д.
Разливаем через deb пакетыПоубивал бы…
В чем проблема deb?
Проблема в том, что алгоритм выкладки читаем лишь админами, которые его прописывали. Изначально deb и т.п. *nix пакетные системы деплоя преднозначен для обновления серверного ПО, а не для delivery и тем более build веб проектов.
Есть множество инструментов изначально предназначенных для сборки и delivery веб-проектов. Будь то Ant, или Phing на нём построенные или хоть даже Maven. Не суть важно. Они предоставляют более прозрачный интерфейс для сборки и выкладки веб-проектов чем deb/rpm/wtf… обновляторы заточенные тупо на обновление серверного ПО.
Из более двух десятков известных мне веб-проектов лишь несколько использовали deb/rpm деплоеры для выкладки, и… что не удивительно, во всех этих проектах тех. диры были бывшими админами, и именно в этих в проектах происходили наибольшие проблемы с деплоями как с точки зрения стабильности выкладки, отката, так и с точки зрения простоты редактирования сценария выкладки.
Есть множество инструментов изначально предназначенных для сборки и delivery веб-проектов. Будь то Ant, или Phing на нём построенные или хоть даже Maven. Не суть важно. Они предоставляют более прозрачный интерфейс для сборки и выкладки веб-проектов чем deb/rpm/wtf… обновляторы заточенные тупо на обновление серверного ПО.
Из более двух десятков известных мне веб-проектов лишь несколько использовали deb/rpm деплоеры для выкладки, и… что не удивительно, во всех этих проектах тех. диры были бывшими админами, и именно в этих в проектах происходили наибольшие проблемы с деплоями как с точки зрения стабильности выкладки, отката, так и с точки зрения простоты редактирования сценария выкладки.
Ну, выходит у нас был противоположный опыт, у меня как раз меньше всего проблем было с пакетами.
Мне кажется не стоит путать сборку и деплой. Все-таки это разные вещи. Сборка — скомпилить JS, CSS, LESS, скомпилить картинки в одну большую, bower install, npm install, etc. Деплой — положить все это дело правильно на сервер. ИМХО для первого ant, phing, maven — в зависимости от платформы, для второго deb лучше. Еще есть настройка окружения — puppet, chef, ansible, тоже не мешать с деплоем артефактов на сервер.
Так вот для деплоя артефактов, ИМХО, как я уже говорил, deb подходит идеально.
Так вот для деплоя артефактов, ИМХО, как я уже говорил, deb подходит идеально.
А почему вы считаете, что Ant/Phing/Maven и т.п. инструменты в плане delivery хуже систем обновления пакетами deb/rpm/..? Сценарии описываемые на XML в том же Ant Script прекрасно читаемы всеми программистами и более того могут быть более безопасно подправлены. И более того, при грамотном написании эти сценарии являются платформонезависимыми позволяя отлаживать и тестировать их на локальных машинах разработчиков.
ИМХО deb подходит для обновления и конфигурации серверного ПО — всего того, что попаает в зону ответственности админов. А всё что касается архитектуры веб-проектов, тонкости функционирования различных компонентов — зона ответственности программистов, и только они должны принимать решения о сценарии сборки и выкладки.
И что касается разделения использования Ant/Phing/Maven для сборки и dev/rpm для выкладки — зачем это разделять, если Ant/Phing/Maven прекрасно справляются и с первым, и с последним?
ИМХО deb подходит для обновления и конфигурации серверного ПО — всего того, что попаает в зону ответственности админов. А всё что касается архитектуры веб-проектов, тонкости функционирования различных компонентов — зона ответственности программистов, и только они должны принимать решения о сценарии сборки и выкладки.
И что касается разделения использования Ant/Phing/Maven для сборки и dev/rpm для выкладки — зачем это разделять, если Ant/Phing/Maven прекрасно справляются и с первым, и с последним?
Не знаю, может быть мы о разных вещах говорим.
Для меня deb это в первую очередь положить в правильные места все необходимые артефакты. Если юзать для этого просто архивы, а не deb, то нужно париться о многих вещах. Во-первых нельзя просто так распаковать новую версию поверх старой, потому что в новой могут удалиться какие-то файлы, их не должно быть после деплоя. Во-вторых нельзя просто так взять и удалить старую версию перед распаковыванием новой, потому что там могут быть какие-то генерируемые во время работы файлы. Приходится писать какие-то скрипты, которые будут удалять все кроме всяких uploaded_images папок. ИМХО это велосипед, потому что deb это идеально сам разруливает.
Далее, кроме того чтобы положить правильные файлы в правильное место при деплое надо сделать еще кое-какие действия: обновить кеш, смигрировать БД, перезапустить воркеров, etc. Мне тоже не нравится делать это в preinstall/postinstall хуках. У нас, например, этим занимается ansible вместе с остальной частью провиженинга системы, такой как: положить правильный конфиг веб-сервера в правильное место, рестартануть веб-сервер только в случае если конфиг изменился и пр. ИМХО ant/phing для этого не очень хорошо подходят, потому что все-таки читабельность его XML очень сомнительна, мне кажется. И что-то более или менее большое на нем сложновато поддерживать.
Мы у себя используем phing для того чтобы собрать deb-пакет со всеми артефактами и прогнать перед этим юниттесты
Для меня deb это в первую очередь положить в правильные места все необходимые артефакты. Если юзать для этого просто архивы, а не deb, то нужно париться о многих вещах. Во-первых нельзя просто так распаковать новую версию поверх старой, потому что в новой могут удалиться какие-то файлы, их не должно быть после деплоя. Во-вторых нельзя просто так взять и удалить старую версию перед распаковыванием новой, потому что там могут быть какие-то генерируемые во время работы файлы. Приходится писать какие-то скрипты, которые будут удалять все кроме всяких uploaded_images папок. ИМХО это велосипед, потому что deb это идеально сам разруливает.
Далее, кроме того чтобы положить правильные файлы в правильное место при деплое надо сделать еще кое-какие действия: обновить кеш, смигрировать БД, перезапустить воркеров, etc. Мне тоже не нравится делать это в preinstall/postinstall хуках. У нас, например, этим занимается ansible вместе с остальной частью провиженинга системы, такой как: положить правильный конфиг веб-сервера в правильное место, рестартануть веб-сервер только в случае если конфиг изменился и пр. ИМХО ant/phing для этого не очень хорошо подходят, потому что все-таки читабельность его XML очень сомнительна, мне кажется. И что-то более или менее большое на нем сложновато поддерживать.
Мы у себя используем phing для того чтобы собрать deb-пакет со всеми артефактами и прогнать перед этим юниттесты
ИМХО ant/phing для этого не очень хорошо подходят, потому что все-таки читабельность его XML очень сомнительна, мне кажется. И что-то более или менее большое на нем сложновато поддерживать.
Я видел сценарии build & delivery реализованные на Ant и на Maven в десятки тысяч строк(XML), разбитые на десятки под-файлов с несколькими десятками под-сценариев, с достаточно сложной, но легко читаемой логикой зависимостей между ними. И вот представить всю эту красоту описанной на deb + bash… извините, но лично мне не хватает фантазии.
Понятно, что опытные админы могут легко читать bash скрипты любых размеров и сложности. Но, опять таки, как я уже писал выше, я за то, чтобы сценарии сборки и выкладки проектов писались программистами, а не админами. Как-то раз столкнулся с ситуацией, когда после увольнение админа команда ещё неделю с ума сходила, чтобы в его deb + bash скриптах разобраться. Хотя сценарий выкладки там был не такой уж сложный. С тех пор я эти решения на дух не переношу.
А в плане хитрого delivery, всё о чём вы говорите вполне реализуемо на Ant/Maven, весь необходимый функционал для этого там есть. Был бы только мозг способный этим функционалом правильно воспользоваться.
Вы, наверное, не внимательно читали мой комментарий. Я призываю использовать deb для копирования файлов на сервер и распаковки правильных файлов в правильном месте, для правильной замены и удаления файлов старых версий. Согласен с вами, что деплой на bash скриптах это жесть.
Посмотрите в сторону ansible для деплоя и провиженинга, может быть передумаете и выкинете phing после этого )
Посмотрите в сторону ansible для деплоя и провиженинга, может быть передумаете и выкинете phing после этого )
А веб-проекты — это не серверное ПО?
Нет, веб-проекты — это не серверное ПО. Ничего не имею против того, чтобы админы использовали deb/rpm пакеты для обновления серверного ПО т.к. там не такие сложные сценарии, и т.к. программистам в принципе лучше не соваться в эти сценарии.
Сценарий сборки и выкладки веб-проектов не так просты как сценарии обновления серверного ПО т.к. они во много зависят от архитектуры проекта(которую админ может не понимать до конца), от бизнес-логики некоторых компонентов(о которой админ может не знать) и т.д. и т.п. Ни один админ не будет знать логику функционирования веб-проекта лучше чем программист, который его реализовал. Поэтому, моё мнение, что сценарий сборки и выкладки должны описывать программисты, а не админы. Поэтому, я считаю, что сценарии сборки и выкладки должны описываться не на deb/rpm пакетах, а на легко читаемых и кроссплатформенных инструментах деплоя типа Ant/Phing/Maven и т.п.
Сценарий сборки и выкладки веб-проектов не так просты как сценарии обновления серверного ПО т.к. они во много зависят от архитектуры проекта(которую админ может не понимать до конца), от бизнес-логики некоторых компонентов(о которой админ может не знать) и т.д. и т.п. Ни один админ не будет знать логику функционирования веб-проекта лучше чем программист, который его реализовал. Поэтому, моё мнение, что сценарий сборки и выкладки должны описывать программисты, а не админы. Поэтому, я считаю, что сценарии сборки и выкладки должны описываться не на deb/rpm пакетах, а на легко читаемых и кроссплатформенных инструментах деплоя типа Ant/Phing/Maven и т.п.
На серверах приложения раскладываются с помощью пакетов и это, на мой взгляд, наиболее правильный и наименее велосипедный способ.
Используя пакеты, прямые руки и светлую голову, у вас автоматом появляется контроль и удовлетворение внешних зависимостей, откат поломанных релизов, чистоту и порядок на рабочем месте и мягкие и шелковистые волосы.
P.S. конечно, не следует пакетировать конфиги. Конфиги должны храниться в VCS и управляться через SCM.
Используя пакеты, прямые руки и светлую голову, у вас автоматом появляется контроль и удовлетворение внешних зависимостей, откат поломанных релизов, чистоту и порядок на рабочем месте и мягкие и шелковистые волосы.
P.S. конечно, не следует пакетировать конфиги. Конфиги должны храниться в VCS и управляться через SCM.
puppet apply
fabric + jenkins
Amazon ESB + puppet + docker + serf + собственная обвязка на bash + php
buildbot
Не указаны следующие варианты :)
Всё делает bash-скрипт:
— Переключает nginx на страницу «ведутся работы»
— Делает свежий дамп базы и копирует куда нужно.
— Скачивает рабочую версию из svn-репозитория.
— Собственно обновляет приложение.
— Запускает приложение и переключает nginx обратно.
Для переключения nginx на страницу «ведутся работы», скрипт создает пустой файл в специальном каталоге, который проверяет nginx и в случае, если файл существует, nginx выдает страницу-заглушку.
— Переключает nginx на страницу «ведутся работы»
— Делает свежий дамп базы и копирует куда нужно.
— Скачивает рабочую версию из svn-репозитория.
— Собственно обновляет приложение.
— Запускает приложение и переключает nginx обратно.
Для переключения nginx на страницу «ведутся работы», скрипт создает пустой файл в специальном каталоге, который проверяет nginx и в случае, если файл существует, nginx выдает страницу-заглушку.
НЛО прилетело и опубликовало эту надпись здесь
capistrano (Rails)
Используем FTP, но прямо сейчас выбираем более удобный вариант для выгрузки из SVN.
В связи с чем вопрос к указавшим capistrano и тп — если использовать подход с симлинком, как быть с папками которые не входят в репозитории и которые не нужно трогать вообще?
Пример:
/public/
../app — 10 кб
../data — 100 Гб
Если создается симлинк на папку /public — и потом обновляется только /app — то огромная папка /data не будет копироваться? К сожалению не очень силён в настройках unix — поэтому прошу сообщество подсказать. Направить на верный путь.
В связи с чем вопрос к указавшим capistrano и тп — если использовать подход с симлинком, как быть с папками которые не входят в репозитории и которые не нужно трогать вообще?
Пример:
/public/
../app — 10 кб
../data — 100 Гб
Если создается симлинк на папку /public — и потом обновляется только /app — то огромная папка /data не будет копироваться? К сожалению не очень силён в настройках unix — поэтому прошу сообщество подсказать. Направить на верный путь.
Capistrano стандартно создает (при команде deploy:setup) директорию shared, где лежат данные, не изменяющиеся при деплое.
Т. е. если data не изменяется при деплое, то можно переместить её в shared и настроить создание нужного симлинка в каждом релизе на неё.
app
|`- current -> releases/20140101100000
|`- releases
| |`- 20130101100000
| `- 20140101100000
`- shared
Т. е. если data не изменяется при деплое, то можно переместить её в shared и настроить создание нужного симлинка в каждом релизе на неё.
1. Нажимаем на кнопку в Jenkins-е -> Делается git clone репозитория, нагоняется buildout (buildout т.к. проекта на python-е, в случае php для этих целей мы используем phing), билдится rpm-ка проекта и кладется в rpm-репозиторий
2. Даем команду salt-у (cм. SaltStack), который раскатывает собранную rpm-ку по серверам, вносит на каждом из серверов необходимые изменения в файлы конфигураций, после чего выполняется миграция БД и делается синхронный рестарт веб-серверов
2. Даем команду salt-у (cм. SaltStack), который раскатывает собранную rpm-ку по серверам, вносит на каждом из серверов необходимые изменения в файлы конфигураций, после чего выполняется миграция БД и делается синхронный рестарт веб-серверов
capistrano
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Опрос. Как вы делаете деплой на production сервер(а)?