{"id":91905,"date":"2020-08-20T07:42:23","date_gmt":"2020-08-20T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii"},"modified":"2020-08-20T07:42:23","modified_gmt":"2020-08-20T05:42:23","slug":"chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"Kaj je Docker: kratek pregled zgodovine in osnovne abstrakcije","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

10. avgusta je na Sljormu zapo\u010deo video kurs o Dockeru<\/a><\/noindex>, u kojemu detaljno razra\u0111ujemo sve aspekte \u2014 od osnovnih apstrakcija do mre\u017enih parametara. <\/p>\n

<\/p>\n

U ovom \u010dlanku razgovarat \u0107emo o istoriji nastanka Dockera i njegovim osnovnim apstrakcijama: Image, Cli, Dockerfile. Predavanje je namijenjeno po\u010detnicima, tako da vjerojatno ne\u0107e biti zanimljivo iskusnim korisnicima. Ne\u0107emo se baviti dubokim analizama. Samo osnovne informacije.<\/p>\n

<\/p>\n

\"Kaj<\/p>\n

<\/a><\/noindex><\/p>\n

\u0160ta je Docker<\/h2>\n

<\/p>\n

Pogledajmo definiciju Dockera iz Wikipedije.<\/p>\n

<\/p>\n

Docker je softver za automatizaciju implementacije i upravljanje aplikacijama u okru\u017eenjima koja podr\u017eavaju kontejnerizaciju.<\/p><\/blockquote>\n

Iz ove definicije ni\u0161ta nije jasno. Pograni\u010dno je nejasno \u0161to zna\u010di \u201eu okru\u017eenjima koja podr\u017eavaju kontejnerizaciju\u201c. Da bismo to razjasnili, vratimo se u pro\u0161lost. Po\u010dnimo iz doba koje naziva \u201eMonolitna era\u201c.<\/p>\n

<\/p>\n

Monolitna era<\/h2>\n

<\/p>\n

Monolitna era je po\u010detak 2000-ih, kada su sve aplikacije bile monolitne, sa mno\u0161tvom zavisnosti. Razvoj je trajao dugo. U to vreme nije bilo mnogo servera, svi smo ih znali po imenu i pratili ih. Postoji zanimljiva usporedba:<\/p>\n

\n

\r\n \"Predvajaj\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Ljubimci \u2014 to su ku\u0107ni prijatelji. U monolitnoj eri odnosili smo se prema svojim serverima kao prema ljubimcima, brinuli smo se i pazili na njih, sklanjaju\u0107i pra\u0161inu. Za bolje upravljanje resursima koristili smo virtualizaciju: uzeli smo server i podelili ga na nekoliko virtuelnih ma\u0161ina, \u010dime smo obezbedili izolaciju okru\u017eenja.<\/p>\n

<\/p>\n

Sistemi virtualizacije na bazi hipervizora<\/h2>\n

<\/p>\n

O sistemima virtualizacije sigurno su svi \u010duli: VMware, VirtualBox, Hyper-V, Qemu KVM itd. Oni obezbe\u0111uju izolaciju aplikacija i upravljanje resursima, ali imaju i nedostatke. Da bi se realizovala virtualizacija, potreban je hipervizor. A hipervizor je dodatno optere\u0107enje resursa. \u010cak i sama virtuelna ma\u0161ina obi\u010dno je velika i te\u0161ka \u2014 obiman imid\u017e, na njemu je operativni sistem, Nginx, Apache, mogu\u0107e i MySQL. Imid\u017e je veliki, te\u0161ko je upravljati virtuelnom ma\u0161inom. Kao posledica, rad sa virtuelnim ma\u0161inama mo\u017ee biti spor. Da bismo re\u0161ili taj problem, stvorene su sisteme virtualizacije na nivou jezgra.<\/p>\n

<\/p>\n

Sistemi virtualizacije na nivou jezgra<\/h2>\n

<\/p>\n

Virtualizaciju na nivou jezgra podr\u017eavaju sistemi OpenVZ, Systemd-nspawn, LXC. Osvetljeni primer takve virtualizacije je LXC (Linux Containers). <\/p>\n

<\/p>\n

LXC \u2014 sistem virtualizacije na nivoju operativnog sistema za pokretanje vi\u0161e izolovanih instanci operativnog sistema Linux na jednom \u010dvoru. LXC ne koristi virtuelne ma\u0161ine, ve\u0107 stvara virtuelno okru\u017eenje sa sopstvenim procesnim prostorom i mre\u017enim stekom.<\/p>\n

<\/p>\n

U su\u0161tini, LXC stvara kontejnere. Koja je razlika izme\u0111u virtuelnih ma\u0161ina i kontejnera?<\/p>\n

<\/p>\n

\"Kaj<\/p>\n

<\/p>\n

Kontejner nije pogodan za izolaciju procesa: u sistemima virtualizacije na nivou jezgra postoje ranjivosti koje omogu\u0107avaju izlazak iz kontejnera na host. Stoga, ako vam je potrebna neka izolacija, bolje je koristiti virtuelnu ma\u0161inu.<\/p>\n

<\/p>\n

Razlike izme\u0111u virtualizacije i kontejnerizacije mogu se videti na dijagramu.
\nPostoje hardverski hipervizori, hipervizori iznad OS i kontejneri. <\/p>\n

<\/p>\n

\"Kaj<\/p>\n

<\/p>\n

\u201eHardverski\u201c hipervizori su sjajna stvar ako zaista \u017eelite ne\u0161to da izolujete. Jer tu postoji mogu\u0107nost izolacije na nivou stranica memorije, procesora.<\/p>\n

<\/p>\n

Postoje hipervizori kao program i postoje kontejneri, o kojima \u0107emo dalje govoriti. U sistemima kontejnerizacije ne postoji hipervizor, ali postoji Container Engine koji stvara kontejneri i upravlja njima. Ova stvar je lak\u0161a, pa zbog rada sa jezgrom overhead je manji ili ga uop\u0161te nema.<\/p>\n

<\/p>\n

\n

\u0160ta se koristi za kontejnerizaciju na nivou jezgra<\/h2>\n

Osnovne tehnologije koje omogu\u0107avaju stvaranje izolovanog kontejnera od drugih procesa su Namespaces i Control Groups.<\/p>\n

Namespaces: PID, Networking, Mount i User. Ima jo\u0161, ali radi jednostavnosti razumevanja \u0107emo se zadr\u017eati na ovim.<\/p>\n

PID Namespace ograni\u010dava procese. Kada, na primer, stvaramo PID Namespace i sme\u0161tamo proces u njega, on postaje sa PID 1. Obi\u010dno je u sistemima PID 1 \u2014 to je systemd ili init. Tako da, kada sme\u0161tamo proces u novi namespace, on tako\u0111e dobija PID 1.<\/p>\n

Networking Namespace omogu\u0107ava ograni\u010davanje\/izolaciju mre\u017ee i unutar nje sme\u0161ta svoje interfejse. Mount \u2014 to je ograni\u010denje po datote\u010dnom sistemu. User \u2014 ograni\u010denje po korisnicima.<\/p>\n

Control Groups: Memory, CPU, IOPS, Network \u2014 ukupno oko 12 pode\u0161avanja. Ina\u010de ih jo\u0161 nazivaju Cgroups (\u201eC grupa\u201c).<\/p>\n

Control Groups upravljaju resursima za kontejner. Putem Control Groups mo\u017eemo re\u0107i da kontejner ne sme tro\u0161iti vi\u0161e od odre\u0111enog broja resursa.<\/p>\n

Da bi kontejnerizacija potpuno funkcionisala, koriste se dodatne tehnologije: Capabilities, Copy-on-write i druge.<\/p>\n

Capabilities su kada ka\u017eemo procesu \u0161ta mo\u017ee da radi, a \u0161ta ne mo\u017ee. Na nivou jezgra to su samo bitmape sa mno\u0161tvom parametara. Na primer, korisnik root ima pune privilegije i mo\u017ee raditi sve. Server vremena mo\u017ee menjati sistemsko vreme: ima capabilities za Time Capsule i to je to. Pomo\u0107u privilegija mo\u017eemo fleksibilno prilagoditi ograni\u010denja za procese i tako se za\u0161tititi.<\/p>\n

Sistem Copy-on-write omogu\u0107ava nam da radimo sa Docker slikama i koristimo ih efikasnije.<\/p>\n

Trenutno Docker ima problema sa kompatibilno\u0161\u0107u Cgroups v2, pa se u \u010dlanku razmatraju upravo Cgroups v1.<\/em><\/p><\/blockquote>\n

Ali, vratimo se istoriji. <\/p>\n

<\/p>\n

Kada su se pojavili sistemi virtuelizacije na nivou jezgra, po\u010deli su se aktivno primenjivati. Overhead na hipervizoru je nestao, ali su neka pitanja ostala:<\/p>\n

<\/p>\n