Pytanie Czym Docker różni się od maszyny wirtualnej?


Ciągle czytam ponownie dokumentacja Docker aby spróbować zrozumieć różnicę między Dockerem a pełną maszyną wirtualną. W jaki sposób udaje się zapewnić pełny system plików, izolowane środowisko sieciowe itp. Bez bycia tak ciężkim?

Dlaczego wdrażanie oprogramowania do obrazu dokowanego (jeśli jest to właściwe pojęcie) jest łatwiejsze niż wdrażanie w spójnym środowisku produkcyjnym?


2921
2018-04-16 21:19


pochodzenie


Analiza wydajności Docker kontra KVM: bodenr.blogspot.com/2014/05/... - HDave
Jeśli szukasz różnic między ich obrazami - stackoverflow.com/questions/29096967/... - devesh-ahuja
Docker nie jest maszyną wirtualną - jest to narzędzie do zarządzania konfiguracją. - aaa90210
@JagatveerSingh Pomyślałem, że wspomnę, że jest to link do tego samego pytania. - Dan Nissenbaum
Stack Overflow to strona z pytaniami dotyczącymi programowania i programowania. To pytanie wydaje się być nie na temat, ponieważ nie chodzi o programowanie czy rozwój. Widzieć O jakich tematach mogę tutaj zapytać w Centrum pomocy. Być może Superużytkownik lub Unix i Linux Stack Exchange byłoby lepszym miejscem do zapytania. - jww


Odpowiedzi:


Pierwotnie używany Docker Kontenery LinuX (LXC), ale później zmieniono na runC (formalnie znany jako libcontainer), który działa w tym samym systemie operacyjnym, co jego host. Dzięki temu może współdzielić wiele zasobów systemu operacyjnego hosta. Ponadto używa warstwowego systemu plików (AuFS) i zarządza siecią.

AuFS jest warstwowym systemem plików, więc możesz mieć część tylko do odczytu i część do zapisu, które są ze sobą połączone. Można mieć wspólne części systemu operacyjnego jako tylko do odczytu (i współużytkowane wśród wszystkich twoich kontenerów), a następnie dać każdemu kontenerowi własny uchwyt do pisania.

Załóżmy, że masz obraz pojemnika o pojemności 1 GB; jeśli chcesz użyć pełnej maszyny wirtualnej, potrzebujesz 1 GB x liczbę maszyn wirtualnych, które chcesz. Dzięki Docker i AuFS możesz udostępnić większą część 1 GB między wszystkimi kontenerami, a jeśli masz 1000 kontenerów, możesz mieć tylko nieco ponad 1 GB miejsca na system operacyjny kontenerów (zakładając, że wszystkie działają z tym samym obrazem systemu operacyjnego) .

W pełni zwirtualizowany system otrzymuje własny zestaw przydzielonych mu zasobów i wykonuje minimalne udostępnianie. Dostajesz więcej izolacji, ale jest ona znacznie cięższa (wymaga więcej zasobów). Dzięki Docker masz mniej izolacji, ale kontenery są lekkie (wymagają mniej zasobów). Więc możesz łatwo uruchomić tysiące kontenerów na hoście, a nawet nie będzie migać. Spróbuj to zrobić z Xenem, a jeśli nie masz naprawdę dużego hosta, nie sądzę, żeby było to możliwe.

Pełny zwirtualizowany system zazwyczaj zajmuje kilka minut, natomiast kontenery Docker / LXC / runC zajmują sekundy, a często nawet mniej niż sekundę.

Istnieją zalety i wady każdego typu zwirtualizowanego systemu. Jeśli chcesz uzyskać pełną izolację z gwarantowanymi zasobami, pełna droga VM jest drogą do zrobienia. Jeśli chcesz odizolować procesy od siebie nawzajem i chcesz je uruchomić na rozsądnym rozmiarze hosta, to Docker / LXC / runC wydaje się być najlepszym rozwiązaniem.

Aby uzyskać więcej informacji, sprawdź ten zestaw wpisów na blogu które dobrze wyjaśniają, jak działa LXC.

Dlaczego wdrażanie oprogramowania do obrazu dokowanego (jeśli jest to właściwe pojęcie) jest łatwiejsze niż wdrażanie w spójnym środowisku produkcyjnym?

Wdrożenie spójnego środowiska produkcyjnego jest łatwiejsze niż zostało powiedziane. Nawet jeśli używasz narzędzi takich jak Szef kuchni i Marionetka, zawsze są aktualizacje systemu operacyjnego i inne rzeczy, które zmieniają się między hostami i środowiskami.

Docker daje możliwość zrzutu systemu operacyjnego na udostępniony obraz i ułatwia jego wdrożenie na innych hostach Docker. Lokalnie, dev, qa, prod, itp .: wszystkie te same obrazy. Oczywiście można to zrobić za pomocą innych narzędzi, ale nie tak łatwo lub szybko.

To jest świetne do testowania; Załóżmy, że masz tysiące testów, które wymagają połączenia z bazą danych, a każdy test wymaga nieskazitelnej kopii bazy danych i wprowadza zmiany w danych. Klasycznym podejściem do tego jest resetowanie bazy danych po każdym teście za pomocą niestandardowego kodu lub narzędzi takich jak Flyway - może to być bardzo czasochłonne i oznacza, że ​​testy muszą być przeprowadzane seryjnie. Jednak w przypadku Dockera można utworzyć obraz bazy danych i uruchomić jedną instancję na test, a następnie uruchomić wszystkie testy równolegle, ponieważ wiadomo, że wszystkie będą działać na tym samym migawce bazy danych. Ponieważ testy prowadzone są równolegle iw kontenerach Docker, mogą działać jednocześnie na tym samym polu i powinny kończyć się znacznie szybciej. Spróbuj to zrobić przy użyciu pełnej maszyny wirtualnej.

Z komentarzy ...

Ciekawy! Przypuszczam, że nadal jestem zdezorientowany przez pojęcie "migawki [OS]". Jak można to zrobić bez tworzenia obrazu systemu operacyjnego?

Zobaczmy, czy potrafię to wyjaśnić. Zaczynasz od obrazu podstawowego, a następnie wprowadzasz zmiany i zatwierdzasz te zmiany za pomocą okna dokowanego i tworzy obraz. Ten obraz zawiera tylko różnice od podstawy. Jeśli chcesz uruchomić obraz, potrzebujesz również bazy, a obraz zostanie umieszczony na wierzchu bazy za pomocą warstwowego systemu plików: jak wspomniano powyżej, Docker używa AUFS. AUFS łączy ze sobą różne warstwy i dostajesz to, czego chcesz; po prostu musisz go uruchomić. Możesz dodawać coraz więcej obrazów (warstw) i nadal będzie tylko zapisywać różnice. Od Docker zazwyczaj opiera się na gotowych obrazów z rejestrrzadko zdarza się, że trzeba "zeskanować" cały system operacyjny.


2817
2018-04-16 22:35



Ken, w niektórych miejscach łączysz system operacyjny z jądrem. Wszystkie pojemniki na hoście działają pod tym samym jądrem, ale pozostałe pliki systemu operacyjnego mogą być unikalne dla każdego kontenera. - Andy
Ciekawy! Przypuszczam, że nadal jestem zdezorientowany przez pojęcie "migawki [OS]". Jak można to zrobić bez tworzenia obrazu systemu operacyjnego? - zslayton
@ murtaza52 dodają obsługę różnych systemów plików, więc odejście Aufa nie powinno stanowić problemu. Nie jestem pewien, kiedy dodana zostanie obsługa 32-bitowa, nie sądzę, że było duże zapotrzebowanie, więc lista ta jest niska, ale mogę się mylić. - Ken Cochrane
@Mike: ... który bez wątpienia był inspirowany przez Więzienia FreeBSD  HISTORY The jail utility appeared in FreeBSD 4.0. - Stefan Paletta
Dla tych, którzy zastanawiają się nad komentarzem do @ Mike'a, na który odpowiadamy, ponieważ wydaje się, że został usunięty, jest on następujący: <Brakuje tylko odniesienia do faktu, że Kontenery Linuksowe są klonem prawdziwego źródła inspiracji : Pojemniki Solaris. Już w 2004 roku ... To rewolucyjna koncepcja i świetny, świetny sposób na niedrogie, hostowane wirtualne maszyny, które są naprawdę wydajne. Joyent był pierwszym, którego znam ...> - Jeffrey 'jf' Lim


Dobre odpowiedzi. Aby uzyskać obraz reprezentujący kontener kontra VM, spójrz na poniższy rysunek.

enter image description here

Źródło: https://www.docker.com/what-container#/package_software


342
2017-10-14 18:02



<strike> O ile rozumiem, powyżej "silnika dokera" powinno być wspólne jądro Linux. Wtedy są często nawet udostępnione bin / libs. Najpierw przychodzą pojemniki / biblioteki i aplikacje, które są specyficzne dla każdego kontenera. Proszę mnie poprawić, jeśli się mylę. </ Strike> Myliłem się. Obrazy Docker współużytkują jądro z hostem, zobacz superuser.com/questions/889472/.... Jednak w celu zilustrowania unijnego systemu plików kontenerów może istnieć wspólna warstwa bibliotek / bin bezpośrednio nad silnikiem dokera. - Betamos
Mam problem z powyższym obrazkiem, ponieważ Hypervisor może być zainstalowany na gołym metalu / infrastrukturze, ale Docket nie może (jeszcze) - reza
@reza, zgadzam się, że Hypervisor może być zainstalowany na Bare metal, ale chodzi o to, że Docker jest zalecany do konteneryzacji aplikacji i jak ograniczyć lub uniknąć wirtualizacji, która nie jest potrzebna / dotyczy niektórych scenariuszy. Ken Cochrane wyjaśnia to bardziej szczegółowo stackoverflow.com/a/16048358/2478933 - manu97
To nie wyjaśnia, co jest Silnik Dockera. Bardzo abstrakcyjne zdjęcia. - kyb
Nie ma warstwy "Docker Engine" między kontenerem a jądrem, kontener to tylko proces ze specjalnymi ustawieniami jądra (przestrzenie nazw, cgroups itp.) - Paweł Prażak


Pomocne może być zrozumienie, jak wirtualizacja i kontenery działają na niskim poziomie. To oczyści wiele rzeczy.

Uwaga: Upraszczam trochę w opisywaniu poniżej. Zobacz referencje, aby uzyskać więcej informacji.

Jak wirtualizacja działa na niskim poziomie?

W tym przypadku menedżer VM przejmuje pierścień CPU 0 (lub "tryb główny" w nowszych procesorach) i przechwytuje wszystkie uprzywilejowane wywołania dokonywane przez system operacyjny gościa, aby stworzyć wrażenie, że system operacyjny gościa ma swój sprzęt. Ciekawostka: Przed 1998 rokiem nie można było tego osiągnąć w architekturze x86, ponieważ nie było sposobu na takie przechwycenie. Ludzie w VMWare byli pierwsi kto miał pomysł przepisania plików wykonywalnych w pamięci na uprzywilejowane wywołania systemu operacyjnego gościa, aby to osiągnąć.

Efektem sieci jest to, że wirtualizacja pozwala na uruchomienie dwóch zupełnie różnych systemów operacyjnych na tym samym sprzęcie. Każdy system operacyjny gościa przechodzi przez cały proces ładowania, ładowania jądra itd. Możesz mieć bardzo ścisłe zabezpieczenia, na przykład system operacyjny gościa nie może uzyskać pełnego dostępu do systemu operacyjnego hosta lub innych gości i nieporządek.

Jak pojemniki działają na niskim poziomie?

Na około 2006, ludzie, w tym niektórzy pracownicy Google, wprowadzili nową funkcję poziomu jądra o nazwie przestrzenie nazw (jednak pomysł długie przed istniały w FreeBSD). Jedną z funkcji systemu operacyjnego jest umożliwienie współdzielenia globalnych zasobów, takich jak sieć i dysk, z procesami. Co się stanie, jeśli te globalne zasoby zostaną zawinięte w przestrzeni nazw, tak aby były widoczne tylko dla tych procesów, które działają w tej samej przestrzeni nazw? Powiedzmy, że możesz zdobyć fragment dysku i umieścić go w przestrzeni nazw X, a następnie procesy działające w przestrzeni nazw Y nie mogą go zobaczyć ani uzyskać do niego dostępu. Podobnie, procesy w przestrzeni nazw X nie mają dostępu do niczego w pamięci, która jest alokowana do przestrzeni nazw Y. Oczywiście procesy w X nie widzą ani nie rozmawiają z procesami w przestrzeni nazw Y. Zapewnia to rodzaj wirtualizacji i izolacji dla zasobów globalnych. W ten sposób działa docker: każdy kontener działa we własnej przestrzeni nazw, ale używa dokładnie tego podobnie jądro jak wszystkie inne pojemniki. Izolacja dzieje się, ponieważ jądro zna przestrzeń nazw, która została przypisana do procesu, a podczas wywołań API upewnia się, że proces ten może uzyskać dostęp tylko do zasobów we własnej przestrzeni nazw.

Ograniczenia kontenerów w stosunku do VM powinny być teraz oczywiste: Nie można uruchomić zupełnie innego systemu operacyjnego w kontenerach, jak w maszynach wirtualnych. Jednak ty mogą uruchamiać różne dystrybucje systemu Linux, ponieważ udostępniają one to samo jądro. Poziom izolacji nie jest tak silny, jak w VM. W rzeczywistości istniał sposób na przejęcie hosta przez kontener "gościa" we wczesnych implementacjach. Widać również, że po załadowaniu nowego kontenera cała nowa kopia systemu operacyjnego nie uruchamia się tak, jak w VM. Wszystkie pojemniki udostępnij to samo jądro. Dlatego pojemniki są lekkie. Także w przeciwieństwie do VM, nie musisz wstępnie alokować znacznej części pamięci do kontenerów, ponieważ nie uruchamiamy nowej kopii systemu operacyjnego. Umożliwia to uruchamianie tysięcy kontenerów w jednym systemie operacyjnym podczas ich pracy w piaskownicy, co może nie być możliwe, jeśli uruchamiamy osobną kopię systemu operacyjnego we własnej maszynie wirtualnej.


298
2018-01-13 01:49



Wow, dzięki za świetne wyjaśnienie na niskim poziomie (i fakty historyczne). Szukałem tego i nie ma go powyżej. Co masz na myśli poprzez "możesz uruchamiać różne dystrybucje Linuksa, ponieważ mają one wspólne jądro."? Czy mówisz, że kontener gościa musi mieć dokładnie taką samą wersję jądra systemu Linux, czy to nie ma znaczenia? Jeśli nie ma znaczenia, czy wywołuję polecenie OS na gościu, ale jest obsługiwane tylko w jądrze gościa. Lub na przykład błąd naprawiony w jądrze gościa, ale nie w kernelu hosta. Wszyscy goście zamanifestują błąd, prawda? Mimo że goście byli załatani. - Jeach
@Jeach: kontenery nie mają własnego jądra, udostępniają / używają jednego z hostów. Nie można więc uruchamiać kontenerów, które wymagają różnych jąder na tym samym komputerze / maszynie wirtualnej. - user276648
Pytanie: piszesz, że niektórzy pracownicy Google byli zaangażowani w funkcję jądra przestrzeni nazw około 1996 r. - Google nie został założony przed 1998 r. Czy miałeś na myśli "ludzi, którzy później mogli zostać pracownikami Google'a? - Martin Gjaldbaek
@martin - dziękuję za uwagę roku 2006. Powinienem także wspomnieć, że różne typy przestrzeni nazw istniały w Linuksie od 2002 roku, ale to właśnie w 2006 roku powstały podstawy do konteneryzacji. Zaktualizowałem odpowiedź z referencją. - ShitalShah
+1 To powinna być zaznaczona odpowiedź, podczas gdy inne odpowiedzi dają pewne wyjaśnienie, tylko wyjaśnienie na niższym poziomie może wyjaśnić, jak działa ta technika, "procesy zgrupowane w ich własnej przestrzeni nazw = kontener". Dziękuję bardzo, rozumiem to teraz. - Tino Mclaren


Podoba mi się odpowiedź Kena Cochrane'a.

Ale chcę dodać dodatkowy punkt widzenia, którego tu nie omówię. Moim zdaniem Docker różni się również w całym procesie. W przeciwieństwie do maszyn wirtualnych, Docker nie jest (tylko) o optymalnym współdzieleniu zasobów sprzętu, ponadto zapewnia "system" dla aplikacji do pakowania (preferowany, ale nie konieczny, jako zestaw Microservices).

Według mnie mieści się w luce między narzędziami zorientowanymi na programistę, takimi jak rpm, pakiety debian, maven, npm + git z jednej strony, a narzędziami Ops, takimi jak Puppet, VMWare, Xen, które nazwasz ...

Dlaczego wdrażanie oprogramowania do obrazu dokowanego (jeśli jest to właściwe pojęcie) jest łatwiejsze niż wdrażanie w spójnym środowisku produkcyjnym?

Twoje pytanie zakłada pewne spójne środowisko produkcyjne. Ale jak zachować spójność?  Zastanów się nad ilością (> 10) serwerów i aplikacji, etapów w przygotowaniu. Aby zachować synchronizację, zaczniesz używać czegoś takiego jak Puppet, Chef lub własne skrypty uruchamiające, niepublikowane reguły i / lub dużo dokumentacji ... Teoretycznie serwery mogą działać bezterminowo i być całkowicie spójne i aktualne. Praktyka nie udaje się całkowicie zarządzać konfiguracją serwera, więc istnieje znaczny zakres dryfów konfiguracji i nieoczekiwanych zmian w działających serwerach.

Istnieje więc znany wzorzec, aby tego uniknąć, tzw Niezmienny serwer. Ale niezmienny wzór serwera nie był kochany. Głównie z powodu ograniczeń maszyn wirtualnych był używany przed Dockerem. Radzenie sobie z kilkoma gigabajtowymi dużymi obrazami, przenoszenie tych dużych obrazów po prostu w celu zmiany niektórych pól w aplikacji było bardzo pracochłonne. Zrozumiale...

Dzięki ekosystemowi Docker nigdy nie będziesz musiał poruszać się po gigabajtach przy "małych zmianach" (Dzięki aufs i Rejestrze) i nie musisz martwić się o utratę wydajności przez pakowanie aplikacji do kontenera Docker w środowisku wykonawczym. Nie musisz się martwić wersjami tego obrazu. I w końcu będziesz nawet w stanie odtworzyć skomplikowane środowiska produkcyjne nawet na swoim laptopie z Linuksa (nie dzwoń do mnie, jeśli nie działa w twoim przypadku;))

I oczywiście można uruchamiać kontenery dokowania w maszynach wirtualnych (to dobry pomysł). Zmniejsz obsługę administracyjną serwera na poziomie VM. Wszystkie powyższe mogą być zarządzane przez Docker.

P.S. Tymczasem Docker używa własnej implementacji "libcontainer" zamiast LXC. Ale LXC nadal nadaje się do użytku.


280
2017-09-19 16:21



Wydaje się dziwne, że zawiera git w grupie narzędzi, takich jak rpm i dpkg. Wspominam o tym, ponieważ uważam, że próby wykorzystania systemów kontroli wersji, takich jak Git, jako narzędzia do dystrybucji / pakowania, są źródłem wielu nieporozumień. - blitzen9872
nie myli się jednak, git może być użyty do zarządzania pakietami, na przykład altanka jest wewnętrznie po prostu fantazyjną biblioteką do pobierania tagów git. - roo2
aplikacje do pakowania w pojemnikach to interesujące i ważne podejście. Jednak jeśli spakowałbyś to w dockerze, byłaby to przesada, ponieważ nie byłoby prostego wsparcia dla zależności lub bibliotek współdzielonych. Właśnie to próbują osiągnąć nowe technologie pakowania, takie jak Ubuntu Snap i Flatpak for Redhat. Moim zdaniem, jedna z tych technologii pakowania wygra i stanie się przyszłością opakowań w Linuksie. - yosefrow


Docker nie jest metodologią wirtualizacji. Opiera się na innych narzędziach, które w rzeczywistości implementują wirtualizację opartą na kontenerach lub wirtualizację na poziomie systemu operacyjnego. W tym celu Docker początkowo używał sterownika LXC, a następnie został przeniesiony do biblioteki libcontainer, która jest teraz zmieniana na nazwę runc. Docker koncentruje się głównie na automatyzacji wdrażania aplikacji w kontenerach aplikacji. Kontenery aplikacji są zaprojektowane do pakowania i uruchamiania pojedynczej usługi, podczas gdy kontenery systemowe są zaprojektowane do uruchamiania wielu procesów, takich jak maszyny wirtualne. Tak więc Docker jest uważany za narzędzie do zarządzania kontenerami lub wdrażania aplikacji w systemach kontenerowych.

Aby dowiedzieć się, jak to się różni od innych wirtualizacji, przejdźmy przez wirtualizację i jej typy. Wtedy łatwiej będzie zrozumieć, jaka jest w tym różnica.

Wirtualizacja

W swojej pierwotnej postaci uznano, że jest to metoda logicznego podziału dużych systemów mainframe, aby umożliwić równoczesne uruchamianie wielu aplikacji. Jednak scenariusz drastycznie się zmienił, gdy firmy i społeczności open source były w stanie zapewnić sposób obsługi uprzywilejowanych instrukcji w taki czy inny sposób i umożliwić jednoczesne uruchomienie wielu systemów operacyjnych w jednym systemie opartym na procesorach x86.

Hypervisor

Hypervisor obsługuje tworzenie wirtualnego środowiska, w którym działają wirtualne maszyny-gości. Nadzoruje systemy gości i zapewnia, że ​​zasoby są przydzielane gościom w razie potrzeby. Hiperwizor znajduje się pomiędzy maszyną fizyczną a maszynami wirtualnymi i zapewnia usługi wirtualizacji maszynom wirtualnym. Aby go zrealizować, przechwytuje operacje systemu-gościa na maszynach wirtualnych i emuluje operację na systemie operacyjnym komputera-hosta.

Szybki rozwój technologii wirtualizacji, głównie w chmurze, spowodował dalsze korzystanie z wirtualizacji poprzez umożliwienie tworzenia wielu serwerów wirtualnych na jednym fizycznym serwerze za pomocą hypervisorów, takich jak Xen, VMware Player, KVM itp. włączenie wsparcia sprzętowego do procesorów towarowych, takich jak Intel VT i AMD-V.

Rodzaje wirtualizacji

Metoda wirtualizacji może być podzielona na kategorie w zależności od tego, jak naśladuje ona sprzęt do systemu operacyjnego gościa i emuluje środowisko operacyjne gościa. Przede wszystkim są trzy rodzaje wirtualizacji:

  • Współzawodnictwo
  • Parawirtualizacja
  • Wirtualizacja oparta na kontenerach

Współzawodnictwo

Emulacja, zwana także pełną wirtualizacją, uruchamia jądro systemu maszyn wirtualnych w całości w oprogramowaniu. Hiperwizor użyty w tym typie jest znany jako hipernadzorca typu 2. Jest instalowany na szczycie systemu operacyjnego hosta, który jest odpowiedzialny za tłumaczenie kodu jądra systemu gościa na instrukcje oprogramowania. Tłumaczenie odbywa się w całości w oprogramowaniu i nie wymaga udziału sprzętu. Emulacja umożliwia uruchamianie dowolnego niezmodyfikowanego systemu operacyjnego obsługującego emulowane środowisko. Minusem tego rodzaju wirtualizacji jest dodatkowe obciążenie zasobów systemowych, które prowadzi do spadku wydajności w porównaniu z innymi typami wirtualizacji.

Emulation

Przykłady w tej kategorii to VMware Player, VirtualBox, QEMU, Bochs, Parallels itp.

Parawirtualizacja

Parawirtualizacja, znana również jako hiperwizor typu 1, działa bezpośrednio na sprzęcie lub "bare-metal" i zapewnia usługi wirtualizacji bezpośrednio na działające na nim maszyny wirtualne. Pomaga systemowi operacyjnemu, wirtualnemu sprzętowi i prawdziwemu sprzętowi współpracować, aby osiągnąć optymalną wydajność. Te hipernadzorcy mają zazwyczaj niewielką powierzchnię i same nie wymagają dużych zasobów.

Przykłady w tej kategorii obejmują Xen, KVM itp.

Paravirtualization

Wirtualizacja oparta na kontenerach

Wirtualizacja oparta na kontenerach, znana również jako wirtualizacja na poziomie systemu operacyjnego, umożliwia wiele izolowanych egzekucji w ramach jednego jądra systemu operacyjnego. Ma najlepszą możliwą wydajność i gęstość oraz funkcje dynamicznego zarządzania zasobami. Izolowane wirtualne środowisko wykonawcze zapewniane przez tego typu wirtualizację nosi nazwę kontenera i można je postrzegać jako śledzoną grupę procesów.

Container-based virtualization

Koncepcja kontenera jest możliwa dzięki funkcji przestrzeni nazw dodanej do jądra Linux w wersji 2.6.24. Kontener dodaje swój identyfikator do każdego procesu i dodaje nowe kontrole kontroli dostępu do każdego wywołania systemowego. Jest dostępny przez klon () wywołanie systemowe umożliwiające tworzenie oddzielnych instancji wcześniejszych globalnych przestrzeni nazw.

Przestrzenie nazw mogą być używane na wiele różnych sposobów, ale najbardziej powszechnym podejściem jest utworzenie izolowanego kontenera, który nie ma widoczności lub dostępu do obiektów poza kontenerem. Procesy działające w kontenerze wydają się działać w normalnym systemie Linux, chociaż dzielą one jądro leżące u podstaw procesów zlokalizowanych w innych przestrzeniach nazw, tak samo dla innych rodzajów obiektów. Na przykład podczas korzystania z przestrzeni nazw użytkownik root w kontenerze nie jest traktowany jako root na zewnątrz kontenera, dodając dodatkowe zabezpieczenia.

Podsystem Linux Control Groups (cgroups), następny główny komponent umożliwiający wirtualizację opartą na kontenerach, służy do grupowania procesów i zarządzania ich zagregowanym wykorzystaniem zasobów. Jest powszechnie stosowany w celu ograniczenia zużycia pamięci i procesora w kontenerach. Ponieważ kontenerowy system Linux ma tylko jedno jądro, a jądro ma pełną widoczność w kontenerach, istnieje tylko jeden poziom alokacji zasobów i planowania.

Dostępnych jest kilka narzędzi do zarządzania zasobami systemu Linux, w tym LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker itd.

Kontenery a maszyny wirtualne

W przeciwieństwie do maszyny wirtualnej, kontener nie musi uruchamiać jądra systemu operacyjnego, więc kontenery mogą być tworzone w czasie krótszym niż sekunda. Ta funkcja sprawia, że ​​wirtualizacja oparta na kontenerach jest wyjątkowa i pożądana niż inne metody wirtualizacji.

Ponieważ wirtualizacja oparta na kontenerach dodaje niewielki lub żaden narzut do komputera hosta, wirtualizacja oparta na kontenerach ma prawie natywną wydajność

W przypadku wirtualizacji opartej na kontenerach nie jest wymagane żadne dodatkowe oprogramowanie, w przeciwieństwie do innych wirtualizacji.

Wszystkie kontenery na hoście współdzielą program planujący hosta, oszczędzając tym samym dodatkowe zasoby.

Stany kontenerów (obrazy Docker lub LXC) mają niewielki rozmiar w porównaniu do obrazów maszyn wirtualnych, więc obrazy kontenerów można łatwo dystrybuować.

Zarządzanie zasobami w kontenerach odbywa się za pośrednictwem cgroups. Cgroups nie pozwala kontenerom na zużywanie większej ilości zasobów niż przydzielone im. Jednak od tej pory wszystkie zasoby hosta są widoczne na maszynach wirtualnych, ale nie można ich używać. Można to osiągnąć przez uruchomienie top lub htop na pojemnikach i maszynie hostującej w tym samym czasie. Dane wyjściowe we wszystkich środowiskach będą wyglądały podobnie.


124
2018-04-02 00:55



Bardzo dobra odpowiedź. Czy mogę zapytać, skąd wziąłeś te diagramy? Oryginalny artykuł / książka, czyli. - Harry
Stworzyłem te diagramy za pomocą Rysunków Google. Nadal mam te na moim koncie Google Drawings. - Ashish Bista
A tekst? Jakie jest oryginalne źródło tekstu dla tej odpowiedzi? - L0j1k
@Sheljohn Pierwsza wersja tej odpowiedzi została skopiowana z innego źródła dosłownie bez przypisania. - L0j1k
@AshishBista Musisz przypisać / połączyć źródło, jeśli zamierzasz używać tekstu dosłownie skądinąd. - L0j1k


W tym poście zamierzamy narysować kilka linii różnic między maszynami wirtualnymi a LXC. Najpierw je zdefiniuj.

VM:

Maszyna wirtualna emuluje fizyczne środowisko komputerowe, ale żądania dotyczące procesora, pamięci, dysku twardego, sieci i innych zasobów sprzętowych są zarządzane przez warstwę wirtualizacji, która tłumaczy te żądania na podstawowy fizyczny sprzęt.

W tym kontekście maszyna wirtualna jest wywoływana jako gość, a środowisko, na którym działa, nazywa się hostem.

LXCs:

Linux Containers (LXC) to funkcje na poziomie systemu operacyjnego, które umożliwiają uruchamianie wielu izolowanych kontenerów systemu Linux na jednym hoście sterującym (host LXC). Linux Containers są lekką alternatywą dla maszyn wirtualnych, ponieważ nie wymagają hipernadzorców. Virtualbox, KVM, Xen itp.

Teraz, dopóki nie zostaniesz odurzony przez Alana (Zach Galifianakis - z serii Kac Vegas) i byłeś w Vegas przez ostatni rok, będziesz w pełni świadomy ogromnego zainteresowania technologią pojemników Linuksa, a jeśli będę konkretnym kontenerem Projekt, który wzbudził zainteresowanie na całym świecie w ciągu ostatnich kilku miesięcy, to - Docker prowadzący do kilku echo-opinii, że środowiska przetwarzania w chmurze powinny porzucić maszyny wirtualne (VM) i zastąpić je kontenerami ze względu na mniejszy narzut i potencjalnie lepszą wydajność.

Ale najważniejsze pytanie brzmi: czy jest to możliwe ?, czy będzie sensowne?

za. LXC są ograniczone do instancji Linuksa. Mogą to być różne smaki Linuksa (np. Kontener Ubuntu na hoście CentOS, ale nadal jest to Linux). Podobnie kontenery oparte na systemie Windows są ograniczone do instancji systemu Windows, jeśli spojrzymy na maszyny wirtualne, mają one szerszy zakres i używają hypervisors nie jesteś ograniczony do systemów operacyjnych Linux lub Windows.

b. LXC mają niskie koszty ogólne i mają lepszą wydajność w porównaniu do maszyn wirtualnych. Narzędzia a mianowicie. Docker zbudowany na barkach technologii LXC zapewnił programistom platformę do uruchamiania aplikacji, a jednocześnie umożliwił ludziom operowanie narzędziem, które pozwoli im wdrożyć ten sam kontener na serwerach produkcyjnych lub centrach danych. Próbuje sprawić, aby doświadczenie między programistą uruchamiającym aplikację, uruchamiającym i testującym aplikację i osobą operującą wdrażającą tę aplikację jest bezproblemowe, ponieważ w tym tkwi całe tarcie i celem DevOps jest rozbicie tych silosów.

Najlepszym rozwiązaniem jest więc, aby dostawcy infrastruktury w chmurze zalecali odpowiednie użycie maszyn wirtualnych i LXC, ponieważ są one dostosowane do obsługi określonych obciążeń i scenariuszy.

Rezygnacja z maszyn wirtualnych nie jest obecnie możliwa. Tak więc obie maszyny wirtualne i LXC mają swoje własne indywidualne znaczenie.


118
2017-08-26 07:46



Twoja część "b" powyżej jest dokładnie tym, co Dockerowie mówili o tej technologii. To ma na celu rozwój i zadania wdrażania są łatwiejsze. I na podstawie mojego doświadczenia jako dev i sysop, muszę się zgodzić. - WineSoaked
To dość abstrakcyjna odpowiedź. Kiedy używamy / nie używamy Dockera, potrzebujemy przypadków użycia. Oto jest pytanie. Każdy może znaleźć to, co Docker jest podobny, ale tylko nieliczni mogą wyjaśnić na podstawie rzeczywistych scenariuszy. - Ivan Voroshilin
czy możesz wyjaśnić część "a". Język nie jest zbyt jasny. - aamir
dokowanie jest teraz wprowadzane do świata okien, ponieważ nie jest już zależne od LXC: blogs.msdn.com/b/nzdev/archive/2015/06/02/... proszę mnie poprawić, jeśli źle zrozumiałem odpowiedzi tutaj - bubakazouba
Trudno mi zrozumieć "(np. kontener Ubuntu na hoście Centos, ale wciąż jest to Linux)" część kontenerów. Sposób, w jaki to rozumiem, polega na tym, że kontenery współdzielą jądro hosta. Jeśli mam maszynę wirtualną hosta z jądrem Linux 4.6, na przykład, mając kilka maszyn wirtualnych gościa z jądrem systemu Linux 2.4, 2.6, 3.2, 4.1 i 4.4. Jeśli wykonam komendy specyficzne dla tego jądra, otrzymam zachowanie jądra gościa (a nie hosta). Ale jeśli moje wirtualne maszyny wirtualne są teraz kontenerami, czy wykonane polecenie zostanie określone przez jądro hosta? - Jeach


Większość odpowiedzi tutaj mówi o maszynach wirtualnych. Zamierzam udzielić odpowiedzi na jedno pytanie, które pomogło mi w ciągu ostatnich kilku lat używania Dockera. To jest to:

Docker jest po prostu fantazyjnym sposobem uruchomienia procesu, a nie maszyny wirtualnej.

Teraz, pozwól mi wyjaśnić nieco więcej o tym, co to znaczy. Maszyny wirtualne są ich własną bestią. Mam ochotę wyjaśnić, co Doker pomoże ci to zrozumieć bardziej niż wyjaśnienie, czym jest maszyna wirtualna. Zwłaszcza, że ​​istnieje wiele dobrych odpowiedzi, mówiących dokładnie, co ktoś ma na myśli mówiąc "maszyna wirtualna". Więc...

Kontener Docker to tylko proces (i jego dzieci), który jest podzielony na sekcje za pomocą cgroups wewnątrz jądra systemu hosta z pozostałych procesów. Możesz faktycznie zobaczyć procesy kontenera Docker, uruchamiając ps aux na hoście. Na przykład początek apache2 "w kontenerze" właśnie się zaczyna apache2 jako specjalny proces na hoście. Został on po prostu podzielony na inne procesy na maszynie. Ważne jest, aby pamiętać, że Twoje pojemniki nie istnieją poza okresem twojego procesu kontenerowego. Kiedy twój proces umiera, twój pojemnik umiera. To dlatego, że Docker zastępuje pid 1 wewnątrz swojego pojemnika z aplikacją (pid 1 jest zwykle systemem inicjującym). Ten ostatni punkt o pid 1 to bardzo ważne.

Jeśli chodzi o system plików używany przez każdy z tych procesów kontenerowych, używa go Docker UnionFS-pobrane obrazy, które pobierasz podczas wykonywania docker pull ubuntu. Każdy "obraz" to tylko seria warstw i powiązanych metadanych. Koncepcja warstw jest tutaj bardzo ważna. Każda warstwa jest po prostu zmianą z warstwy pod nią. Na przykład, po usunięciu pliku w pliku Docker podczas budowania kontenera Docker, właśnie tworzysz warstwę na wierzchu ostatniej warstwy, która mówi "ten plik został usunięty". Nawiasem mówiąc, dlatego można usunąć duży plik z systemu plików, ale obraz nadal zajmuje taką samą ilość miejsca na dysku. Plik nadal tam jest, w warstwach pod bieżącym. Warstwy same w sobie są tylko paczkami plików. Możesz to przetestować przy pomocy docker save --output /tmp/ubuntu.tar ubuntui wtedy cd /tmp && tar xvf ubuntu.tar. Następnie możesz się rozejrzeć. Wszystkie te katalogi, które wyglądają jak długie hasze, są w rzeczywistości poszczególnymi warstwami. Każdy zawiera pliki (layer.tar) i metadane (json) z informacjami o tej konkretnej warstwie. Te warstwy po prostu opisują zmiany w systemie plików, które są zapisywane jako warstwa "na wierzchu" jej pierwotnego stanu. Podczas odczytu danych "bieżących" system plików odczytuje dane tak, jakby patrzyły tylko na najwyższe warstwy zmian. Dlatego wydaje się, że plik został usunięty, mimo że nadal istnieje na "poprzednich" warstwach, ponieważ system plików patrzy tylko na najwyższe warstwy. Dzięki temu zupełnie inne pojemniki mogą współdzielić swoje warstwy systemu plików, mimo że niektóre istotne zmiany mogły nastąpić w systemie plików na najwyższych warstwach w każdym kontenerze. To może zaoszczędzić mnóstwo miejsca na dysku, gdy twoje pojemniki dzielą swoje podstawowe warstwy obrazu. Jednak po zamontowaniu katalogów i plików z hosta do kontenera za pomocą woluminów, te woluminy "omijają" UnionFS, więc zmiany nie są przechowywane w warstwach.

Praca w sieci w Docker odbywa się za pomocą mostu ethernetowego (tzw docker0 na hoście) i wirtualne interfejsy dla każdego kontenera na hoście. Tworzy wirtualną podsieć w docker0 aby twoje kontenery komunikowały się "między". Istnieje wiele opcji tworzenia sieci, w tym tworzenie niestandardowych podsieci dla kontenerów i możliwość "udostępniania" stosu sieciowego hosta dla kontenera w celu bezpośredniego dostępu.

Docker porusza się bardzo szybko. Jego dokumentacja to jedna z najlepszych dokumentacji, jakie widziałem. Jest ogólnie dobrze napisany, zwięzły i dokładny. Zalecam sprawdzenie dostępnej dokumentacji, aby uzyskać więcej informacji, i zaufaj dokumentacji dotyczącej wszystkiego, co przeczytałeś online, w tym Stack Overflow. Jeśli masz konkretne pytania, gorąco polecam dołączenie #docker na IRC Freenode i pytając tam (możesz nawet użyć Freenode internetowy czat za to!).


91
2018-04-04 02:35



"Docker to po prostu ciekawy sposób na uruchomienie procesu, a nie maszyny wirtualnej". to świetne podsumowanie, dzięki! - mkorman
Dzięki! Uznanie za to wychodzi na programmerq od #docker kanał na IRC Freenode. - L0j1k
To jest świetna odpowiedź. Spodobała mi się analogia. - Teoman shipahi


Docker hermetyzuje aplikację ze wszystkimi jej zależnościami, a wirtualizator zawiera w sobie O.S. która może uruchamiać dowolne aplikacje, które normalnie mogą uruchamiać na maszynie z gołym metalem.


57
2017-08-27 18:25



Uczę się o LXC, popraw mnie, jeśli się mylę, ale może to być jakiś virtualenv? ale oczywiście szerszy, nie tylko napisany w okrężnym języku do pythona - NeoVe
Ta odpowiedź jest najlepsza. To proste i idzie prosto do punktu. Teraz, gdy ktoś ma podstawowe pojęcie o tym, co mogą zrobić LXC i Virtualizery, szczegóły z innego czytania będą miały sens. - Phil
@Phil To zrobiło po przeczytaniu szczegółowych odpowiedzi powyżej. - johnny


Obaj są bardzo różni. Docker jest lekki i używa LXC / libcontainer (który bazuje na przestrzeni nazw jądra i cgroups) i nie ma emulacji maszyny / sprzętu, takiej jak hypervisor, KVM. Xen, które są ciężkie.

Docker i LXC są przeznaczone raczej do piaskownicy, kontenerów i izolacji zasobów. Korzysta z interfejsu API hosta (obecnie tylko jądro Linux), który zapewnia przestrzeń nazw dla IPC, NS (mount), sieci, PID, UTS itp.

A co z pamięcią, we / wy, procesorem itp.? Jest to kontrolowane za pomocą cgroups, w których można tworzyć grupy z określoną specyfikacją / ograniczeniem zasobów (procesora, pamięci itp.) I umieszczać tam swoje procesy. Na szczycie LXC, Docker zapewnia backend pamięci (http://www.projectatomic.io/docs/filesystems/), na przykład, system plików złącz typu union, w którym można dodawać warstwy i współdzielić warstwy między różnymi obszarami nazw montowania.

Jest to potężna funkcja, w której obrazy podstawowe są zwykle tylko do odczytu i tylko wtedy, gdy kontener modyfikuje coś w warstwie, zapisze coś na partycji do odczytu i zapisu (kopie przy zapisie). Zapewnia także wiele innych programów typu wrapper, takich jak rejestrowanie i wersjonowanie obrazów.

Przy normalnym LXC musisz dostarczyć trochę rootfów lub udostępnić rootfs i kiedy je udostępnisz, a zmiany zostaną odzwierciedlone w innych kontenerach. Ze względu na wiele z tych dodatkowych funkcji, Docker jest bardziej popularny niż LXC. LXC jest popularny w środowiskach osadzonych w celu implementacji zabezpieczeń wokół procesów narażonych na zewnętrzne elementy, takie jak sieć i interfejs użytkownika. Docker jest popularny w środowiskach multi-tenancy w chmurze, gdzie spodziewane jest spójne środowisko produkcyjne.

Zwykła maszyna wirtualna (na przykład VirtualBox i VMware) korzysta z hiperwizora, a powiązane technologie mają dedykowane oprogramowanie układowe, które staje się pierwszą warstwą dla pierwszego systemu operacyjnego (host OS lub gościa systemu operacyjnego 0) lub oprogramowania działającego na systemie hosta w celu zapewnia emulację sprzętową, taką jak CPU, USB / akcesoria, pamięć, sieć itp., do systemów-gości. Maszyny wirtualne nadal są (od 2015 r.) Popularne w środowisku z wieloma dzierżawionymi zabezpieczeniami.

Docker / LXC można prawie uruchomić na dowolnym tanim sprzęcie (mniej niż 1 GB pamięci jest również w porządku, o ile masz nowsze jądro), a normalne maszyny wirtualne potrzebują co najmniej 2 GB pamięci itd., Aby zrobić z nim coś sensownego . Jednak obsługa Dockera w systemie hosta nie jest dostępna w systemie operacyjnym, takim jak Windows (stan na listopad 2014 r.), Ponieważ podobnie jak typy maszyn wirtualnych mogą być uruchamiane w systemach Windows, Linux i Mac.

Oto zdjęcie z docker / rightscale: Here is a pic from rightscale


45
2017-11-03 17:44





1. Lekki

Jest to prawdopodobnie pierwsze wrażenie dla wielu uczniów dokerów.

Po pierwsze, obrazy w doku są zwykle mniejsze niż obrazy VM, ułatwiają budowanie, kopiowanie, udostępnianie.

Po drugie, kontenery Docker mogą zostać uruchomione w ciągu kilku milisekund, a VM rozpocznie się w kilka sekund.

2. Warstwowy system plików

To kolejna kluczowa cecha Docker. Obrazy mają warstwy, a różne obrazy mogą współdzielić warstwy, dzięki czemu jest jeszcze bardziej oszczędny i szybszy w budowie.

Jeśli wszystkie pojemniki używają Ubuntu jako swoich podstawowych obrazów, nie każdy obraz ma swój własny system plików, ale ma te same podkreślone pliki ubuntu i różni się tylko ich własnymi danymi aplikacji.

3. Wspólne jądro systemu operacyjnego

Pomyśl o kontenerach jako o procesach!

Wszystkie kontenery uruchomione na hoście są w istocie zbiorem procesów z różnymi systemami plików. Korzystają z tego samego jądra systemu operacyjnego, tylko hermetyzują bibliotekę systemową i zależności.

Jest to dobre w większości przypadków (nie ma żadnego dodatkowego jądra systemu operacyjnego), ale może stanowić problem, jeśli między kontenerami wymagane są ścisłe izolacje.

Dlaczego jest to ważne?

Wszystko to wydaje się być poprawą, a nie rewolucją. Dobrze, akumulacja ilościowa prowadzi do jakościowej transformacji.

Pomyśl o wdrożeniu aplikacji. Jeśli chcemy wdrożyć nowe oprogramowanie (usługę) lub zaktualizować je, lepiej jest zmienić pliki konfiguracyjne i procesy zamiast tworzyć nową maszynę wirtualną. Ponieważ tworzenie maszyny wirtualnej ze zaktualizowaną usługą, jej testowanie (udział między Dev & QA), wdrożenie do produkcji zajmuje wiele godzin, a nawet dni. Jeśli coś pójdzie nie tak, musisz zacząć od nowa, marnując jeszcze więcej czasu. Tak więc, użyj narzędzia do zarządzania konfiguracją (kukiełka, słona sól, szef kuchni itp.), Aby zainstalować nowe oprogramowanie, zalecane jest pobieranie nowych plików.

Jeśli chodzi o dokowanie, niemożliwe jest użycie nowo utworzonego kontenera dokera do zastąpienia starego. Utrzymanie jest o wiele łatwiejsze: budowanie nowego obrazu, udostępnianie go za pomocą kontroli jakości, testowanie go, wdrożenie zajmuje tylko minuty (jeśli wszystko jest zautomatyzowane), godziny w najgorszym przypadku. To się nazywa niezmienna infrastruktura: nie utrzymuj (aktualizuj) oprogramowania, zamiast tego twórz nowe.

Zmienia sposób dostarczania usług. Chcemy aplikacji, ale musimy utrzymywać maszyny wirtualne (co jest uciążliwe i ma niewiele wspólnego z naszymi aplikacjami). Docker skupia się na aplikacjach i wygładza wszystko.


23
2017-08-10 04:25



To powinna być akceptowana odpowiedź! - Sharan Duggirala


W związku z:-

"Dlaczego wdrażanie oprogramowania do obrazu w doku jest łatwiejsze niż proste   wdrażanie w spójnym środowisku produkcyjnym? "

Większość oprogramowania jest wdrażana w wielu środowiskach, zazwyczaj co najmniej w trzech z następujących:

  1. Indywidualny komputer (y) dla programistów
  2. Wspólne środowisko programistów
  3. Indywidualny komputer testowy
  4. Wspólne środowisko testowe
  5. Otoczenie QA
  6. Środowisko UAT
  7. Testowanie obciążenia / wydajności
  8. Animacja na żywo
  9. Produkcja
  10. Archiwum

Należy również wziąć pod uwagę następujące czynniki:

  • Programiści, a nawet testerzy, będą mieli albo subtelne, albo bardzo różne konfiguracje komputerów PC, ze względu na charakter pracy
  • Deweloperzy mogą często rozwijać się na komputerach PC, które nie podlegają kontroli korporacyjnych lub biznesowych norm dotyczących standaryzacji (np. Freelancerzy, którzy rozwijają się na własnych maszynach (często zdalnie) lub współtwórcy projektów open source, którzy nie są "zatrudnieni" lub "zakontraktowani" w celu skonfigurowania swoich komputerów. droga)
  • Niektóre środowiska będą składać się ze stałej liczby wielu maszyn w zbalansowanej konfiguracji obciążenia
  • Wiele środowisk produkcyjnych będzie dynamicznie (lub "elastycznie") tworzonych i niszczonych serwerów w zależności od poziomu ruchu

Jak widać ekstrapolowana całkowita liczba serwerów dla organizacji rzadko występuje w pojedynczych liczbach, bardzo często jest w potrójnych liczbach i może być znacznie wyższa.

To wszystko oznacza, że ​​tworzenie spójnych środowisk w pierwszej kolejności jest wystarczająco trudne ze względu na samą objętość (nawet w scenariuszu z zielonym polem), ale utrzymanie ich w zgodności jest praktycznie niemożliwe biorąc pod uwagę dużą liczbę serwerów, dodawanie nowych serwerów (dynamicznie lub ręcznie), automatyczne aktualizacje od producentów / dostawców, producentów oprogramowania antywirusowego, dostawców przeglądarek itp., ręczne instalowanie oprogramowania lub zmiany konfiguracji wykonywane przez programistów lub techników serwerów itp. Pozwólcie, że powtórzę - wirtualnie (nie gra słów) nie jest w stanie zachować spójności środowiska (w porządku, dla purysty można to zrobić, ale wymaga to ogromnej ilości czasu, wysiłku i dyscypliny, dlatego właśnie maszyny wirtualne i pojemniki (np. Docker) zostały wymyślone w pierwszej kolejności).

Pomyśl o swoim pytaniu bardziej w ten sposób "Biorąc pod uwagę ogromną trudność utrzymania wszystkich środowisk, czy łatwiej jest wdrożyć oprogramowanie do obrazu w doku, nawet przy uwzględnieniu krzywej uczenia się?". Myślę, że odpowiedź będzie niezmiennie "tak" - ale jest tylko jeden sposób, aby się tego dowiedzieć, po tym nowym pytaniu na Stack Overflow.


16
2017-10-15 11:25



Tak więc, jeśli wdrażam obraz dokowania z 15 różnymi polami, które mają różne kombinacje systemów operacyjnych / wersji, wszystkie moje obrazy dokowane będą działać tak samo? - Teoman shipahi