•  untoreh-light

Pe containere

Utilizarea containerelor, ce și de ce

Ce sunt containerele

[Containere] este un nume dat mediilor restricționate, făcut posibil de o colecție de subsisteme din Linux, cum ar fi [cgroups ] și [namespaces ]. Deși pagina wiki folosește cuvântul virtualizare Cred că cuvântul izolare este mai adecvat, deoarece virtualizarea înseamnă că există un strat de traducere între ele, în timp ce ceea ce fac grupurile și spațiile de nume este să separe și să contextualizeze procesele.

Cgroups sunt utilizate pentru a defini politicile de alocare pentru resurse, de obiceiRAM șiCPU , în timp ce spațiile de nume controlează contextele precum punctele de montare, rețelele și utilizatorii. [Apparmor] oferă în schimb o modalitate de a restricționa capacitățile pentru mediile de containere în ansamblu, în timp ce apparmor fără containere este, așa cum este scris în Wikipedia, bazat pe programe.

Instrumente precum flatpak și firejailutilizați containere, pentru a limita suprafața de acces a aplicațiilor utilizatorului. Containerele [Windows] implementează sisteme echivalente și oferă, de asemenea, suport pentru containerele Linux prin [WSL].

Dar de ce?

Prea mult?

Când am început să construiesc pin , Am experimentat puțin cu livrarea propriilor imagini de containere, distribuite din versiunile github. Scenariul principal (trees ) comenzile erau

Usage: trees APP [FLAGS]...
'APP'               Install apps through ostree deltas checkouts.
    -b, --base      base image (alp,trub...)
    -n, --name      same as APP (etcd,hhvm...)
    -f, --force     clear before install
    -d, --delete    clear checkout and prune ostree repo
ck, check           make sure the apps repo is mounted
co, checkout        builds the trees of links for the specified APP
    -t 	            optional path where to build the tree

A fost similar cu flatpak, deoarece transportam o delta statică ostree bazată pe imaginea principală a pinului și [verificând] noua aplicație rootfs bazată pe aplicație și apoi lansând o instanță de container deasupra acestuia. OpenVZ a avut o mulțime de probleme înainte de v7 pentru rularea containerului (deoarece știți ... ați rulat un cuibărit container pe un [VPS] bazat pe container, iar nucleul era o furcă av2.6 (!))...a fost o imens pierdere de timp.

Cand?

Încercarea mea a fost de a obține un timp de rulare minim al containerelor fără a necesitadocker sau mai multe programe mai puternice, deoarece docker este probabil cel mai ușor și roi docker , fiind încorporat împărtășește o mulțime de funcționalități și vă oferă cele mai utile caracteristici pentru orchestrație, ceea ce îl face cel mai bazat pe cerințele sistemului gazdă în comparație cu k8s sau nomad.

Deși containerele sunt o caracteristică pe care s-ar putea să o doriți de cele mai multe ori, orchestrarea nu este. Eu cred slab vizat campaniile publicitare atrag neintenționat publicul țintă pentru un astfel de software, făcându-l să creadă că poate fi util lor , fără a sublinia premisa că tu într-adevăr trebuie să scalați mult (!) pentru a justifica costul complexității unor astfel de setări. Numarul scule convenabile construit în jurul k8s pentru a ajuta procesul de bootstrapping al unui cluster k8s ar trebui să fie suficiente dovezi ...

Concluzii

Instrumentele de orchestrații ajung să aglomereze locul pentru soluții de gestionare a mașinilor cu mai multe gazde, atunci când utilizatorii nu pot face diferența între serverele pentru animale de companie și cele pentru vite. În multe ocazii, programe precum ansible, pyinfra sau chiar cssh sau ash este tot ce trebuie vreodată.

Post Tag-uri: