Re: [rlug] Containers - to be or not to be
On 24/05/2020 10:42, Mihai Badici wrote: Eu unul pentru produse stabile ca nginx sau mysql as merge tot pe pachete din distributie. Avantajul containerelor incepe sa apara cand vrei ceva bleeding edge sau care nu are pachet in distro (sau vrei simultan versiuni diferite ale aceleiasi aplicatii). Also, uita de idei conform carora containerele aduc in sine un avantaj de performanta (as zice chiar din contra dar YMMV). Eu am acum pe mana o infrastructura unde exista si kubernetes si masini separate standalone. Au fost surprinzator de multe situatii unde dupa ce ne-am gandit bine am decis ca scoatem unele aplicatii de pe k8s si le punem direct pe OS. Exista si situatia inversa, aplicatii pe care voiam sa le tin separat si mi-am dat seama ca sunt maintained in principal ca containere asa ca e cu mai putina bataie de cap. Ba chiar zilele astea ma uit sa punc docker pe un server extern ca sa pot pune acolo cateva aplicatii care prefera sa fie containere. Of course, daca vrei sa pui docker "ca sa-ti faci mana", go ahead, dar nu-ti vinde ideea ca e mai bine asa :) Aici subscriu. Evident că docker introduce propriul overhead. Ceea ce e vândut că avantaj de performanţă poate funcţiona dacă ai flexibilitatea să te întinzi pe mai multe servere la nevoie. Totuşi de cele mai multe ori flexibilitatea asta e aparentă ( ok, ridici mai multe containere care servesc conţinut static, dar nu de acolo vine load-ul în principal) . Până la urmă la aplicaţiile web în genere botleneck-ul e tot între php şi baza de date (sau ce platforme or mai fi în zilele noastre), iar ca să scapi de el nu poţi pune pur şi simplu "încă un server", trebuie să ai infrastructura adecvată, să poţi să replici baza de date ca să o poţi accesa independent de pe fiecare container etc. Dimpotrivă, vorbind de performanţă, mai degrabă poţi invers, să îl limitezi pe un client la anumiţi parametri, ceea ce poate fi util ca să nu mănânce toate resursele. Ceea ce e de reţinut e separarea ( dacă ai un site compromis în container îl izolezi uşor şi nici nu e foarte simplu să ajungă în celelalte containere) . Şi faptul că poţi rula versiuni diferite de servicii, aplicaţii destul de uşor - poţi să o faci şi fără docker dar e mai mult de muncă - e un avantaj destul de bun. Asta zisă de Petre cu faptul că ai aplicaţii gata împachetate e iar un avantaj major ( acum trec în "moşulică mode" şi zic că aplicaţiile din zilele noastre nu prea merg decât în mediul în care au fost create, din motive de "programatorii din zilele noastre". Eu am cam cedat să încerc să le instalez altfel, de fiecare dată e un pachet incompatibil orice ai face, şi eu am instalat chestii pe slackware, nu mă descurajez uşor, dar spre deosebire de acele vremuri, acum pachetele astea sunt aşa de obscure că nu poţi face nimic pentru ele :) ) . Multumesc pentru confirmari, si eu sunt de acord ca nu poti aduce niciun plus de performanta avand un server fizic si mai multe containere care sa imparta acelasi scop, dimpotriva. Inclinam spre LXC-uri in ideea securitatii, sa separ site-urile intre ele, sau pentru viitor pentru scalabilitate, dar daca pun pe primul loc perfomanta mai bine ma bazez pe OS-ul instalat pe serverul fizic si refac configuratia cand va fi cazul. Numai bine -- Catalin Bucur ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Containers - to be or not to be
Eu unul pentru produse stabile ca nginx sau mysql as merge tot pe pachete din distributie. Avantajul containerelor incepe sa apara cand vrei ceva bleeding edge sau care nu are pachet in distro (sau vrei simultan versiuni diferite ale aceleiasi aplicatii). Also, uita de idei conform carora containerele aduc in sine un avantaj de performanta (as zice chiar din contra dar YMMV). Eu am acum pe mana o infrastructura unde exista si kubernetes si masini separate standalone. Au fost surprinzator de multe situatii unde dupa ce ne-am gandit bine am decis ca scoatem unele aplicatii de pe k8s si le punem direct pe OS. Exista si situatia inversa, aplicatii pe care voiam sa le tin separat si mi-am dat seama ca sunt maintained in principal ca containere asa ca e cu mai putina bataie de cap. Ba chiar zilele astea ma uit sa punc docker pe un server extern ca sa pot pune acolo cateva aplicatii care prefera sa fie containere. Of course, daca vrei sa pui docker "ca sa-ti faci mana", go ahead, dar nu-ti vinde ideea ca e mai bine asa :) Aici subscriu. Evident că docker introduce propriul overhead. Ceea ce e vândut că avantaj de performanţă poate funcţiona dacă ai flexibilitatea să te întinzi pe mai multe servere la nevoie. Totuşi de cele mai multe ori flexibilitatea asta e aparentă ( ok, ridici mai multe containere care servesc conţinut static, dar nu de acolo vine load-ul în principal) . Până la urmă la aplicaţiile web în genere botleneck-ul e tot între php şi baza de date (sau ce platforme or mai fi în zilele noastre), iar ca să scapi de el nu poţi pune pur şi simplu "încă un server", trebuie să ai infrastructura adecvată, să poţi să replici baza de date ca să o poţi accesa independent de pe fiecare container etc. Dimpotrivă, vorbind de performanţă, mai degrabă poţi invers, să îl limitezi pe un client la anumiţi parametri, ceea ce poate fi util ca să nu mănânce toate resursele. Ceea ce e de reţinut e separarea ( dacă ai un site compromis în container îl izolezi uşor şi nici nu e foarte simplu să ajungă în celelalte containere) . Şi faptul că poţi rula versiuni diferite de servicii, aplicaţii destul de uşor - poţi să o faci şi fără docker dar e mai mult de muncă - e un avantaj destul de bun. Asta zisă de Petre cu faptul că ai aplicaţii gata împachetate e iar un avantaj major ( acum trec în "moşulică mode" şi zic că aplicaţiile din zilele noastre nu prea merg decât în mediul în care au fost create, din motive de "programatorii din zilele noastre". Eu am cam cedat să încerc să le instalez altfel, de fiecare dată e un pachet incompatibil orice ai face, şi eu am instalat chestii pe slackware, nu mă descurajez uşor, dar spre deosebire de acele vremuri, acum pachetele astea sunt aşa de obscure că nu poţi face nimic pentru ele :) ) . ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Containers - to be or not to be
On Sat, May 23, 2020 at 12:24 PM Catalin Bucur wrote: > Salutare, > > > Am un server (fizic) pe care va rula un site destul de accesat ce va > consuma resurse maricele, dar nimic exagerat, poate ceva mai mult pe > perioade scurte. > > Din experienta voastra merita "efortul" sa-l configurez pe baza de > containere, de exemplu unul pentru nginx, altul pentru mysql? Ma gandesc > ca poate mi-ar aduce avantaje in viitor in cazul in care mai apare un > site de aceeasi anvergura pe acelasi server, sau poate daca intru in > zona fail-over/load-balancing. > > Eu unul pentru produse stabile ca nginx sau mysql as merge tot pe pachete din distributie. Avantajul containerelor incepe sa apara cand vrei ceva bleeding edge sau care nu are pachet in distro (sau vrei simultan versiuni diferite ale aceleiasi aplicatii). Also, uita de idei conform carora containerele aduc in sine un avantaj de performanta (as zice chiar din contra dar YMMV). Eu am acum pe mana o infrastructura unde exista si kubernetes si masini separate standalone. Au fost surprinzator de multe situatii unde dupa ce ne-am gandit bine am decis ca scoatem unele aplicatii de pe k8s si le punem direct pe OS. Exista si situatia inversa, aplicatii pe care voiam sa le tin separat si mi-am dat seama ca sunt maintained in principal ca containere asa ca e cu mai putina bataie de cap. Ba chiar zilele astea ma uit sa pun docker pe un server extern ca sa pot pune acolo cateva aplicatii care prefera sa fie containere. Of course, daca vrei sa pui docker "ca sa-ti faci mana", go ahead, dar nu-ti vinde ideea ca e mai bine asa :) -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
