De ceva vreme, cel puțin în lumea Linux se vorbește din ce în ce mai mult despre “containere”. Acestea vin oarecum să înlocuiască parțial cealaltă “modă”, cea a virtualizării, al cărei apogeu pare să fi trecut, dar nu în sensul dispariției ci mai degrabă al intrării în obișnuit.
Virtualizarea era de mai multă vreme la modă, și asta din cel puțin două motive: unul ținând de eficiență ( serverele din ziua de azi sunt prea puternice pentru a avea un singur rol, așa că le folosim pentru a rula mai multe servere virtuale, cu diferite roluri, pentru a le ocupa corespunzător) și al doilea, de separare : putem rula servere diferite (cu sisteme de operare sau setup-uri diferite) care să nu interfereze între ele. Cel puțin pentru un dezvoltator, nevoit să testeze produsul pe sisteme de operare diferite sau în condiții diferite, virtualizarea este mană cerească. Este însă și o metodă, așa cum ziceam, de a folosi pe același server sisteme de operare diferite sau configurații diferite, care să nu interfereze.
Virtualizarea a devenit atât de comună, încât orice sistem de operare contemporan a integrat-o în propriul kernel, ceea ce a devenit o problemă pentru producătorii tradiționali ca Vmware; motivele pentru care cineva arr plăti pentru un astfel de produs devin din ce în ce mai puține.
La un nivel teoretic, virtualizarea ar parea o “non-soluție” pentru o “non-problemă” : în mod normal orice program scris pentru un anumit computer, să zicem pentru PC, devine cod mașină, deci ar trebui să ruleze pe orice PC, indiferent de sistemul de operare sau de alte condiții. Sistemul de operare trebuie să îi asigure cerințele specifice și interfața cu exteriorul. Aici intervine prima problemă, pentru că această interfață depinde de sistemul de operare; de exemplu respectivul program nu accesează direct placa video, ci prin intermediul unor apeluri de sistem prezente în sistemul de operare; ele sunt diferite de la sistem la sistem, deci programul nu va putea să afișeze decât dacă are la dispoziție aceste apeluri.
Pe de altă parte, sistemele de operare actuale oferă un acces la resurse mai mult sau mai puțin “la grămadă”. Nu avem prea multe posibilități să limităm accesul la resurse ( memorie, disc, procesor) pentru anumite procese.
Ori aici apare virtualizarea, care ne permite să definim mașina virtuală pentru care alocăm anumite resurse și pe care instalăm sistemul de operare dorit; în felul acesta am separat și resursele și am și dat programului nostru apelurile de sistem necesare.
Prețul plătit se măsoară pe de o parte în spațiu pe disc ( pentru trei mașini virtuale instalăm trei sisteme de operare, deci ocupăm de trei ori mai mult spațiu, plus spațiul ocupat de sistemul de bază. Se pot folosi imagini diferențiale, dar problema în sine rămâne, e doar minimizată) . În plus, mașina host consumă niște resurse pentru a administra toate celelalte mașini virtuale, nu totdeauna neglijabile. Bineînțeles, mai sunt și alte probleme care țin de implementare iar pe ansamblu soluția devine destul de greoaie.
Aici intervine moda containerelor despre care vorbeam la început. Prin introducerea unor posibilități noi în kernel, de izolare a memoriei alocate, ele transformă practic mașinile virtuale în procese, folosind apelurile de sistem ale serverului host. E adevărat, asta limitează folosirea lor la virtualizarea doar a mașinilor cu același sistem de operare ( dacă hostul e Linux, putem “virtualiza” sau “containeriza” doar Linux). Dar e un doar un mic impediment, ținând cont că respectivele containere vor funcționa practic la “viteza reală” și vor consuma doar resursele de care au nevoie. Docker, lxc, lxd, se tot succed și se tot combină.
Eu personal însă nu m-aș grăbi să pariez, comercial vorbi nd, pe această tehnologie, și nu din cauză că nu e promițătoare, ci tocmai pentru că pare prea promițătoare. Atât de promițătoare încăt mă aștept ca posibilitatea de izolare a proceselor și a resurselor să devină standard în noile generații de sisteme de operare. Până la urmă, alocarea resurselor a fost dintotdeauna treaba sistemului de operare; faptul că acesta le alocă “la grămadă” e dovada că încă se află într-o epocă primitivă. Ori în ultima vreme, o mare parte a eforturilor de dezvoltare sunt concentrate în această zonă: hypervizoare, containere. Integrarea lor în sistem pare o urmare firească, chiar daca vor mai curge mulți kilobiți pe Internet până atunci.
Aikido cu mintea si corpul coordonate. Invatati cum sa va relaxati si cum sa va pastrati calmul in conditii de stress. 
Err… Lunix are cgroups din 2.6… Where’s the news?
E news pentru autor :>
Containerele astea virtuale mai populare cum sunt Docker si Vagrant au aparut pentru a simplifica replicarea medilor de testare in development. Ca unii dau jos containerele publice si participa la atacuri dos cu ele, in loc sa si le creeze singuri e alta mancare de peste :>
La cggroups se lucreaza, intr-adevar, de ceva vreme, a trecut si printr-un redesign acum cativa ani, insa ca sa poata fi folosita aceasta facilitate e nevoie de tot ecosistemul, integrarea cu quemu, networking, deployment etc. Nu e ca si cum ar fi aparut ieri, dar e un domeniu inca in dezvoltare (mie mi se pare cea mai importanta directie de dezvoltare in momentul de față, dar nu mă gândesc la containere- le vad ca pe un pas intermediar- ci la posibilitatea de a aloca/limita resursele chiar la lansarea procesului într-un mod simplu direct din sistemul de operare , de asta am adus vorba). Tehnic, probabil ca e posibil și acum, dar e nevoie de o modalitate practica de a o face.