распространение кода на сервера

git?

т е центральный репозитарий + куча маленьких копий на серверах ? Некрасиво как-то - нет автоматизации для всяких конфиг файлов ( ведь они разные для разных машин )

Как раз донастраиваю ChiliProject, и поднимаю Git, так как самому уже надоело ручками делать.

Хранить настройки и параметры в центральной БД?

puppet какой-нить?

Разные настройки для разных машин в разных бранчах

rsync, nfs

svn, конфиги автоматом мержатся при svn up, но нужно следить за возможными конфликтами

ведь они разные для разных машин

Индивидуальные настройки как раз на конкретных машинах и хранят. Общий код — в vcs.

Разные настройки для разных машин в разных бранчах

Даже пароли?

голосую за пакетики! обновлять же потом придется!

В крон команду git pull

Не, пароли куда-нибудь ещё

и чего же тогда бинарные дистрибутивы через этот ваш гит-пулл не обновляются?!

не, я не против гита, но зачем засирать систему, если в ней есть пакетный манагер?

и чего же тогда бинарные дистрибутивы через этот ваш гит-пулл не обновляются?!

Я думаю, ты сам прекрасно сможешь назвать причины.

Пакеты. DVCS для этого не предназначены.

так о чем и речь! я, если чё, гит-пулл не пиярил для задачи ТС-а. ;)

так о чем и речь!

Речь идет о применимости vcs в качестве дешевого и сердитого деплой-тула. И, в не особо ответственных случаях, он с этой ролью вполне может справиться.

вы еще предложИте через тарболы деплоить, ага...

Хах. FreeBSD, Gentoo, Ubuntu, Debian - целый зоопарк машин, и для каждой собирать пакеты/ебилды/порты?

в ОП сказано про зоопарк?
да, собирать.

вы еще предложИте через тарболы деплоить, ага...

Не агитируйте за чрезмерный энтерпрайз там где это не нужно.

Два пути

* во первых - HMS (puppet, cfengine, pikt, ...)

* во вторых - DVCS, VCS + соотв изменения в приложении. Этот путь проще.

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

Собственно ваш конфликт - файл конфига лежит по одному пути а конфиги везде разные это следствие того что в вашем приложении использование в распределенной системе не предусмотрено. Распределенная система де-факто рассматриваться как множество одиночных машин которые админят разные люди.

В классическом юникс (и его подходе к приложениям) это решается host-зависимыми секциями конфига или файла. Банальный пример - /etc/sudoers

Самый тупой вариант - ваше приложение должно смотреть в хостнейм и грузить my-config-${HOSTNAME}.config , и соотвественно сигналить о том если my-config-${HOSTNAME}.config не найден, работа невозможна.

Как вариант написать свой ботнет =-) я кстати так и сделал для того, чтобы рулить зоопарком машин.

вы еще предложИте через тарболы деплоить, ага...

На старой работе так и было сделано. Всё было автоматизировано до предела. И весь разворачивающий скрипт был в 20 строк. Намного меньше чем мудохаться с deb/rpm спекой.

только торенты, только хардкор

да, собирать.

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

> Как решал проблему плавного переключения на новую версию в пределах одной ноды?

Что такое «плавное переключение» и чем оно отличается от апгрейда пакета?

Что такое «плавное переключение» и чем оно отличается от апгрейда пакета?

Это, видимо, специфика php. Но с пакетом будет следующая ситуация: во время его установки сервер работает на смешанном коде, по мере копирования файлов. Плавное переключение позволяло убрать этот рейс.

«плавное переключение» - это по 5 новых строк кода в день? чтобы аппаратуру не шокировать? ;)

и да, как заметили ниже, немного не понятно, чем это будет отличаться от обновления пакета.

Еще случай. Есть рассыпуха достаточно легких, но критичных вебсервисов, вполне работающих на одном сервере. Простой больше 10 секунд — бида. Рестарт сервиса около минуты. Как обеспечить непрерывную работу через обновление пакетом?

> во время его установки сервер работает на смешанном коде, по мере копирования файлов

Я не вижу, как можно избежать проблем без остановки/приостановки сервера.

Есть рассыпуха достаточно легких, но критичных вебсервисов, вполне работающих на одном сервере. Простой больше 10 секунд — бида. Рестарт сервиса около минуты.

И какова стандартная процедура обновления?

Я не вижу, как можно избежать проблем без остановки/приостановки сервера.

php-fpm может делать graceful stop/start. То есть в конфиге указываем новый путь и делаем релоад. Текущие коннекты работают со старым кодом, а новые с новым.

процедура обновления?

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

> При деплое новой версии, запускается еще один инстанс, на него переключается балансер, если всё в порядке, то старая версия тушится.

То же самое можно сделать из preinst и postinst скриптов. Впрочем, если речь о Java, то там же своя аритектура и инструменты для деплоя.

То же самое можно сделать из preinst и postinst скриптов.

Вижу только одно применение: есть много нод, со своей фс, тогда локальный репозиторий с пакетами дает хоть какие-то преимущества.