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

Dobre odpowiedzi. Aby uzyskać obraz reprezentacji kontenera vs maszyny wirtualnej, spójrz na jeden poniżej.

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

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

Uwaga: upraszczam nieco opis poniżej. Zobacz referencje, aby uzyskać więcej informacji.

Jak wirtualizacja działa na niskim poziomie?

W tym przypadku vm manager przejmuje pierścień CPU 0 (lub "tryb roota" w nowszych procesorach) i przechwytuje wszystkie uprzywilejowane połączenia wykonywane przez system operacyjny gościa, aby stworzyć iluzję, że system operacyjny gościa ma swój własny sprzęt. Ciekawostka: Przed rokiem 1998 uważano, że osiągnięcie tego w architekturze x86 jest niemożliwe, ponieważ nie było sposobu na tego typu przechwytywanie. Ludzie z VMWare byli pierwszymi , którzy wpadli na pomysł przepisania bajtów wykonywalnych w pamięci dla uprzywilejowanych wywołań systemu operacyjnego gościa, aby to osiągnąć.

Efekt sieciowy polega na tym, ż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 bootstrappingu, ładowania jądra itp. Możesz mieć bardzo ścisłe 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ć rzeczy.

Jak kontenery działają na niskim poziomie?

Wokół 2006, ludzie, w tym niektórzy pracownicy Google zaimplementowali nową funkcjonalność na poziomie jądra o nazwie przestrzenie nazw (jednak idea długo zanim istniała we FreeBSD ). Jedną z funkcji systemu operacyjnego jest umożliwienie współdzielenia globalnych zasobów, takich jak Sieć i dysk, procesom. Co? jeśli te globalne zasoby były zawinięte w przestrzenie nazw tak, że są widoczne tylko dla tych procesów, które działają w tej samej przestrzeni nazw? Powiedzmy, że możesz dostać kawałek 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 mogą uzyskać dostępu do niczego w pamięci, która jest przydzielona 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 globalnych zasoby. Tak działa docker: każdy kontener działa w swojej własnej przestrzeni nazw, ale używa dokładnie jądra tego samego, co wszystkie inne kontenery. Izolacja ma miejsce, ponieważ jądro zna przestrzeń nazw, która została przypisana do procesu i podczas wywołań API upewnia się, że proces może uzyskać dostęp tylko do zasobów w swojej własnej przestrzeni nazw.

Ograniczenia containers vs VM powinny być teraz oczywiste: nie można uruchomić zupełnie innego systemu operacyjnego w kontenerach, takich jak w maszynach wirtualnych. Jednak możesz uruchamiaj różne dystrybucje Linuksa, ponieważ mają to samo jądro. Poziom izolacji nie jest tak silny jak w VM. W rzeczywistości we wczesnych implementacjach istniał sposób na przejęcie hosta przez kontener "gość". Możesz również zobaczyć, że po załadowaniu nowego kontenera cała nowa kopia systemu operacyjnego nie uruchamia się tak, jak w maszynie wirtualnej. Wszystkie kontenery mają to samo jądro. Dlatego kontenery są lekkie. W przeciwieństwie do maszyn wirtualnych, nie trzeba wstępnie przydzielać znaczącej części pamięci do kontenerów ponieważ nie uruchamiamy nowej kopii systemu operacyjnego. Umożliwia to uruchamianie tysięcy kontenerów na jednym systemie operacyjnym podczas piaskownicy, co może nie być możliwe, jeśli uruchomiliśmy oddzielną kopię systemu operacyjnego we własnej maszynie wirtualnej.

Podoba mi się odpowiedź Kena Cochrane ' a.

Ale chcę dodać dodatkowy punkt widzenia, nie omówiony szczegółowo tutaj. Moim zdaniem Docker różni się również całym procesem. W przeciwieństwie do maszyn wirtualnych, Docker nie polega (tylko) na optymalnym współdzieleniu zasobów sprzętu, ponadto zapewnia "system" dla aplikacji pakujących (preferowany, ale nie musi, jako zestaw mikroserwisów).

Dla mnie pasuje do luki pomiędzy narzędziami zorientowanymi na deweloperów, takimi jak rpm, Pakiety Debian , Maven , npm + Git na jednej stronie i ops narzędzia takie jak Puppet , VMware, Xen, nazwij to...

Dlaczego wdrażanie oprogramowania na obrazie dokera (jeśli to właściwe określenie) jest łatwiejsze niż wdrażanie 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 potoku.

Aby zachować synchronizację, zaczniesz używać coś jak Puppet, Chef lub własne skrypty, niepublikowane zasady i / lub dużo dokumentacji... Teoretycznie serwery mogą działać w nieskończoność i być całkowicie spójne i aktualne. Praktyka nie pozwala na całkowite zarządzanie konfiguracją serwera, więc istnieje znaczne pole do dryfowania konfiguracji i nieoczekiwanych zmian w uruchomionych serwerach.

Istnieje więc znany wzorzec, aby tego uniknąć, tzw. immutable server. Ale niezmienny wzór serwera nie był kochany. Głównie ze względu na ograniczenia maszyn wirtualnych, które były używane przed Dockerem. Radzenie sobie z kilkoma gigabajtami dużych obrazów, przenoszenie tych dużych obrazów, aby zmienić niektóre pola w aplikacji, było bardzo pracochłonne. To zrozumiałe...

Dzięki ekosystemowi Dockera 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 Dockera kontener w czasie wykonywania. Nie musisz się martwić o wersje tego obrazu.

I wreszcie będziesz nawet często w stanie odtworzyć 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żna uruchomić kontenery Dockera w maszynach wirtualnych (to dobry pomysł). Ogranicz obsługę serwera na poziomie maszyny wirtualnej. Wszystko to może być zarządzane przez Docker.

P. S. tymczasem Docker korzysta z własnej implementacji "libcontainer" zamiast LXC. Ale LXC jest nadal użyteczny.

Docker nie jest metodologią wirtualizacji. Opiera się na innych narzędziach, które faktycznie implementują wirtualizację opartą na kontenerach lub wirtualizację na poziomie systemu operacyjnego. W tym celu Docker początkowo używał sterownika LXC, a następnie przeniósł się do libcontainer, który teraz został przemianowany na runc. Docker koncentruje się przede wszystkim na automatyzacji wdrażania aplikacji wewnątrz kontenerów aplikacji. Kontenery aplikacji są przeznaczone do pakowania i uruchamiania pojedynczej usługi, podczas gdy kontenery systemowe są przeznaczone do uruchamiania wiele procesów, takich jak maszyny wirtualne. Docker jest więc uważany za narzędzie do zarządzania kontenerami lub wdrażania aplikacji w systemach kontenerowych.

Aby dowiedzieć się, czym różni się od innych wirtualizacji, przejdźmy do wirtualizacji i jej typów. Wtedy łatwiej byłoby zrozumieć, jaka jest różnica.

Wirtualizacja

W swojej pomyślanej formie, był uważany za metodę logicznego dzielenia ramek mainframe, aby umożliwić wielokrotne aplikacje uruchamiane jednocześnie. Jednak scenariusz drastycznie się zmienił, gdy firmy i społeczności open source były w stanie zapewnić metodę obsługi uprzywilejowanych instrukcji w taki czy inny sposób i umożliwić jednoczesne uruchamianie wielu systemów operacyjnych na jednym systemie opartym na x86.

Hypervisor

Hypervisor zajmuje się tworzeniem środowiska wirtualnego, na którym działają maszyny wirtualne gości. Nadzoruje systemy gości i sprawia, że upewnij się, że zasoby są przydzielane Gościom w razie potrzeby. Hypervisor znajduje się pomiędzy maszyną fizyczną a maszynami wirtualnymi i zapewnia usługi wirtualizacji maszyn wirtualnych. Aby go zrealizować, przechwytuje operacje systemu operacyjnego gościa na maszynach wirtualnych i emuluje operację na systemie operacyjnym maszyny hosta.

Rodzaje wirtualizacji

Metodę wirtualizacji można sklasyfikować na podstawie tego, w jaki sposób naśladuje ona sprzęt do systemu operacyjnego gościa i emuluje środowisko operacyjne gościa. Przede wszystkim istnieją trzy rodzaje wirtualizacja:

• Emulacja
• Parawirtualizacja
• wirtualizacja oparta na kontenerach

Emulacja

Emulacja, znana również jako pełna wirtualizacja, uruchamia jądro systemu operacyjnego maszyny Wirtualnej w całości w oprogramowaniu. Hipernadzorca używany w tym typie jest znany jako hipernadzorca typu 2. Jest on zainstalowany w górnej części systemu operacyjnego hosta, który jest odpowiedzialny za tłumaczenie kodu jądra systemu operacyjnego gościa na instrukcje oprogramowania. Tłumaczenie jest zrobione całkowicie w oprogramowaniu i nie wymaga udziału sprzętu. Emulacja umożliwia uruchamianie dowolnego niezmodyfikowanego systemu operacyjnego, który obsługuje emulowane środowisko. Wadą tego typu wirtualizacji jest dodatkowy narzut zasobów systemowych, który prowadzi do spadku wydajności w porównaniu z innymi typami wirtualizacji.

Przykłady w tej kategorii obejmują VMware Player, VirtualBox, QEMU, Bochs, Parallels, itd.

Parawirtualizacja

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

Wirtualizacja kontenerów

Wirtualizacja kontenerów, znana również jako wirtualizacja na poziomie systemu operacyjnego, umożliwia wiele odizolowanych egzekucji w obrębie jednego jądra systemu operacyjnego. Ma najlepszą możliwą wydajność i gęstość oraz oferuje dynamiczne zarządzanie zasobami. Izolowane Wirtualne Środowisko wykonawcze dostarczane przez tego typu wirtualizacja nazywana jest kontenerem i może być postrzegana jako śledzona grupa procesów.

Koncepcja kontenera jest możliwa dzięki funkcji przestrzeni nazw dodanej do jądra Linuksa 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 on dostępny przez wywołanie systemowe clone () , które umożliwia tworzenie oddzielnych instancji poprzednio globalnych przestrzeni nazw.

Przestrzenie nazw mogą być używane na wiele różnych sposobów, ale najczęstszym podejściem jest tworzenie izolowanego kontenera, który nie ma widoczności ani dostępu do obiektów poza kontenerem. Procesy działające wewnątrz kontenera wydają się działać na normalnym systemie Linux, chociaż współdzielą jądro z procesami znajdującymi się w innych przestrzeniach nazw, tak samo dla innych rodzajów obiektów. Na przykład, gdy używasz przestrzeni nazw, użytkownik root wewnątrz kontenera nie jest traktowany jako root poza kontenerem, dodając dodatkowe zabezpieczenie.

Podsystem Linux Control Groups (Cgroups), kolejny główny komponent umożliwiający wirtualizację kontenerów, jest używany do grupowania procesów i zarządzania ich zagregowanym zużyciem zasobów. Jest powszechnie stosowany w celu ograniczenia pamięci i zużycia procesora kontenerów. Ponieważ kontenerowy system Linux ma tylko jedno jądro, a jądro ma pełny wgląd w kontenery, istnieje tylko jeden poziom alokacji zasobów i planowania.

Kilka zarządów narzędzia są dostępne dla kontenerów Linuksa, w tym LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, itp.

Kontenery vs 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ż sekundę. Ta funkcja sprawia, że wirtualizacja oparta na kontenerach jest wyjątkowa i pożądana niż inne podejścia do wirtualizacji.

Ponieważ wirtualizacja oparta na kontenerach dodaje wirtualizacja bazująca na kontenerach ma niemal natywną wydajność.]} W przypadku wirtualizacji kontenerowej nie jest wymagane żadne dodatkowe oprogramowanie, w przeciwieństwie do innych wirtualizacji.

Wszystkie kontenery na maszynie hosta współdzielą scheduler maszyny hosta, oszczędzając dodatkowe zasoby.

Stany kontenerów (obrazy Docker lub LXC) są małe w porównaniu do obrazów maszyn wirtualnych, więc obrazy kontenerów są łatwe do Rozdaj.

Zarządzanie zasobami w kontenerach odbywa się za pomocą cgroups. Cgroups nie pozwala kontenerom zużywać więcej zasobów niż im przydzielono. Jednak na razie wszystkie zasoby maszyny hosta są widoczne w maszynach wirtualnych, ale nie mogą być używane. Można to zrealizować uruchamiając top LUB htop na kontenerach i maszynie hosta w tym samym czasie. Dane wyjściowe we wszystkich środowiskach będą wyglądać podobnie.

Aktualizacja:

Jak Docker uruchamia kontenery w systemy nie-linuksowe?

Jeśli kontenery są możliwe ze względu na funkcje dostępne w jądrze Linuksa, oczywistym pytaniem jest, w jaki sposób systemy nie-linuksowe uruchamiają kontenery. Zarówno Docker dla komputerów Mac, jak i Windows używa maszyn wirtualnych Linux do uruchamiania kontenerów. Docker Toolbox służy do uruchamiania kontenerów w wirtualnych maszynach wirtualnych. Ale najnowszy Docker używa Hyper-V W Windows i Hypervisor.framework w Mac.

Teraz pozwól mi opisać jak Docker for Mac uruchamia kontenery w szczegółach.

Docker dla komputerów Mac https://github.com/moby/hyperkit aby emulować możliwości hipernadzorcy i Hyperkit używa hipernadzorcy.ramy w swoim rdzeniu. Hypervisor.framework jest natywnym rozwiązaniem hipernadzorcy Mac. Hyperkit używa również VPNKit i DataKit odpowiednio do sieci i systemu plików.

Maszyna wirtualna pod Linuksem uruchamiana na Macu jest tylko do odczytu. Można go jednak wbić, uruchamiając:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty. Teraz możemy nawet sprawdzić wersję jądra tego VM:

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

Wszystkie kontenery działają wewnątrz tej maszyny wirtualnej.

Istnieją pewne ograniczenia hipernadzorcy.ramy. Z tego powodu Docker nie ujawnia docker0 interfejsu sieciowego w Mac. Więc nie możesz uzyskać dostępu do kontenerów z hosta. Od tej pory {[4] } jest dostępna tylko wewnątrz maszyny wirtualnej.

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

VM :

Maszyna wirtualna emuluje fizyczne środowisko obliczeniowe, 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, na którym działa jest zadzwoniłem do gospodarza.

LXC s:

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

Teraz, jeśli nie zostałeś odurzony przez Alana (Zach Galifianakis - z serii Kac Vegas) i byłeś w Vegas przez ostatni rok, będziesz całkiem świadomy ogromnego wzrostu zainteresowania technologią kontenerów Linuksa, a jeśli będę konkretny, jeden projekt kontenera, który wywołał szum na całym świecie w ciągu ostatnich kilku miesięcy, to-Docker prowadzący do niektórych ECHA opinii, że środowiska przetwarzania w chmurze powinny porzucić maszyny wirtualne (VM) i zastąpić je kontenerami ze względu na ich niższy koszt i potencjalnie lepszą wydajność.

Ale pytanie brzmi: czy jest to wykonalne? czy to będzie sensowne?

A. LXC są przypisane do instancji Linuksa. Może to być inne smaki Linuksa (np. kontener Ubuntu na Hostie CentOS, ale nadal jest to Linux.) Podobnie, kontenery oparte na systemie Windows są teraz ograniczone do instancji Windows jeśli spojrzymy na maszyny wirtualne mają dość szerszy zakres i używając hipernadzorców 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 czyli Docker, które są zbudowane na ramionach Technologia LXC zapewniła programistom platformę do uruchamiania ich aplikacji, a jednocześnie umożliwiła operatorom narzędzie, które pozwoli im wdrożyć ten sam kontener na serwerach produkcyjnych lub centrach danych. Stara się, aby doświadczenie pomiędzy programistą uruchamiającym aplikację, uruchamiającym i testującym aplikację a osobą operacyjną wdrażającą tę aplikację było bezproblemowe, ponieważ to właśnie tutaj tkwią wszystkie tarcia, a celem DevOps jest załamanie się te silosy.

Najlepszym rozwiązaniem jest więc to, że dostawcy infrastruktury chmurowej powinni zalecać odpowiednie wykorzystanie maszyn wirtualnych i LXC, ponieważ każdy z nich nadaje się do obsługi określonych obciążeń i scenariuszy.

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

Większość odpowiedzi tutaj mówi o maszynach wirtualnych. Dam ci jednoliniową odpowiedź na to pytanie, które najbardziej pomogło mi w ciągu ostatnich kilku lat korzystania z Dockera. To jest to:

Docker to tylko wymyślny sposób na uruchomienie procesu, a nie maszyny wirtualnej.

Teraz, pozwól mi wyjaśnić trochę więcej o tym, co to znaczy. Maszyny wirtualne to ich własna bestia. Mam ochotę wyjaśnić czym jest Docker pomoże Ci to zrozumieć bardziej niż wyjaśnianie, czym jest maszyna wirtualna. Zwłaszcza, że jest tu wiele dobrych odpowiedzi mówiących dokładnie, co ktoś ma na myśli, gdy mówi "maszyna wirtualna". Więc...

Kontener Dockera jest po prostu procesem (i jego potomkami), który jest dzielony za pomocą cgroups wewnątrz jądra systemu hosta od reszty procesów. Możesz faktycznie zobaczyć procesy kontenera Dockera, uruchamiając ps aux na hoście. Na przykład uruchamianie apache2 "w kontenerze" dopiero się zaczyna apache2 jako specjalny proces na serwerze. Po prostu został oddzielony od innych procesów na maszynie. Ważne jest, aby pamiętać, że kontenery nie istnieją poza okresem użytkowania procesu kontenerowego. Gdy twój proces umiera, twój pojemnik umiera. Dzieje się tak dlatego, że Docker zastępuje pid 1 wewnątrz kontenera Twoją aplikacją (pid 1 jest zwykle systemem init). Ten ostatni punkt o pid 1 jest bardzo ważny.

Jeśli chodzi o system plików używany przez każdy z tych kontenerów procesy, Docker używa obrazów wspieranych przez unionfs , czyli tego, co pobierasz, gdy wykonujeszdocker pull ubuntu. Każdy "obraz" to tylko seria warstw i powiązanych metadanych. Pojęcie warstw jest tutaj bardzo ważne. Każda warstwa jest tylko zmianą od warstwy pod nią. Na przykład, gdy usuwasz Plik z pliku Dockerfile podczas budowania kontenera Dockera, tworzysz warstwę na ostatniej warstwie z napisem "ten plik został usunięty". Nawiasem mówiąc, jest to dlaczego 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żącą. Warstwy same w sobie to tylko kulki plików. Możesz to przetestować za pomocą docker save --output /tmp/ubuntu.tar ubuntu, a następnie cd /tmp && tar xvf ubuntu.tar. Potem możesz się rozejrzeć. Wszystkie te katalogi, które wyglądają jak długie skróty, są w rzeczywistości pojedynczymi warstwami. Każda z nich zawiera pliki (layer.tar) i metadane (json) z informacjami o danej warstwie. Te warstwy po prostu opisują zmiany w systemie plików, które są zapisywane jako warstwa "na wierzchu" jej pierwotnego stanu. Podczas odczytu "bieżących" danych, system plików odczytuje dane tak, jakby patrzył tylko na górne warstwy zmian. Dlatego plik wydaje się być usuwany, mimo że nadal istnieje w" poprzednich " warstwach, ponieważ system plików patrzy tylko na górne warstwy. Pozwala to całkowicie różnym kontenerom na współdzielenie swoich warstw systemu plików, nawet jeśli niektóre znaczące zmiany mogły mieć miejsce w systemie plików na górnej większości warstw w każdym kontenerze. Pozwala to zaoszczędzić mnóstwo miejsca na dysku, gdy kontenery udostępniają swoje podstawowe warstwy obrazu. Jednak gdy montujesz katalogi i pliki z systemu hosta do kontenera za pomocą woluminów, woluminy te "omijają" UnionFS, więc zmiany nie są przechowywane w warstwach.

Sieć w Dockerze jest osiągana przez użycie mostu ethernet (zwanego docker0 na hoście), a Interfejsy wirtualne dla każdego pojemnik na hosta. Tworzy wirtualną podsieć w docker0, aby kontenery komunikowały się między sobą. Istnieje wiele opcji tworzenia sieci, w tym tworzenie niestandardowych podsieci dla kontenerów i możliwość "udostępniania" stosu sieciowego hosta, aby kontener mógł uzyskać bezpośredni dostęp.

Docker porusza się bardzo szybko. Jego dokumentacja jest jedną z najlepszych dokumentacji, jaką kiedykolwiek widziałem. Jest ogólnie dobrze napisany, zwięzły i dokładny. Polecam sprawdzasz dostępną dokumentację, aby uzyskać więcej informacji, i ufasz dokumentacji nad wszystkim innym, co czytasz online, w tym przepełnieniem stosu. Jeśli masz konkretne pytania, polecam dołączyć #docker na Freenode IRC i zapytać tam (możesz nawet użyć Freenode ' s webchat!).

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

Wirtualizator hermetyzuje system operacyjny, który może uruchamiać dowolne aplikacje, które może normalnie uruchamiać na maszynie z metalu.

Oba są bardzo różne. Docker jest lekki i używa LXC / libcontainer (który opiera się na przestrzeni nazw jądra i cgroups) i nie ma emulacji maszynowo-sprzętowej, takiej jak hypervisor, KVM. Xen, które są ciężkie.

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

Co z pamięcią, I/O, CPU, itd.? To jest kontrolowane za pomocą cgroups, gdzie można tworzyć grupy z określonym zasobem (CPU, pamięci, itp.) specyfikacji/ograniczenia i umieścić tam swoje procesy. Oprócz LXC, Docker zapewnia backend pamięci masowej ( http://www.projectatomic.io/docs/filesystems / ) np. union mount filesystem, w którym można dodawać warstwy i współdzielić warstwy pomiędzy różnymi przestrzeniami 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, czy napisze coś do partycji do odczytu i zapisu (vel copy on write). Zapewnia również wiele innych owijarek, takich jak rejestr i wersjonowanie obrazów.

W normalnym LXC musisz dostarczać pliki rootfs lub udostępniać pliki rootfs i kiedy są udostępniane, a zmiany są odzwierciedlane na innych kontenerach. Ze względu na wiele dodatkowych funkcji, Docker jest bardziej popularny niż LXC. LXC jest popularny w środowiskach wbudowanych do wdrażania zabezpieczeń wokół procesów narażonych na podmioty zewnętrzne, takie jak Sieć i interfejs użytkownika. Docker jest popularny w chmurze, gdzie oczekuje się spójnego środowiska produkcyjnego.

Docker / LXC można uruchomić prawie na dowolnym tanim sprzęcie (mniej niż 1 GB pamięci jest również OK, jeśli masz nowsze jądro) vs. normalne maszyny wirtualne potrzebują co najmniej 2 GB pamięci itp., aby zrobić z nim cokolwiek znaczącego. Ale obsługa Dockera na systemie operacyjnym hosta nie jest dostępna w systemach operacyjnych takich jak Windows (od listopada 2014 r.), gdzie typy maszyn wirtualnych mogą być uruchamiane w systemach windows, Linux i Mac.

Oto zdjęcie z docker/rightscale :

1. Lightweight

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

Po Pierwsze, obrazy dokerów są zwykle mniejsze niż obrazy maszyn wirtualnych, co ułatwia tworzenie, kopiowanie i udostępnianie.

Po Drugie, kontenery Docker mogą uruchamiać się w ciągu kilku milisekund, podczas gdy VM uruchamia się w ciągu kilku sekund.

2. Layered File System

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

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

3. Shared OS Kernel

Pomyśl o kontenerach jak o procesach!

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

To jest dobre dla większości przypadków (nie utrzymuje się żadne dodatkowe jądro systemu operacyjnego), ale może być problemem, jeśli konieczne są ścisłe izolacje między kontenerami.

Dlaczego to ma znaczenie?

Pomyśl o wdrożeniu aplikacji. Jeśli chcemy wdrożyć nowe oprogramowanie (usługę) lub uaktualnić je, lepiej zmienić pliki konfiguracyjne i procesy zamiast tworzyć nową maszynę wirtualną. Ponieważ Tworzenie maszyny Wirtualnej z zaktualizowaną usługą, testowanie jej (udostępnianie między Dev i QA), wdrożenie 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ą (puppet, saltstack, chef itp.) aby zainstalować nowe oprogramowanie, preferowane jest pobieranie nowych plików.

Jeśli chodzi o Dockera, nie można użyć nowo utworzonego kontenera Dockera do zastąpienia starego. Konserwacja jest o wiele łatwiejsza!Budowanie nowego wizerunku, podziel się nim z QA, testowanie go, wdrożenie zajmuje tylko minuty( jeśli wszystko jest zautomatyzowane), godziny w najgorszym przypadku. Nazywa się to immutable infrastructure: nie utrzymuj(Aktualizuj) oprogramowania, zamiast tego utwórz nowe.

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

Docker, zasadniczo 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ętu . Czujesz, że jest 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 systemu operacyjnego. Środowisko (system operacyjny), w którym tworzysz aplikację, byłoby takie samo, gdy wdrażasz ją do różnych serwerów środowiska, takie jak "testowanie" lub "produkcja".

Na przykład, jeśli tworzysz serwer WWW, który działa na porcie 4000, po wdrożeniu go do środowiska "testowego", ten port jest już używany przez inny program, więc przestaje działać. W kontenerach są warstwy; wszystkie zmiany wprowadzone w systemie operacyjnym będą zapisywane w jednej lub kilku warstwach, a te warstwy będą częścią obrazu, więc gdziekolwiek pójdzie obraz, będą również obecne zależności.

W pokazanym przykładzie poniżej maszyna hosta ma trzy maszyny wirtualne. Aby zapewnić aplikacje w maszynach wirtualnych pełną izolację, każda 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. Natomiast poniższy rysunek pokazuje ten sam scenariusz z kontenerami. W tym przypadku kontenery po prostu współ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 pliki. Jedyną przyrostową przestrzenią, jaką zajmują, jest dowolna pamięć i miejsce na dysku niezbędne do uruchomienia aplikacji w kontenerze. Podczas gdy środowisko aplikacji przypomina dedykowany system operacyjny, aplikacja wdraża się tak, jak na dedykowanym hoście. Aplikacja kontenerowa uruchamia się w ciągu kilku sekund i wiele więcej instancji aplikacji może zmieścić się na maszynie niż w przypadku maszyny wirtualnej.

Źródło: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

W odniesieniu do:-

" dlaczego wdrażanie oprogramowania na obrazie dokera jest łatwiejsze niż po prostu wdrożenie do spójnego środowiska produkcyjnego ?"

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

1. indywidualny programista PC (s)
2. współdzielone środowisko programistyczne
3. indywidualny Tester PC (s)
4. Shared test environment
5. QA environment
6. środowisko UAT
7. załaduj / testy wydajności
8. inscenizacja na żywo
9. produkcja
10. archiwum

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

[9]}Programiści, a nawet testerzy, będą mieli subtelnie lub znacznie różne konfiguracje komputerów PC, ze względu na samą naturę pracy [10]}
• programiści mogą często rozwijać się na komputerach poza kontrolą korporacyjnych lub biznesowych zasad standaryzacji (np. freelancerzy, którzy rozwijają się na własnych maszynach (często zdalnie) lub autorzy projektów open source, którzy nie są "zatrudnieni" lub "zakontraktowani" w celu skonfigurowania swoich komputerów w określony sposób)
• niektóre środowiska będą składać się ze stałej liczby wielu maszyn w konfiguracji równoważonej obciążeniem
W wielu środowiskach produkcyjnych serwery oparte na chmurze będą tworzone dynamicznie (lub "elastycznie") i niszczone w zależności od poziomu ruchu]}

Jak widać ekstrapolowana całkowita liczba serwerów dla organizacji jest rzadko w pojedynczych figures, jest bardzo często w trzech figures i może być łatwo znacznie wyższe jeszcze.

To wszystko oznacza, że tworzenie spójnych środowisk w pierwszej kolejności jest wystarczająco trudne tylko ze względu na dużą objętość (nawet w scenariuszu green field), ale utrzymanie ich spójności jest niemożliwe biorąc pod uwagę dużą liczbę serwerów, dodawanie nowych serwerów (dynamicznie lub ręcznie), automatyczne aktualizacje od dostawców o/ S, producentów antywirusów, dostawców przeglądarek i tym podobnych, ręczne oprogramowanie instaluje lub zmienia konfigurację wykonywaną przez programistów lub techników serwerów itp. Pozwól, że powtórzę - praktycznie (nie zamierzony kalambur) niemożliwe jest utrzymanie spójnego Środowiska (ok, dla purystów można to zrobić, ale wymaga to ogromnej ilości czasu, wysiłku i dyscypliny, dlatego właśnie w pierwszej kolejności opracowano maszyny wirtualne i kontenery (np. Docker)).

Więc pomyśl o swoim pytaniu bardziej w ten sposób " biorąc pod uwagę ekstremalną trudność utrzymania wszystkich środowisk konsekwentnie, czy łatwiej jest wdrożyć oprogramowanie do obrazu dokera, nawet biorąc pod uwagę krzywą uczenia się ?". Myślę, że odpowiedź będzie niezmiennie brzmiała " tak " - ale jest tylko jeden sposób, aby się dowiedzieć, post to nowe pytanie na Stack Overflow.

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) tradycyjny stos serwera składa się z fizycznego serwera, który uruchamia system operacyjny i aplikację.

Zalety:

• Wykorzystanie surowca zasoby

• Isolation

Wady:

• bardzo powolny czas wdrożenia
• drogie
• Wasted resources
• trudne do skalowania
• trudny do migracji
• złożona konfiguracja

2) stos maszyn wirtualnych składa się z fizycznego serwera, na którym działa system operacyjny oraz hipernadzorcy, który zarządza maszyną wirtualną, współdzielonymi zasobami i interfejsem sieciowym. Każda maszyna wirtualna działa System operacyjny gościa, aplikacja lub zestaw aplikacji.

Zalety:

• dobre wykorzystanie zasobów
• łatwy w skalowaniu
Łatwe tworzenie kopii zapasowych i migracja]}
• efektywność kosztowa
• elastyczność

Wady:

• alokacja zasobów jest problematyczna
• Vendor lockin
• złożona konfiguracja

3) The Container Setup , the key różnica w stosunku do innych stosów polega na tym, że wirtualizacja oparta na kontenerach wykorzystuje jądro systemu operacyjnego hosta do rum wielu izolowanych wystąpień gości. Te instancje gości nazywane są kontenerami. Hostem może być serwer fizyczny lub maszyna wirtualna.

Zalety:

• Izolacja
• Lightweight
• efektywne wykorzystanie zasobów
• łatwa migracja
• bezpieczeństwo
• Low overhead
• produkcja i rozwój lustra środowisko

Wady:

• Ta Sama Architektura
• resource heavy apps
[[12]}problemy z siecią i bezpieczeństwem.

Porównując konfigurację kontenera z poprzednikami, możemy stwierdzić, że konteneryzacja jest najszybszą, najbardziej efektywną pod względem zasobów i najbezpieczniejszą konfiguracją, jaką znamy do tej pory. Kontenery to pojedyncze instancje, które uruchamiają aplikację. Docker podkręca kontener w sposób, warstwy uzyskują pamięć czasu pracy z domyślne sterowniki pamięci masowej (sterowniki Nakładki) te uruchamiają się w ciągu kilku sekund i warstwa kopiowania przy zapisie utworzona na niej po zatwierdzeniu do kontenera, która zasila wykonywanie kontenerów. W przypadku maszyn wirtualnych, których załadowanie do środowiska wirtualizacji zajmie około minuty. Te lekkie instancje można łatwo wymieniać, odbudowywać i przenosić. Pozwala nam to na odzwierciedlenie środowiska produkcyjnego i programistycznego i jest ogromną pomocą w procesach CI / CD. Zalety kontenery mogą dostarczyć są tak przekonujące, że na pewno tu zostaną.

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

Ważną różnicą jest to, że maszyny wirtualne używają oddzielnego jądra do uruchamiania systemu operacyjnego . Z tego powodu jest ciężki i wymaga czasu na rozruch, zużywając więcej zasobów systemowych.

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

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

Docker używa UNION File system .. Docker wykorzystuje technologię kopiowania przy zapisie, aby zmniejszyć przestrzeń pamięci zużywaną przez kontenery. Czytaj więcej tutaj

Z maszyną wirtualną mamy serwer, mamy system operacyjny hosta na tym serwerze, a następnie mamy hipernadzorcę. A następnie uruchomiony na tym hypervisorze, mamy dowolną liczbę systemów operacyjnych gościa z aplikacją i zależnymi od niej binariami i bibliotekami na tym serwerze. Niesie ze sobą cały system operacyjny gościa. Jest dość ciężki. Istnieje również limit, ile można rzeczywiście umieścić na każdym fizycznym maszyna.

Z drugiej strony kontenery Docker są nieco inne. Mamy serwer. Mamy system operacyjny hosta. Ale zamiast hipernadzorcy , mamy Docker engine , w tym przypadku. W tym przypadku nie zabieramy ze sobą całego systemu operacyjnego gościa. Wprowadzamy bardzo cienką warstwę systemu operacyjnego, a kontener może rozmawiać do systemu operacyjnego hosta, aby dostać się do funkcjonalności jądra tam. A to pozwala nam mieć bardzo lekki Pojemnik.

Wszystko, co tam ma, to kod aplikacji oraz wszelkie potrzebne binaria i biblioteki. A te binaria i biblioteki mogą być współdzielone między różnymi kontenerami, jeśli chcesz, aby były również. A to pozwala nam zrobić wiele rzeczy. Mają znacznie szybszy czas uruchamiania . Nie możesz wytrzymać jednej maszyny Wirtualnej w kilka sekund. I tak samo, likwidując je tak szybko.. więc możemy skaluj w górę iw dół bardzo szybko i przyjrzymy się temu później.

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 rodzajem kłamstwa. Jest zwirtualizowana.

Używałem Dockera w środowiskach produkcyjnych i stagingowych. Kiedy się do tego przyzwyczaisz, znajdziesz go bardzo wydajnego do budowania wielu kontenerów i izolowanych środowisk.

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

Kontenery Docker są izolowanymi środowiskami. Można go zobaczyć, gdy wydajesz polecenie top w kontenerze Dockera, który został utworzony z Dockera obraz.

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

Na przykład, możesz utworzyć obraz Dockera i skonfigurować plik Dockera i powiedzieć, że na przykład, gdy jest uruchomiony, to wget 'this', apt-get 'that', Uruchom 'some shell script', ustawiając zmienne środowiskowe i tak dalej.

W projektach mikrousług i architekturze Docker jest bardzo opłacalnym atutem. Możesz osiągnąć skalowalność, sprężystość i elastyczność dzięki Docker, Docker Rój, Kubernetes i Docker komponują.

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

Aby to zrobić, pobrałem skonfigurowane kontenery Docker dla zookeeper, kafka, Prometheus, Grafana i JMX-collector, a następnie zamontowałem własną konfigurację dla niektórych z nich za pomocą Plików yml lub dla innych zmieniłem niektóre pliki i konfigurację w kontener Dockera i ja budujemy cały system monitorowania Kafki za pomocą Dockerów wielokanałowych na jednej maszynie z izolacją, skalowalnością i odpornością, dzięki czemu Architektura ta może być łatwo przeniesiona na wiele serwerów.

Oprócz strony Docker Hub istnieje jeszcze jedna strona o nazwie quay.io możesz go użyć, aby mieć własny pulpit nawigacyjny Docker images i ciągnąć/wciskać do / z niego. Możesz nawet importować obrazy Dockera z Docker Hub do quay, a następnie samodzielnie uruchamiać je z quay maszyna.

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

Pamiętam pierwsze dni pracy z Dockerem, kiedy wydałem złe polecenia lub omyłkowo usuwałem moje kontenery i wszystkie dane i konfiguracje.

Tak przedstawia się Docker:

Docker to firma kierująca ruchem kontenerów i jedyna dostawcy platformy kontenerowej, aby zająć się każdą aplikacją w całym chmura hybrydowa. Dzisiejsze firmy są pod presją cyfryzacji przekształcić, ale są ograniczone przez istniejące aplikacje i infrastruktury, jednocześnie racjonalizując coraz bardziej zróżnicowany portfel chmury, centra danych i architektury aplikacji. Docker umożliwia prawda niezależność między aplikacjami a infrastrukturą oraz deweloperów i działów IT, aby odblokować ich potencjał i stworzyć model dla lepszej współpracy i innowacji.

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

Jeśli rozumiesz kontenery, dostajesz to, czym jest Docker i czym się różni od VM s...

Obraz kontenera jest lekkim, samodzielnym, wykonywalnym pakietem kawałek oprogramowania, który zawiera wszystko, co potrzebne do jego uruchomienia: kod, runtime, Narzędzia systemowe, biblioteki systemowe, Ustawienia. Dostępne dla obu Aplikacje oparte na Linuksie i Windows, oprogramowanie kontenerowe zawsze będzie działać to samo, niezależnie od środowiska. Containers isolate software z jego otoczenia, na przykład różnice między rozwojem a środowiska inscenizacyjne i pomagają zmniejszyć konflikty między działającymi zespołami różne oprogramowanie na tej samej infrastrukturze.

Tak więc jak widać na poniższym obrazku, każdy kontener ma oddzielny pakiet i działa na jednej maszynie Udostępnij system operacyjny tej maszyny... Są bezpieczne i łatwe do wysłania...

Jest tu wiele ładnych odpowiedzi technicznych, które wyraźnie omawiają różnice między maszynami wirtualnymi i kontenerami, a także pochodzenie Dockera.

Dla mnie podstawową różnicą między VMs a Dockerem jest sposób zarządzania promocją aplikacji.

Dzięki maszynom wirtualnym promujesz swoją aplikację i jej zależności od jednej maszyny Wirtualnej do następnej maszyny deweloperskiej, UAT do PRD.

1. często te maszyny wirtualne będą miały różne łatki i biblioteki.
2. nie jest rzadkością dla wiele aplikacji do współdzielenia maszyny wirtualnej. Wymaga to zarządzania konfiguracją i zależnościami dla wszystkich aplikacji.
3. cofnięcie wymaga cofnięcia zmian w maszynie wirtualnej. Lub przywrócenie go, jeśli to możliwe.

W aplikacji Docker chodzi o to, aby spakować aplikację do własnego kontenera wraz z bibliotekami, których potrzebuje, a następnie promować cały kontener jako pojedynczą jednostkę.

1. poza jądrem łaty i biblioteki są identyczne.
2. jako ogólna zasada na kontener jest tylko jedna aplikacja, co upraszcza konfigurację.
3. Backout polega na zatrzymaniu i usunięciu kontenera.

Więc na najbardziej podstawowym poziomie z VMs promujesz aplikację i jej zależności jako dyskretne komponenty, podczas gdy z Docker promujesz wszystko za jednym zamachem.

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

Źródło: Kubernetes w akcji.