Dotaz: Automatizace nasazovani PHP do produkce

[ET]

Zdravim,

zdedil jsem jednu apku v PHP (po odeslych programatorech) a resim, jak zautomatizovat deployment kodu do produkce (pro novy server, na ktery se bude migrovat). Kod je zatim v SVN, ale planuji prestehovat do GITu (resp. on-premise gitlabu).

 

Produkcni server je klasicke kombo NGINX/PHP-FPM/MARIADB, kde ma kazdy "zakaznik" vlastni instanci, tj:

* vlastni (sub)domenu/www-root

* vlastni kod (vetsinou stejny mezi instancemi, ale pro testovani se nekdy pouziva kod z jine revize/branche)

* vlastni DB (postavenou z "migrations" skriptu)

 

Hledam teda nastroj, ktery umi "snadno":

1) vytvorit/upravit NGINX konfigurak pro novy/stavajici VirtualHost

2) nasadit do daneho www-rootu/domeny kod z SVN/GIT (e.g. revize/branche 12345xyz)

3) vytvorit prazdnou DB a spustit "migrations" skripty

bohuzel jsem nic moc pouzitelneho nenasel (mozna prehledl).

 

Jak provadite deployment u podobnych projektu? Nechce se mi verit, ze to vsichni bastli svymi vlastnimi skripty (navesenymi do SVN/GIT hooku apod.), nebo pouzivaji vice nezavislych nastroju (pro nginx, pro GIT/SVN, pro DB).  Koukal jsem na Gitlab CI, ale to mi pripada, ze je spise na "testovani" kodu, nez na deployment na server...

 

Predem diky za pripadne nasmerovani/doporuceni.

 

 

 

 

 

 

 

Odpovědi

[Pavel 'TIGER' Růžička]

Ano, myslím si, že toto je přesný čas pro vlastní skripty.

[xkucf03]

+1

Poslední dobrou se často setkávám s jakýmsi náboženstvím (nebo jak to nazvat), že by na všechno měl existovat nějaký dedikovaný nástroj, který danou činnost „usnadní“.

Spousta nástrojů, frameworků a knihoven často ale práci spíš přidělávají – zejména pokud se použijí na menší úkoly, než pro jaké byly navržené.

Ano, pro hromadné nasazování existuje třeba Ansible, Puppet, CFE a další. Na automatizované úpravy konfiguráků zase Augeas. Ale zrovna to, co chce tazatel, bych řešil pomocí Bashe a SSH.

Nechce se mi verit, ze to vsichni bastli svymi vlastnimi skripty

Na tom není nic neuvěřitelného a často je to nejlepší volba. Bash je přesně nástroj pro úlohy typu „potřebuji něco někam nakopírovat“ nebo „potřebuji spustit příkaz XY“. Pokud je někomu bližší třeba Perl nebo Python, udělá v nich totéž, jako v tom Bashi.

[Pavel 'TIGER' Růžička]

Já se s tím také setkávám, ale vnímám to jako: "Nechci to dělat, nebaví mne to, chci aby to za mne udělalo něco jiného a já mohl strávit čas jinak." A vlastně to je ještě ten lepší případ, v tom horším je v seznamu navíc "... neumím to ..." Přijde mi, že ubývá lidí, které jejich práce baví. Tím, nechci říct, že je to i tento případ. Někdy je zase dobré znát možnosti a mít možnost výběru.

[ET]

Panove diky, ale zbytecnej hrot ;)

Ja si to klidne zbastlim v bash/php/python/java a po nikom nechci, aby to delal za me - jen nechci vynalezat kolo pro takto beznou ulohu. Rad bych to po realizaci nekomu predal, coz s "prasenim" vlastnich skriptu moc dohromady nejde ;). Ale mozna by to byl dobry namet na novy (OSS) projekt.

Jak teda bezne pouzivate celej ten cirkus pro deployment?

* pouzivate ciste bash - tj. mate hromadu skriptu a ty pak pri deploymentu volate?

* mate (web)gui, nebo ciste prikazova radka?

* umite roll-back? (nebo pak nekde zustava smeti)

* pouzivate pro skripty navrhovy vzor(y)?

* jak "generujete" konfigurak pro nginx(/apache)? Mate sablonu a tu kopirujete a `sed`ujete?

* kolik dalsich lidi to umi ovladat? mate to zdokumentovane? komentare v kodu? wiki? readme?

PS: webmin nechci

[Pavel 'TIGER' Růžička]

Podle mne tohle všechno se odvíjí i od toho, jak schopnému člověku to budeš předávat. Někdo se raději naučí to, co připravíš, jiný si to raději předělá podle sebe.

* pokud bych nenarazil na nějakou překvapivou překážku, tak by mi mohl bash stačit.

* web gui k tomuto není potřeba

* raději s roll-backem

* návrhové vzory většinou ne

* ano, předpřipravená šablona je fajn

* nikdo, ale kdyby takový požadavek byl, není problém zaškolit. Nejsem nejmladší, takže komentáře v ḱódu určitě. Zbytek dle požadavků, nebo složitosti projektu.

PS: Ani já bych k tomuto účelu webmin nechtěl.

[Vlado]

+1 Naučiť sa logiku niektorého "kombajnu", nakonfigurovať ho, vysporiadať sa s jeho zvláštnosťami, ... to môže byť viac práce a starostí, než napísať pár skriptov na mieru.

Namiesto slova "náboženstvo" ma napadá skôr "choroba": ako sú dnes ľudia zblnutí z klikania, majú pocit, ze všetko sa musí naklikať (prípadne napatlať prstom na obrazovke).

[Kit]

V současné době dělám deployment přes

make deploy

a potřebné závislosti mám ukryty v Makefile. Výhodou je, že jsou hezky pohromadě, sdílené s ostatními požadavky (DRY) a že se přes to dobře spouští generátory.

[ET]

Diky, to mi pripada celkem elegantni (i kdyz stale na urovni "praseni" vlastnich skriptu). Jestli tomu dobre rozumim, ma teda kazda "instance" vlastni Makefile (s vlastnimi parametry)?

[xkucf03]

Make je dobrá věc a nutí dát těm skriptům nějakou strukturu a trochu standardní UI.

Jinak nevím, proč o tom píšeš pořád jako o „prasení“ – umět číst a psát jednoduché skripty je základní schopnost, kterou by každý administrátor měl mít. Jasně, že předat někomu stovky nebo tisíce řádků nepřehledných skriptů je špatně, ale to tu nikdo neradí. Většina podobných skriptů se ale dá napsat v délce cca na jednu obrazovku – a když k tomu přijde někdo jiný, tak jen koukne a vidí. Pokud tam nepoužíváš nějaké záludnosti a píšeš to přímočaře, tak to ani nemusíš moc komentovat, protože kód dokumentuje sám sebe – v těchto případech je lepší si přečíst pár řádků kódu a vědět s jistotou, co to dělá, než si přečíst pár řádků komentářů a doufat, že kód tomu odpovídá.

[Kit]

Podstatné je, že se v tom Makefile nachází hlavně ty vlastní parametry a že jsou přehledně koncentrovány do jednoho souboru. U větších projektů je možné totéž udělat v každém podadresáři a spouštět rekurzívně do hloubky.

V tom Makefile mám všechny potřebné utility, včetně spouštění testů, generování závislostí, deploymentu či mazání cache. Na tu obrazovku se to skutečně vejde.

Hodně utilit však spouštím i přes Git. Má to trochu jiné vlastnosti, například že se úlohy spouští v kořeni projektu. Jsou to hlavně skripty, které jsou univerzálně použitelné v každém projektu a mohou tedy být umístěny v ~/.gitconfig

Make může spouštět Git a Git může spouštět Make. Jen je dobré si z těchto dvou přístupů vybrat a nemíchat je.

Jedinou nevýhodou Make je závislost na platformě, což může u některých projektů představovat problém. V takovém případě dám Makefile do .git/info/exclude a neverzuji ho.

[Josef Kufner]

Gitlab CI je přesně ten nástroj, který chceš. Je to však jen jedna půlka řešení.

Ta druhá půlka je skript, který nakopíruje tvoje soubory tam, kam patří. Může to být klidně jen zaobalené volání rsync nebo něčeho takového. Přesná podoba tohoto skriptu záleží na prostředí i projektu.

Makefile je velice užitečný na organizaci takových skriptů. Typicky chceš příkazy na build, na migrace databáze, na spuštění testů, na vyčištění cache a na nasazení. Jako výchozí cíl doporučuju mít nápovědu. Makefile má výhodu v tom, že všechna ta volání různých nástrojů dostaneš na jedno místo a nemusíš hledat, co ten který projekt zrovna používá a jak se to spouští.

Makefile se naopak nehodí na spouštění parametrizovaných úloh. Na to je lepší mít nějaký jiný entrypoint, například bin/console postavené na Symfony Console.

Celé řešení deploye vypadá tak, že Gitlab CI spustí pipeline, tam se provedou testy, build a nakopíruje se výsledek na server, kde se pak ještě spustí migrace databáze a vyčištění různých cache. Když se to povede, v Gitlabu uvidíž zelenou fajfku, když ne, tak ti přijde mail a máš k dispozici log výstupu toho deploy skriptu.

[ET]

Super, diky.

Ja uz jim ve firme pred nejakou dobou rozjel on-premis gitlab (i s runnerem), ale prislo mi, ze CI je jen na "otestovani" pred deploymentem - co mi teda uteklo a je dulezite je PIPELINE.

Predstavuju si to dobre, ze mas nadefinovanou pipeline/sekvenci akci (podle potreby projektu) a v nich "tahas" za make(file)? :)

[ttt]

Na deploy používám většinou Capistrano / Ansitrano (https://github.com/ansistrano/deploy) volané z GitlabCI.

[Josef Kufner]

Víceméně se to tak dá říct. Občas se tam připlete nějaký rsync, scp, či curl, aby se výsledek dostal na správné místo a nebo se zavolal nějaký externí (web)hook.