Как "деплойвате"
Petyo Ivanov
Ако не сте обърнали внимание, с Христо ни предстои едно -излагане-/
презентация на тема деплоймънт на продукт. Ако го изнесем извън
контекста на уеб приложението, можем да го гледаме като пускане в
експлоатация, или "release-ване". Знам как се рилийсват релси, и
гледам как става при .нет-а (специално за уеб приложенията). Пълна
мъгла ми е как стоят нещата в другите платформи. Как е в Питон? А при
ПХП? Краси беше правил рецепти за деплой на ПХП през капистрано. А
джавърите как деплойват?
Ще се радвам да разкажете малко истории за вашия процес на пускане в
експлоатация.
Петьо
Nikolay Bachiyski
> Привет,
>
> Ако не сте обърнали внимание, с Христо ни предстои едно -излагане-/
> презентация на тема деплоймънт на продукт. Ако го изнесем извън
> контекста на уеб приложението, можем да го гледаме като пускане в
> експлоатация, или "release-ване". Знам как се рилийсват релси, и
> гледам как става при .нет-а (специално за уеб приложенията). Пълна
> мъгла ми е как стоят нещата в другите платформи. Как е в Питон? А при
> ПХП? Краси беше правил рецепти за деплой на ПХП през капистрано. А
> джавърите как деплойват?
>
В PHP света няма утвърдено приложение за deploy. Някои ползват капистрано,
някои техни си неща. Няма нищо универсално и готино.
> Ще се радвам да разкажете малко истории за вашия процес на пускане в
> експлоатация.
Два аспекта – философски и технически.
Философски:
* Всеки, който има commit права до хранилището може да deploy-ва. Дори
и дизайнерите.
* Всички се окуражават да го правят максимално често. Така свикват да си
цепят работата на дребни *и* работещи парчета.
* Процесът трябва да е много лесен. Един бутон или една команда в конзолата.
* Процесът трябва да максимално бърз. За това повече при техническите
глупости.
Технически:
* svn up на всяка машина
* Има само един checkout, няма символни връзки като при капистрано. Ако искаш
да можеш да сменяш много лесно межу старо и ново копие има два варианта:
= бавен – всеки път checkout-ваш ново копие и сменяш със старото при
deploy (така прави капистрано);
= сложен – пазиш две работни копия. При deploy svn up-ваш неактивното,
сменяш ги и после svn up-ваш другото.
Досега (противно на моите очаквания), не сме имали проблеми. Ако някъде има
проблеми със svn up-а, просто сървърът се вади от ротацията автоматично.
* Сървърите са твърде много и един svn сървър не може да удържи всички
желаещи. Затова се налага да се репликира хранилището със svnsync на няколко
slave-а само за четене.
* Няма svn externals, които не контролираме и които не можем да минем през
svnsync. Това е добра идея така или иначе.
* Има няколко svn externals, които са си при нас и които може да не се
deploy-ват, ако не си ги пипал: преводи, теми, такива неща.
* Не генерираме нищо по време на deploy. CSS и JavaScript се мачкат
on-the-fly със съответното стабилно кеширане. Така се избягват тъпи
неконсистености и процесът остава бърз.
* Скоростта на svn up зависи от кеша на файловата система. При два близки
във времето deploy-а вторият може да е много много бърз, защото всичко,
което му трябва на svn up е в stat кеша.
* 10-20 секунди.
И за накрая, deploy на схема на базата от данни. Накратко – на ръка с лесен
начин за връщане обратно, ако нещо се омаже.
Имаме код, който минава автоматично от една схема на друга. Така се upgrade-ва
WordPress. Но при по-голяма и сложна база нещата не са толкова прости.
В MySQL ALTER TABLE заключва таблицата и не дава да се прави нищо по нея, докато
не свърши. Един грешен ALTER TABLE, после цял живот replciation lag.
Затова минахме
на по-ръчен режим, за да може всички да осъзнават и по-важното – да
виждат навреме
резултата от действията си. Междувременно един бот върви и следи за промени в
структурата и ги държи в svn. После може с една команда да се върнеш на предна
ревизия, ако нещо не ти харесва и не искаш да рискуваш да връщаш старата
структура на ръка.
Н.
--
Subscription settings: http://groups.google.com/group/software-craftsmanship-bulgaria/subscribe?hl=bg
Nasko
Най-напред искам да ви поздравя за презентацията - ако съдя по
отзивите на хората около мен, трябва да сте се -изложили- доста
качествено :-)
Как ние деплойваме PHP приложения:
Ами понеже все още Continuous integration стека не ни е пълен (доста
legacy code, практически нетестваем) деплоймънта се извършва на 2
стъпки:
* Мърджване на ревизии в production бранча
* Стартиране на PHING деплоймънт скрипт (http://phing.info)
PHING е порт на Apache ANT, написан на PHP, което го прави доста лесен
за разширяване. Например в предишната стабилна версия липсваше
SshTask, който се ползва ако искаш да изпълниш някаква конзолна
команда на отдалечената машина - преди или след деплоймънт. Някой беше
добавил тази функционалност с 30-40 реда PHP код, а по-късно влезе в
следващата стабилна версия.
Няма да се впускам в подробности за възможностите на PHING - който
вече е заинтересован, може да прегледа документацията на сайта им -
само ще спомена 2-3 основни неща, които ние ползваме в нашите build
сценарии:
* Изтриваме предния рилийз от локалната машина - тази от която се
стартира деплоймънта (DeleteTask)
* Създаваме отново същата папка (MkdirTask)
* Експортираме production бранча (SvnExportTask)
* Подменяме динамичните стойности в различни конфиг файлове, с
предефинирани такива в *.properties файл (FileSet, ReflexiveTask,
ReplaceRegexp)
* Катерим на отдалечената машина (ScpTask, FtpDeployTask, ExecTask +
rsync)
Ето тук съм постнал примерен build XML скрипт от един от моите
проекти, писан на CakePHP: http://pastebin.com/6cp75P1u
Променливите стойности - ${...}, се заместват с литерали от
съпътстващия build.properties файл, който не съм постнал (синтаксисът
е variable=value редове)
Не правим симлинкове, което означава, че теоретично през около 10-те
секунди, които трае деплоъмънта може някой да види грешка. В повечето
случаи ползваме RSYNC като транспортен слой, който пък качва само
делтите, така че освен ако не е начален деплоймънт почти винаги самото
качване не отнема повече от 4-5 секунди.
Ако се наложи да се върне спешно предишната версия, просто ролбакваме
последната ревизия от Production бранча и деплойваме отново.
Ами това е, ще се радвам на критики и идеи за усъвършенстване на
процеса ни.
Поздрави,
Атанас Василев
Hristo Deshev
Благодаря за поста. Интересно ми беше да науча, че има порт на Ant за PHP. Нали знаете каква е разликата между Ant и Maven за джава деплоймънт - авторът на Ant се извини на обществото за ужасите, които причини с този XML, а тия от Maven още си мълчат. :-)
Конкретно за билда ти, ми прави впечатление странното подменяне с регекси на разни пропъртита в конфиг файл. Предполагам това ти трябва, за да поддържаш различни конфигурации - стейджинг, продъкшън и т.н. Играл съм я тази игра и според мен е по-просто тези неща да се дръпнат в отделен конфиг файл, който има същото име - staging.config, production.config, etc. Така при деплой просто копираш или преименуваш файла до therealconfig.config и си готов.
Иначе си имам едно мрънкане за инструментите, които ни карат да програмираме с XML...
Понеже съм потрошил страшно много време с XML-базирани билд/деплой тулове, вече съм 100% убеден, че такива трябва да се избягват при всяка възможност. Ant/NAnt/MSBuild примерно (тези, с които съм работил) са адски добри за премятане на файлове насам-натам - абстракциите за файлсетовете са доста добри и вършат работа. Обаче, за други неща, тези инструменти са пълна дупка. Ако искаш нещо по-интересно - да кажем парсване на нещо от файл, четене от пайп, викане на .NET, COM или каквото и да е API, си сам - почваш да пишеш свои таскове до полудяване. Друго си е да имаш истински език за програмиране - в това отношение Rake е абсолютният шампион за мен.
Между другото попаднах на Rake порт за PHP - Phake: http://github.com/jaz303/phake. Не знам колко е завършен обаче. Поне изглежда интересно.
Христо
Atanas Vasilev
Благодаря много за коментарите ти, със сигурност ще обмисля всички
аспекти на решението ми още веднъж.
On 04/26/2010 10:56 AM, Hristo Deshev wrote:
> Здравей, Атанасе,
>
> Благодаря за поста. Интересно ми беше да науча, че има порт на Ant за
> PHP. Нали знаете каква е разликата между Ant и Maven за джава
> деплоймънт - авторът на Ant се извини на обществото за ужасите, които
> причини с този XML, а тия от Maven още си мълчат. :-)
>
Умишлено прескочих Капистрано като вариант, защото влече със себе си
доста зависимости към външни приложения, които дори не са нейтив за
типичната среда, която обикновено PHP разработчиците инсталират на
компютрите си. Това от една страна би затормозило сетъпването му на
всички девелоперски машини, а от друга - няма да ни позволи да го
разширяваме когато/ако се наложи, заради това, че не е реализиран на
езика за програмиране, който ползваме.
Другата основна причина е, че Phing може почти без никакви други
зависимости и със съвсем козметични промени в билд-файла да се изпълнява
и от страната на отдалечената машина, което не би било вярно за варианта
с Капистрано. Не че имаме такъв билд, който се инициира от отдалечената
машина, но аргументът си беше налице, когато взимахме решение за
инструмента.
> Конкретно за билда ти, ми прави впечатление странното подменяне с
> регекси на разни пропъртита в конфиг файл. Предполагам това ти трябва,
> за да поддържаш различни конфигурации - стейджинг, продъкшън и т.н.
> Играл съм я тази игра и според мен е по-просто тези неща да се дръпнат
> в отделен конфиг файл, който има същото име - staging.config,
> production.config, etc. Така при деплой просто копираш или преименуваш
> файла до therealconfig.config и си готов.
Прав си разбира се, че вариантът с отделни конфиг файлове е доста
по-чист за изпълнение. Моята обосновка е, че исках в случаите когато са
забъркани повече от 2-3 файла, в които има environment-specific
настройки да може с бърз поглед в един единствен файл на всеки да му
стане ясно, кои са те и какво точно се подменя. При твоя вариант за да
стане ясно кои са тези файлове би било нужно да се гледа в отделните
папки, където се намират. Както вече писах, ще ревизирам билда си.
>
> Иначе си имам едно мрънкане за инструментите, които ни карат да
> програмираме с XML...
>
> Понеже съм потрошил страшно много време с XML-базирани билд/деплой
> тулове, вече съм 100% убеден, че такива трябва да се избягват при
> всяка възможност. Ant/NAnt/MSBuild примерно (тези, с които съм
> работил) са адски добри за премятане на файлове насам-натам -
> абстракциите за файлсетовете са доста добри и вършат работа. Обаче, за
> други неща, тези инструменти са пълна дупка. Ако искаш нещо
> по-интересно - да кажем парсване на нещо от файл, четене от пайп,
> викане на .NET, COM или каквото и да е API, си сам - почваш да пишеш
> свои таскове до полудяване. Друго си е да имаш истински език за
> програмиране - в това отношение Rake е абсолютният шампион за мен.
>
> Между другото попаднах на Rake порт за PHP - Phake:
> http://github.com/jaz303/phake. Не знам колко е завършен обаче. Поне
> изглежда интересно.
>
За съжаление Phake е за PHP 5.3, което не мога да прогнозирам, кога ще
може да ползваме за клиентски приложения.
Наистина би било интересно ако и други споделят техните билд стратегии,
така всички ще научим много.
//Н.
Liubomir Petrov
време ми отнема да му се чудя, отколкото да свърша нещо практично.
Вариантите като капистрано..хм, не съм запознат много с тях, но самото
капистрано съдържа тонове неща, които не ми трябват + (няма да го
крия) не съм фен на Руби, от което следва, че като отворя "Getting
started" и затварям :)
През времето, съм опитвал доста варианти... един от които (колкото и
учудващо и за мен) беше, чрез svn up. Работи...така, че мисля, че на
него ще си остана :)
В допълнение, си имам 10-20 реда код които освен svn up, ми правят
post-update операцииките.
Примитивно или не, имам гъвкавостта от която се нуждая, а не обичам да
ме ограничават :)
> Subscription settings:http://groups.google.com/group/software-craftsmanship-bulgaria/subscr...
Valentin Mihov
справяш с този проблем?
Много ценна дискусия! Особенно ми хареса обосновката защо ant е зле.
Напълно съм съгласен с нея. Иначе ние на работа мисля, че ползваме
capistrano, но тъй като не съм аз този, които се занимава с тези неща,
не съм много наясно. Но определено имаме дпълнителна стъпка на пускане
на smoke интеграционни тестове върху деплойнатите неща за да се
провери дали нещо не е изгърмяло и разбира се ако нещо не е наред се
прави rollback. Ако науча нещо по-интересно ще пиша :-)
Поздрави,
Вальо
2010/5/2 Liubomir Petrov <liubomi...@gmail.com>:
Liubomir Petrov
От друга страна, самата архитектура която аз ползвам...съм разделил приложението на много малки ""приложениийца"", които ъпдейтвам и следя по отделно. По-лесно ми е :)
Иначе от някъде ми хрумна идеята (май съм го чел някъде) за пакетиране на приложенията в pkg (debian/ubuntu) и локален сървър, които да ги държи... доста удобно за maintaince ми се струва, някой от вас пробвал ли е нещо такова?
А и като заговорихме за ферми... по-сериозен проблем ми се струва как да поддържам 100 сървъра с up-to-date packages?
Поздрави,
Любомир Петров
Founder of Bizz.bg
Mobile: +359 897 994 386
E-Mail: lpe...@mylo.bg and lpe...@bizz.bg
E-Commerce Software as a Service: http://www.Bizz.bg/
Nikolay Bachiyski
> Ферма, за сега не...имаме 3-4-5 сървръа под ръка и все още не мисля, че ми е
> толкова трудно да се разходя и да направя ./svnup
> От друга страна, самата архитектура която аз ползвам...съм разделил
> приложението на много малки ""приложениийца"", които ъпдейтвам и следя по
> отделно. По-лесно ми е :)
Спри каквото правиш и си направи скрипт, който се логва през ssh към
всичките ти сървъри и вика този ./svnup Наистина ти трябва възможност
да deploy-ваш с *едно* натискане на команда. Някоя нощ ще се счупи
нещо, ще си толкова пиян, че ще си си забравил и имената на сървърите,
но няма да си забравил как да викаш ./svnup Накратко – ако имаш да
правиш 3-4-5 неща, все ще намериш кое да объркаш. Аз лично използвам
всяка възможност да объркам нещо :-)
В скрипта можеш да си вкараш и svn up-ване на под-системки. Например
може да му даваш по-директория на основната като аргумент и той
обновява само нея.
>
> Иначе от някъде ми хрумна идеята (май съм го чел някъде) за пакетиране на
> приложенията в pkg (debian/ubuntu) и локален сървър, които да ги държи...
> доста удобно за maintaince ми се струва, някой от вас пробвал ли е нещо
> такова?
Пробвал съм го навремето с FreeBSD. Удобно е, защото имаш инструменти,
с които лесно да си го обновяваш и да оправяш зависимости. На практика
обаче тези неща не ти трябват.
Тъй като сървърите ти са на практика еднакви можеш да слагаш едно и
също нещо с всичките му зависимости. Дори на някой сървър да сложиш
някой излишен компонент си заслужава заради еднаквостта. Ако пък някой
от компонентите ти е тооолкова голям ще му мислиш тогава :-)
>
> А и като заговорихме за ферми... по-сериозен проблем ми се струва как да
> поддържам 100 сървъра с up-to-date packages?
Ако сървърите са еднакви няма проблеми. Пускаш обновяването на един и
ако няма драми, пускаш и на другите.
Много администратори поддържат философията на Debian Stable да
обновяват цялата система рядко. Разбира се, важните ти пакети си ги
пре-компилираш и обновяваш сам, но те обикновено са малко.
Н.
Liubomir Petrov
> Ферма, за сега не...имаме 3-4-5 сървръа под ръка и все още не мисля, че ми еСпри каквото правиш и си направи скрипт, който се логва през ssh към
> толкова трудно да се разходя и да направя ./svnup
> От друга страна, самата архитектура която аз ползвам...съм разделил
> приложението на много малки ""приложениийца"", които ъпдейтвам и следя по
> отделно. По-лесно ми е :)
всичките ти сървъри и вика този ./svnup Наистина ти трябва възможност
да deploy-ваш с *едно* натискане на команда. Някоя нощ ще се счупи
нещо, ще си толкова пиян, че ще си си забравил и имената на сървърите,
но няма да си забравил как да викаш ./svnup Накратко – ако имаш да
правиш 3-4-5 неща, все ще намериш кое да объркаш. Аз лично използвам
всяка възможност да объркам нещо :-)
В скрипта можеш да си вкараш и svn up-ване на под-системки. Например
може да му даваш по-директория на основната като аргумент и той
обновява само нея.
Самите приложения, за момента са ми на един и същи сървър и само него ъпдейтвам, за вбъдеще ще ги деля според нуждите им, но за сега още не съм стигнал толкова голямо натоварване :)
Пробвал съм го навремето с FreeBSD. Удобно е, защото имаш инструменти,
>
> Иначе от някъде ми хрумна идеята (май съм го чел някъде) за пакетиране на
> приложенията в pkg (debian/ubuntu) и локален сървър, които да ги държи...
> доста удобно за maintaince ми се струва, някой от вас пробвал ли е нещо
> такова?
с които лесно да си го обновяваш и да оправяш зависимости. На практика
обаче тези неща не ти трябват.
Тъй като сървърите ти са на практика еднакви можеш да слагаш едно и
също нещо с всичките му зависимости. Дори на някой сървър да сложиш
някой излишен компонент си заслужава заради еднаквостта. Ако пък някой
от компонентите ти е тооолкова голям ще му мислиш тогава :-)
Ако сървърите са еднакви няма проблеми. Пускаш обновяването на един и
>
> А и като заговорихме за ферми... по-сериозен проблем ми се струва как да
> поддържам 100 сървъра с up-to-date packages?
ако няма драми, пускаш и на другите.
Много администратори поддържат философията на Debian Stable да
обновяват цялата система рядко. Разбира се, важните ти пакети си ги
пре-компилираш и обновяваш сам, но те обикновено са малко.
Мисля, за вбъдеще да седна да напиша един ssh скрипт, които да го пускам ръчно и да ъпдейтва всички машини/пакети с latest stable (чрез apt).. но пък се притеснявам, защото на практика има доста пакети, които не се актуализират често (пр. nginx... :/).
Тук пак има решение де, но не е толкова просто.. да си правя прекомпилирани пакети за сървърите и локално repo за пакетите... но е голяма занимавка и се чудих, дали има начин да го пропусна :)
Н.
Като цяло, май съм в правилната посока, 10кс за съветите :)
Petyo Ivanov
пакетите, само трябва да прецениш дали инвестицията ще е оправдана.
Което пък опира как ще скейлваш, което пък идва да определи как го
мериш това ми ти скейлване - друга тема с две думи.
On May 2, 8:30 pm, Liubomir Petrov <liubomir.pet...@gmail.com> wrote:
> 2010/5/2 Liubomir Petrov <liubomir.pet...@gmail.com>: