Letezik-e ilyen fajlrendszer feature?

Leginkabb az RDBMS-ekbol megszokott tranzakcio kezeleshez tudnam hasonlitani a feature-t amit keresek, de kicsit komplexebb, megprobalom elmagyarazni.

Tegyuk fel hogy van egy API PHP-ban irva es 10-1000 request per sec eri a szervert.

A szerveren levo kodot mindig egy verziokezelovel modositjuk (peldankban az egyszeruseg kedveert legyen git).

valtozik egy uj verzio kitevesekor:

/model/semam.php

atnevezodik:

/controller/Pistike.php -> /controller/SzemelyPistike.php
/controller/Moricka.php -> /controller/SzemelyMoricka.php

/model/semam.php peldanyositja a Pistike.php -bol a Pistike class-t es a Moricka.php -bol a Moricka class-t, de a mostani frissitessel ezek atnevezodnek SzemelyMorcika es SzemelyPistike class-ra (az a modositasunk, hogy azt fogja hasznalni a semam.php)

Tegyuk fel, hogy a git mar modositotta a szerveren a /model/semam.php -t, de meg nem modositotta a controllereket, es ekkor hivodik meg egy request PHP-bol, ami hibara fog futni, mert SzemelyPistike class nem letezik (ez csak nehany millisecondig van, de megtortenhet).

Az altalam keresett feature:

-csak egy adott pidu process-nek (gites updater script es child-jai, de lehet egy bash peldany is a child-jaival) adja at, hogy az a process fajlrendszer szinten az uj fajlokat lassa, amig az dolgozik
-amig a git be nem fejezi a dolgat, minden mas process, azaz pl minden szerveren hivott script a projekt mappabol a regi fajlokat nyitja meg, nem a git altal modositott fajlokat, akkor sem, ha "az a fajl epp kesz van a modositassal"
-a git ha "elkeszult", akkor "commitoljuk" a fajlrendszer valtoztatasait. De a regi processzek meg befejezik a futast a regi mappan (leven lehet valamelyik mar par masodperce "gondolkodik" es ne fusson emiatt hibara.) A regi "verziojat" a mappanak/a fajloknak akkor torli a rendszer, ha mar egy process sem hasznalja a regi fajlrendszert.

Meg pl. composer-nel is tok hasznos lenne, hogy amig nem fut le a composer install, addig a regi package-eket hasznalod, de a composer mar tud dolgozni maganak az uj fajlrendszerrel, meg ami a composer install vege utan fut le, az is mar az uj libeket hivja. Akar kombinalni is lehetne, hogy egy tranzakciot elkezdunk, vegezzen a git, aztan vegezzen a composer, es utana commit (vagy akar rollback hiba eseten!), de amig ennek nincs vege, addig csak a git meg a composer lassa az uj fajlrendszert.

Valahol hallottam, hogy az NTFS-ben van "fajlrendszer szintu tranzakcio kezeles", de nem tudom hogy az mit takar, ennyire komplex feladatot meg tudna oldani? Talaltam rola dokumentaciot, de megijesztett a hossza.

Ha nem, mas fajlrendszer + oprendszer parossal megoldhato ez a feladatkor? Dolgozott mar ilyesmin valaha valaki? Google nem nagyon segitett

( mn3monic v | 2015. 04. 03., p – 20:06 )

yet another miert nem jo a php :)
bezzeg milyen jo lenne a parallel deploy :)

Csak peldanak hoztam a PHP-t, en is egyre surubben kerulom ahol lehet, csak azzal volt konnyu elmagyarazni.

Javas Parallel deployment pont ezt csinalja? Topik szempontjabol mindegy, mert igazabol fejlrendszer szinten kene nem csak webapp deploy-hoz, de ugyanakkor a Java-+tomcat+JSP irany egyre inkabb erdekel egy ideje.

Amugy ha csak PHP deploy a kerdes, szerintem lehet ugyeskedni symlinkekkel, de mint mondtam OS + fajlrendszer szinten erdekelne a dolog engem.

Java egy kicsit bonyolultabb. :) Biztos van, aki ezt nálam jobban tudja, de nagyjából a következő történik. Először becsomagolod a lefordított osztályaidat egyetlen war fileba (opcionálisan mehet bele a static content is). Amikor kideployolod, ez a war file betöltődik és a megfelelő módon felkonfigurálódik. Ezután az új kérések kiszolgálásához szükséges kód már ebből a war fileból kerül betöltésre. A még futó kérések a korábbi war fileból érkező osztályok által vannak kiszolgálva, a trükk pedig az, hogy nincs névütközés. Méghozzá azért nem, mert javaban futásidőben az osztályt a kanonikus neve és a classloadere együtt azonosítja, deploykor pedig egy új classloader tölti be a war tartalmát. Miután a régi kérések befejeződnek, a régi osztályokra már nincs szükség, a gc ki tudja takarítani a régi osztályokat a classloaderrel együtt.

( Elbandi v | 2015. 04. 03., p – 20:08 )

site-off feature: valahogy jelzed az php kod elejen hogy most epp ez az allapot van (pl lekarsz egy "down" fajl valahova), es ilyenkor az user csak egy "mingya jovunk" lapot kap. ha tobb webservered van valami load balancerrel, akkor azzal megakadalyozod hogy forgalom jonnon a szerverre.

kicsereled a kodot, majd visszalovod a site-ot.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ez nem opcio ha surun deployolsz es olyankor sokmindent elenorizned is kell, meg a composer install magatol is tul sokaig fut ehhez. De mint mondottam, engem ez a feature fajlrendszer + OS szinten erdekelne mas, sokkal bonyolultabb feladathoz, a PHP-s pelda csak szigoruan pelda ehhez.

Getting close

Erre mar meg tudnam irni, igaz nem fajlrendszer + OS, hanem shell szinten, es magamnak kene kitalalnom es megszerveznem, hogy hogy nezzen ki a ket mappa, amik kozul a nemvaltozot a publik ele linkelem. Bar meg tan ezt is lehetne automatizalni. Jo kiindulasi pont, koszi, shell peldany szerint tehat gyakorlatilag mar letezik ilyen megoldas.

P.s.: ja meg azt is tesztelnem kene hogy amit 5 perce inditottam az a regi mappaban dolgozik-e, amit kesobb az meg az ujban-e, es hogy hasznalja-e meg valami a regi mappat, es ha nem, akkor hogy tudom torolni / ekvivalensse tenni a kovetkezo "transaction start"-ig.

(nem olvastam végig, de) itt az a baj, hogy ő egy tranzakcionális fájlrendszert szeretne, de a rajta futó alkalmazás is a saját tranzakciójában kellene, hogy éljen, rá nem szabad kihatnia a többi futó tranzakciónak.
Az nem jó, ha atomi művelettel kirakod az új fájlokat, mert ha az atomi művelet előtt töltötted be a pistike.php-t, majd megtörténik a commit és a pistike.php eljut oda, hogy be akarja húzni mariska.php-t, de az már nincs ott, akkor FAIL.
--
zsebHUP-ot használok!

Hat szamomra ez nem valami meggyozo:

"
Idea:
Pack an entire transaction into a single system call. This may include updates to several files and directories.
Rollbacks are not existent: Starting and committing are the same thing.
Problem:
The patch introducing this ioctl was not accepted by the Btrfs developers and can therefore not be found in the Linux mainline kernel.
"

Write transactions: "Resources are blocked using named POSIX semaphores."

Read only transaction nalam meg fel se merulne, ahhoz hogy ez menjen, annak nem is kene kerdesnek lennie hogy mikor mit lockol es kinek mit mutat.

Ezenfelul:

"Process forks don’t work: State machine in libbtrfstrans would need to be duplicated."

"Forced serialization of write transactions leads to performance bottleneck."

( bra | 2015. 04. 03., p – 22:01 )

Szerintem ne keress túl bonyolult megoldásokat. :) 


$ ls -l
total 2
lrwxr-xr-x  1 bra  wheel  3 Apr  3 21:58 cur -> old
drwxr-xr-x  2 bra  wheel  2 Apr  3 21:58 new
drwxr-xr-x  2 bra  wheel  2 Apr  3 21:58 old
$ ln -s new tmp
$ mv -h tmp cur
$ ls -l
total 2
lrwxr-xr-x  1 bra  wheel  3 Apr  3 22:00 cur -> new
drwxr-xr-x  2 bra  wheel  2 Apr  3 21:58 new
drwxr-xr-x  2 bra  wheel  2 Apr  3 21:58 old

Na itt a pont: ez sajnos nem fajlrendszer szintu (process-ekhez kotve). Valojaban nem PHP scripthez kell, csak az volt a legegyszerubb pelda azok kozul, amik felmerultek, de amig csak PHP kodokrol van szo, addig valoban szepen "meg lehet kerulni" a feladatot.

Szerintem valamelyik nap osszeszedem magam es megprobalom erthetoen leirni az egyik jobb es kevesbe primitiv peldat, es felvazolni, miert erne ennyit, hogy ez fajlrendszer szinten legyen megoldva.

Szerintem bra pont erre gondolt. Ha a git update előtt belépsz a cur (vagyis old) könyvtárba, akkor a már futó processz ottmarad, és relatív hivatkozásai továbbra is az old könyvtár alatti fájlokhoz nyúlnak hozzá, míg az új processzek már a new könyvtárat használják.

De lehet akár egy komplett futtató környezetet felhúzni, és chroot-olni is.

Ha a fájlokat (old és new könyvtárat) nem sima könyvtárként, hanem (loop-)mountolt fájlrendszerként hozod létre, akkor utána megpróbálhatod másodpercenként umountolni, a kernel figyel arra hogy ez akkor fog sikerülni ha már nincs processz ami használja, ezáltal ezt megoldja helyetted.

( BaT | 2015. 04. 03., p – 22:17 )

Amit én csinálnék (annyira nem ismerem a php lelkivilágát (szerencsére), a tévedés jogát fenntartom), hogy eleve olyan architektúrát alakítanék ki, hogy a programom egy konfigurálható path-ról töltse be a további php fileokat (mintha lenne is ilyen feature php-ban alapból). Nyilván ekkor a régi és az új verziónak két könyvtárban kell laknia, a confignak pedig közösnek kell lennie. Amikor bejön a kérés és elindul a php script, betölti a configot, és végig a betöltött értékkel (path-tal) dolgozik. Ha befejezted az új verzió előkészítését, egyszerűen módosítod a configot hogy mostantól az új requestek az új könyvtárat használják. Ez akár egy symlink is lehet, de akkor a symlink által mutatott könyvtárat kell megőrizned a memóriában.

( Protezis | 2015. 04. 04., szo – 00:32 )

Ne használj erre szerveren se gitet, se más verziókövető rendszert, se composert, mavent, akármit! Legyen meg a teljes deployolandó cucc egyben, függőségekkel, mindennel. Csinálj egy symlinket, arra lődd be a webszervert, a deployolt cuccot meg mondjuk dátumot/miegymást tartalmazó könyvtárba rakd, a symlink pedig mutasson erre.
Előnyők:
- ha kirakod az új verziót (tartson az akármeddig), csak a symlinket kell átállítani
- ha valamiért mégis rossz az új verzió, visszaállítod a symylinket és ráérsz agyalni, mi is a gond

Amit mostanaban en csinalok, az egy-egy git commitbol tudok egy paranccsal docker containert forditani.
Azt feltoltom szerverre, kitomoritem es elinditom.
Kiprobalom, hogy minden jo-e, majd lelovom a regi containert es ujrainditom az ujat a regi nevevel.

Mivel minden kulon containerben lakozik (adatbaziskezelo is), igy baromi jo inkrementalis update-eket lehet csinalni. Magyaran, amikor a site-ot frissitem, akkor az adatbaziskezelo vegig futvamarad.

Nagyon egyszeru visszavaltani is, mert leallitom a mostanit, es elinditom a regit ujbol (addig nem torlom).

A meretet is baromi egyszeru nyomonkovetni, nincs az, hogy "beszemetelodik" a rendszer idovel.

Most nalam ez az irany, hogy mindent bedobozoljak. A legujabb (jovoheti) hobbiprojekt (ami igazabol nem hobbi), hogy az imagemagick-et tegyem be egy containerbe. Meg azt nem dontottem el, hogy hogyan adok-veszek feladatot-eredmenyt neki-tole.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

jah, ez a dockeres cuccon en is agyaltam mar: dockerben van az egesz php kornyezet, startkor elindul a php-fpm, csak azt nem tudom hogy a sockerjet hogy vezessem ki :/
a sima portbind nemjo, mert ket container egyszerre is futhat (regi meg fut, az uj meg epp indul), ketten meg ugye nemtudnak egy porton figyelni.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

minden docker kontener kulon ip cimen erheto el, igy figyelhet ugyanazon a porton.

Amit en csinalok, az az, hogy van egy reverse proxy egy kulon kontenerben,
ami domain nev alapjan koti ossze a kontenereket.

Amit te csinalhatsu az az, hogy fixen kikotod ugyanarra a gazda gep portjara a kontener portjat.
Ugy nem is fog menni. De mivel ugyse a 80as portra teszed a kontenereket, igy
Kikotheted oket a 8080,8081,8082...8098-ra es akkor marcsak egy reverse proxy kell ele...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( carlcolt | 2015. 04. 04., szo – 11:31 )

A valaszokat osszegezve:

Ha jol ertem akkor ezt a feladatot mindenki userspace-en / shell szinten oldja meg, es az az altalanos nezet, hogy ez nem OS + fajlrendszer feladata. Valoban plusz egy hibalehetoseg lenne, ha mar picit is rosszul van megirva, akkor mindenkepp. (Fajlrendszernel raadasul gondolni kell ilyenekre is, mint pl. aramszunet, kiveve ha opcio nalad az, hogy a felesegedet lovod le egy process helyett). Ebbol arra assume-olok, hogy falrendszer szinten _nincs_ ilyesmi megoldva sehol.

Meg felmerult meg bennem a fentebbi btrfs doksit olvasgatva, hogy meg lehetene-e ezt ugy oldani egyaltalan, hogy nem lenne komoly performacne vonzata pusztan annak, hogy ez a feature letezik es barmikortol hasznalhato. Raadasul a mar korabban emlitett aramszunet miatt mindenrol kell, hogy legyen egy tokeletes "state-detektalas" (== hol is maradt felbe ez az egesz "ketmappazas"?). Elgondolkodtato.