Re: [rlug] composer, php si peluza
2015-08-25 15:44 GMT+03:00 Catalin Muresan : > 2015-08-25 13:03 GMT+01:00 Petru Rațiu : > > > N-am nici o problema cu enshpe versiuni diferite in pipeline-ul de > > development, dar pe live eu prezint _un_ serviciu, da. Ma intereseaza sa > > fie consistent (pe oricate servere sau datacentere ar fi in spate) si sa > > treaca printr-un proces riguros de change management. Dar poate lucram in > > medii diferite... > > > > Normal ca oricine vrea asta, cmon. Doar ca realistic pe live or sa fie mai > multe versiuni al aceluias serviciu. > Dar dupa ce au deployment rapid si consistent vor si rollback instant, ca > deh au facut buba mare si trebuie rezolvat - 2 versiuni , una live > Dupa ce ai deploy/rollback rapid, consistent si alea alea vor deploy > partial, adica 5% din trafic sa treaca prin versiunea noua de aplicatie ca > deh daca e buba mare sa fie doar la 5%. Dupa aia 15%,30%. etc. - 2 > versiuni, ambele live. > Dupa aia or sa vrea API versioning unde ai defapt o versiune mai noua si > una mai veche care merg simultan (si care or sa evolueze paralel). - 4 > versiuni, 2 live. > Si ai doua optiuni, ori le tai macaroana din start ori iti faci un sistem > care sa suporte asa ceva. > > Pai cam asta incerc sa fac, sa masor cam cat e macaroana si unde o taiem, dinainte sa vina idei. IMHO situatia e asa: daca userului i se prezinta produsul ca "intri la http://blabla.net/foo si ai acolo aplicatia cutarescu", apai aplicatia aia trebuie sa i se prezinte sub o singura forma gogului cu pricina, indiferent de ce loz castigator sau necastigator a tras din balancer sau anycast sau pana mea. Daca faci A/B test, o faci cu feature flags intr-o unica aplicatie (rezerv scenariul cu red/green environments pt. migrari mult mai mari, nu pt. common releases). Daca o sa-mi vina userul ca "ieri la ora X, am incercat Y si mi-a iesit Z", prefer sa stiu care era versiunea W care era in productie, ce a schimbat, cine a pus-o live, cine i-a facut review si cine repara, nu sa fie un quest in sine "oare ce-o fi nimerit". Treaba cu serializarea release-urilor se face de catre cine e designat ca release manager (un om, un script, un proces, not my problem) undeva in pipeline. Chestiile paralelizabile se intampla mai aproape de devi, care pot trai daca vor in universul lor paralel in care doar feature-ul la care lucreaza acum exista. Acolo e bine mersi loc de composer si curl|sh si alte gheisme(tm) de genul asta, pe live vreau releasuri reproductibile si consistente (in functie de environment, nevoia asta de consistenta se poate certa mai mult sau mai putin cu legile termodinamicii si relativitatii, dar personal prefer sa imping produsul si procesul departe de directiile unde asta conteaza). > Oricum asta e alta discuitie, vreau doar sa atrag atentia sau sa trezesc > curiozitatea celor care nu sunt in discutie, domeniul e foarte interesant > si vorba aia "de viitor" :). > Eu am un background mai de inginer constructor, mie mi s-a bagat in cap ca infrastructurile reliable au principii simple si clare in spate si enshpe factori de siguranta suplimentari. Complexitatea e un bug in sine. Ca atare nu cred ca facem vreun bine industriei daca permitem chestii de-astea ozenistice doar pentru ca cineva le cere, fara sa aiba si argumente. "Mi-e mai simplu la development" nu e un argument pt. probleme de productie. Nu e nici contra, dar e irelevant. -- Petre, oldschool. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-25 13:03 GMT+01:00 Petru Rațiu : > N-am nici o problema cu enshpe versiuni diferite in pipeline-ul de > development, dar pe live eu prezint _un_ serviciu, da. Ma intereseaza sa > fie consistent (pe oricate servere sau datacentere ar fi in spate) si sa > treaca printr-un proces riguros de change management. Dar poate lucram in > medii diferite... > Normal ca oricine vrea asta, cmon. Doar ca realistic pe live or sa fie mai multe versiuni al aceluias serviciu. Dar dupa ce au deployment rapid si consistent vor si rollback instant, ca deh au facut buba mare si trebuie rezolvat - 2 versiuni , una live Dupa ce ai deploy/rollback rapid, consistent si alea alea vor deploy partial, adica 5% din trafic sa treaca prin versiunea noua de aplicatie ca deh daca e buba mare sa fie doar la 5%. Dupa aia 15%,30%. etc. - 2 versiuni, ambele live. Dupa aia or sa vrea API versioning unde ai defapt o versiune mai noua si una mai veche care merg simultan (si care or sa evolueze paralel). - 4 versiuni, 2 live. Si ai doua optiuni, ori le tai macaroana din start ori iti faci un sistem care sa suporte asa ceva. Oricum asta e alta discuitie, vreau doar sa atrag atentia sau sa trezesc curiozitatea celor care nu sunt in discutie, domeniul e foarte interesant si vorba aia "de viitor" :). ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
> > >> > M-am distrat foarte tare incercand sa buildez composer din surse (cand >> > mi-ai dat link la releases credeam ca nu vazusem eu release-uri binare >> pe >> > github, dar e doar tree-ul cu sursa): >> > >> > root@vagran:~/composer# ./bin/compile >> > You must set up the project dependencies, run the following commands: >> > curl -sS https://getcomposer.org/installer | php >> > php composer.phar install >> > >> >> installer-ul doar face download la composer.phar ( >> https://getcomposer.org/composer.phar) si il face executabil (si mai >> verifica una alta). >> >> > Gluma era ca eu tocmai composer.phar ala incercam sa-l buildez :) > > BTW, tocmai am avut o discutie pe IRC cu unul din developeri, a zis ca o sa ia in considerare sa publice undeva (preferabil gpg-signed) versiunile tagged. -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-25 14:13 GMT+03:00 Catalin Muresan : > 2015-08-25 0:48 GMT+01:00 Petru Rațiu : > > > Ok, m-am mai lamurit dupa ce am discutat azi cu cativa developeri de prin > > firma, o sa incercam sa metinem un tree cu toate dependintele > out-of-distro > > > > meh. uita-te in .gitignore din laravel sa vezi ca vendor/ e acolo. Doar > daca tii neaparat sa vezi ce s-a schimbat in vendor(dependinte). > > > > in el (i.e. partea cu composer se ruleaza pe masina celui care comite in > > repo, se hotaraste el ce versiuni si cand comite), testarea si > deploymentul > > dupa aia le vom face static la fel ca la proiectele traditionale. > > > > Dependintele out-of-distro sunt in directorul vendor/ (in laravel de ex.) > Mai elegant e sa ai un hook pe commit in git repo care sa faca build la > versiunea respectiva. > Developerul sa aiba local un VM in care sa scrie cod si de unde sa faca > push / pull request. Ca sa automatizezi asta poti folosi vagrant. Ce _nu_ > vrei e ca fiecare sa instaleze ce versiune vrea el si la final sa nu mearga > pentru ca e ceva versiune diferita. > Si mai elegant e sa ai CI tool (hudson/jenkins, bamboo, etc) care sa faca > asta dupa care sa ruleze testele automate. > Daca trece de testing CI ruleaza script-ul de packing care impacheteaza > aplicatia cu toate dependintele si o pune pe server (sau daca vrei docker > image si push in docker-registry). > Dupa asta deployment e simplu, symlinks. > > Sunt zeci de optiuni, toate au evoluat nu ca sa fie lucrurile mult mai > complicate ci ca sa poata oferi developerilor o interfata simpla prin care > sa-si poata testa o aplicatie intr-un mediu cit mai mult similar cu > productia. > Sunt aplicatii care merg pe 10-20 servere si au 10-20 servicii unde trebuie > sa automatizezi si lansarea de instante, configurarea, deployment si la > final stergerea instantelor. > Tu esti fericit cu un server si un serviciu :). > > N-am nici o problema cu enshpe versiuni diferite in pipeline-ul de development, dar pe live eu prezint _un_ serviciu, da. Ma intereseaza sa fie consistent (pe oricate servere sau datacentere ar fi in spate) si sa treaca printr-un proces riguros de change management. Dar poate lucram in medii diferite... > > > > > M-am distrat foarte tare incercand sa buildez composer din surse (cand > > mi-ai dat link la releases credeam ca nu vazusem eu release-uri binare pe > > github, dar e doar tree-ul cu sursa): > > > > root@vagran:~/composer# ./bin/compile > > You must set up the project dependencies, run the following commands: > > curl -sS https://getcomposer.org/installer | php > > php composer.phar install > > > > installer-ul doar face download la composer.phar ( > https://getcomposer.org/composer.phar) si il face executabil (si mai > verifica una alta). > > Gluma era ca eu tocmai composer.phar ala incercam sa-l buildez :) -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-25 0:48 GMT+01:00 Petru Rațiu : > > Din ce in ce mai des imi aduc aminte de bancul cu mosul ala care voia sa > emigreze... > O sa te oblige :) Merita citit link-ul de mai jos, singura diferenta e ca acum vine clientul la tine cu toate ideile si le vrea implementate _asa_. http://blog.circleci.com/its-the-future/ > > -- > P. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-25 0:48 GMT+01:00 Petru Rațiu : > Ok, m-am mai lamurit dupa ce am discutat azi cu cativa developeri de prin > firma, o sa incercam sa metinem un tree cu toate dependintele out-of-distro > meh. uita-te in .gitignore din laravel sa vezi ca vendor/ e acolo. Doar daca tii neaparat sa vezi ce s-a schimbat in vendor(dependinte). > in el (i.e. partea cu composer se ruleaza pe masina celui care comite in > repo, se hotaraste el ce versiuni si cand comite), testarea si deploymentul > dupa aia le vom face static la fel ca la proiectele traditionale. > Dependintele out-of-distro sunt in directorul vendor/ (in laravel de ex.) Mai elegant e sa ai un hook pe commit in git repo care sa faca build la versiunea respectiva. Developerul sa aiba local un VM in care sa scrie cod si de unde sa faca push / pull request. Ca sa automatizezi asta poti folosi vagrant. Ce _nu_ vrei e ca fiecare sa instaleze ce versiune vrea el si la final sa nu mearga pentru ca e ceva versiune diferita. Si mai elegant e sa ai CI tool (hudson/jenkins, bamboo, etc) care sa faca asta dupa care sa ruleze testele automate. Daca trece de testing CI ruleaza script-ul de packing care impacheteaza aplicatia cu toate dependintele si o pune pe server (sau daca vrei docker image si push in docker-registry). Dupa asta deployment e simplu, symlinks. Sunt zeci de optiuni, toate au evoluat nu ca sa fie lucrurile mult mai complicate ci ca sa poata oferi developerilor o interfata simpla prin care sa-si poata testa o aplicatie intr-un mediu cit mai mult similar cu productia. Sunt aplicatii care merg pe 10-20 servere si au 10-20 servicii unde trebuie sa automatizezi si lansarea de instante, configurarea, deployment si la final stergerea instantelor. Tu esti fericit cu un server si un serviciu :). > > M-am distrat foarte tare incercand sa buildez composer din surse (cand > mi-ai dat link la releases credeam ca nu vazusem eu release-uri binare pe > github, dar e doar tree-ul cu sursa): > > root@vagran:~/composer# ./bin/compile > You must set up the project dependencies, run the following commands: > curl -sS https://getcomposer.org/installer | php > php composer.phar install > installer-ul doar face download la composer.phar ( https://getcomposer.org/composer.phar) si il face executabil (si mai verifica una alta). > > > Funny, nu? :) Din fericire se pare ca un suflet milostiv a facut pachet de > debian de composer (dar e doar in testing, asa ca o sa fac un mediu de sid, > in care buildez un composer.phar pe care sa-l dau mai departe la cel de > stable, etc, etc). > > Din ce in ce mai des imi aduc aminte de bancul cu mosul ala care voia sa > emigreze... > > -- > P. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
On 08/25/2015 02:48 AM, Petru Rațiu wrote: > [...] > Din ce in ce mai des imi aduc aminte de bancul cu mosul ala care voia sa > emigreze... acum, cind mai sint doar 6 luni ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
Ok, m-am mai lamurit dupa ce am discutat azi cu cativa developeri de prin firma, o sa incercam sa metinem un tree cu toate dependintele out-of-distro in el (i.e. partea cu composer se ruleaza pe masina celui care comite in repo, se hotaraste el ce versiuni si cand comite), testarea si deploymentul dupa aia le vom face static la fel ca la proiectele traditionale. M-am distrat foarte tare incercand sa buildez composer din surse (cand mi-ai dat link la releases credeam ca nu vazusem eu release-uri binare pe github, dar e doar tree-ul cu sursa): root@vagran:~/composer# ./bin/compile You must set up the project dependencies, run the following commands: curl -sS https://getcomposer.org/installer | php php composer.phar install Funny, nu? :) Din fericire se pare ca un suflet milostiv a facut pachet de debian de composer (dar e doar in testing, asa ca o sa fac un mediu de sid, in care buildez un composer.phar pe care sa-l dau mai departe la cel de stable, etc, etc). Din ce in ce mai des imi aduc aminte de bancul cu mosul ala care voia sa emigreze... -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-22 12:00 GMT+01:00 Petru Rațiu : > Bun, m-am lamurit ca nu ne trollam, doar vorbim unul pe langa altul. > Resetez si mai incerc o data. > > 1. Cu restul de ecosisteme am un trust ceva mai bun (nu absolut), pentru ca > sunt mai multi pasi in toolchain unde pot fi verificate chestii si ai un > control mai bun asupra cand se fac schimbarile. Povestea de care vorbesti > cu ssl-ul din debian e un exemplu bun de ce e nevoie sa faileze: cineva a > introdus bugul din greseala si acelasi pachet l-a avut toata lumea. Cand > s-a observat bugul, toti au putut sa isi dea seama daca si cand au instalat > pachetul cu pricina si ce e de facut in case shit. > > 2. La composer prima chestie care ma deranjeaza e ca nu am nici o legatura > intre ce zice la https://getcomposer.org/download/ si ce zice la > https://github.com/composer/composer . Nu mi-a sarit in ochi vreun script > de build, nu exista pachete in Debian, nici macar amaratul ala de .phar pe > care-l downloadez nu are vreun md5 sau ceva publicat, sa stiu si eu ca am > downloadat ce trebuie inainte sa-l rulez. > Atunci nu folosi deloc getcomposer.org si foloseste numai versiunea din guithub, si nu orice e acolo ci de aici https://github.com/composer/composer/releases https://github.com/composer/composer/archive/1.0.0-alpha10.tar.gz si gata. Asupra zip/tar.gz nu este nici un control din partea celui care a publicat repository-ul din punctul lui de vedere e doar un anumit commit in git repo, adica nu se poate "trisa" si zip-ul sa fie defapt altundeva. Faci audit la 1.0.0-alpha10 si daca iese tot OK zici "asta e bun, avem incredere in el, asta il folosim". Dupa asta faci audit la toate modulele folosite, asta e, daca vrei siguranta. > 3. Vad ca ai oaresce experienta cu chestia asta, chiar daca ai decis ca mai > intai razi de mine. Cum zici ca faci update la aplicatia live? Niciodata, > doar pui containere noi si pointezi traficul la ele? Desteptii astia ai mei > Da. Cu mentiunea ca "pointezi traficul la ele" o faci si asta automat cu un service discovey tool. > mi-au zis sa rulez composer direct pe mediul de productie si sa mut un > symlink dupa, ca sa-si pastreze diverse cache-uri si alte traznai. Pot rula > treaba aia in alta parte si doar sa le copiez fisierele? Ce-mi scapa? > Asta recomand, faci un build script pentru aplicatie, care ruleaza composer, si rezultatul e un director undeva. Ala il pui intr-un tar.gz, zip, git repo, orice, si deployment propriuzis e defapt unpack la arhiva aia, fara composer. Specific pentru laravel inainte de a rula composer nu o sa ai directorul vendor. Dupa ce rulezi o sa ai vendor in care sunt toate dependintele : https://github.com/laravel/laravel/blob/master/composer.json - (require si require-dev) Implicit composer ruleaza cu --with-dev ( https://getcomposer.org/doc/03-cli.md#install) asa ca pentru prod poate vrei sa faci "curat" ca sa nu instaleze dependintele pentru dev. Dupa care iei exact ce-ti trebuie (cam tot fara composer.phar) si pui intr-un tar.gz si acolo e aplicatia. git clone cd php composer.phar install --witout-dev cd .. tar cvzf aplicatie-v.tar.gz --exclude=composer.* rm -rf Ia-o ca pseudocod ;). Poti sa faci asta cu un commit-hook in git si cind faci deployment in test/staging/production o faci doar specificind commit-ul. Rollback ? depinde de mediu (cu containere/haproxy sau symlinks sau altele). Hell poti sa le instalezi pe toate in /var/www/aplicatie-v si doar sa muti symlinks si atunci deployment/rollback e instant pentru ca toate versiunile de aplicatie sunt preinstalate ;). HTH. > -- > P. "pe bune, containerele n-au nici o legatura cu povestea asta" > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
Bun, m-am lamurit ca nu ne trollam, doar vorbim unul pe langa altul. Resetez si mai incerc o data. 1. Cu restul de ecosisteme am un trust ceva mai bun (nu absolut), pentru ca sunt mai multi pasi in toolchain unde pot fi verificate chestii si ai un control mai bun asupra cand se fac schimbarile. Povestea de care vorbesti cu ssl-ul din debian e un exemplu bun de ce e nevoie sa faileze: cineva a introdus bugul din greseala si acelasi pachet l-a avut toata lumea. Cand s-a observat bugul, toti au putut sa isi dea seama daca si cand au instalat pachetul cu pricina si ce e de facut in case shit. 2. La composer prima chestie care ma deranjeaza e ca nu am nici o legatura intre ce zice la https://getcomposer.org/download/ si ce zice la https://github.com/composer/composer . Nu mi-a sarit in ochi vreun script de build, nu exista pachete in Debian, nici macar amaratul ala de .phar pe care-l downloadez nu are vreun md5 sau ceva publicat, sa stiu si eu ca am downloadat ce trebuie inainte sa-l rulez. 3. Vad ca ai oaresce experienta cu chestia asta, chiar daca ai decis ca mai intai razi de mine. Cum zici ca faci update la aplicatia live? Niciodata, doar pui containere noi si pointezi traficul la ele? Desteptii astia ai mei mi-au zis sa rulez composer direct pe mediul de productie si sa mut un symlink dupa, ca sa-si pastreze diverse cache-uri si alte traznai. Pot rula treaba aia in alta parte si doar sa le copiez fisierele? Ce-mi scapa? -- P. "pe bune, containerele n-au nici o legatura cu povestea asta" ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-21 22:48 GMT+01:00 Petru Rațiu : > Multa lume alege 1 pentru ca e codul disponibil pentru toata lumea. Ma mir > > ca ai ajuns la problema asta filozofica si folosesti deja Linux, MySQL, > si > > multe multe altele la care sigur nu te-ai agitat asa de mult si nu ti-ai > > pus atitea probleme in a le folosi. > > > > > Aici nu inetelg ce vrei sa spui (sau mai degraba nu vreau sa cred ca > argumentul pe care vrei sa-l faci e atat de retard ca cel pe care il > inteleg eu, asa ca prefer sa cred ca nu am inteles). > Ai inteles argumentul retard. Dece ai incredere in tot restul ecosistemului ? L-ai auditat la un moment dat si ai ? sau orbeste ? > Dar o intrebare, cum folosesti tu composer in productie? il folosesti > > pentru dependency management si cind faci deploy in productie codul > > respectiv nu instaleaza composer pe serverul de productie, right right ? > > > > > Nu folosesc (inca). E vorba de un proiect care a fost dezvoltat de niste > developeri fara sa-mi ceara parerea pana nu s-a ajuns la pusul in > productie. Acu incerc sa ma pun la curent cu cum se folosesc chestiile > astea intr-o forma de bun simt. Faptul ca pun intrebari inseamna ca inca > sper ca exista o solutie si ca inca nu am dat mailul cu "mizeria asta n-o > sa ajunga vreodata pe vreun mediu de productie pe care sunt eu admin". Tot > faptul ca pun intrebari inseamna ca de la cei care au decis sa foloseasca > frameworkuri de-astea moderne nu am ce insighturi operationale sa aflu, ca > inca sunt incantati de ce usor se scrie codul si uite ce simplu se pune > live. > composer nu se foloseste in productie, il folosesti doar la faza de build. Sa zicem ca ai o aplicatie care foloseste 20 module php si inca 5 scrise de compania ta si peste asta e aplicatia. Cu composer poti in loc sa tot copiezi de fiecare data de pe net cele 20 module, sa le faci doar referinta ceva de genul "ia de pe github versionea 1.2.3". Multe pachete au la rindul lor composer.json in care sunt mentionate toate dependintele (daca au) si or sa fie downloadate toate. Rezultatul e un director unde ai aplicatia si toate dependintele. De aici incolo nu ai nevoie de composer, iei directorul si il pui unde vrei tu. > > > Ca sa fac o analogie, e ca si cum as avea dubii privind identitatea si > > > competenta dentistului care imi umbla prin masele (ca vine cu masca > pusa > > si > > > nu-i vad decat ochii) si tu zici ca e ok ca masca aia e sterila. Faptul > > ca > > > poarta masca sterila si manusi nu inseamna ca stie ce face cand imi > baga > > > chestii prin dinti. > Diferenta e ca tu ai control total la ce dinti, ce dentist, ce scule foloseste, tot tot. > > cum ziceam mai sus. In Linux ai incredere, in CentOS ai. Daca nu ai, fai > > audit si daca tot e ok, il folosesti. Daca nu, nu. > > > > > Da, in Linux si Centos si Debian am incredere pentru ca stiu ca au un > mecanism de qa si ca artefactele lor de build imi vin semnate gpg, nu > trebuie sa verific de fiecare data ce e in ele. La mecanismul asta am niste > dubii: > Debian e hilar, adu-ti aminte de bug-ul de generat ssh keys care l-a introdus super Debian-ul ca au vrut ei sa repare un warning, si, ca bonus, nu l-au trimis si la upstream, l-au tinut doar pentru ei ca deh. QA. Semnatura gpg nu are valoare pentru ca nu-ti garanteaza ca odata ce se face un update nu se introduce si un backdoor. > 1. trebuie sa obtin un phar care nu stiu cine e ma-sa si ta-su, doar ca > l-am luat de pe un site si parea sa mearga si aia zic ca e legat de > versiunea cutarescu din git la care pot sa ma uit daca vreau (cum ar fi > uite o sursa si un link de unde iei rpm-ul care ar trebui sa fie produs din > sursa aia, fara sa-ti garantez in vreun fel ca uite asa l-am produs si iti > semnez eu gpg ca eu l-am produs). > https://github.com/composer/composer hai ca nu e facut de un chinez pe genunchi, sunt gramada de contributii, gramada de commits, lumea lucreaza la el, "lots of eyeballs". > 2. mecanismul de build trage chestii de pe internet din niste branchuri pe > care le mentin diversi, pe care nu pot sa-i urmaresc cand si de ce au facut > schimbari (asta cred ca e doable daca imi trag local repo-urile cu pricina > si-l invat pe composer sa traga doar de acolo stuff, si cineva de la mine > din organizatie le schimba pe-alea doar cand stie f. bine de ce) > asta e greseala numarul unu, nu trage din branch, ia dintr-un commit/tag/release etc. Ceva ce e stabil si nu se poate modifica. Cind ai release nou atunci schimbi versiunea/tag/branch/whatever si bineinteles testezi inainte. Totul e transparent (version control) asa ca trebuie doar sa te uiti. > 3. oarecum legat de 2, faptul ca versiunile de soft depind de ce anume se > nimerea sa fie pe repo-uri la momentul cand am dat build sau update sau > spanac, face sa nu pot garanta ca pot reproduce in alta parte un anumit > comportament, pentru ca nu pot fi sigur ca pot controla toate schimbarile. > Sa zicem ca am un mediu de sandbox pe care testez nushce nou si maret > feature, cum
Re: [rlug] composer, php si peluza
2015-08-21 18:29 GMT+03:00 Catalin Muresan : > 2015-08-21 8:27 GMT+01:00 Petru Rațiu : > > > 2015-08-21 0:48 GMT+03:00 Catalin Muresan : > > > > > Deaia a s-au inventat VM-urile. Ca sa vezi ce face codul altora. > > > > > > [...] > > > > > deaia are PHP safe_mode, disable_functions si alte chestii frumoase. > Iei > > si > > > pui tot frumos intr-un container (in care ai doar apache+php, nu si > curl > > si > > > wget si alte prostii) si gata. > > > > > > [...] > > > > > Gindeste-te si la containere, nu-ti trebuie RPM si package manager in > > > container e prea "gras". Lumea vrea containere mici, 60-80MB/serviciu. > > > > > > [...] > > > > > preferat din php direct + container, cum ziceam mai sus, limiteaza mult > > de > > > tot environment-ul. > > > > > > > Ok, esti fan containere, am inteles. Nu are legatura cu ce problema am > eu. > > > > Nu prea sunt. Multa lume le foloseste fara sa le inteleaga si isi prind > urechile ca nu pot face debugging corect. > > > > E vorba de mediul de productie al codului ala. Da, este deja intr-un > > "container" (server separat, dedicat pt. chestia asta, samd). Problema e > ca > > ala interactioneaza prin natura lui cu useri si date si backenduri reale, > > unde are acces la chestii la care trebuie sa aiba acces pentru ca asta e > in > > specificatiile proiectului. Problema mea e mainly de change management si > > cum fac sa stiu care-s toate schimbarile pe care le introduce un release > > nou, ca sa pot face dupa aia troubleshooting, sa pot reproduce > > comportamentul in alte parti, sa dau rollback, samd. > > > > Ai trei optiuni: > - il folosesti dar ca intr-un sandbox si faci logging la tot ce face > - nu-l folosesti si te duci cu 10 ani in urma > - il scrii tu. > > Aici e cam falsa dihotomie. "e de cacat, da' asa e modern". Nu sunt de acord ca e atat de clear-cut problema, tot asa cum nu vreau sa cred ca toti aia care folosesc tooluri de genul asta au trebuit sa renunte la common sense. Multa lume alege 1 pentru ca e codul disponibil pentru toata lumea. Ma mir > ca ai ajuns la problema asta filozofica si folosesti deja Linux, MySQL, si > multe multe altele la care sigur nu te-ai agitat asa de mult si nu ti-ai > pus atitea probleme in a le folosi. > > Aici nu inetelg ce vrei sa spui (sau mai degraba nu vreau sa cred ca argumentul pe care vrei sa-l faci e atat de retard ca cel pe care il inteleg eu, asa ca prefer sa cred ca nu am inteles). > Dar o intrebare, cum folosesti tu composer in productie? il folosesti > pentru dependency management si cind faci deploy in productie codul > respectiv nu instaleaza composer pe serverul de productie, right right ? > > Nu folosesc (inca). E vorba de un proiect care a fost dezvoltat de niste developeri fara sa-mi ceara parerea pana nu s-a ajuns la pusul in productie. Acu incerc sa ma pun la curent cu cum se folosesc chestiile astea intr-o forma de bun simt. Faptul ca pun intrebari inseamna ca inca sper ca exista o solutie si ca inca nu am dat mailul cu "mizeria asta n-o sa ajunga vreodata pe vreun mediu de productie pe care sunt eu admin". Tot faptul ca pun intrebari inseamna ca de la cei care au decis sa foloseasca frameworkuri de-astea moderne nu am ce insighturi operationale sa aflu, ca inca sunt incantati de ce usor se scrie codul si uite ce simplu se pune live. > > > > > Ca sa fac o analogie, e ca si cum as avea dubii privind identitatea si > > competenta dentistului care imi umbla prin masele (ca vine cu masca pusa > si > > nu-i vad decat ochii) si tu zici ca e ok ca masca aia e sterila. Faptul > ca > > poarta masca sterila si manusi nu inseamna ca stie ce face cand imi baga > > chestii prin dinti. > > > > cum ziceam mai sus. In Linux ai incredere, in CentOS ai. Daca nu ai, fai > audit si daca tot e ok, il folosesti. Daca nu, nu. > > Da, in Linux si Centos si Debian am incredere pentru ca stiu ca au un mecanism de qa si ca artefactele lor de build imi vin semnate gpg, nu trebuie sa verific de fiecare data ce e in ele. La mecanismul asta am niste dubii: 1. trebuie sa obtin un phar care nu stiu cine e ma-sa si ta-su, doar ca l-am luat de pe un site si parea sa mearga si aia zic ca e legat de versiunea cutarescu din git la care pot sa ma uit daca vreau (cum ar fi uite o sursa si un link de unde iei rpm-ul care ar trebui sa fie produs din sursa aia, fara sa-ti garantez in vreun fel ca uite asa l-am produs si iti semnez eu gpg ca eu l-am produs). 2. mecanismul de build trage chestii de pe internet din niste branchuri pe care le mentin diversi, pe care nu pot sa-i urmaresc cand si de ce au facut schimbari (asta cred ca e doable daca imi trag local repo-urile cu pricina si-l invat pe composer sa traga doar de acolo stuff, si cineva de la mine din organizatie le schimba pe-alea doar cand stie f. bine de ce) 3. oarecum legat de 2, faptul ca versiunile de soft depind de ce anume se nimerea sa fie pe repo-uri la momentul cand am dat build sau update sau spanac, face sa nu pot garanta ca pot reproduce in alta parte un anumit comp
Re: [rlug] composer, php si peluza
2015-08-21 8:27 GMT+01:00 Petru Rațiu : > 2015-08-21 0:48 GMT+03:00 Catalin Muresan : > > > Deaia a s-au inventat VM-urile. Ca sa vezi ce face codul altora. > > > > [...] > > > deaia are PHP safe_mode, disable_functions si alte chestii frumoase. Iei > si > > pui tot frumos intr-un container (in care ai doar apache+php, nu si curl > si > > wget si alte prostii) si gata. > > > > [...] > > > Gindeste-te si la containere, nu-ti trebuie RPM si package manager in > > container e prea "gras". Lumea vrea containere mici, 60-80MB/serviciu. > > > > [...] > > > preferat din php direct + container, cum ziceam mai sus, limiteaza mult > de > > tot environment-ul. > > > > Ok, esti fan containere, am inteles. Nu are legatura cu ce problema am eu. > Nu prea sunt. Multa lume le foloseste fara sa le inteleaga si isi prind urechile ca nu pot face debugging corect. > E vorba de mediul de productie al codului ala. Da, este deja intr-un > "container" (server separat, dedicat pt. chestia asta, samd). Problema e ca > ala interactioneaza prin natura lui cu useri si date si backenduri reale, > unde are acces la chestii la care trebuie sa aiba acces pentru ca asta e in > specificatiile proiectului. Problema mea e mainly de change management si > cum fac sa stiu care-s toate schimbarile pe care le introduce un release > nou, ca sa pot face dupa aia troubleshooting, sa pot reproduce > comportamentul in alte parti, sa dau rollback, samd. > Ai trei optiuni: - il folosesti dar ca intr-un sandbox si faci logging la tot ce face - nu-l folosesti si te duci cu 10 ani in urma - il scrii tu. Multa lume alege 1 pentru ca e codul disponibil pentru toata lumea. Ma mir ca ai ajuns la problema asta filozofica si folosesti deja Linux, MySQL, si multe multe altele la care sigur nu te-ai agitat asa de mult si nu ti-ai pus atitea probleme in a le folosi. Dar o intrebare, cum folosesti tu composer in productie? il folosesti pentru dependency management si cind faci deploy in productie codul respectiv nu instaleaza composer pe serverul de productie, right right ? > > Ca sa fac o analogie, e ca si cum as avea dubii privind identitatea si > competenta dentistului care imi umbla prin masele (ca vine cu masca pusa si > nu-i vad decat ochii) si tu zici ca e ok ca masca aia e sterila. Faptul ca > poarta masca sterila si manusi nu inseamna ca stie ce face cand imi baga > chestii prin dinti. > cum ziceam mai sus. In Linux ai incredere, in CentOS ai. Daca nu ai, fai audit si daca tot e ok, il folosesti. Daca nu, nu. > > -- > P. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-21 0:48 GMT+03:00 Catalin Muresan : > Deaia a s-au inventat VM-urile. Ca sa vezi ce face codul altora. > > [...] > deaia are PHP safe_mode, disable_functions si alte chestii frumoase. Iei si > pui tot frumos intr-un container (in care ai doar apache+php, nu si curl si > wget si alte prostii) si gata. > > [...] > Gindeste-te si la containere, nu-ti trebuie RPM si package manager in > container e prea "gras". Lumea vrea containere mici, 60-80MB/serviciu. > > [...] > preferat din php direct + container, cum ziceam mai sus, limiteaza mult de > tot environment-ul. > Ok, esti fan containere, am inteles. Nu are legatura cu ce problema am eu. E vorba de mediul de productie al codului ala. Da, este deja intr-un "container" (server separat, dedicat pt. chestia asta, samd). Problema e ca ala interactioneaza prin natura lui cu useri si date si backenduri reale, unde are acces la chestii la care trebuie sa aiba acces pentru ca asta e in specificatiile proiectului. Problema mea e mainly de change management si cum fac sa stiu care-s toate schimbarile pe care le introduce un release nou, ca sa pot face dupa aia troubleshooting, sa pot reproduce comportamentul in alte parti, sa dau rollback, samd. Ca sa fac o analogie, e ca si cum as avea dubii privind identitatea si competenta dentistului care imi umbla prin masele (ca vine cu masca pusa si nu-i vad decat ochii) si tu zici ca e ok ca masca aia e sterila. Faptul ca poarta masca sterila si manusi nu inseamna ca stie ce face cand imi baga chestii prin dinti. -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
Deaia a s-au inventat VM-urile. Ca sa vezi ce face codul altora. 2015-08-20 17:40 GMT+01:00 Petru Rațiu : > Am si eu o intrebare pt. astia care sunteti mai curent cu ultimele traznai > din domeniul phpistic: chestia numita composer poate fi folosita intr-un > mod care sa nu faca pe cineva moderat de paranoic sa se suie pe pereti? > > *** approximate rant start *** > > Din ce m-am prins pana acum, toata lumea downloadeaza un phar cu traznaia > impachetata si il ruleaza. Exista codul sursa dar nu are nici o > documentatie mai ca pentru prosti de cum se produce acel phar si aparent > nimeni de pe internet n-a mai avut aceasta dilema. So daca te-a incaltat > cineva cu un composer.phar rootkitat, poate sa-ti faca ce chestii vrea pe > proiectele curente si viitoare (si probabil si pe servere, pentru ca lumea > il ruleaza ca root, doh. > > Sarind peste problema de bootstrap (care sa zicem ca s-ar rezolva daca ma > lamuresc ce script trebuie rulat sa compilez traznaia din surse), asta mai > departe trage chestii de pe github sau wherever (e chiar fain, iti trage by > default ultimul commit ca sa ai si tu cele mai noi features/bugs/exploits > ca restul de cool kids) si daca inteleg bine isi face si auto-update, ca de > ce nu. > > Atat proiectul din care rulezi ala cat si dependintele lui pot avea diverse > hookuri si traznai care se ruleaza la update si carora le face review naiba > stie cine (pentru ca pe github e numai cod de calitate si perfect). > si s-a si intimplat. Firma X a cumparat add-on-ul foarte popular din chrome Y ( cu 100k useri ) si a pus ce a vrut in el, pentru ca Chrome nu verifica update-urile. cauta, o sa gasesti exemple. > Pana aici am ajuns inainte sa ma doara capul, sunt convins ca o sa mai am > niste minunate intalniri cu features care sunt valabile doar de la php 9.x > in sus sau cu vreun minunat framework care are alte concepte la fel de > creative. > > *** approximate rant end *** > deaia are PHP safe_mode, disable_functions si alte chestii frumoase. Iei si pui tot frumos intr-un container (in care ai doar apache+php, nu si curl si wget si alte prostii) si gata. Acu serios, inteleg si pana la un punct sustin toata treaba asta cu agile, > fast development, rapid prototyping, etc, etc. Da' diverse alte roti > patrate cu care am mai avut de-a face pana acu mai aveau documentate niste > metode de-a le face cat de cat mai compatibile cu conceptul sysadminaresc > de mediu de productie (si la npm si la rubygems poti sa-ti compilezi sau > obtii din distro package managerul, cu un efort mediu poti preinstala > pachetele cu pricina undeva in sistem a.i. sa nu aibe nevoie sa downloadeze > chestii, e relativ documentat cum poti avea configuri out-of-tree > pt.diverse environments, etc, etc). > Problema care o rezolva compozer (si berkshelf, puppet librarian/r10k si multe altele) e sa tii codul altora la zi si codul tau sa-l ai cu ce versiune vrei tu. Nu te opreste nimeni sa iei v1.2.3 si sa stai cu versiunea aia pe viata, dar daca folosesti tools gen composer atunci poti sa si faci refresh la module fara sa te complici (download manual, etc). Gindeste-te si la containere, nu-ti trebuie RPM si package manager in container e prea "gras". Lumea vrea containere mici, 60-80MB/serviciu. Revenind la chestii mai concrete, daca cineva lucreaza cu aplicatii php > bazate pe composer (si alti prieteni de-ai lui gen laravel) si poate sa le > tina in friu intr-un mod mai security-conscious, ziceti-mi si mie chestii. > De cautat pe google am cautat da' gasesc in cel mai bun caz de-aia care > stiu ca "curl | sh" e insecure, trebuie sa dai "curl -o , chmod +x ; > ./stuff" si mi-au cam murit cei mai rabdatori dintre neuroni. > preferat din php direct + container, cum ziceam mai sus, limiteaza mult de tot environment-ul. > > -- > P. > > PS: peluza din subiect se refera la "get off my lawn" > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-20 20:18 GMT+03:00 Alex 'CAVE' Cernat : > On 20/8/2015 8:05 PM, Petru Rațiu wrote: > > si corect, da' sa mor daca gasesc cum. Cu developerii nu prea pot sa fac > > treaba, ei considera ca si-au terminat misiunea cand codul e comis si > trece > > testele la ei pe statie (iar draciile astea metrosexuale ii ajuta foarte > > mult cand vine vorba de neglijat probleme de care-mi pasa numai mie). > deja offtopic: macar testeaza cu date reale sau cum am mai vazut bat din > palme ca le merge soafta la 100 de inregistrari in baza si dupa aia > ridica din umeri ca de ce nu merge cand ai vreo 50 de clienti calare si > o baza de date nici macar medie, dar cu un numar de inregistrari (normal > de altfel) pe care nu l-a testat nici cutzu ? > > Da, nu, irelevant. Cate un pic din toate trei. Nu prea pot intra in detalii fara sa dau chestii din casa :) Sa zicem ca daca am face o diagrama tridimensionala unde axele ar fi performanta , volum, bani, s-ar putea identifica zone in spatiul ala de probleme unde se aplica sau nu dilema asta a ta, iar zona in care se aplica are la randul ei subzone in care merita sau nu sa-ti bati capul. (la randul lor impartite dupa care cap e ala batut si pentru cine merita, samd, samd). Dar cum ziceai, deja e offtopic. -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
On 20/8/2015 8:05 PM, Petru Rațiu wrote: > si corect, da' sa mor daca gasesc cum. Cu developerii nu prea pot sa fac > treaba, ei considera ca si-au terminat misiunea cand codul e comis si trece > testele la ei pe statie (iar draciile astea metrosexuale ii ajuta foarte > mult cand vine vorba de neglijat probleme de care-mi pasa numai mie). deja offtopic: macar testeaza cu date reale sau cum am mai vazut bat din palme ca le merge soafta la 100 de inregistrari in baza si dupa aia ridica din umeri ca de ce nu merge cand ai vreo 50 de clienti calare si o baza de date nici macar medie, dar cu un numar de inregistrari (normal de altfel) pe care nu l-a testat nici cutzu ? Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
On 20/8/2015 8:05 PM, Petru Rațiu wrote: > Adica zici ca astea merg si rulate la el pe statie si de comis si deploy se > poate face la codul gata mantzocarit? > Asta inseamna ca code review si security acceptance si alte alea se fac pe > codul final (caz in care tratez astea ca pe niste scule de development cu > care nu vreau sa am de-a face) sau pe codul initial (caz in care procesul > de build , deploy, rollback, bla e tot la mine in curte). iarasi, as prefera sa-si dea cu parerea si cei mai versati in ale composer si laravel (pana acum cred ca la mine se poate numi 'scratch the surface', si mai mult in laravel, fara composer), dar din cultura generala pe care o am si din ce am citit se poate urma calea de dezvoltare si deploy pe care am precizat-o in mailul anterior (dar pe care hipsterii programatori o sa o huleasca, nefacand parte din filosofia lu' laravel si al composerului) da, inteleg, apare un bug in modulul 14, dai comanda de update si s-a rezolvat (si ca in bancul ala, rezolvi un bug apar inca trei :-P); insa mie unuia nu imi place deloc ideea ca php-ul sa se poata updata pe sine (cu singura exceptie notabila fiind wordpress-ul unde ... asta e, dupa noi potopul); cu atat mai putin sa rulez un script (mai ales sub root) care cine stie ce spanac face si ce mai executa prefer sa-si bata capul pe dev cum vor ei dar pe productie fac doar ce le permit eu (si macar de ar merge intotdeauna filosofia asta) Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
2015-08-20 19:55 GMT+03:00 Alex 'CAVE' Cernat : > On 20/8/2015 7:40 PM, Petru Rațiu wrote: > > > > Revenind la chestii mai concrete, daca cineva lucreaza cu aplicatii php > > bazate pe composer (si alti prieteni de-ai lui gen laravel) si poate sa > le > > tina in friu intr-un mod mai security-conscious, ziceti-mi si mie > chestii. > > De cautat pe google am cautat da' gasesc in cel mai bun caz de-aia care > > stiu ca "curl | sh" e insecure, trebuie sa dai "curl -o , chmod +x ; > > ./stuff" si mi-au cam murit cei mai rabdatori dintre neuroni. > > > curentul la moda (baga-l-as la 220 pe ala care a inventat moda asta > cretina) e ce a 'rant'-uit tu mai devreme, cu nebunii, module, > update-uri, ca oricum nu dam doi bani pe securitate si ne doare in > paispe de ea, doar e treaba fraierului de admin sa faca asta nu ? > adicatelea pui intr-un conf o caruta de module, de naiba stie cine le-a > facut si ce buguri au, le mai impachetezi cu 2-3 legaturi si gata, te > lauzi ca ai facut aplicatia lu peste prajit > partea buna este ca daca ocolesti putin filosofia default nebuna a lu > composerul lu' laravel si a familiei sale, poti sa faci ce vrea muschii > tai de programator pe serverul de dezvoltare, ca oricum pe ala toata > lumea face teste, dar cand e vorba de productie faci upload la surse ca > atare, fara executabilele sau scripturi de composer, doar > aplicatia/site-ul in sine; la partea de server de productie blindezi > php-ul si sistemul cum crezi de cuviinta si toata lumea e fericita > > pe scurt: isi face programatorul de cap cu compozoare cat vrea pe > dezvoltare, si apoi deploy la site/aplicatie ca atare > daca urla ca e treaba (sau ca tu esti) old fashion ... zi-i ca poate sa > ma pupe si pe mine undeva, dar are de stat la coada > > Alex > > ps: as vrea sa mai vad si eu un programator gandind asa cum trebuie > inainte de a se apuca de munca (nu mai zic de documentatie, ca suntem in > romania) ... dar deh, toate treburile trebuie terminate ieri, si se mai > si schimba specificatiile dupa cum bate vantul > Adica zici ca astea merg si rulate la el pe statie si de comis si deploy se poate face la codul gata mantzocarit? Asta inseamna ca code review si security acceptance si alte alea se fac pe codul final (caz in care tratez astea ca pe niste scule de development cu care nu vreau sa am de-a face) sau pe codul initial (caz in care procesul de build , deploy, rollback, bla e tot la mine in curte). Ca sa-mi intelegi pozitia, am niste devi care au facut o jucarie (ma rog, jucarie ii zic eu pentru ca n-are treaba cu cardurile, aparent unii-l considera proiect important pentru ca business impact, etc) in chestii de-astea super hipsteresti, iar acu se apropie momentul cand trebuie sa fie si "pe live", si incerc sa ma prind de unde se apuca fara sa te murdaresti de chestii. Inteleg ca e ceva relativ popular si ca posibil se poate folosi si corect, da' sa mor daca gasesc cum. Cu developerii nu prea pot sa fac treaba, ei considera ca si-au terminat misiunea cand codul e comis si trece testele la ei pe statie (iar draciile astea metrosexuale ii ajuta foarte mult cand vine vorba de neglijat probleme de care-mi pasa numai mie). -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] composer, php si peluza
On 20/8/2015 7:40 PM, Petru Rațiu wrote: > > Revenind la chestii mai concrete, daca cineva lucreaza cu aplicatii php > bazate pe composer (si alti prieteni de-ai lui gen laravel) si poate sa le > tina in friu intr-un mod mai security-conscious, ziceti-mi si mie chestii. > De cautat pe google am cautat da' gasesc in cel mai bun caz de-aia care > stiu ca "curl | sh" e insecure, trebuie sa dai "curl -o , chmod +x ; > ./stuff" si mi-au cam murit cei mai rabdatori dintre neuroni. > curentul la moda (baga-l-as la 220 pe ala care a inventat moda asta cretina) e ce a 'rant'-uit tu mai devreme, cu nebunii, module, update-uri, ca oricum nu dam doi bani pe securitate si ne doare in paispe de ea, doar e treaba fraierului de admin sa faca asta nu ? adicatelea pui intr-un conf o caruta de module, de naiba stie cine le-a facut si ce buguri au, le mai impachetezi cu 2-3 legaturi si gata, te lauzi ca ai facut aplicatia lu peste prajit partea buna este ca daca ocolesti putin filosofia default nebuna a lu composerul lu' laravel si a familiei sale, poti sa faci ce vrea muschii tai de programator pe serverul de dezvoltare, ca oricum pe ala toata lumea face teste, dar cand e vorba de productie faci upload la surse ca atare, fara executabilele sau scripturi de composer, doar aplicatia/site-ul in sine; la partea de server de productie blindezi php-ul si sistemul cum crezi de cuviinta si toata lumea e fericita pe scurt: isi face programatorul de cap cu compozoare cat vrea pe dezvoltare, si apoi deploy la site/aplicatie ca atare daca urla ca e treaba (sau ca tu esti) old fashion ... zi-i ca poate sa ma pupe si pe mine undeva, dar are de stat la coada Alex ps: as vrea sa mai vad si eu un programator gandind asa cum trebuie inainte de a se apuca de munca (nu mai zic de documentatie, ca suntem in romania) ... dar deh, toate treburile trebuie terminate ieri, si se mai si schimba specificatiile dupa cum bate vantul ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
[rlug] composer, php si peluza
Am si eu o intrebare pt. astia care sunteti mai curent cu ultimele traznai din domeniul phpistic: chestia numita composer poate fi folosita intr-un mod care sa nu faca pe cineva moderat de paranoic sa se suie pe pereti? *** approximate rant start *** Din ce m-am prins pana acum, toata lumea downloadeaza un phar cu traznaia impachetata si il ruleaza. Exista codul sursa dar nu are nici o documentatie mai ca pentru prosti de cum se produce acel phar si aparent nimeni de pe internet n-a mai avut aceasta dilema. So daca te-a incaltat cineva cu un composer.phar rootkitat, poate sa-ti faca ce chestii vrea pe proiectele curente si viitoare (si probabil si pe servere, pentru ca lumea il ruleaza ca root, doh. Sarind peste problema de bootstrap (care sa zicem ca s-ar rezolva daca ma lamuresc ce script trebuie rulat sa compilez traznaia din surse), asta mai departe trage chestii de pe github sau wherever (e chiar fain, iti trage by default ultimul commit ca sa ai si tu cele mai noi features/bugs/exploits ca restul de cool kids) si daca inteleg bine isi face si auto-update, ca de ce nu. Atat proiectul din care rulezi ala cat si dependintele lui pot avea diverse hookuri si traznai care se ruleaza la update si carora le face review naiba stie cine (pentru ca pe github e numai cod de calitate si perfect). Pana aici am ajuns inainte sa ma doara capul, sunt convins ca o sa mai am niste minunate intalniri cu features care sunt valabile doar de la php 9.x in sus sau cu vreun minunat framework care are alte concepte la fel de creative. *** approximate rant end *** Acu serios, inteleg si pana la un punct sustin toata treaba asta cu agile, fast development, rapid prototyping, etc, etc. Da' diverse alte roti patrate cu care am mai avut de-a face pana acu mai aveau documentate niste metode de-a le face cat de cat mai compatibile cu conceptul sysadminaresc de mediu de productie (si la npm si la rubygems poti sa-ti compilezi sau obtii din distro package managerul, cu un efort mediu poti preinstala pachetele cu pricina undeva in sistem a.i. sa nu aibe nevoie sa downloadeze chestii, e relativ documentat cum poti avea configuri out-of-tree pt.diverse environments, etc, etc). Revenind la chestii mai concrete, daca cineva lucreaza cu aplicatii php bazate pe composer (si alti prieteni de-ai lui gen laravel) si poate sa le tina in friu intr-un mod mai security-conscious, ziceti-mi si mie chestii. De cautat pe google am cautat da' gasesc in cel mai bun caz de-aia care stiu ca "curl | sh" e insecure, trebuie sa dai "curl -o , chmod +x ; ./stuff" si mi-au cam murit cei mai rabdatori dintre neuroni. -- P. PS: peluza din subiect se refera la "get off my lawn" ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
