[rlug] Containers - to be or not to be

Catalin Bucur cata at geniusnet.ro
Sun May 24 13:42:39 EEST 2020


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



More information about the RLUG mailing list