{"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\/pl\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"Czym jest Docker: kr\u00f3tka historia i podstawowe abstrakcje","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

10 sierpnia w S\u0142urmie rozpocz\u0105\u0142 si\u0119 kurs wideo dotycz\u0105cy Dockera<\/a><\/noindex>, w kt\u00f3rym omawiamy go w ca\u0142o\u015bci \u2014 od podstawowych abstrakcji po parametry sieciowe. <\/p>\n

<\/p>\n

W tym artykule om\u00f3wimy histori\u0119 pojawienia si\u0119 Dockera i jego podstawowe abstrakcje: Image, Cli, Dockerfile. Wyk\u0142ad jest przeznaczony dla nowicjuszy, wi\u0119c raczej nie b\u0119dzie interesuj\u0105cy dla do\u015bwiadczonych u\u017cytkownik\u00f3w. Nie b\u0119dzie tu krwi, wyrostka i g\u0142\u0119bokiego zag\u0142\u0119bienia. Same podstawy.<\/p>\n

<\/p>\n

\"Czym<\/p>\n

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

Czym jest Docker<\/h2>\n

<\/p>\n

Sp\u00f3jrzmy na definicj\u0119 Dockera z Wikipedii.<\/p>\n

<\/p>\n

Docker to oprogramowanie do automatyzacji wdra\u017cania i zarz\u0105dzania aplikacjami w \u015brodowiskach wspieraj\u0105cych konteneryzacj\u0119.<\/p><\/blockquote>\n

Z tej definicji nic nie wynika. Szczeg\u00f3lnie niejasne jest, co oznacza \u201ew \u015brodowiskach wspieraj\u0105cych konteneryzacj\u0119\u201d. Aby to zrozumie\u0107, wr\u00f3\u0107my do przesz\u0142o\u015bci. Zacznijmy od epoki, kt\u00f3r\u0105 nazywam \u201eEpok\u0105 monolit\u00f3w\u201d.<\/p>\n

<\/p>\n

Epoka monolit\u00f3w<\/h2>\n

<\/p>\n

Epoka monolit\u00f3w to pocz\u0105tek lat 2000, kiedy wszystkie aplikacje by\u0142y monolityczne, z mn\u00f3stwem zale\u017cno\u015bci. Proces rozwoju trwa\u0142 d\u0142ugo. Serwer\u00f3w nie by\u0142o zbyt du\u017co, wszyscy znali\u015bmy je po imieniu i monitorowali\u015bmy. Istnieje zabawne por\u00f3wnanie:<\/p>\n

\n

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

Pets \u2014 to zwierz\u0119ta domowe. W epoce monolit\u00f3w odnosili\u015bmy si\u0119 do naszych serwer\u00f3w jak do zwierz\u0105t domowych, piel\u0119gnowali\u015bmy je, dbali\u015bmy o nie, zdmuchiwali\u015bmy kurz. A aby lepiej zarz\u0105dza\u0107 zasobami, u\u017cywali\u015bmy wirtualizacji: brali\u015bmy serwer i dzielili\u015bmy go na kilka maszyn wirtualnych, zapewniaj\u0105c tym samym izolacj\u0119 \u015brodowiska.<\/p>\n

<\/p>\n

Systemy wirtualizacji oparte na hipernadzorze<\/h2>\n

<\/p>\n

O systemach wirtualizacji zapewne wszyscy s\u0142yszeli: VMware, VirtualBox, Hyper-V, Qemu KVM itd. Zapewniaj\u0105 one izolacj\u0119 aplikacji i zarz\u0105dzanie zasobami, ale maj\u0105 te\u017c swoje wady. Aby uzyska\u0107 wirtualizacj\u0119, potrzebny jest hipernadzorca. A hipernadzorca to nadmiar zasob\u00f3w. Poza tym sama maszyna wirtualna zazwyczaj jest du\u017cym bytem \u2014 ci\u0119\u017cki obraz, na kt\u00f3rym znajduje si\u0119 system operacyjny, Nginx, Apache, a by\u0107 mo\u017ce i MySQL. Obraz jest du\u017cy, trudno operowa\u0107 maszyn\u0105 wirtualn\u0105. W konsekwencji praca z wirtualkami mo\u017ce by\u0107 wolna. Aby rozwi\u0105za\u0107 ten problem, stworzono systemy wirtualizacji na poziomie j\u0105dra.<\/p>\n

<\/p>\n

Systemy wirtualizacji na poziomie j\u0105dra<\/h2>\n

<\/p>\n

Wirtualizacj\u0119 na poziomie j\u0105dra wspieraj\u0105 systemy OpenVZ, Systemd-nspawn, LXC. Jaskrawym przyk\u0142adem takiej wirtualizacji s\u0105 LXC (Linux Containers). <\/p>\n

<\/p>\n

LXC \u2014 system wirtualizacji na poziomie systemu operacyjnego, kt\u00f3ry umo\u017cliwia uruchamianie wielu izolowanych instancji systemu operacyjnego Linux na jednym w\u0119\u017ale. LXC nie korzysta z maszyn wirtualnych, lecz tworzy \u015brodowisko wirtualne z w\u0142asn\u0105 przestrzeni\u0105 proces\u00f3w i stosu sieciowego.<\/p>\n

<\/p>\n

W zasadzie LXC tworzy kontenery. Jaka jest r\u00f3\u017cnica mi\u0119dzy maszynami wirtualnymi a kontenerami?<\/p>\n

<\/p>\n

\"Czym<\/p>\n

<\/p>\n

Kontener nie nadaje si\u0119 do izolowania proces\u00f3w: w systemach wirtualizacji na poziomie j\u0105dra odkrywane s\u0105 luki, kt\u00f3re pozwalaj\u0105 na wydostanie si\u0119 z kontenera na ho\u015bcie. Dlatego je\u015bli chcesz co\u015b izolowa\u0107, lepiej u\u017cy\u0107 maszyny wirtualnej.<\/p>\n

<\/p>\n

R\u00f3\u017cnice mi\u0119dzy wirtualizacj\u0105 a konteneryzacj\u0105 mo\u017cna zobaczy\u0107 na schemacie.
\nS\u0105 hyperwizory sprz\u0119towe, hyperwizory nad systemem operacyjnym i kontenery. <\/p>\n

<\/p>\n

\"Czym<\/p>\n

<\/p>\n

\u00abSprz\u0119towe\u00bb hyperwizory to \u015bwietne narz\u0119dzie, je\u015bli naprawd\u0119 chcesz co\u015b izolowa\u0107. Poniewa\u017c istnieje mo\u017cliwo\u015b\u0107 izolowania na poziomie stron pami\u0119ci i procesor\u00f3w.<\/p>\n

<\/p>\n

S\u0105 hyperwizory jako programy, a s\u0105 kontenery, o kt\u00f3rych b\u0119dziemy m\u00f3wi\u0107 dalej. W systemach konteneryzacji nie ma hyperwizora, ale jest Container Engine, kt\u00f3ry tworzy kontenery i zarz\u0105dza nimi. Jest to l\u017cejsze rozwi\u0105zanie, dlatego dzi\u0119ki pracy z j\u0105drem overhead jest mniejszy lub wr\u0119cz nie wyst\u0119puje.<\/p>\n

<\/p>\n

\n

Co jest u\u017cywane do konteneryzacji na poziomie j\u0105dra<\/h2>\n

Podstawowe technologie, kt\u00f3re umo\u017cliwiaj\u0105 tworzenie kontener\u00f3w izolowanych od innych proces\u00f3w, to Namespaces i Control Groups.<\/p>\n

Namespaces: PID, Networking, Mount i User. Jest ich wi\u0119cej, ale dla uproszczenia zatrzymamy si\u0119 na tych.<\/p>\n

Namespace PID ogranicza procesy. Gdy na przyk\u0142ad tworzymy namespace PID i umieszczamy w nim proces, staje si\u0119 on PID 1. Zwykle w systemach PID 1 to systemd lub init. Odpowiednio, kiedy umieszczamy proces w nowym namespace, r\u00f3wnie\u017c otrzymuje PID 1.<\/p>\n

Networking Namespace pozwala na ograniczenie\/izolacj\u0119 sieci i wewn\u0105trz ju\u017c umieszczanie w\u0142asnych interfejs\u00f3w. Mount to ograniczenie w systemie plik\u00f3w. User to ograniczenie dotycz\u0105ce u\u017cytkownik\u00f3w.<\/p>\n

Control Groups: Pami\u0119\u0107, CPU, IOPS, Sie\u0107 \u2014 \u0142\u0105cznie oko\u0142o 12 ustawie\u0144. Inaczej nazywane Cgroups (C grupy).<\/p>\n

Control Groups zarz\u0105dzaj\u0105 zasobami dla kontenera. Dzi\u0119ki Control Groups mo\u017cemy powiedzie\u0107, \u017ce kontener nie powinien zu\u017cywa\u0107 wi\u0119cej ni\u017c okre\u015blon\u0105 ilo\u015b\u0107 zasob\u00f3w.<\/p>\n

Aby konteneryzacja mog\u0142a dzia\u0142a\u0107 w pe\u0142ni, wykorzystuje si\u0119 dodatkowe technologie: Capabilities, Copy-on-write i inne.<\/p>\n

Capabilities to sytuacja, w kt\u00f3rej m\u00f3wimy procesowi, co mo\u017ce robi\u0107, a czego nie. Na poziomie j\u0105dra to po prostu bitmapy z wieloma parametrami. Na przyk\u0142ad u\u017cytkownik root ma pe\u0142ne uprawnienia i mo\u017ce robi\u0107 wszystko. Serwer czasu mo\u017ce zmienia\u0107 czas systemowy: ma capabilities na Time Capsule i ju\u017c. Dzi\u0119ki uprawnieniom mo\u017cna elastycznie dostosowa\u0107 ograniczenia dla proces\u00f3w, co pozwala zwi\u0119kszy\u0107 bezpiecze\u0144stwo.<\/p>\n

System Copy-on-write pozwala nam skuteczniej pracowa\u0107 z obrazami Docker.<\/p>\n

Obecnie Docker ma problemy z kompatybilno\u015bci\u0105 Cgroups v2, dlatego w artykule skupiamy si\u0119 na Cgroups v1.<\/em><\/p><\/blockquote>\n

Ale wr\u00f3\u0107my do historii. <\/p>\n

<\/p>\n

Kiedy pojawi\u0142y si\u0119 systemy wirtualizacji na poziomie j\u0105dra, zacz\u0119to je intensywnie wykorzystywa\u0107. Opr\u00f3cz obci\u0105\u017cenia hipernadzorc\u0105, pojawi\u0142y si\u0119 inne problemy:<\/p>\n

<\/p>\n