Używaj Dockera do zaufanych, dobrze zapakowanych aplikacji; używaj LXC do lekkich środowisk systemu Linux; używaj maszyny wirtualnej, gdy usługa wymaga niezależnego jądra lub silniejszej granicy zaufania.
To nie są trzy wymienne opakowania. Docker pakuje aplikacje, LXC bardziej przypomina kompaktowy system Linux, a maszyna wirtualna wirtualizuje sprzęt na potrzeby osobnego jądra systemu gościa. Właściwy wybór zmienia się, gdy usługa jest dostępna z Internetu, wymaga szerokich uprawnień, korzysta z GPU lub urządzenia USB albo musi zostać odtworzona bez zaufania do stanu hosta.
Określ poziom zaufania i granicę jądra
Zacznij od oznaczenia każdej usługi jako zaufanej wewnętrznej, uprzywilejowanej infrastrukturalnej albo dostępnej z Internetu i potencjalnie wrogiej. Następnie zapisz, kto dostarcza jej obraz lub pakiety, jakie dane może odczytywać oraz czy przejęcie może umożliwić dostęp do sieci zarządzania, kopii zapasowych lub plików rodzinnych.
Usługa nie jest niskiego ryzyka tylko dlatego, że jest mała. Publiczny panel bez montowań hosta może być bezpieczniejszy niż wewnętrzne narzędzie automatyzacji przechowujące dane uwierzytelniające sieci, gniazdo Dockera i dostęp z prawem zapisu do każdego udziału.
Ten pierwszy etap może zakończyć porównanie. Jeśli obciążenie nie może współdzielić jądra hosta, Docker i LXC odpadają niezależnie od mniejszego zużycia pamięci; jeśli jest to zaufana aplikacja jednego przeznaczenia z ograniczonymi montowaniami, maszyna wirtualna może zwiększyć nakład administracyjny bez wystarczającej zmiany praktycznego poziomu ryzyka.
Docker i LXC izolują procesy, korzystając z jądra hosta; maszyna wirtualna uruchamia jądro gościa za granicą wyznaczaną przez hipernadzorcę. Niezależne porównanie współdzielenia jądra i izolacji maszyn wirtualnych wyjaśnia, dlaczego różnica w bezpieczeństwie ma charakter architektoniczny, a nie oznacza, że każdy kontener jest niebezpieczny.
Docker zwykle ogranicza jednostkę do aplikacji i jej zależności. LXC zapewnia pełniejszą przestrzeń użytkownika z systemem init, pakietami, kontami i usługami systemowymi. Dzięki temu LXC jest wygodny w przypadku małego środowiska Linux, ale nie zmienia go to w maszynę wirtualną.
Wybierz maszynę wirtualną, gdy istotne są różne jądra, niezaufany kod albo przejrzysta granica zapory i aktualizacji na poziomie systemu gościa. Pozostań przy Dockerze lub LXC, gdy współdzielone jądro hosta jest akceptowalną zależnością, a prostota operacyjna jest cenniejsza niż osobny system gościa.
Pozwól, aby uprawnienia i dostęp do sprzętu zmieniły domyślny wybór
Zaufana usługa Docker jest wydajna, dopóki nie wymaga sieci hosta, szerokich możliwości, montowań systemowych z prawem zapisu ani gniazda do zarządzania kontenerami. Każdy wyjątek osłabia wąską granicę aplikacji i zwiększa zasadność przeniesienia usługi do własnej maszyny wirtualnej lub przeprojektowania ścieżki dostępu.
LXC może być praktycznym rozwiązaniem pośrednim dla usługi Linux, która potrzebuje standardowego menedżera pakietów, stabilnej nazwy hosta i dostępu do wybranych urządzeń. Uprzywilejowane LXC, rozbudowane montowania bind i zagnieżdżony Docker zwiększają jednak powiązania, dlatego oszczędność zasobów należy zestawić z trudniejszymi aktualizacjami i odzyskiwaniem.
W przypadku GPU, HBA, kontrolera USB lub specjalnej karty sieciowej przetestuj zachowanie po resecie, uprawnienia i trwałość po ponownym uruchomieniu. Bezpośredni dostęp do urządzenia może być najłatwiejszy na hoście, ale maszyna wirtualna z przekazywaniem urządzenia może zapewnić wyraźniejszą granicę własności, jeśli pozwalają na to sprzęt i układ IOMMU.
Traktuj dostęp z Internetu jako decyzję dotyczącą sieci i tożsamości
Umieszczaj usługi publiczne za jedną kontrolowaną ścieżką odwrotnego serwera proxy lub VPN, interfejsy zarządzania pozostawiaj prywatne, a dane uwierzytelniające usług ograniczaj do najmniejszych możliwych zbiorów danych. Izolacja środowiska uruchomieniowego nie zrekompensuje publicznie dostępnego panelu administracyjnego, ponownie użytych haseł ani nieograniczonego dostępu do pamięci masowej i kopii zapasowych.
Dyskusja społecznościowa o tym, jak operatorzy przypisują obciążenia do Dockera, LXC i maszyn wirtualnych, pokazuje, że rzeczywiste wdrożenia często wykorzystują model hybrydowy: maszyna wirtualna ustanawia granicę zaufania, a Docker uruchomiony wewnątrz niej zapewnia pakowanie aplikacji. To trzecia architektura, a nie przyznanie, że jedna z opcji zawiodła.
W przypadku publicznej usługi o poważnych konsekwencjach preferuj dedykowaną maszynę wirtualną lub hosta, nawet jeśli Docker uruchomiłby ją taniej. W przypadku aplikacji o niewielkich konsekwencjach, z niezmiennym wdrażaniem, ograniczonymi montowaniami i silną kontrolą sieci Docker nadal może być prostszą odpowiedzią.
Porównaj jednostkę, którą będziesz aktualizować, tworzyć dla niej kopie zapasowe i przywracać
Docker najłatwiej odbudować, gdy pliki Compose, sekrety, wersje i trwałe woluminy są przechowywane oddzielnie. LXC można przywrócić jako jednostkę systemową, ale ręczne zmiany pakietów w jego wnętrzu powodują rozbieżności konfiguracji, chyba że są udokumentowane lub zautomatyzowane.
Maszyna wirtualna zwykle zużywa więcej pamięci i miejsca, ale sprawia, że system gościa staje się odrębną jednostką kopii zapasowej i wycofywania zmian. Ta korzyść jest realna dopiero po teście przywracania; migawka na tym samym hoście nie jest niezależną kopią odzyskiwania.
| Oś decyzyjna | Docker | LXC | VM |
|---|---|---|---|
| Główna jednostka | Aplikacja i woluminy | Przestrzeń użytkownika Linux i pliki | System gościa i dyski wirtualne |
| Jądro | Współdzielone z hostem | Współdzielone z hostem | Niezależne jądro gościa |
| Najlepsze zastosowanie | Spakowana zaufana aplikacja | Lekka usługa systemowa Linux | Silniejsza granica zaufania lub systemu operacyjnego |
| Ostrzeżenie dotyczące uprawnień | Gniazdo, możliwości, szerokie montowania | Tryb uprzywilejowany, zagnieżdżanie, montowania bind | Przekazywanie urządzeń i rozrost systemu gościa |
| Dowód możliwości odzyskania | Odtworzenie oraz przywrócenie woluminów | Odtworzenie lub przywrócenie stanu kontenera | Przywrócenie systemu gościa oraz sprawdzenie urządzeń |
Wybieraj granicę dla każdej usługi, nie dla całego serwera
Wybierz Dockera dla zaufanych stosów aplikacji z ograniczonymi montowaniami i powtarzalnymi definicjami. Wybierz LXC dla wydajnych usług systemowych Linux, które korzystają z pełniejszej przestrzeni użytkownika i nie wymagają niezależnego jądra. Wybierz maszynę wirtualną dla niezaufanych lub dostępnych z Internetu obciążeń o poważnych konsekwencjach, alternatywnych systemów operacyjnych albo własności sprzętu, której sprzyja izolacja systemu gościa.
Wybór systemu operacyjnego serwera domowego jest kolejną warstwą, ponieważ wybór hosta decyduje o tym, które mechanizmy kopii zapasowych, sieci, kontenerów i maszyn wirtualnych są praktyczne. Serwer hybrydowy może wykorzystywać wszystkie trzy granice, bez traktowania którejkolwiek jako uniwersalnego ustawienia domyślnego.
Przestań optymalizować zagęszczenie, gdy usługa wymaga uprzywilejowanego dostępu do hosta, udostępnia poufne funkcje administracyjne albo nie może być niezależnie odtworzona. Właściwą granicą jest najmniej złożona opcja, która nadal ogranicza awarię, na której naprawdę Ci zależy.
Porównania produktów
Więcej do przeczytania

LXC vs Docker na Proxmox do aktualizacji i przywracania aplikacji
Docker zapewnia kontrolę wersji na poziomie aplikacji, a LXC umożliwia przywracanie stanu na poziomie gościa. Lepsze rozwiązanie zależy od najmniejszej jednostki stanu, którą można...

Granice bezpieczeństwa Dockera i LXC dla uprzywilejowanych usług domowych
Docker pasuje do ciasno pakowanych aplikacji; LXC sprawdza się w przypadku pełniejszych usług linuksowych, ale żadne z nich nie zastępuje maszyny wirtualnej, gdy ryzyko...

Gotowy system NAS czy modułowy Linux dla początkującego konstruktora
Wybierz gotowe oprogramowanie NAS do obsługi pamięci masowej z instrukcjami; wybierz modułowy system Linux, gdy nauka i pełna kontrola uzasadniają większą samodzielność.

