2015-08-21 18:29 GMT+03:00 Catalin Muresan <[email protected]>:
> 2015-08-21 8:27 GMT+01:00 Petru Rațiu <[email protected]>: > > > 2015-08-21 0:48 GMT+03:00 Catalin Muresan <[email protected]>: > > > > > 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 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 ma asigur ca mediul de productie va fi fix la fel si nu se vor introduce buguri noi din cauza ca intre timp cineva prin una din dependinte a decis ca schimba nushce api? PS: Incep sa suspectez ca ma trollezi, da' mi-am propus sa mai raspund la inca 1-2 mailuri tot serios, pentru ca chiar vreau sa vad daca exista vreo solutie, da' dupa aia scot si eu capacul la borcan. -- P. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
