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

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

Dlaczego wdrażanie oprogramowania na obrazie Docker (jeśli jest to właściwy termin) jest łatwiejsze niż zwykłe wdrażanie w spójnym środowisku produkcyjnym?

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

AuFS jest warstwowym systemem plików, więc możesz mieć część tylko do odczytu i część do zapisu, które są połączone. Można mieć wspólne części systemu operacyjnego jako tylko do odczytu (i współużytkowane przez wszystkie swoje kontenery), a następnie nadać każdemu kontenerowi własny montaż do pisania.

Załóżmy, że masz obraz kontenera o pojemności 1 GB; jeśli chcesz użyć pełnej maszyny wirtualnej, musisz mieć 1 GB x liczbę maszyn wirtualnych, które chcesz. Dzięki Docker i AuFS możesz współdzielić większość 1 GB między wszystkie kontenery, a jeśli masz 1000 kontenerów, nadal możesz mieć tylko nieco ponad 1 GB miejsca na system operacyjny kontenerów (zakładając, że wszystkie mają ten sam obraz systemu operacyjnego) .

W pełni zwirtualizowany system otrzymuje własny zestaw zasobów i zapewnia minimalne udostępnianie. Dostajesz więcej izolacji, ale jest znacznie cięższy (wymaga więcej zasobów). Dzięki Dockerowi masz mniej izolacji, ale pojemniki są lekkie (wymagają mniej zasobów). Możesz więc z łatwością uruchomić tysiące kontenerów na hoście, a nawet nie mrugnie. Spróbuj zrobić to z Xen i jeśli nie masz naprawdę dużego hosta, nie sądzę, że jest to możliwe.

Uruchomienie w pełni zwirtualizowanego systemu zajmuje zwykle kilka minut, a kontenery Docker / LXC / runC zajmują sekundy, a często nawet mniej niż sekundę.

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

Aby uzyskać więcej informacji, zapoznaj się z tym zestawem postów na blogu, które dobrze wyjaśniają działanie LXC.

Dlaczego wdrażanie oprogramowania na obrazie dokera (jeśli to właściwy termin) jest łatwiejsze niż zwykłe wdrażanie w spójnym środowisku produkcyjnym?

Wdrożenie spójnego środowiska produkcyjnego łatwiej powiedzieć niż zrobić. Nawet jeśli używasz narzędzi takich jak Chef i Puppet , zawsze są aktualizacje systemu operacyjnego i inne rzeczy, które zmieniają się między hostem a środowiskiem.

Docker umożliwia migawkę systemu operacyjnego na udostępnionym obrazie i ułatwia jego wdrożenie na innych hostach Docker. Lokalnie, dev, qa, prod itp .: wszystkie te same obrazy. Pewnie, że możesz to zrobić za pomocą innych narzędzi, ale nie tak łatwo lub 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 potrzebuje nieskazitelnej kopii bazy danych i wprowadzi zmiany w danych. Klasycznym podejściem jest resetowanie bazy danych po każdym teście za pomocą niestandardowego kodu lub narzędzi takich jak Flyway - może to być bardzo czasochłonne i oznacza, że ​​testy muszą być uruchamiane szeregowo. Jednak dzięki Dockerowi możesz utworzyć obraz bazy danych i uruchomić jedną instancję na test, a następnie uruchomić wszystkie testy równolegle, ponieważ wiesz, że wszystkie będą działać na tej samej migawce bazy danych. Ponieważ testy są przeprowadzane równolegle iw kontenerach Docker, mogą one być uruchamiane jednocześnie na tym samym pudełku i powinny zakończyć się znacznie szybciej. Spróbuj to zrobić z pełną maszyną wirtualną.

Z komentarzy ...

Ciekawy! Przypuszczam, że wciąż jestem zdezorientowany pojęciem „snapshot [ting] OS”. Jak można to zrobić bez tworzenia obrazu systemu operacyjnego?

Zobaczmy, czy potrafię wyjaśnić. Zaczynasz od obrazu podstawowego, a następnie wprowadzasz zmiany i zatwierdzasz je za pomocą okna dokowanego, a to tworzy obraz. Ten obraz zawiera tylko różnice w stosunku do bazy. Jeśli chcesz uruchomić obraz, potrzebujesz także podstawy, która nakłada obraz na podstawę za pomocą warstwowego systemu plików: jak wspomniano powyżej, Docker używa AuFS. AuFS scala różne warstwy razem i dostajesz to, czego chcesz; po prostu musisz go uruchomić. Możesz dodawać coraz więcej obrazów (warstw), a zapisywanie różnic będzie kontynuowane. Ponieważ Docker zwykle opiera się na gotowych obrazach z rejestru , rzadko trzeba samodzielnie „migawkować” cały system operacyjny.

Dobre odpowiedzi Aby uzyskać obrazową reprezentację kontenera kontra VM, spójrz na poniższy.

Źródło

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

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

Jak działa wirtualizacja na niskim poziomie?

W tym przypadku menedżer VM przejmuje pierścień procesora 0 (lub „tryb root” w nowszych procesorach) i przechwytuje wszystkie uprzywilejowane wywołania wykonane przez system operacyjny gościa, aby stworzyć złudzenie, że system operacyjny gościa ma własny sprzęt. Ciekawostka: przed 1998 rokiem uważano, że nie jest możliwe osiągnięcie tego w architekturze x86, ponieważ nie było możliwości przeprowadzenia tego rodzaju przechwytywania. Ludzie z VMWare byli pierwszymi, którzy wpadli na pomysł przepisania bajtów wykonywalnych w pamięci na uprzywilejowane wywołania systemu operacyjnego 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 operacyjny gościa przechodzi cały proces ładowania, ładowania jądra itp. Możesz mieć bardzo ścisłe zabezpieczenia, na przykład system operacyjny gościa nie może uzyskać pełnego dostępu do systemu hosta lub innych gości i zepsuć wszystko.

Jak działają pojemniki na niskim poziomie?

Około 2006 roku , ludzie w tym niektóre z pracowników firmy Google realizowane na poziomie jądra nowa funkcja o nazwie nazw (jakkolwiek idea długo zanim istniał w FreeBSD). Jedną z funkcji systemu operacyjnego jest umożliwienie współużytkowania globalnych zasobów, takich jak sieć i dysk, dla procesów. Co jeśli te globalne zasoby zostały zapakowane w przestrzenie nazw, aby były widoczne tylko dla procesów działających w tym samym obszarze 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 mają 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 globalnych zasobów. Tak działa okno dokowane: każdy kontener działa we własnej przestrzeni nazw, ale używa dokładnie tego samegojądro jak wszystkie inne pojemniki. Izolacja ma miejsce, ponieważ jądro zna przestrzeń nazw przypisaną do procesu, a podczas wywołań API upewnia się, że proces może uzyskiwać dostęp do zasobów tylko we własnej przestrzeni nazw.

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

Podoba mi się odpowiedź Kena Cochrane'a.

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

Według mnie mieści się w luce między narzędziami zorientowanymi na programistów, takimi jak rpm, pakiety Debian , Maven , npm + Git z jednej strony, a narzędziami operacyjnymi, takimi jak Puppet , VMware, Xen, nazywacie to ...

Dlaczego wdrażanie oprogramowania na obrazie dokera (jeśli to właściwy termin) jest łatwiejsze niż zwykłe wdrażanie w spójnym środowisku produkcyjnym?

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

Aby to zsynchronizować, zaczniesz używać czegoś takiego jak Puppet, Chef lub własne skrypty obsługi, niepublikowane reguły i / lub dużo dokumentacji ... Teoretycznie serwery mogą działać w nieskończoność, zachowując pełną spójność i aktualność. Praktyka nie pozwala całkowicie zarządzać konfiguracją serwera, więc istnieje znaczny zakres dryfu konfiguracji i nieoczekiwanych zmian w działających serwerach.

Istnieje więc znany wzorzec tego, tak zwany niezmienny serwer . Ale niezmienny wzorzec serwera nie był kochany. Głównie ze względu na ograniczenia maszyn wirtualnych używanych 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. Zrozumiale...

Dzięki ekosystemowi Docker nigdy nie będziesz musiał poruszać się w 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 się martwić wersjami tego obrazu.

I w końcu nawet często będziesz w stanie odtworzyć złożone środowiska produkcyjne nawet na swoim laptopie z systemem Linux (nie dzwoń do mnie, jeśli nie działa w twoim przypadku;))

I oczywiście możesz uruchomić kontenery Docker na maszynach wirtualnych (to dobry pomysł). Ogranicz obsługę administracyjną serwera na poziomie maszyny wirtualnej. Wszystkim powyższym może zarządzać Docker.

PS Tymczasem Docker używa 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 wdrażają 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 przemianowano na runc. Docker koncentruje się przede wszystkim na automatyzacji wdrażania aplikacji w kontenerach aplikacji. Kontenery aplikacji są zaprojektowane do pakowania i uruchamiania pojedynczej usługi, podczas gdy kontenery systemowe są zaprojektowane do uruchamiania wielu procesów, takich jak maszyny wirtualne. 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 tam różnica.

Wirtualizacja

W swojej wymyślonej formie uznano ją za metodę logicznego dzielenia komputerów mainframe, aby umożliwić jednoczesne działanie wielu aplikacji. 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 uruchomienie wielu systemów operacyjnych w jednym systemie opartym na architekturze x86.

Hypervisor

Hiperwizor obsługuje tworzenie wirtualnego środowiska, w 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 na maszynach wirtualnych. Aby to zrealizować, przechwytuje operacje systemu operacyjnego gościa na maszynach wirtualnych i emuluje operację w systemie operacyjnym hosta.

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

Rodzaje wirtualizacji

Metodę wirtualizacji można podzielić na kategorie na podstawie tego, jak naśladuje sprzęt w systemie operacyjnym gościa i emuluje środowisko operacyjne gościa. Przede wszystkim istnieją trzy typy wirtualizacji:

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

Współzawodnictwo

Emulacja, znana również jako pełna wirtualizacja, uruchamia jądro systemu operacyjnego maszyny wirtualnej całkowicie w oprogramowaniu. Hiperwizor stosowany w tym typie jest znany jako hiperwizor typu 2. Jest instalowany w systemie operacyjnym hosta, który jest odpowiedzialny za tłumaczenie kodu jądra systemu operacyjnego gościa na instrukcje oprogramowania. Tłumaczenie odbywa się całkowicie w oprogramowaniu i nie wymaga udziału sprzętu. Emulacja umożliwia uruchomienie dowolnego niezmodyfikowanego systemu operacyjnego, który obsługuje emulowane środowisko. Wadą tego rodzaju wirtualizacji jest dodatkowy narzut zasobów systemowych, który prowadzi do zmniejszenia wydajności w porównaniu do innych rodzajów wirtualizacji.

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

Parawirtualizacja

Parawirtualizacja, znana również jako hiperwizor typu 1, działa bezpośrednio na sprzęcie lub „bez systemu” i zapewnia usługi wirtualizacji bezpośrednio na uruchomionych na nim maszynach wirtualnych. Pomaga systemowi operacyjnemu, zwirtualizowanemu sprzętowi i prawdziwemu sprzętowi współpracować w celu osiągnięcia optymalnej wydajności. Te hiperwizory zwykle mają raczej niewielką powierzchnię i same w sobie nie wymagają dużych zasobów.

Przykłady w tej kategorii to Xen, KVM itp.

Wirtualizacja oparta na kontenerach

Wirtualizacja oparta na kontenerach, zwana również wirtualizacją na poziomie systemu operacyjnego, umożliwia wiele izolowanych wykonań w ramach jednego jądra systemu operacyjnego. Ma najlepszą możliwą wydajność i gęstość oraz funkcje dynamicznego zarządzania zasobami. Izolowane wirtualne środowisko wykonawcze zapewniane przez ten typ wirtualizacji nazywane jest kontenerem i może być postrzegane 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. Dostęp do niego ma wywołanie systemowe clone () , które umożliwia tworzenie oddzielnych instancji wcześniej globalnych przestrzeni nazw.

Przestrzeni nazw można używać na wiele różnych sposobów, ale najczęstszym podejściem jest utworzenie izolowanego kontenera, który nie ma widoczności ani dostępu do obiektów poza kontenerem. Wydaje się, że procesy działające w kontenerze działają w normalnym systemie Linux, chociaż współużytkują jądro bazowe z procesami znajdującymi się w innych przestrzeniach nazw, tak samo jak w przypadku innych rodzajów obiektów. Na przykład podczas korzystania z przestrzeni nazw użytkownik root w kontenerze nie jest traktowany jak root poza kontem, co zwiększa bezpieczeństwo.

Podsystem Linux Control Groups (cgroups), kolejny główny komponent umożliwiający wirtualizację opartą na kontenerach, służy do grupowania procesów i zarządzania ich zagregowanym zużyciem zasobów. Jest powszechnie stosowany w celu ograniczenia zużycia pamięci i procesora przez pojemniki. 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.

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

Kontenery kontra maszyny wirtualne

W przeciwieństwie do maszyny wirtualnej, kontener nie musi uruchamiać jądra systemu operacyjnego, więc kontenery można utworzyć w niecałą sekundę. Ta funkcja sprawia, że ​​wirtualizacja oparta na kontenerach jest wyjątkowa i pożądana niż inne metody wirtualizacji.

Ponieważ wirtualizacja oparta na kontenerach wnosi niewielki lub żaden narzut na maszynę hosta, wirtualizacja oparta na kontenerach ma prawie natywną wydajność

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

Wszystkie kontenery na maszynie hosta współdzielą program planujący maszynę hosta, oszczędzając zapotrzebowanie na 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 można łatwo dystrybuować.

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 na maszynach wirtualnych, ale nie można ich użyć. Można to zrealizować, uruchamiając jednocześnie toplub htopna kontenerach i maszynie hosta. Dane wyjściowe we wszystkich środowiskach będą wyglądać podobnie.

Aktualizacja:

Jak Docker obsługuje kontenery w systemach innych niż Linux?

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 inne niż Linux uruchamiają kontenery. Zarówno Docker dla komputerów Mac, jak i Windows używają maszyn wirtualnych z systemem Linux do uruchamiania kontenerów. Docker Toolbox służy do uruchamiania kontenerów w maszynach wirtualnych Virtual Box. Ale najnowszy Docker używa Hyper-V w Windows i Hypervisor.framework w Mac.

Teraz opiszę szczegółowo, w jaki sposób Docker dla komputerów Mac szczegółowo uruchamia kontenery.

Docker dla komputerów Mac używa https://github.com/moby/hyperkit do emulowania funkcji hypervisora, a Hyperkit korzysta z hypervisor.framework w swoim rdzeniu. Hypervisor.framework to natywne rozwiązanie hypervisora ​​dla komputerów Mac. Hyperkit używa również VPNKit i DataKit do odpowiednio przestrzeni sieci i systemu plików.

Maszyna wirtualna z systemem Linux, którą Docker działa na komputerze Mac, jest tylko do odczytu. Możesz jednak zaatakować go, uruchamiając:

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

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

# 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 dotyczące hypervisor.framework. Z tego powodu Docker nie ujawnia docker0interfejsu sieciowego na komputerze Mac. Tak więc nie możesz uzyskać dostępu do kontenerów z hosta. Na razie docker0jest dostępny tylko w maszynie wirtualnej.

Hyper-v to natywny hypervisor w systemie Windows. Próbują również wykorzystać możliwości systemu Windows 10 do natywnego uruchamiania systemów Linux.

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

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 nazywana gościem, a środowisko, w którym działa, nazywane jest 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 (hoście LXC). Kontenery Linux służą jako lekka alternatywa dla maszyn wirtualnych, ponieważ nie wymagają mianowicie hypervisors. Virtualbox, KVM, Xen itp.

Teraz, chyba że zostałeś odurzony przez Alana (Zach Galifianakis - z serii Hangover) i byłeś w Vegas przez ostatni rok, będziesz dość świadomy ogromnego zainteresowania technologią Linux, a jeśli będę konkretny Projekt, który wywołał burzę na całym świecie w ciągu ostatnich kilku miesięcy, jest - Docker prowadzi do niektórych powtarzających się opinii, że środowiska przetwarzania w chmurze powinny porzucić maszyny wirtualne (VM) i zastąpić je kontenerami ze względu na ich niższe koszty i potencjalnie lepszą wydajność.

Ale najważniejsze pytanie brzmi: czy jest to wykonalne? Czy będzie sensowne?

za. LXC mają zasięg do instancji Linuksa. Mogą to być różne smaki Linuksa (np. Kontener Ubuntu na hoście CentOS, ale nadal jest to Linux). Podobnie, kontenery oparte na systemie Windows mają teraz zasięg do instancji Windows, jeśli spojrzymy na maszyny wirtualne, mają one znacznie szerszy zakres i używają hiperwizory 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 mianowicie. Platforma dokująca zbudowana na ramionach technologii LXC zapewniła programistom platformę do uruchamiania aplikacji, a jednocześnie umożliwiła pracownikom operacyjnym narzędzie, które pozwoli im wdrożyć ten sam kontener na serwerach produkcyjnych lub centrach danych. Stara się sprawić, by programista uruchamiający aplikację, uruchamiający i testujący aplikację oraz operator wdrażający tę aplikację bezproblemowo, ponieważ w tym tkwi cała trudność i celem DevOps jest rozbicie tych silosów.

Dlatego najlepszym podejściem jest 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 jest obecnie niepraktyczne. 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 jednoznaczną odpowiedź na to pytanie, która pomogła mi najbardziej w ciągu ostatnich kilku lat korzystania z Dockera. To jest to:

Docker to tylko fantazyjny sposób na uruchomienie procesu, a nie maszyna wirtualna.

Teraz pozwól mi wyjaśnić nieco więcej, co to oznacza. Maszyny wirtualne są ich własną bestią. Wyjaśnienie, czym jest Docker , pomoże ci zrozumieć to bardziej niż wyjaśnienie, czym jest maszyna wirtualna. Zwłaszcza, że ​​istnieje wiele dobrych odpowiedzi, które dokładnie mówią, co ktoś ma na myśli, gdy mówi „maszyna wirtualna”. Więc...

Kontener Docker jest po prostu procesem (i jego elementami potomnymi), który jest podzielony na partycje za pomocą grup cgroup w jądrze systemu hosta od pozostałych procesów. Rzeczywiście możesz zobaczyć swoje procesy kontenerowe Docker, uruchamiając ps auxsię na hoście. Na przykład uruchomienie apache2„w kontenerze” zaczyna się apache2jako specjalny proces na hoście. Właśnie został podzielony na inne procesy na maszynie. Ważne jest, aby pamiętać, że twoje kontenery nie istnieją poza okresem użytkowania procesu konteneryzowanego. Kiedy proces umiera, pojemnik umiera. Wynika to z faktu, że Docker zastępuje pid 1wewnątrz kontenera aplikacją ( pid 1zwykle jest to system init). Ten ostatni punkt pid 1jest bardzo ważny.

Jeśli chodzi o system plików używany przez każdy z tych procesów kontenerowych, Docker używa obrazów zabezpieczonych przez UnionFS, które pobierasz po wykonaniu docker pull ubuntu. Każdy „obraz” jest tylko serią warstw i powiązanych metadanych. Bardzo ważna jest tutaj koncepcja nakładania warstw. Każda warstwa jest tylko zmianą w stosunku do warstwy pod nią. Na przykład, gdy usuwasz plik ze swojego pliku Docker podczas budowania kontenera Docker, w rzeczywistości tworzysz warstwę na ostatniej warstwie, która mówi „ten plik został usunięty”. Nawiasem mówiąc, dlatego możesz usunąć duży plik ze swojego systemu plików, ale obraz nadal zajmuje tyle samo miejsca na dysku. Plik nadal tam jest, w warstwach pod bieżącą. Same warstwy to tylko pliki tar. Możesz to sprawdzić za pomocądocker save --output /tmp/ubuntu.tar ubuntui potem 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 zawiera pliki ( layer.tar) i metadane (json) z informacjami o tej konkretnej warstwie. Warstwy te opisują po prostu zmiany w systemie plików, które są zapisywane jako warstwa „nad” pierwotnym stanem. Podczas odczytywania „bieżących” danych system plików odczytuje dane tak, jakby patrzyły tylko na najwyższe warstwy zmian. Dlatego wydaje się, że plik został usunięty, mimo że nadal istnieje na „poprzednich” warstwach, ponieważ system plików patrzy tylko na najwyższe warstwy. Pozwala to zupełnie innym kontenerom na dzielenie się warstwami systemu plików, nawet jeśli mogły wystąpić pewne znaczące zmiany w systemie plików na najwyższych warstwach w każdym kontenerze. Pozwala to zaoszczędzić mnóstwo miejsca na dysku, gdy kontenery współużytkują swoje podstawowe warstwy obrazu. Jednak,

Praca w sieci w Docker odbywa się za pomocą mostka Ethernet (wywoływanego docker0na hoście) oraz interfejsów wirtualnych dla każdego kontenera na hoście. Tworzy wirtualną podsieć docker0dla twoich kontenerów do komunikowania się „między” sobą. Dostępnych jest tutaj wiele opcji sieciowych, w tym tworzenie niestandardowych podsieci dla kontenerów oraz możliwość „udostępniania” stosu sieciowego hosta, aby kontener mógł uzyskać bezpośredni dostęp.

Doker porusza się bardzo szybko. Jego dokumentacja jest jedną z najlepszych dokumentów, jakie 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 zaufać dokumentacji nad wszystkim, co czytasz online, w tym nad przepełnieniem stosu. Jeśli masz konkretne pytania, bardzo polecam dołączyć #dockerdo Freenode IRC i zadać tam pytanie (możesz nawet użyć do tego czatu internetowego Freenode !).

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

Wirtualizator zawiera system operacyjny, który może uruchamiać dowolne aplikacje, które normalnie może działać na maszynie bez systemu operacyjnego.

Oba są bardzo różne. Docker jest lekki i wykorzystuje LXC / libcontainer (który opiera się na przestrzeni nazw jądra i grupach cg) i nie ma emulacji komputera / sprzętu, takiej jak hypervisor, KVM. Xen, które są ciężkie.

Docker i LXC są przeznaczone bardziej do piaskownicy, konteneryzacji i izolacji zasobów. Wykorzystuje API klonu systemu operacyjnego hosta (obecnie tylko jądro Linux), które zapewnia przestrzeń nazw dla IPC, NS (montowanie), sieci, PID, UTS itp.

Co z pamięcią, I / O, CPU itp.? Jest to kontrolowane za pomocą cgroups, w których można tworzyć grupy o określonych specyfikacjach / ograniczeniach dotyczących zasobów (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 przestrzeniami nazw montowania.

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

W normalnym LXC musisz przyjść z niektórymi rootfami lub współdzielić rootfy i kiedy są udostępnione, a zmiany są odzwierciedlone w innych kontenerach. Z powodu wielu dodanych funkcji Docker jest bardziej popularny niż LXC. LXC jest popularny w środowiskach osadzonych do wdrażania zabezpieczeń wokół procesów narażonych na zewnętrzne podmioty, takie jak sieć i interfejs użytkownika. Docker jest popularny w chmurowym środowisku wielodostępnym, w którym oczekuje się spójnego środowiska produkcyjnego.

Normalna maszyna wirtualna (na przykład VirtualBox i VMware) korzysta z hiperwizora, a pokrewne technologie mają dedykowane oprogramowanie układowe, które staje się pierwszą warstwą dla pierwszego systemu operacyjnego (system hosta lub system gościa 0) lub oprogramowanie, które działa na systemie hosta w celu zapewnić emulację sprzętową, taką 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 bezpieczeństwa.

Docker / LXC można prawie uruchomić na dowolnym tanim sprzęcie (mniej niż 1 GB pamięci jest również OK, o ile masz nowsze jądro) w porównaniu z normalnymi maszynami wirtualnymi potrzebują co najmniej 2 GB pamięci itp., Aby zrobić z nim cokolwiek sensownego . Jednak obsługa Docker w systemie operacyjnym hosta nie jest dostępna w systemach operacyjnych takich jak Windows (od listopada 2014 r.), W których typy maszyn wirtualnych mogą być uruchamiane w systemach Windows, Linux i Mac.

Oto zdjęcie z okna dokowanego / skali praw:

1. Lekki

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

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

Po drugie, kontenery Docker można uruchomić w kilka milisekund, a VM uruchamia się w kilka sekund.

2. Warstwowy system plików

To kolejna kluczowa funkcja Dockera. Obrazy mają warstwy, a różne obrazy mogą współdzielić warstwy, dzięki czemu oszczędza miejsce i przyspiesza budowę.

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

3. Wspólne jądro systemu operacyjnego

Pomyśl o pojemnikach jak o procesach!

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

Jest to dobre w większości przypadków (nie utrzymuje się dodatkowe jądro systemu operacyjnego), ale może stanowić problem, jeśli konieczne są ścisłe izolacje między kontenerami.

Dlaczego jest to ważne?

Wszystko to wydaje się ulepszeniem, a nie rewolucją. Cóż, akumulacja ilościowa prowadzi do transformacji jakościowej .

Pomyśl o wdrożeniu aplikacji. Jeśli chcemy wdrożyć nowe oprogramowanie (usługę) lub uaktualnić, lepiej jest zmienić pliki konfiguracyjne i procesy zamiast tworzyć nową maszynę wirtualną. Ponieważ tworzenie maszyny wirtualnej za pomocą zaktualizowanej usługi, testowanie jej (udział między deweloperami i kontrolą jakości), wdrożenie do produkcji zajmuje godziny, a nawet dni. Jeśli coś pójdzie nie tak, musisz zacząć od nowa, marnując jeszcze więcej czasu. Tak więc użyj narzędzia do zarządzania konfiguracją (marionetka, gra w soli, szefa kuchni itp.), Aby zainstalować nowe oprogramowanie, preferowane jest pobieranie nowych plików.

Jeśli chodzi o dokera, nie można użyć nowo utworzonego kontenera dokera do zastąpienia starego. Utrzymanie jest znacznie łatwiejsze! Budowanie nowego obrazu, dzielenie się nim z kontrolą jakości, testowanie, wdrażanie zajmuje tylko minuty (jeśli wszystko jest zautomatyzowane), w najgorszym przypadku godziny. Nazywa się to niezmienną infrastrukturą : 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 wszystko wygładza.

Docker, zasadniczo kontenery, obsługuje wirtualizację systemu operacyjnego, tzn. Aplikacja czuje, że ma pełną instancję systemu operacyjnego, podczas gdy VM obsługuje wirtualizację sprzętu . Czujesz, że jest to fizyczna maszyna, na której można uruchomić dowolny system operacyjny.

W Dockerze uruchomione kontenery współużytkują jądro systemu operacyjnego, podczas gdy na maszynach wirtualnych mają własne pliki systemu operacyjnego. Ś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 opracujesz serwer WWW działający na porcie 4000, po wdrożeniu go w środowisku „testowym”, port ten jest już używany przez inny program, więc przestaje działać. W pojemnikach są warstwy; wszystkie zmiany, które wprowadziłeś w systemie operacyjnym, byłyby zapisywane na jednej lub więcej warstwach, a warstwy te byłyby częścią obrazu, więc gdziekolwiek obraz się znajdzie, zależności również byłyby obecne.

W poniższym przykładzie komputer hosta ma trzy maszyny wirtualne. Aby zapewnić aplikacjom maszyn 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 pojemnikami. W tym przypadku kontenery po prostu współużytkują system operacyjny hosta, w tym jądro i biblioteki, więc nie muszą uruchamiać systemu operacyjnego, ładować bibliotek ani płacić za te pliki prywatnego kosztu pamięci. Jedyne zajmowane przez nich miejsce to dowolna pamięć i miejsce na dysku niezbędne do uruchomienia aplikacji w kontenerze. Podczas gdy środowisko aplikacji wydaje się być dedykowanym systemem operacyjnym, aplikacja wdraża się tak, jak na dedykowanym hoście. Aplikacja w kontenerze uruchamia się w ciągu kilku sekund, a na urządzeniu może się zmieścić znacznie więcej instancji aplikacji niż w przypadku maszyny wirtualnej.

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

Istnieją trzy różne konfiguracje, które zapewniają stos do uruchamiania 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 serwerów składa się z fizycznego serwera z systemem operacyjnym i aplikacją.

Zalety:

• Wykorzystanie surowców

• Izolacja

Niedogodności:

• Bardzo wolny czas wdrażania
• Kosztowny
• Zmarnowane zasoby
• Trudne do skalowania
• Trudno migrować
• Złożona konfiguracja

2) Stos maszyn wirtualnych składa się z fizycznego serwera, na którym działa system operacyjny i hiperwizora, który zarządza maszyną wirtualną, współdzielonymi zasobami 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ść

Niedogodności:

• Przydział zasobów jest problematyczny
• Blokowanie się dostawcy
• Złożona konfiguracja

3) Konfiguracja kontenera , kluczowa różnica w stosunku do innych stosów polega na tym, że wirtualizacja oparta na kontenerach wykorzystuje jądro systemu operacyjnego hosta do przeszukiwania wielu izolowanych wystąpień gościa. Te instancje gościa są wywoływane jako kontenery. Host może być serwerem fizycznym lub maszyną wirtualną.

Zalety:

• Izolacja
• Lekki
• Efektywne zasoby
• Łatwa migracja
• Bezpieczeństwo
• Niskie koszty ogólne
• Lustrzane środowisko produkcyjne i programistyczne

Niedogodności:

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

Porównując konfigurację kontenera z jego poprzednikami, możemy stwierdzić, że konteneryzacja jest najszybszą, najbardziej zasobooszczędną i najbezpieczniejszą konfiguracją, jaką znamy do tej pory. Kontenery to izolowane instancje uruchamiające aplikację. Docker w pewien sposób podkręca kontener, warstwy uzyskują pamięć czasu działania z domyślnymi sterownikami pamięci (sterowniki nakładki), które działają w ciągu kilku sekund, a warstwa kopiowania przy zapisie utworzona na nim po zatwierdzeniu do kontenera, która zasila wykonanie pojemnikiW przypadku maszyn wirtualnych ładowanie wszystkiego do środowiska wirtualizacji zajmie około minuty. Te lekkie instancje można łatwo wymienić, odbudować i przenieść. To pozwala nam odzwierciedlać środowisko produkcyjne i programistyczne i stanowi ogromną pomoc w procesach CI / CD. Zalety, jakie mogą zapewnić pojemniki, są tak przekonujące, że zdecydowanie pozostaną.

W związku z:-

„Dlaczego wdrażanie oprogramowania na obrazie dokera jest łatwiejsze niż zwykłe wdrażanie w spójnym środowisku produkcyjnym?”

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

1. Komputery indywidualne programistów
2. Wspólne środowisko programistyczne
3. Indywidualne komputery PC testera
4. Wspólne środowisko testowe
5. Środowisko kontroli jakości
6. Środowisko UAT
7. Testy obciążenia / wydajności
8. Inscenizacja na żywo
9. Produkcja
10. Archiwum

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

• Programiści, a nawet testerzy, będą mieli subtelnie lub bardzo różne konfiguracje komputerów PC, z uwagi na charakter zadania
• Deweloperzy często mogą rozwijać się na komputerach PC poza kontrolą reguł standaryzacji korporacyjnej lub biznesowej (np. Freelancerzy, którzy rozwijają się na własnych komputerach (często zdalnie) lub wspierają projekty typu open source, które nie są „zatrudnione” lub „zakontraktowane” w celu konfiguracji komputerów droga)
• Niektóre środowiska składają się ze stałej liczby wielu komputerów w konfiguracji z równoważeniem obciążenia
• W wielu środowiskach produkcyjnych serwery oparte na chmurze będą dynamicznie (lub „elastycznie”) tworzone i niszczone w zależności od natężenia ruchu

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

Wszystko to oznacza, że ​​tworzenie spójnych środowisk jest przede wszystkim wystarczająco trudne ze względu na samą objętość (nawet w scenariuszu z zielonym polem), ale utrzymanie ich spójności jest prawie 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, antywirusów, przeglądarek itp., ręczne instalacje oprogramowania lub zmiany konfiguracji dokonywane przez programistów lub techników serwerów itp. Powtórzę - to praktycznie (bez zamierzonej gry słów) niemożliwe aby zachować spójność środowisk (w porządku, dla purystów można to zrobić, ale wymaga to ogromnego czasu, wysiłku i dyscypliny, i właśnie dlatego właśnie opracowano maszyny wirtualne i kontenery (np. Docker)).

Pomyśl więc o swoim pytaniu w ten sposób: „Biorąc pod uwagę ogromną trudność utrzymania 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ę dowiedzieć, opublikuj nowe pytanie na temat przepełnienia stosu.

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

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

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

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 zatem są wysoce skalowalne.

Docker korzysta z systemu plików UNION . Docker wykorzystuje technologię kopiowania przy zapisie, aby zmniejszyć ilość pamięci zajmowanej przez kontenery. Przeczytaj więcej tutaj

Dzięki maszynie wirtualnej mamy serwer, mamy system operacyjny hosta na tym serwerze, a następnie mamy hypervisor. A następnie działając na tym hiperwizorze, mamy dowolną liczbę systemów operacyjnych gościa z aplikacją i jej zależnymi plikami binarnymi oraz bibliotekami na tym serwerze. Wnosi cały system operacyjny gościa. Jest dość ciężki. Istnieje również limit, ile faktycznie można umieścić na każdej maszynie fizycznej.

Z drugiej strony pojemniki dokowe są nieco inne. Mamy serwer. Mamy system operacyjny hosta. Ale zamiast tego hiperwizora mamy w tym przypadku silnik Docker . W tym przypadku nie zabieramy ze sobą całego systemu operacyjnego gościa. Wprowadzamy bardzo cienką warstwę systemu operacyjnego , a kontener może komunikować się z systemem operacyjnym hosta, aby uzyskać dostęp do funkcji jądra. A to pozwala nam mieć bardzo lekki pojemnik.

Ma tam tylko kod aplikacji oraz wymagane przez niego pliki binarne i biblioteki. Te pliki binarne i biblioteki mogą być współużytkowane przez różne kontenery, jeśli chcesz, aby były również. A to pozwala nam robić, jest wiele rzeczy. Mają znacznie szybszy czas uruchamiania . Nie możesz znieść pojedynczej maszyny wirtualnej w ciągu kilku sekund. Równie szybko zdejmując je ... dzięki czemu możemy bardzo szybko skalować w górę i w dół, a my przyjrzymy się temu później.

Każdy kontener uważa, że ​​działa na własnej kopii systemu operacyjnego. Ma własny system plików, własny rejestr itp., Co jest rodzajem kłamstwa. W rzeczywistości jest wirtualizowany.

Źródło: Kubernetes in Action.

Bardzo często korzystałem z Dockera w środowiskach produkcyjnych i scenicznych. Kiedy się do tego przyzwyczaisz, przekonasz się, że jest bardzo wydajny do budowania wielu kontenerów i odizolowanych środowisk.

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

Kontenery dokowe to izolowane środowiska. Możesz to zobaczyć po wydaniu toppolecenia 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 Docker i powiedzieć, że na przykład, gdy jest uruchomiony, wget 'this', apt-get 'that', uruchom 'jakiś skrypt powłoki, ustawiając zmienne środowiskowe i tak dalej.

W projektach i architekturze mikrousług Docker jest bardzo opłacalnym zasobem. Możesz uzyskać 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 Docker.

W tym celu pobrałem skonfigurowane kontenery Docker dla Zookeepera, Kafki, Prometheusa, Grafany i jmx-collectora, a następnie podłączyłem własną konfigurację dla niektórych z nich za pomocą plików YAML, lub dla innych zmieniłem niektóre pliki i konfigurację w kontenerze Docker i ja zbuduj cały system do monitorowania Kafki za pomocą dokerów wielokontenerowych na jednym komputerze z izolacją, skalowalnością i odpornością, aby tę architekturę można łatwo przenieść na wiele serwerów.

Oprócz witryny Docker Hub istnieje jeszcze jedna strona o nazwie quay.io, której można użyć, aby mieć tam własny pulpit nawigacyjny z obrazami Docker i ciągnąć / naciskać na niego. Możesz nawet importować obrazy Docker z Docker Hub do nabrzeża, a następnie uruchamiać je z nabrzeża na własnym komputerze.

Uwaga: Nauka Dockera wydaje się przede wszystkim złożona i trudna, ale kiedy się przyzwyczaisz, nie będziesz mógł bez niego pracować.

Pamiętam pierwsze dni pracy z Dockerem, kiedy błędnie wydałem niewłaściwe polecenia lub usunąłem swoje pojemniki oraz wszystkie dane i konfiguracje.

Oto jak Docker się przedstawia:

Docker to firma kierująca ruchem kontenerów i jedyny dostawca platformy kontenerowej, który obsługuje każdą aplikację w chmurze hybrydowej. Dzisiejsze firmy znajdują się pod presją cyfrowej transformacji, ale są ograniczone istniejącymi aplikacjami i infrastrukturą, jednocześnie racjonalizując coraz bardziej zróżnicowane portfolio chmur, centrów danych i architektur aplikacji. Docker zapewnia prawdziwą niezależność między aplikacjami i infrastrukturą a programistami i działami IT w celu uwolnienia ich potencjału i tworzy model lepszej współpracy i innowacji.

Więc Docker opiera się pojemnik, czyli masz obrazy i pojemników, które mogą być uruchamiane na aktualnym urządzeniu. Nie obejmuje systemu operacyjnego, takiego jak maszyny wirtualne , ale jak pakiet różnych działających pakietów, takich jak Java, Tomcat itp.

Jeśli rozumiesz kontenery, wiesz, czym jest Docker i czym różni się od maszyn VM ...

Czym jest pojemnik?

Obraz kontenera to lekki, autonomiczny, wykonywalny pakiet oprogramowania, który zawiera wszystko, co jest potrzebne do jego uruchomienia: kod, środowisko wykonawcze, narzędzia systemowe, biblioteki systemowe, ustawienia. Dostępne w aplikacjach opartych na systemie Linux i Windows oprogramowanie w kontenerze zawsze będzie działać tak samo, niezależnie od środowiska. Kontenery izolują oprogramowanie od otoczenia, na przykład różnice między środowiskiem programistycznym i testowym oraz pomagają zmniejszyć konflikty między zespołami, które używają różnych programów w tej samej infrastrukturze.

Jak widać na poniższym obrazku, każdy pojemnik ma osobne opakowanie i działa na jednym komputerze z systemem operacyjnym tego komputera ... Są bezpieczne i łatwe do wysyłki ...

Istnieje wiele fajnych 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 maszynami wirtualnymi a Dockerem jest sposób zarządzania promocją aplikacji.

Za pomocą maszyn wirtualnych promujesz swoją aplikację i jej zależności od jednej maszyny wirtualnej do następnej wersji DEV, UAT i PRD.

1. Często te maszyny wirtualne będą miały różne łatki 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. Wycofanie wymaga cofnięcia zmian w maszynie wirtualnej. Lub przywracanie, jeśli to możliwe.

W przypadku Docker chodzi o to, aby spakować aplikację do własnego kontenera wraz z potrzebnymi bibliotekami, a następnie wypromować cały kontener jako pojedynczą jednostkę.

1. Z wyjątkiem jądra, łaty i biblioteki są identyczne.
2. Zasadniczo istnieje tylko jedna aplikacja na kontener, co upraszcza konfigurację.
3. Wycofanie polega na zatrzymaniu i usunięciu kontenera.

Zatem na najbardziej podstawowym poziomie z maszynami wirtualnymi promujesz aplikację i jej zależności jako odrębne komponenty, podczas gdy dzięki Docker promujesz wszystko za jednym razem.

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