19 Pytanie: Czym różni się Docker od maszyny wirtualnej? [Zamknięte]

pytanie utworzone w Tue, Aug 28, 2018 12:00 AM

Ciągle czytam dokumentację Dockera , aby zrozumieć różnicę między Dockerem a pełną maszyną wirtualną. W jaki sposób udaje mu się zapewnić pełny system plików, izolowane środowisko sieciowe itp., Nie będąc tak ciężkim?

Dlaczego wdrażanie oprogramowania do obrazu Docker (jeśli jest to właściwy termin) jest łatwiejsze niż po prostu wdrożenie w spójnym środowisku produkcyjnym?

    
3367
  1. Analiza wydajności Docker vs KVM: bodenr.blogspot.com/2014/05/…
    2016-04-13 17: 39: 02Z
  2. Jeśli szukasz różnicy między ich obrazami - stackoverflow.com/questions/29096967/…
    2017-04-05 06: 51: 02Z
  3. Docker nie jest maszyną wirtualną - jest narzędziem do zarządzania konfiguracją.
    2017-05-25 05: 19: 33Z
  4. Możesz znaleźć interesujące fakty dotyczące implementacji i izolacji kontenerów w doger. io .
    2017-07-07 08: 50: 06Z
  5. W prostych słowach: VM - > trzy wirtualne warstwy muszą działać, aby pozwolić na uruchomienie aplikacji, jeśli chcesz wirtualizacji serwera OK, ale jeśli chcesz uruchomić tylko aplikację internetową, nie jest najlepszym rozwiązaniem. DOCKER - > Tylko jedna warstwa między prawdziwym procesorem a aplikacją internetową. Bardziej wydajne i lepsze klonowanie /dublowanie, jeśli musisz uruchamiać swoją aplikację internetową do wirtualizacji tych, które polecam
    2018-07-21 09: 18: 24Z
19 odpowiedzi                              19                         

Docker pierwotnie używał kontenerów LinuX (LXC), ale później przełączył się na runC (wcześniej znany jako libcontainer ), który działa w tym samym systemie operacyjnym, co jego host. Pozwala to na współdzielenie wielu 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ą scalane razem. Można mieć wspólne części systemu operacyjnego jako tylko do odczytu (i współużytkowane przez wszystkie kontenery), a następnie nadać każdemu kontenerowi własny uchwyt do pisania.

Powiedzmy, że masz obraz kontenera o pojemności 1 GB; Jeśli chcesz użyć pełnej maszyny wirtualnej, musisz mieć 1 GB razy x żądaną liczbę maszyn wirtualnych. Dzięki Dockerowi i AuFS możesz udostępnić większość 1 GB pomiędzy wszystkimi kontenerami, a jeśli masz 1000 kontenerów, nadal możesz mieć tylko trochę ponad 1 GB miejsca na kontenery OS (zakładając, że wszystkie działają na tym samym obrazie systemu operacyjnego) .

Pełny zwirtualizowany system otrzymuje własny zestaw zasobów przydzielonych do niego i minimalizuje udostępnianie. Dostajesz więcej izolacji, ale jest ona znacznie cięższa (wymaga więcej zasobów). Dzięki Dockerowi masz mniej izolacji, ale pojemniki są lekkie (wymagają mniej zasobów). Możesz więc łatwo uruchomić tysiące kontenerów na hoście, a nawet nie mrugnie. Spróbuj zrobić to z Xenem i chyba, że ​​masz naprawdę dużego hosta, nie sądzę, aby było to możliwe.

W pełni zwirtualizowany system zwykle zajmuje kilka minut, podczas gdy kontenery Docker /LXC /runC zajmują sekundy, a często nawet mniej niż sekundę.

Istnieją zalety i wady dla każdego typu systemu zwirtualizowanego. Jeśli chcesz mieć pełną izolację z gwarantowanymi zasobami, możesz wybrać pełną maszynę wirtualną. Jeśli typo prostu chcę odizolować procesy od siebie i chcesz uruchomić ich mnóstwo na rozsądnie dużym hoście, a Docker /LXC /runC wydaje się być dobrym rozwiązaniem.

Aby uzyskać więcej informacji, sprawdź ten zestaw postów na blogu , który dobrze wyjaśnia, jak działa LXC.

  

Dlaczego wdrażanie oprogramowania do obrazu dokera (jeśli jest to właściwy termin) jest łatwiejsze niż po prostu wdrożenie w spójnym środowisku produkcyjnym?

Wdrożenie spójnego środowiska produkcyjnego jest łatwiejsze niż powiedziane. Nawet jeśli używasz narzędzi takich jak Chef i Puppet , zawsze są aktualizacje OS i inne rzeczy, które zmieniają się między hostami a środowiskami.

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

To jest świetne do testowania; powiedzmy, że masz tysiące testów, które muszą połączyć się z bazą danych, a każdy test wymaga nieskazitelnej kopii bazy danych i dokona zmian w danych. Klasycznym podejściem jest zresetowanie bazy danych po każdym teście za pomocą kodu niestandardowego lub narzędzi takich jak Flyway - może to być bardzo czasochłonne i oznacza, że ​​testy muszą być wykonywane seryjnie. Jednak przy pomocy 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 tej samej migawce bazy danych. Ponieważ testy przebiegają równolegle i w kontenerach Docker, mogą działać na tym samym polu w tym samym czasie i kończyć się znacznie szybciej. Spróbuj to zrobić przy użyciu pełnej maszyny wirtualnej.

Z komentarzy ...

  

Ciekawe! Przypuszczam, że nadal jestem zdezorientowany pojęciem „migawki systemu operacyjnego”. W jaki sposób można to zrobić bez tworzenia obrazu systemu operacyjnego?

Zobaczmy, czy mogę wyjaśnić. Zaczynasz od obrazu podstawowego, a następnie dokonujesz zmian i zatwierdzasz te zmiany za pomocą okna dokowanego i tworzysz obraz. Ten obraz zawiera tylko różnice względem bazy. Jeśli chcesz uruchomić swój obraz, potrzebujesz również bazy, a twój obraz zostanie nałożony na bazę za pomocą warstwowego systemu plików: jak wspomniano powyżej, Docker używa AUFS. AUFS łączy różne warstwy i dostajesz to, czego chcesz; wystarczy go uruchomić. Możesz dodawać coraz więcej obrazów (warstw) i nadal będą zapisywać tylko różnice. Ponieważ Docker zazwyczaj buduje na gotowych obrazach z rejestru , rzadko musisz „migać” cały system operacyjny sam.

    
3173
2017-03-11 17: 15: 08Z
  1. Ken, w niektórych miejscach łączysz system operacyjny z jądrem. Wszystkie kontenery na hoście działają pod tym samym jądrem, ale pozostałe pliki systemu operacyjnego mogą być unikalne dla każdego kontenera.
    2013-04-16 23: 44: 47Z
  2. Ciekawe! Przypuszczam, że nadal jestem zdezorientowany pojęciem „migawki systemu operacyjnego”. W jaki sposób można to zrobić bez tworzenia obrazu systemu operacyjnego?
    2013-04-19 15: 03: 24Z
  3. @ murtaza52 dodają obsługę różnych systemów plików, więc odejście Aufs nie powinno być problemem. Nie jestem pewien, czy zostanie dodana obsługa 32-bitowa, nie sądzę, aby wystąpił silny popyt, więc jest on niski na liście priorytetów, ale mogę się mylić.
    2013-05-20 12: 18: 43Z
  4. @ Mike: ... który bez wątpienia został zainspirowany przez 2013-09-13 17: 17: 01Z
  5. Dla tych, którzy zastanawiają się, na jaki komentarz @ Mike'a odpowiadamy, ponieważ wydaje się, że został usunięty, jest to: < Brakuje tylko jednej odniesienie do faktu, że Kontenery Linuksa są klonem tźródło inspiracji: pojemniki Solaris. W 2004 roku ... To rewolucyjna koncepcja i świetny, świetny sposób na niedrogie, hostowane maszyny wirtualne, które są naprawdę wydajne. Joyent był pierwszym, którego znam ... >
    2014-08-09 06: 13: 51Z

Dobre odpowiedzi. Aby uzyskać reprezentację obrazu kontenera względem maszyny wirtualnej, spójrz na poniższy.

 wprowadź opis obrazu tutaj>> </a> </p>

<p> <a href= Źródło

    
472
2018-11-07 12: 12: 11Z
  1. < strike > O ile mi wiadomo, nad „silnikiem dokera” powinno znajdować się wspólne jądro Linuksa. Potem są nawet wspólne kosze /libs. Najpierw pojawiają się bin /libs i aplikacje specyficzne dla każdego kontenera. Popraw mnie, jeśli się mylę. &Lt; /strike > Myliłem się. Obrazy dokerów współdzielą jądro z hostem, zobacz superuser.com/questions/889472/… . Aby jednak zilustrować system plików unii kontenerów, może istnieć wspólna warstwa bibliotek /kontenerów bezpośrednio nad silnikiem dokowania.
    2015-12-05 01: 33: 38Z
  2. Mam problem z powyższym obrazem, ponieważ Hypervisor może być zainstalowany na nagim metalu /infrastrukturze, ale Docket nie może (jeszcze)
    2016-06-10 11: 50: 17Z
  3. @ reza, zgadzam się Hypervisor może być zainstalowany na Bare metal, ale chodzi o to, że Docker jest zalecany do kontenerowania aplikacji i jak ograniczyć lub uniknąć wirtualizacji, która nie jest potrzebne /odpowiednie dla niektórych scenariuszy. Ken Cochrane wyjaśnia to bardziej szczegółowo stackoverflow.com/a/16048358/2478933
    2016-06-10 17: 32: 21Z
  4. To nie wyjaśnia, czym jest Docker Engine . Bardzo abstrakcyjne zdjęcia.
    2017-05-15 13: 22: 45Z
  5. Nie ma warstwy „Docker Engine” pomiędzy kontenerem a jądrem, kontener jest tylko procesem ze specjalnymi ustawieniami w jądrze (przestrzenie nazw, cgroups itp.)
    2017-06-14 16: 54: 22Z

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

Uwaga: Trochę upraszczam opisując poniżej. Zobacz referencje, aby uzyskać więcej informacji.

Jak działa wirtualizacja na niskim poziomie?

W tym przypadku menedżer maszyn wirtualnych przejmuje pierścień procesora 0 (lub „tryb główny” w nowszych procesorach) i przechwytuje wszystkie uprzywilejowane wywołania systemu gościa, aby stworzyć iluzję, że system operacyjny gościa ma własny sprzęt. Ciekawostka: przed 1998 r. Uznano, że niemożliwe jest osiągnięcie tego w architekturze x86, ponieważ nie było sposobu na przechwycenie tego typu. Ludzie z VMWare byli pierwszymi , który wpadł na pomysł przepisania wykonywalnych bajtów w pamięci na uprzywilejowane wywołania systemu gościa, aby to osiągnąć.

Efektem netto jest to, że wirtualizacja pozwala na uruchomienie dwóch całkowicie różnych systemów operacyjnych na tym samym sprzęcie. Każdy system gościa przechodzi cały proces ładowania początkowego, ładowania jądra itp. Możesz mieć bardzo ograniczone bezpieczeństwo, na przykład system operacyjny gościa nie może uzyskać pełnego dostępu do systemu operacyjnego hosta lub innych gości i zepsuć wszystko.

Jak działają pojemniki na niskim poziomie?

Wokół 2006 ,ludzie, w tym niektórzy pracownicy Google, wdrożyli nową funkcję poziomu jądra o nazwie przestrzenie nazw (jednak pomysł długi przed istniało w FreeBSD ). Jedną z funkcji systemu operacyjnego jest umożliwienie udostępniania globalnych zasobów, takich jak sieć i dysk, procesom. Co jeśli te globalne zasoby zostały zapakowane w przestrzenie nazw, aby były widoczne tylko dla tych procesów, które działają w tej samej przestrzeni nazw? Powiedzmy, że możesz pobrać 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 przydzielonej 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 globalnych zasobów. W ten sposób działa doker: każdy kontener działa we własnej przestrzeni nazw, ale używa dokładnie jądra tego samego jak wszystkie inne pojemniki. Izolacja ma miejsce, ponieważ jądro zna przestrzeń nazw przypisaną do procesu i podczas wywołań API zapewnia, że ​​proces może uzyskać dostęp tylko do zasobów we własnej przestrzeni nazw.

Ograniczenia kontenerów vs VM powinny być teraz oczywiste: nie można uruchomić zupełnie innego systemu operacyjnego w kontenerach, takich jak maszyny wirtualne. Jednak możesz uruchamiać różne dystrybucje Linuksa, ponieważ korzystają z tego samego jądra. Poziom izolacji nie jest tak silny jak w maszynie wirtualnej. W rzeczywistości istniał sposób, aby kontener „gościa” przejął hosta we wczesnych implementacjach. Widać również, że po załadowaniu nowego kontenera cała nowa kopia systemu operacyjnego nie zaczyna się tak, jak w VM. Wszystkie kontenery udostępniają to samo jądro . Dlatego pojemniki są lekkie. W przeciwieństwie do maszyn wirtualnych nie musisz wstępnie przydzielać znacznej części pamięci do kontenerów, ponieważ nie uruchomiliśmy nowej kopii systemu operacyjnego. Umożliwia to uruchamianie tysięcy kontenerów w jednym systemie operacyjnym podczas ich piaskowania, co może nie być możliwe, jeśli uruchamiamy oddzielną kopię systemu operacyjnego we własnej maszynie wirtualnej.

    
414
2017-10-24 11: 19: 22Z
  1. Wow, dzięki za wspaniałe wyjaśnienie na niskim poziomie (i fakty historyczne). Szukałem tego i nie znalazłem go powyżej. Co masz na myśli mówiąc „możesz uruchomić różne dystrybucje Linuksa, ponieważ korzystają z tego samego jądra.” ? Czy mówisz, że kontener gościa musi mieć dokładnie taką samą wersję jądra Linuksa lub że nie ma to znaczenia? Jeśli to nie ma znaczenia, jeśli wywołam polecenie systemu operacyjnego na gościu, ale jest ono obsługiwane tylko w jądrze gościa. Lub na przykład błąd naprawiony w jądrze gościa, ale nie w jądrze hosta. Wszyscy goście manifestują błąd, prawda? Nawet jeśli goście zostali załatani.
    2016-06-09 21: 23: 59Z
  2. @ Jeach: kontenery nie mają własnego jądra, dzielą się /używają jednego z hostów. Nie można więc uruchamiać kontenerów, które wymagają różnych jąder na tej samej maszynie /maszynie wirtualnej.
    2016-09-26 02: 08: 24Z
  3. Pytanie: Piszecie, że niektórzy pracownicy Google byli zaangażowani w funkcję jądra przestrzeni nazw około 1996 roku - jeszcze Google nie zostało założone aż do 1998 roku. kto później zostanie pracownikami Google?
    2016-10-17 08: 44: 26Z
  4. @ martin - dziękuję za zauważenie roku 2006. Powinienem też wspomnieć, że różne typy przestrzeni nazw istniały w Linuksie od 2002 roku, ale to była praca w 2006 roku. grunt do kontenerowania. Zaktualizowałem odpowiedź z odwołaniem.
    2016-10-17 18: 28: 22Z
  5. + 1 To powinna być zaznaczona odpowiedź, podczas gdy inne odpowiedzi dają pewne wyjaśnienie, tylko oddolne wyjaśnienie niskiego poziomu może wyjaśnić, jak działa ta technika, „procesy zgrupowane we własnej przestrzeni nazw = kontener ”. Dziękuję bardzo, teraz to rozumiem.
    2017-03-05 22: 16: 20Z

Lubię odpowiedź Kena Cochrane'a.

Chcę jednak dodać dodatkowy punkt widzenia, który nie został tu szczegółowo opisany. Moim zdaniem Docker różni się także w całym procesie. W przeciwieństwie do maszyn wirtualnych, Docker nie jest (tylko) o optymalnym współużytkowaniu zasobów sprzętowych, ponadto zapewnia „system” dla aplikacji do pakowania (preferowany, ale nie konieczny, jako zestaw mikroserwisów).

Dla mnie pasuje do luki między narzędziami zorientowanymi na programistów, takimi jak rpm, pakiety Debiana , Maven , npm + Git z jednej strony i narzędzia ops, takie jak Puppet , VMware, Xen, nazwij to ...

  

Dlaczego wdrażanie oprogramowania do obrazu dokera (jeśli jest to właściwy termin) jest łatwiejsze niż po prostu wdrożenie w spójnym środowisku produkcyjnym?

Twoje pytanie zakłada pewne spójne środowisko produkcyjne. Ale jak zachować spójność? Rozważmy pewną ilość (> 10) serwerów i aplikacji, etapów w przygotowaniu.

Aby zachować synchronizację, zaczniesz używać czegoś takiego jak Puppet, Chef lub własne skrypty zaopatrzeniowe, niepublikowane reguły i /lub wiele dokumentacji ... Teoretycznie serwery mogą działać w nieskończoność i być całkowicie spójne i aktualne. Praktyka nie pozwala całkowicie zarządzać konfiguracją serwera, więc istnieje znaczny zakres dryfowania konfiguracji i nieoczekiwanych zmian w działających serwerach.

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

W ekosystemie Docker nigdy nie będziesz musiał poruszać się po gigabajtach na „małych zmianach” (dzięki aufs i Registry) i nie musisz się martwić o utratę wydajności przez pakowanie aplikacji do kontenera Docker w czasie wykonywania. Nie musisz martwić się o wersje tego obrazu.

I wreszcie będziesz nawet w stanie odtwarzać złożone środowiska produkcyjne nawet na swoim laptopie z Linuksem (nie dzwoń do mnie, jeśli nie działa w twoim przypadku;))

I oczywiście możesz uruchomić kontery Docker w maszynach wirtualnych (to dobry pomysł). Zmniejsz obsługę serwerów na poziomie maszyny wirtualnej. Wszystkim powyższym może zarządzać Docker.

P.S. Tymczasem Docker używa własnej implementacji „libcontainer” zamiast LXC. Ale LXC jest nadal użyteczny.

    
315
2018-08-28 20: 13: 25Z
  1. Wydaje się dziwne, aby dołączyć git do grupy narzędzi, takich jak rpm i dpkg. Wspominam o tym, ponieważ widzę, że próby użycia systemów kontroli wersji, takich jak git, jako narzędzia do dystrybucji /pakowania są źródłem wielu nieporozumień.
    2017-04-20 22: 12: 02Z
  2. nie myli się jednak, git może być użyty do zarządzania pakietami, bower na przykład jest wewnętrznie w zasadzie fantazyjnym cli do pobierania tagów git.
    2017-08-24 01: 21: 29Z
  3. aplikacje do pakowania w pojemnikach to interesujące i ważne podejście. Jeśli jednak spakowałeś go w oknie dokowanym, byłoby to przesadą, ponieważ nie byłoby prostego wsparcia dla zależności lub jakichkolwiek bibliotek współdzielonych. To właśnie starają się osiągnąć nowe technologie pakowania, takie jak Ubuntu Snap i Flatpak dla Redhata. Moim zdaniem jedna z tych technologii wygra i stanie się przyszłością opakowań w systemie Linux.
    2017-12-25 10: 08: 15Z
  4. @ blitzen9872 zgadzam się na to. Ale wspomniano o tym dokładnie, ponieważ tak często używano go do dystrybucji w praktyce, znowu mi się to nie podoba.
    2019-02-14 14: 37: 17Z
  5. @ yosefrow opracuj „overkill”. Sprawdź pomysł i zalety of Wzorzec „niezmiennego serwera” ma oczywiście pewne wady… Jeśli widzisz przesadę, nie używaj go…
    2019-02-14 14: 40: 04Z

Docker nie jest metodologią wirtualizacji. Opiera się na innych narzędziach, które faktycznie wdrażają wirtualizację opartą na kontenerach lub wirtualizację na poziomie systemu operacyjnego. W tym celu Docker początkowo korzystał ze sterownika LXC, a następnie przeniósł się do libcontainer, którego nazwę zmieniono na runc. Docker skupia się przede wszystkim na automatyzacji wdrażania aplikacji wewnątrz kontenerów 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 różni się od innych wirtualizacji, przejdźmy przez wirtualizację i jej typy. Wtedy łatwiej byłoby zrozumieć różnicę.

Virtualizacja

W swojej wymyślonej formie uznano ją za metodę logicznego dzielenia komputerów mainframe, aby umożliwić jednoczesne uruchamianie wielu aplikacji. Jednak scenariusz drastycznie się zmienił, gdy firmy i społeczności open source były w stanie dostarczyć metodę obsługi uprzywilejowanych instrukcji w taki czy inny sposób i umożliwić jednoczesne uruchomienie wielu systemów operacyjnych w pojedynczym systemie opartym na procesorze x86.

Hypervisor

Hiperwizor obsługuje tworzenie środowiska wirtualnego, na którym działają maszyny wirtualne gościa. Nadzoruje systemy gościa 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 dla maszyn wirtualnych. Aby to zrealizować, przechwytuje operacje systemu operacyjnego gościa na maszynach wirtualnych i emuluje operację na systemie operacyjnym komputera głównego.

Szybki rozwój technologii wirtualizacji, głównie w chmurze, spowodował dalsze wykorzystanie wirtualizacji, umożliwiając tworzenie wielu serwerów wirtualnych na jednym serwerze fizycznym z pomocą hiperwizorów, takich jak Xen, VMware Player, KVM itp. . oraz włączenie obsługi sprzętu w procesorach towarowych, takich jak Intel VT i AMD-V.

Typy wirtualizacji

Metoda wirtualizacji może być podzielona na kategorie w zależności od tego, jak naśladuje sprzęt w systemie operacyjnym gościa i emuluje środowisko operacyjne gościa. Przede wszystkim istnieją trzy typy wirtualizacji:

  • Emulacja
  • Parawirtualizacja
  • Wirtualizacja oparta na kontenerach

Emulation

Emulacja, znana również jako pełna wirtualizacja, uruchamia jądro systemu operacyjnego maszyny wirtualnej całkowicie w oprogramowaniu. Hiperwizor używany w tym typie jest znany jako hiperwizor typu 2. Jest on instalowany w górnej części systemu operacyjnego hosta, który jest odpowiedzialny za tłumaczenie kodu jądra systemu gościa na instrukcje oprogramowania. Tłumaczenie odbywa się wyłącznie w oprogramowaniu i nie wymaga zaangażowania sprzętu. Emulacja umożliwia uruchomienie dowolnego niezmodyfikowanego systemu operacyjnego, który wspiera emulowane środowisko. Wadą tego typu wirtualizacji jest dodatkowy nakład zasobów systemowych, który prowadzi do spadku wydajności w porównaniu z innymi typami wirtualizacji.

https://github.com/moby/hyperkit do emulacji funkcji hypervisora i Hyperkit używa hypervisor.framework w swoim rdzeniu. Hypervisor.framework to natywne rozwiązanie dla hypervisora ​​Maca. Hyperkit używa również VPNKit i DataKit odpowiednio do sieci nazw i systemu plików.

Maszyna wirtualna systemu Linux uruchamiana przez program Docker na komputerach Mac jest tylko do odczytu. Jednak możesz w niego wpaść, uruchamiając:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

Teraz możemy nawet sprawdzić wersję jądra tej maszyny wirtualnej:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

Wszystkie kontenery działają w tej maszynie wirtualnej.

Istnieją pewne ograniczenia dotyczące hypervisor.framework. Z tego powodu Docker nie ujawnia docker0 interfejsu sieciowego w systemie Mac. Nie możesz więc uzyskać dostępu do kontenerów z hosta. Obecnie docker0 jest dostępny tylko w maszynie wirtualnej.

Hyper-v jest rodzimym hiperwizorem w systemie Windows. Próbują również wykorzystać możliwości systemu Windows 10 do uruchamiania systemów Linux natywnie.

    
193
2018-10-18 19: 54: 18Z
  1. komentarz
    Bardzo ładna odpowiedź. Czy mogę zapytać, skąd masz te diagramy? Oryginalny artykuł /książka.
    2016-10-20 09: 07: 21Z
  2. Stworzyłem te diagramy za pomocą Rysunków Google. Nadal mam te na koncie Google Drawings.
    2016-10-20 14: 59: 16Z
  3. @ AshishBista czy możesz podać cytaty dla cytowanych artykułów. Oczywiście włożono w to wiele wysiłku, a część pracy pochodzi z innych artykułów badawczych. Chociaż możesz podać przypisanie w opublikowanej pracy, musisz to zrobić tutaj. Dzięki.
    2018-08-12 17: 22: 15Z
  4. Należy również pamiętać, że twoja praca jest tutaj kopiowana medium.com/@evalsocket/under-the-hood-docker-98f99189f38a bez przypisania.
    2018-08-12 17: 25: 00Z
  5. @ L0j1k - Podam to ponownie: twoje oskarżenia wydają się fałszywe. Artykuły, które dostarczyłeś jako dowód, zostały napisane po tej odpowiedzi i wydają się plagiatować z tej odpowiedzi. Dlatego Twoje komentarze zostały usunięte, a flagi nie zostały uruchomione. Jeśli nie możesz podać źródła, które poprzedza tę odpowiedź, sugeruję przejście dalej.
    2018-12-05 15: 42: 30Z

W tym poście narysujemy kilka linii różnic między maszynami wirtualnymi i LXC. Najpierw zdefiniujmy je.

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 sprzęt fizyczny.

W tym kontekście maszyna wirtualna jest wywoływana jako gość, podczas gdy środowisko, w którym działa, jest nazywane hostem.

LXC s:

Kontenery Linux (LXC) to funkcje na poziomie systemu operacyjnego, które umożliwiają uruchamianie wielu izolowanych kontenerów Linux na jednym hoście sterującym (hostie LXC). Kontenery Linux służą jako lekka alternatywa dla maszyn wirtualnych, ponieważ nie wymagają hiperwizorów, a mianowicie. Virtualbox, KVM, Xen itp.

Jeśli nie jesteś odurzony przez Alana (Zach Galifianakis - z serii Hangover) i byłeś w Vegas przez ostatni rok, będziesz bardzo świadomy ogromnego zainteresowania technologią pojemników z Linuksem i jeśli będę konkretny jeden projekt kontenerowy, który wywołał burzę na całym świecie w ciągu ostatnich kilku miesięcy - Docker prowadzi do echa opinii, że środowiska przetwarzania w chmurze powinny porzucić maszyny wirtualne (VM) i zastąpić je kontenerami ze względu na ich niższy narzut i potencjalnie lepszą wydajność.

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

a. LXC są ograniczone do instancji Linuksa. Mogą to być różne odmiany Linuksa (np. Kontener Ubuntu na hoście CentOS, ale nadal jest to Linux). Podobnie, kontenery oparte na systemie Windows są teraz ograniczone do instancji systemu Windows, jeśli spojrzymy na maszyny wirtualne, mają one szerszy zakres i używają hiperwizory nie są ograniczone 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 to. Docker, który jest zbudowany na barkach technologii LXC, zapewnił programistom platformę do uruchamiania aplikacji, a jednocześnie umożliwiał ludziom operacyjnym korzystanie z narzędzia, które pozwoli im wdrożyć ten sam kontener na serwerach produkcyjnych lub centrach danych. Próbuje uzyskać doświadczenie między deweloperem, który uruchamia aplikację, uruchamia i testuje aplikację, a operatorem wdrażającym tę aplikację bezproblemowo, ponieważ w tym właśnie tkwi całe tarcie i celem DevOps jest rozbicie tych silosów.

Tak więc najlepszym rozwiązaniem jest, aby dostawcy infrastruktury chmurowej opowiedzieli się za odpowiednim wykorzystaniem maszyn wirtualnych i LXC, ponieważ każdy z nich jest odpowiedni do obsługi określonych obciążeń i scenariuszy.

Porzucenie maszyn wirtualnych nie jest obecnie praktyczne. Zatem zarówno maszyny wirtualne, jak i LXC mają swoje indywidualne istnienie i znaczenie.

    
138
2017-03-11 17: 19: 53Z
  1. Twoja część "b" powyżej jest dokładnie tym, co ludzie Dockera mówili o tej technologii. Ma to ułatwić zadania rozwojowe i . W oparciu o moje doświadczenie jako dev i sysop muszę się zgodzić.
    2014-10-01 05: 30: 43Z
  2. To dość abstrakcyjna odpowiedź. Potrzebujemy przypadków użycia, kiedy używamy /nie używamy Dockera. Oto jest pytanie. Każdy może dowiedzieć się, jak działa Docker, ale tylko nieliczni mogą wyjaśnić rzeczywiste scenariusze.
    2014-10-15 08: 43: 20Z
  3. czy możesz wyjaśnić część „a”. Język nie jest zbyt jasny.
    2015-05-20 07: 34: 51Z
  4. doker jest teraz wprowadzany do świata okien, ponieważ nie jest już zależny od LXC: blogs.msdn.com/b/nzdev/archive/2015/06/02/… proszę poprawić ja, jeśli źle zrozumiałem odpowiedzi tutaj
    2015-11-16 05: 50: 33Z
  5. Trudno mi zrozumieć "(np. kontener Ubuntu na hoście Centos, ale wciąż jest Linux)" część kontenerów. Rozumiem to tak, że kontenery współdzielą jądro hosta. Jeśli mam maszynę wirtualną hosta, na przykład jądro Linuksa 4.6, z kilkoma maszynami VM działającymi na jądrach 2.4, 2.6, 3.2, 4.1 i 4.4. Jeśli wykonam polecenia specyficzne dla tego jądra, otrzymam zachowanie jądra gościa (a nie hosta). Ale jeśli moje maszyny wirtualne dla gości są teraz kontenerami, czy wykonane polecenie zostanie określone przez jądro hosta?
    2016-06-09 21: 06: 13Z

Większość odpowiedzi mówi o maszynach wirtualnych. Dam ci odpowiedź na to pytanie, która najbardziej mi pomogła w ciągu ostatnich kilku lat używania Dockera. Tak jest:

  

Docker to po prostu fantazyjny sposób na uruchomienie procesu, a nie maszyny wirtualnej.

Pozwólcie, że wyjaśnię nieco więcej, co to znaczy. Maszyny wirtualne są ich własną bestią. Chciałbym wyjaśnić, czym jest Docker , aby pomóc ci zrozumieć to bardziej niż wyjaśnienie, czym jest maszyna wirtualna. Zwłaszcza, że ​​jest tu wiele świetnych odpowiedzi mówiących dokładnie, co ktoś ma na myśli mówiąc „maszyna wirtualna”. Więc ...

Kontener Docker to po prostu proces (i jego dzieci), który jest podzielony za pomocą cgroups wewnątrz jądra systemu hosta z reszta procesów. Możesz zobaczyć procesy kontenerów Docker, uruchamiając na hoście ps aux. Na przykład uruchomienie apache2 „w kontenerze” rozpoczyna się dopiero od apache2 jako specjalnego procesu na hoście. Po prostu został podzielony na inne procesy na komputerze. Ważne jest, aby pamiętać, że twoje kontenery nie istnieją poza okresem twojego kontenerowego procesu. Gdy twój proces umrze, twój kontener umiera. Dzieje się tak, ponieważ Docker zastępuje pid 1 wewnątrz twojego kontenera aplikacją (pid 1 jest zwykle systemem inicjującym). Ten ostatni punkt o pid 1 jest bardzo ważny.

Jeśli chodzi o system plików używany przez każdy z tych procesów kontenerowych, Docker używa UnionFS obrazów z kopii zapasowej, co jest tym co pobierasz, gdy robisz docker pull ubuntu. Każdy „obraz” to tylko seria warstw i powiązanych metadanych. Koncepcja warstwowania jest tutaj bardzo ważna. Każda warstwa to tylko zmiana z warstwy pod nią. Na przykład, gdy usuniesz plik z pliku Docker podczas budowania kontenera Docker, faktycznie tworzysz warstwę na wierzchu ostatniej warstwy, która mówi „ten plik został usunięty”. Nawiasem mówiąc, dlatego możesz usunąć duży plik z systemu plików, ale obraz nadal zajmuje tyle samo miejsca na dysku. Plik nadal istnieje, w warstwach pod bieżącym. Same warstwy są po prostu archiwami plików. Możesz test to z docker save --output /tmp/ubuntu.tar ubuntu, a następnie cd /tmp && tar xvf ubuntu.tar. Następnie możesz się rozejrzeć. Wszystkie te katalogi, które wyglądają jak długie skróty, są w rzeczywistości pojedynczymi warstwami. Każdy z nich zawiera pliki (layer.tar) i metadane (json) z informacjami o tej konkretnej warstwie. Warstwy te opisują zmiany w systemie plików, które są zapisywane jako warstwa „na wierzchu” jego oryginalnego stanu. Podczas odczytywania danych „bieżących” system plików odczytuje dane tak, jakby patrzył tylko na najwyższe warstwy zmian. Dlatego plik wydaje się być usunięty, mimo że nadal istnieje w „poprzednich” warstwach, ponieważ system plików patrzy tylko na najwyższe warstwy. Pozwala to całkowicie innym kontenerom na współdzielenie ich warstw systemu plików, nawet jeśli w systemie plików na najwyższych warstwach w każdym kontenerze mogły wystąpić istotne zmiany. Może to zaoszczędzić mnóstwo miejsca na dysku, gdy pojemniki dzielą swoje podstawowe warstwy obrazu. Jednak gdy montujesz katalogi i pliki z systemu hosta do swojego kontenera za pomocą woluminów, te woluminy „omijają” UnionFS, więc zmiany nie są przechowywane w warstwach.

Sieci w Dockerze osiąga się za pomocą mostka ethernetowego (nazywanego na hoście docker0) i wirtualnych interfejsów dla każdego kontenera na hoście. Tworzy wirtualną podsieć docker0, aby kontenery komunikowały się „między”. Istnieje wiele opcji sieciowych, w tym tworzenie niestandardowych podsieci dla kontenerów i możliwość „współużytkowania” stosu sieciowego hosta dla kontenera w celu uzyskania bezpośredniego dostępu.

Docker porusza się bardzo szybko. Jego dokumentacja to najlepsza dokumentacja, jaką kiedykolwiek 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 przepełnienia stosu. Jeśli masz konkretne pytania, gorąco polecam dołączenie do #docker na IRC Freenode i tam spytanie (możesz nawet użyć webchat Freenode!).

    
118
2016-06-15 19: 09: 01Z
  1. "Docker to po prostu fantazyjny sposób na uruchomienie procesu, a nie maszyny wirtualnej." to świetne podsumowanie, dzięki!
    2017-11-28 16: 54: 34Z
  2. Dzięki! To zasługa programisty z kanału #docker na IRC Freenode.
    2017-12-10 08: 55: 27Z
  3. To świetna odpowiedź. Podobała mi się analogia.
    2018-01-10 19: 48: 49Z
  4. To jest znacznie jaśniejsze niż inne odpowiedzi. Myślę, że to analogia procesu robi to dla mnie. Po prostu obniża poziom abstrakcji.
    2018-09-19 12: 53: 07Z

Docker hermetyzuje aplikację ze wszystkimi jej zależnościami.

Wirtualizator hermetyzuje system operacyjny, który może uruchamiać dowolne aplikacje, które normalnie może działać na komputerze z metalem.

    
78
2018-08-28 20: 07: 38Z
  1. Uczę się o LXC, popraw mnie, jeśli się mylę, ale może to być jakiś rodzaj wirtualizacji? ale oczywiście szerszy, nie tylko circunscripted do python do powiedzenia
    2015-09-03 18: 35: 12Z
  2. Najlepiej podoba mi się ta odpowiedź. To proste i idzie prosto do punktu. Teraz, gdy ktoś ma podstawowe zrozumienie CO LXC i Virtualizers mogą to zrobić, szczegóły z innego czytania będą miały sens.
    2015-10-26 16: 58: 51Z
  3. @ Phil Zrobił to po przeczytaniu szczegółowych odpowiedzi powyżej.
    2015-10-29 20: 27: 14Z
  4. Zakładam, że chcą wiedzieć, jak kapsułkować. To duża część, która pokazuje różnicę między nimi, ale nie odpowiedziałeś.
    2018-09-28 05: 43: 40Z

Oboje są bardzo różni. Docker jest lekki i używa LXC /libcontainer (który opiera się na nazwach jąder jądra i grupach) i nie ma emulacji komputera /sprzętu, takiej jak hypervisor, KVM. Xen, które są ciężkie.

Docker i LXC są przeznaczone bardziej do piaskowania, kontenerowania i izolacji zasobów. Używa klonowego interfejsu API systemu operacyjnego hosta (obecnie tylko jądro Linuksa), który zapewnia przestrzeń nazw dla IPC, NS (montowanie), sieci, PID, UTS itp.

A co z pamięcią, we /wy, procesorem itp.? Jest to kontrolowane przy użyciu grup, w których można tworzyć grupy z określonymi specyfikacjami /ograniczeniami dotyczącymi określonego zasobu (procesora, pamięci itp.) I umieszczać tam swoje procesy. Oprócz LXC, Docker zapewnia zaplecze pamięci ( http://www.projectatomic.io/docs/filesystems /), np. system plików montowania unii, w którym można dodawać warstwy i udostępniać warstwy między różnymi obszarami nazw montowania.

Jest to potężna funkcja, w której obrazy bazowe są zwykle tylko do odczytu i tylko wtedy, gdy kontener modyfikuje coś w warstwie, zapisze coś do partycji do odczytu i zapisu (a.k.a. copy przy zapisie). Zapewnia również wiele innych opakowań, takich jak rejestracja i wersjonowanie obrazów.

Przy normalnym LXC musisz mieć trochę rootfów lub współużytkować rootfs i kiedy są one udostępniane, a zmiany są odzwierciedlane w innych kontenerach. Ze względu na wiele z tych dodatkowych funkcji, Docker jest bardziej popularny niż LXC. LXC jest popularny w środowiskach wbudowanych do wdrażania zabezpieczeń wokół procesów narażonych na zewnętrzne elementy, takie jak sieć i interfejs użytkownika. Docker jest popularny w środowisku multi-tenancy, gdzie oczekiwane jest spójne środowisko produkcyjne.

Normalna 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 (system operacyjny hosta lub system operacyjny gościa 0) lub oprogramowanie działające na system operacyjny hosta do zapewnienia emulacji sprzętowej, takiej jak procesor, USB /akcesoria, pamięć, sieć itp. dla systemów-gości. Maszyny wirtualne są nadal (od 2015 r.) Popularne w środowisku wielu dzierżawców o wysokim poziomie zabezpieczeń.

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 zwykłe maszyny wirtualne potrzebują co najmniej 2 GB pamięci itd. do zrobienia czegokolwiek znaczący z tym. Ale obsługa Dockera w systemie operacyjnym nie jest dostępna w systemie operacyjnym, takim jak Windows (stan na listopad 2014 r.), Gdzie mogą być uruchamiane typy maszyn wirtualnych na systemach Windows, Linux i Mac.

Oto zdjęcie z dokera /prawica:  Oto zdjęcie z prawcala

    
57
2017-04-03 05: 15: 43Z

1. Lekki

To prawdopodobnie pierwsze wrażenie dla wielu dokerów.

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

Po drugie, kontenery Docker mogą się uruchomić za kilka milisekund, podczas gdy VM zaczyna się w kilka sekund.

2. System plików warstwowych

To kolejna kluczowa funkcja Dockera. Obrazy mają warstwy, a różne obrazy mogą współdzielić warstwy, dzięki czemu są jeszcze bardziej oszczędne i szybsze w budowie.

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

3. Wspólne jądro systemu

Pomyśl o kontenerach jako procesach!

Wszystkie kontenery działające na hoście to rzeczywiście zbiór procesów z różnymi systemami plików. Dzielą to samo jądro systemu operacyjnego, hermetyzuje tylko bibliotekę systemową i zależności.

Jest to dobre dla większości przypadków (brak dodatkowych jąder jądra systemu operacyjnego), ale może być problemem, jeśli konieczne są ścisłe izolacje między kontenerami.

Dlaczego to ma znaczenie?

Wszystko to wygląda na ulepszenia, a nie rewolucję. Akumulacja ilościowa prowadzi do transformacji jakościowej .

Pomyśl o wdrożeniu aplikacji. Jeśli chcemy wdrożyć nowe oprogramowanie (service) lub uaktualnij jeden, lepiej jest zmienić pliki konfiguracyjne i procesy, zamiast tworzyć nową maszynę wirtualną. Ponieważ tworzenie maszyny wirtualnej ze zaktualizowaną usługą, testowanie jej (dzielenie między Dev i QA), wdrażanie do produkcji zajmuje godziny, a nawet dni. Jeśli coś pójdzie nie tak, musisz zacząć od nowa, tracąc jeszcze więcej czasu. Użyj więc narzędzia do zarządzania konfiguracją (marionetka, solniczka, szef kuchni itp.), Aby zainstalować nowe oprogramowanie, preferowane jest pobieranie nowych plików.

Jeśli chodzi o okno dokowane, niemożliwe jest użycie nowo utworzonego kontenera dokowanego do zastąpienia starego. Utrzymanie jest znacznie łatwiejsze! Budowanie nowego obrazu, dzielenie się nim z QA, testowanie go, wdrażanie zajmuje tylko kilka minut (jeśli wszystko jest zautomatyzowane), godziny w najgorszym przypadku. Nazywa się to niezmienną infrastrukturą : nie utrzymuj oprogramowania (aktualizuj), zamiast tego utwórz nowe.

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

    
31
2017-08-10 04: 25: 41Z
  1. Odpowiedź powinna być zaakceptowana!
    2017-10-28 01: 08: 37Z

Docker, w zasadzie kontenery, obsługuje wirtualizację systemu operacyjnego , tzn. twoja aplikacja uważa, że ​​ma pełną instancję systemu operacyjnego, podczas gdy VM obsługuje wirtualizację sprzętową . Czujesz, że to fizyczna maszyna, w której możesz uruchomić dowolny system operacyjny.

W Dockerze uruchomione kontenery współdzielą jądro systemu operacyjnego, podczas gdy w maszynach wirtualnych mają własne pliki OS. Środowisko (system operacyjny), w którym tworzysz aplikację, będzie takie samo po wdrożeniu w różnych środowiskach obsługujących, takich jak „testowanie” lub „produkcja”.

Na przykład, jeśli stworzysz serwer WWW działający na porcie 4000, po wdrożeniu go w swoim środowisku „testowym” ten port jest już używany przez jakiś inny program, więc przestaje działać. W pojemnikach znajdują się warstwy; wszystkie zmiany dokonane w systemie operacyjnym zostaną zapisane w jednej lub wielu warstwach, a te warstwy będą częścią obrazu, więc gdziekolwiek obraz się pojawi, zależności również będą obecne.

W poniższym przykładzie komputer hosta ma trzy maszyny wirtualne. Aby zapewnić pełną izolację aplikacji w maszynach wirtualnych, każdy z nich ma własne kopie plików systemu operacyjnego, bibliotek i kodu aplikacji, a także pełną instancję systemu operacyjnego w pamięci. Without Containers Podczas gdy poniższy rysunek przedstawia ten sam scenariusz z kontenerami. W tym przypadku kontenery po prostu dzielą system operacyjny hosta, w tym jądro i biblioteki, więc nie muszą uruchamiać systemu operacyjnego, ładować bibliotek ani płacić za nie prywatnych kosztów pamięci dla tych plików. Jedyną przyrostową przestrzenią, jaką zajmują, jest pamięć i miejsce na dysku niezbędne do działania aplikacji w kontenerze. Podczas gdy środowisko aplikacji wygląda jak dedykowany system operacyjny, aplikacja wdraża się tak, jak na dedykowanym hoście. Aplikacja kontenerowa uruchamia się w kilka sekund, a wiele innych aplikacji może zmieścić się na maszynie niż w przypadku maszyny wirtualnej. wprowadź opis obrazu tutaj „> </a> </p>

<p> Źródło: <a href= https://azure.microsoft.com/en- us /blog /containers-docker-windows-and-trends /

    
23
2017-01-09 15: 07: 24Z
  1. Bardzo podoba mi się pierwszy akapit.
    2018-09-28 05: 47: 27Z

Istnieją trzy różne konfiguracje, które zapewniają stos do uruchomienia aplikacji (Pomoże nam to rozpoznać, czym jest kontener i co czyni go tak potężnym niż inne rozwiązania):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) Stos Tradycyjny serwer składa się z serwera fizycznego z systemem operacyjnym i yoaplikacja ur.

Zalety:

  • Wykorzystanie surowych zasobów

  • Isolation

Wady:

  • Bardzo powolny czas wdrażania
  • Drogie
  • Zmarnowane zasoby
  • Trudne do skalowania
  • Trudne do migracji
  • Konfiguracja złożona

2) Stos maszyn wirtualnych składa się z serwera fizycznego z systemem operacyjnym i hiperwizorem, który zarządza maszyną wirtualną, zasobami udostępnionymi i interfejsem sieciowym. Każdy Vm uruchamia system operacyjny gościa, aplikację lub zestaw aplikacji.

Zalety:

  • Dobre wykorzystanie zasobów
  • Łatwy do skalowania
  • Łatwe tworzenie kopii zapasowych i migracja
  • Efektywność kosztowa
  • Elastyczność

Wady:

  • Alokacja zasobów jest problematyczna
  • Blokada dostawcy
  • Konfiguracja złożona

3) Konfiguracja kontenerów , kluczową różnicą w stosunku do innych stosów jest wirtualizacja oparta na kontenerach, w której jądro hosta systemu operacyjnego obsługuje wiele izolowanych wystąpień gościa. Te wystąpienia gościa są nazywane kontenerami. Host może być serwerem fizycznym lub maszyną wirtualną.

Zalety :

  • Izolacja
  • Lekki
  • Efektywne zasoby
  • Łatwa migracja
  • Bezpieczeństwo
  • Niskie obciążenie
  • Odbij środowisko produkcyjne i programistyczne

Wady:

  • Ta sama architektura
  • Zasoby ciężkie aplikacje
  • Problemy z siecią i bezpieczeństwem.

Porównując konfigurację kontenera z poprzednikami, możemy stwierdzić, że kontenerowanie jest najszybszą, najbardziej efektywną pod względem zasobów i najbardziej bezpieczną konfiguracją, jaką znamy do tej pory. Kontenery to pojedyncze przypadki, w których uruchamiana jest aplikacja. Docker uruchamia pojemnik w pewien sposób, warstwy pobierają pamięć czasu pracy z domyślnymi sterownikami pamięci masowej (sterowniki nakładek), które są uruchamiane w ciągu kilku sekund, a warstwa kopiowania przy zapisywaniu tworzona na wierzchu po zatwierdzeniu w kontenerze. wykonanie kontenerów. W przypadku maszyn wirtualnych załadowanie wszystkiego do środowiska wirtualizacji zajmie około minuty. Te lekkie instancje można łatwo wymieniać, odbudowywać i przenosić. Pozwala nam to odzwierciedlić środowisko produkcyjne i programistyczne i jest ogromną pomocą w procesach CI /CD. Zalety, które mogą zapewnić kontenery, są tak ważne, że na pewno zostaną tutaj.

    
19
2017-02-12 17: 43: 24Z
  1. Proszę powiedzieć, dlaczego ma to być „najbezpieczniejsza konfiguracja” w porównaniu do maszyn wirtualnych.
    2018-01-11 09: 18: 49Z
  2. @ MKesper: Podczas migracji ze starszego środowiska do środowiska kontenera masz różne sposoby budowania paradygmatu bezpieczeństwa, który opiera się na proaktywnym, a nie reaktywnym podejściu do zapobiegania włamaniom. . Pozwala zabezpieczyć aplikację i środowisko wykonawcze na bardziej szczegółowym poziomie. Umożliwiają również identyfikowanie i rozwiązywanie potencjalnych zagrożeń bezpieczeństwa, zanim zakłócą przepływy pracy. Możliwe jest także połączenie analizy statycznej z ML, aby zautomatyzować obronę środowiska wykonawczego i egzekwować zasady w całym środowisku. Stąd linia „najbezpieczniejsza konfiguracja”.
    2018-02-15 04: 21: 31Z

W odniesieniu do: -

  

„Dlaczego wdrażanie oprogramowania do obrazu dokera jest łatwiejsze niż po prostu   wdrażanie w spójnym środowisku produkcyjnym? ”

Większość oprogramowania jest wdrażana w wielu środowiskach, zazwyczaj co najmniej trzech z poniższych:

  1. Indywidualne komputery programistów
  2. Wspólne środowisko programistyczne
  3. Indywidualne komputery testowe
  4. Wspólne środowisko testowe
  5. Środowisko QA
  6. Środowisko UAT
  7. Testowanie obciążenia /wydajności
  8. Scena na żywo
  9. Produkcja
  10. Archiwum

Istnieją również następujące czynniki do rozważenia:

  • Deweloperzy, a nawet testerzy, będą mieli subtelnie lub znacznie różne konfiguracje komputerów PC, z samej natury zadania
  • Deweloperzy często mogą rozwijać się na komputerach niezależnych od zasad normalizacji korporacyjnej lub biznesowej (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”, aby skonfigurować swoje komputery w określony sposób)
  • Niektóre środowiska będą składały się ze stałej liczby wielu komputerów w konfiguracji z równoważeniem obciążenia
  • Wiele środowisk produkcyjnych będzie miało dynamiczne (lub „elastyczne”) serwery w chmurze tworzone i niszczone w zależności od poziomu ruchu

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

Wszystko to oznacza, że ​​tworzenie spójnych środowisk w pierwszej kolejności jest wystarczająco trudne z powodu czystej objętości (nawet w scenariuszu ekologicznym), ale utrzymywanie ich spójnych jest prawie niemożliwe , biorąc pod uwagę wysoką liczbę serwerów, dodawanie nowych serwerów (dynamicznie lub ręcznie), automatyczne aktualizacje od dostawców O /S, dostawców oprogramowania antywirusowego, dostawców przeglądarek itp., ręczne instalacje oprogramowania lub zmiany konfiguracji wykonywane przez programistów lub techników serwerowych itp. Powtarzam że - jest praktycznie (nie zamierzone) niemożliwe do utrzymania spójnego środowiska (w porządku, dla purystów, można to zrobić, ale wiąże się to z ogromną ilością czasu, wysiłku i dyscypliny, dlatego właśnie maszyny wirtualne i kontenery (np. Docker) zostały opracowane w pierwszej kolejności).

Pomyśl o tym pytaniu bardziej jak „Biorąc pod uwagę ekstremalną trudność w utrzymaniu spójności wszystkich środowisk, czy łatwiej jest wdrożyć oprogramowanie na obrazie dokera, nawet biorąc pod uwagę krzywą uczenia się?” . Myślę, że odpowiedź zawsze będzie brzmiała „tak” - ale jest tylko jeden sposób, aby się o tym dowiedzieć, opublikuj to nowe pytanie na temat przepełnienia stosu.

    
17
2016-10-15 11: 25: 12Z
  1. Więc jeśli wdrożę mój obraz dokera z 15 różnymi polami, które mają wszystkie różne kombinacje OS /wersji, wszystkie moje obrazy dokerów będą działać tak samo?
    2018-01-10 19: 52: 50Z
  2. @ Teomanshipahi Jeśli wszystkie te pojemniki mogłyby używać tego samego jądra dostarczonego przez hosta, tak, wszystkie będą działać pomyślnie.
    2018-09-28 05: 49: 27Z
  3. Jeśli używam dokera dla okien na moim lokalnym, czy mogę zainstalować i uruchomić w ten sam sposób w linux /mac?
    2018-09-28 12: 42: 34Z

Istnieje wiele odpowiedzi, które wyjaśniają bardziej szczegółowo różnice, ale oto moje krótkie wyjaśnienie.

Jedną ważną różnicą jest to, że maszyny wirtualne używają oddzielnego jądra do uruchamiania systemu operacyjnego . To jest powód, dla którego jest ciężki i wymaga czasu, aby zużyć więcej zasobów systemowych.

W Dockerze kontenery współdzielą jądro z hostem; dlatego jest lekki i może szybko się uruchomić i zatrzymać.

W wirtualizacji zasoby są przydzielane na początku konfiguracji, a zatem zasoby nie są w pełni wykorzystywane, gdy maszyna wirtualna jest bezczynna przez wiele razy. W Dockerze kontenery nie są przydzielane ze stałą ilością zasobów sprzętowych i mogą swobodnie korzystać z zasobów w zależności od wymagań, a tym samym są wysoce skalowalne.

Docker używa systemu plików UNION . Docker używa technologii kopiowania na zapisie, aby zmniejszyć ilość pamięci zajmowanej przez kontenery. Czytaj więcej tutaj

    
17
2017-10-09 19: 38: 43Z
  1. Krótki i zwięzły, brakuje tylko części o systemie plików.
    2017-10-08 10: 58: 02Z
  2. Dzięki! Dodałem też trochę na części systemu plików!
    2017-10-09 19: 39: 05Z
  3. "W wirtualizacji zasoby są przydzielane na początku konfiguracji, a zatem zasoby nie są w pełni wykorzystywane, gdymaszyna wirtualna jest bezczynna przez wiele razy „Hyper-V ma pojęcie pamięci dynamicznej, w której można określić minimalną, maksymalną i początkową pamięć RAM.
    2018-01-11 15: 32: 07Z

Dzięki maszynie wirtualnej mamy serwer, mamy system operacyjny hosta na tym serwerze, a następnie mamy hypervisora. Następnie uruchamiamy ten hiperwizor i mamy dowolną liczbę systemów operacyjnych gościa z aplikacją i zależnymi plikami binarnymi oraz biblioteki na tym serwerze. Przynosi ze sobą cały system operacyjny gościa. Jest dość ciężki. Istnieje również ograniczenie, ile możesz włożyć na każdą fizyczną maszynę.

 Wpisz opis obrazu tutaj>> </a> </p>

Z drugiej strony <p> <strong> Kontenery dokowania </strong> są nieco inne. Mamy serwer. Mamy system operacyjny hosta. Ale w tym przypadku <strong> zamiast hiperwizora </strong> mamy <strong> silnik dokowania </strong>. W tym przypadku nie wprowadzimy do nas całego systemu operacyjnego gościa. <strong> Wprowadzamy bardzo cienką warstwę systemu operacyjnego </strong>, a kontener może przejść do systemu operacyjnego hosta, aby dostać się do funkcjonalności jądra. Dzięki temu możemy mieć bardzo lekki pojemnik. </p>

<p> Ma tylko kod aplikacji i wszystkie wymagane pliki binarne i biblioteki. Te pliki binarne i biblioteki mogą być w rzeczywistości udostępniane w różnych kontenerach, jeśli również mają być. To, co pozwala nam to zrobić, to wiele rzeczy. Mają <strong> znacznie szybszy czas uruchamiania </strong>. W ciągu kilku sekund nie możesz postawić pojedynczej maszyny wirtualnej. Równie szybko je usuniemy ... abyśmy mogli szybko skalować w górę iw dół, a my przyjrzymy się temu później. </p>

<p> <a href= Wpisz opis obrazu tutaj>> </a> </p>

<p> Każdy kontener myśli, że działa na własnej kopii systemu operacyjnego. Ma własny system plików, własny rejestr itp., Co jest swego rodzaju kłamstwem. W rzeczywistości jest wirtualizowany. </p>
    </div>
<div class = 13

2018-06-21 19: 49: 37Z
  1. Dziękujemy za prawidłowe i graficzne wyjaśnienie. Upvoted ..
    2018-07-12 18: 58: 46Z

Używałem Dockera w środowiskach produkcyjnych i bardzo dużo inscenizacji. Kiedy się do tego przyzwyczaisz, odkryjesz, że jest bardzo skuteczny w budowaniu wielopojemników i izolowanych środowisk.

Docker został opracowany na podstawie LXC (Linux Container) i działa doskonale w wielu dystrybucjach Linuksa, zwłaszcza w Ubuntu.

Kontenery Docker to izolowane środowiska. Możesz to zobaczyć, gdy wydasz komendę top w kontenerze Docker, który został utworzony z obrazu Docker.

Poza tym są bardzo lekkie i elastyczne dzięki konfiguracji dockerFile.

Na przykład, możesz utworzyć obraz Dockera i skonfigurować plik DockerFile i powiedzieć, że na przykład, gdy jest uruchomiony, wget „this”, apt-get „that”, uruchomić „jakiś skrypt powłoki”, ustawić zmienne środowiskowe i tak na.

W projektach i architekturze usług mikro Docker jest bardzo opłacalnym zasobem. Możesz osiągnąć skalowalność, elastyczność i elastyczność dzięki Docker, Docker Swarm, Kubernetes i Docker Compose.

Kolejną ważną kwestią dotyczącą Dockera jest Docker Hub i jego społeczność. Na przykład zaimplementowałem ekosystem do monitorowania kafki za pomocą Prometheus, Grafana, Prometheus-JMX-Exporter i Dokcer.

Aby to zrobić, pobrałem skonfigurowane kontenery Dockera dla Zookeepera, Kafki, Prometheusa, Grafany i jmx-collector, a następnie zamontowałem własną konfigurację dla niektórych z nich przy użyciu plików yml lub dla innych Zmieniłem niektóre pliki i konfigurację w kontenerze Docker i I zbuduj cały system do monitorowania kafki za pomocą dokerów wielopojemnikowych na pojedynczej maszynie z izolacją i skalowalnością oraz odpornością, którą tę architekturę można łatwo przenieść na wiele serwerów.

Oprócz witryny Docker Hub znajduje się inna strona o nazwie quay.io, której możesz użyć, aby mieć własnąPulpit nawigacyjny obrazów tam i przeciągnij /pchnij do /z niego. Możesz nawet importować obrazy Docker z Docker Hub do quay, a następnie uruchamiać je z quay na własnej maszynie.

Uwaga: Nauka Dockera w pierwszej kolejności wydaje się skomplikowana i trudna, ale kiedy się do tego przyzwyczaisz, nie możesz pracować bez niego.

Pamiętam pierwsze dni pracy z Dockerem, gdy wydałem błędne polecenia lub usunąłem kontenery i wszystkie dane i konfiguracje omyłkowo.

    
9
2018-06-21 19: 55: 50Z

Różnica między tym, jak aplikacje w VM używają procesora a kontenerami

Źródło: Kubernetes in Action.

    
8
2018-07-16 02: 56: 46Z

Tak przedstawia się Docker :

  

Docker to firma sterująca ruchem kontenerów i jedyna   dostawca platformy kontenerowej do każdej aplikacji   chmura hybrydowa. Dzisiejsze firmy są pod presją cyfrowej   przekształcić, ale są ograniczone przez istniejące aplikacje i   infrastruktura przy racjonalizacji coraz bardziej zróżnicowanego portfolio   chmur, centrów danych i architektur aplikacji. Docker umożliwia   prawdziwa niezależność między aplikacjami a infrastrukturą   deweloperzy i operatorzy IT, aby odblokować swój potencjał i stworzyć model   dla lepszej współpracy i innowacji.

Więc Docker jest oparty na kontenerze, co oznacza, że ​​masz obrazy i kontenery, które można uruchomić na bieżącym komputerze. Nie obejmuje systemu operacyjnego takiego jak VM , ale przypomina pakiet różnych pakietów roboczych, takich jak Java, Tomcat itp.

Jeśli rozumiesz kontenery, dostajesz to, co jest w Dockerze i czym różni się od maszyny wirtualnej s ...

Więc co to jest kontener?

  

Obraz kontenera jest lekkim, samodzielnym, wykonywalnym pakietem   kawałek oprogramowania, który zawiera wszystko, co jest potrzebne do jego uruchomienia: kod,   środowisko wykonawcze, narzędzia systemowe, biblioteki systemowe, ustawienia. Dostępne dla obu   Aplikacje oparte na systemie Linux i Windows, oprogramowanie kontenerowe zawsze będzie działać   to samo, bez względu na środowisko. Kontenery izolują oprogramowanie   z jego otoczenia, na przykład różnice między rozwojem i   środowiska inscenizacyjne i pomagają ograniczyć konflikty między uruchomionymi zespołami   inne oprogramowanie w tej samej infrastrukturze.

 Doker

Jak widać na poniższym obrazku, każdy kontener ma osobny pakiet i działa na jednym komputerze współużytkującym system operacyjny tej maszyny ... Są bezpieczne i łatwe do wysyłki ...

    
5
2018-06-21 19: 47: 15Z

Istnieje wiele miłych odpowiedzi technicznych, które jasno omawiają różnice między maszynami wirtualnymi i kontenerami, a także pochodzenie Dockera.

Dla mnie podstawową różnicą między maszynami wirtualnymi a programem Docker jest sposób zarządzania promocją aplikacji.

W przypadku maszyn wirtualnych promujesz swoją aplikację i jej zależności z jednej maszyny wirtualnej na następną DEV do UAT na PRD.

  1. Często te maszyny wirtualne będą miały różne poprawki i biblioteki.
  2. Często zdarza się, że wiele aplikacji współużytkuje maszynę wirtualną. Wymaga to zarządzania konfiguracją i zależnościami dla wszystkich aplikacji.
  3. Backout wymaga cofnięcia zmian w maszynie wirtualnej. Lub przywrócenie go, jeśli to możliwe.

W Dockerze pomysł polega na spakowaniu aplikacji wewnątrz własnego kontenera wraz z potrzebnymi bibliotekami, a następnie promowaniu całego kontenera jako pojedynczej jednostki.

  1. Z wyjątkiem jądra, łatki i biblioteki są identyczne.
  2. Jako ogólna zasada istnieje tylko jedna aplikacja na kontener, która upraszcza konfigurację.
  3. Backout polega na zatrzymaniu i usunięciu kontenera.

Więc na najbardziej podstawowym poziomie z maszynami wirtualnymi promujesz aplikację i jej zależności jako elementy dyskretne, podczas gdy w Dockerze promujesz wszystkow jednym trafieniu.

I tak, istnieją problemy z kontenerami, w tym zarządzanie nimi, chociaż narzędzia takie jak Kubernetes lub Docker Swarm znacznie upraszczają zadanie.

    
4
2018-06-21 19: 57: 57Z
źródło umieszczone tutaj
Inne pytania