Nie wszystko, co nowe, jest dobre i nie wszystko, co rewolucyjne, jest konieczne. Dzięki technologiom kontenerowym, jak w przypadku każdej innej „następnej wielkiej rzeczy”, widzimy szalejący wynalezienie abstrakcji na wyższym poziomie, a następnie wdrażanie w produkcji, z całą infrastrukturą CD/CI zależną od tego i DevOps, nie rozumiejąc tego, co faktycznie robi.
Zacznijmy od tego, czym faktycznie były pojemniki, historycznie. Na początku 2000 roku FreeBSD wprowadził pojęcie „więzień”, które oferowały nowe środowisko, takie jak nowa instalacja systemu operacyjnego, który oferuje całą bibliotekę FreeBSD i infrastrukturę jądra, która jest już na miejscu. Czyste tablice dla programistów do testowania nowego oprogramowania.
Jest to wyraźne kontrast z VMware, KVM lub VirtualBox, takimi jak technologie, w których całe sprzęt jest zwirtualizowane, gdzie system operacyjny hosta oferuje wirtualny zestaw procesora, pamięci RAM i innych zasobów. Twój system operacyjny gości znajduje się na podstawie tych wirtualnych zasobów sprzętowych. Prawie każda warstwa abstrakcji jest powtarzana dwukrotnie, a zasoby, takie jak RAM i CPU, kiedyś przydzielone gościowi nie są już dostępne dla gospodarza (niezależnie od tego, czy gość je całkowicie używa).
W przypadku wirtualizacji systemu operacyjnego kontenery mogą być powiązane z ustawionymi kwotami do wykorzystania zasobów. Na przykład, jeśli skonfigurujemy maksymalny limit 2 GB użytkowania pamięci RAM dla kontenera, nie będzie on w stanie go przekroczyć. Z drugiej strony, ponieważ w pętli znajduje się tylko jedno jądro, jeśli pojemnik nie używa całego pamięci RAM, jądro może umieścić pozostałe zasoby do użycia gdzie indziej.
Pierwszą wadą, którą ludzie zrealizowali za pomocą modelu kontenera, jest to, że ponieważ wirtualizujemy system operacyjny, a nie sprzęt, możesz mieć wiele instancji tego samego systemu operacyjnego i stracisz możliwość wirowania dowolnego systemu operacyjnego.
Nie ma czegoś takiego jak kontener Windows w Linux lub Linux w systemie Windows. Na przykład Docker w systemie Windows używa Moby Moby Linux, który faktycznie działa w maszynie wirtualnej wewnątrz systemu Windows.
Jeśli chodzi o dystrybucję Linuksa, możesz zrobić wiele interesujących rzeczy. Ponieważ to, co nazywamy Linux, to tylko jądro i potrzebuje stosu bibliotek GNU, aby zapewnić pełne środowisko systemu operacyjnego, możesz naśladować różne rozkłady, takie jak centos, Ubuntu, alpine w różnych przypadkach kontenera.
Dotyczy to zarówno LXD, jak i Docker.
Docker zrobi to, co Apt zrobił, aby smołować. To znaczy, nadal będziesz używać apt, ale z dodatkową warstwą abstrakcji. Aby zrozumieć, w jaki sposób rozważ następujący przykład.
Masz instancję swojej witryny działającej w PHP5.6 i musisz uruchomić inną usługę internetową na tym samym serwerze za pomocą PHP7.0. Teraz prowadzenie dwóch różnych wersji samego PHP jest przerażającym pomysłem, nie wiedząc, jakie konflikty by się z nich powstały. Aktualizacja i modernizacja wkrótce stanie się beznadziejnym przedsięwzięciem.
Ale co, gdybyśmy mieli naszą oryginalną instancję internetową działającą w pojemniku Docker? Teraz potrzebujemy tylko nowego kontenera Docker, w którym możemy zainstalować PHP7.0 i nasza druga usługa internetowa będzie działać z tego nowo obróconego kontenera. Nadal będziemy używać apt w tle, podobnie jak apt używa smoły w tle, ale Docker upewnił się, że różne aplikacje z różnych kontenerów nie są ze sobą sprzeczne.
Docker jest szczególnie przydatny do uruchamiania aplikacji bezstanowych i słyszysz ludzi, którzy często mówią, że nie możesz uruchomić więcej niż jednego procesu w kontenerze. Chociaż jest to fałszywe, uruchomienie wielu usług stanowych w jednym instancji kontenera może często spowodować, że Docker daje niespójne wyniki. Wkrótce okaże się, że ponowne uruchomienie tego samego zestawu pojemników w kółko.
Z kontenerami LXD, co otrzymujesz, jest znacznie bliżej samodzielnego systemu operacyjnego niż to, co otrzymujesz od Docker. Wszystkie kontenery Docker mają ten sam stos sieciowy i stos magazynowy.
Oznacza to podstawowe polecenia, takie jak świst Lub ifconfig są niedostępne z wnętrza kontenera Docker. W rzeczywistości nie możesz wiedzieć prawie nic o sieci, w której jesteś, od wewnątrz tego pojemnika. Docker Nat działający na stosie sieci hosta oferuje większość łączności i udogodnień, takich jak przekierowanie portów.
Pojemniki LXD są o wiele wyprzedzając krzywą, obsługując mosty sieciowe, MacVlan i wiele innych opcji. Twoje kontenery LXD i gospodarz tworzą własną prywatną sieć i mogą się ze sobą komunikować, jakby rozmawiali z różnymi komputerami przez sieć.
To samo dotyczy stosu przechowywania. Często jest o wiele bardziej praktyczne korzystanie z LXD z pulami ZFS, w których można alokować zestawy danych z kwotami ograniczającymi wykorzystanie przechowywania. LXD jest w bezpośrednim konkursie z VMware, KVM i innymi technologiami Hypervisor.
Korzystając z niego, twój dostawca w chmurze może teraz zapewnić Ci swój osobisty kontener, który pachnie i czułby się jak kompletny system operacyjny, a nadal jest tani i szybki do kręcenia i zabijania, wraz ze wszystkimi uprzejmością uporczywych danych, których oczekujesz.
Z punktu widzenia dostawcy rzeczy są również ekonomiczne. Ponieważ nie wszyscy używają całego pamięci RAM, o które proszą, możesz wcisnąć o wiele więcej pojemników na ten sam metal niż VMS.
Dla użytkowników końcowych może to na początku brzmieć jak oszukiwanie, ale wygrywają również na końcu, pojemniki LX szybciej kręci i zabijają proces znacznie płynniej i „skalowalny” (jak ludzie lubią mówić).
Możesz zwinąć pojemniki w węźle obliczeniowym, w którym przebywają dane, wykonaj obliczenia, które chcesz wykonać, a następnie zniszczyć kontener, pozostawiając dane nienaruszone. Jest to znacznie szybsze niż pobieranie odpowiednich danych aż do Twojej maszyny wirtualnej, która działa w innym centrum danych. Działa to szczególnie dobrze z ZFS w pętli.
Podsumowując wszystko, co wiemy, zarówno LXD, jak i Docker to technologie kontenerów. Docker jest lekki, uproszczony i jest odpowiedni do izolowania od siebie aplikacji, dzięki czemu jest popularny wśród DevOps i programistów. Jedna aplikacja na kontener Docker.
Z drugiej strony LXD jest znacznie lepiej wyposażony i jest znacznie bliżej kompletnego środowiska systemu operacyjnego z interfejsami sieciowymi i magazynowymi. Możesz uruchomić wiele kontenerów Docker zagnieżdżonych w LXD, jeśli chcesz.