Jedna maszyna wirtualna Docker kontra jeden kontener LXC na aplikację: co zapewnia lepszą kontrolę nad kopiami zapasowymi i zasięgiem awarii?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

One Docker VM vs One LXC per App: Which Gives Better Backup and Blast-Radius Control? - Zima Store Online

Wybierz jedną maszynę wirtualną z Dockerem, gdy aplikacje współdzielą wspólne środowisko uruchomieniowe, odwrotne proxy, stos monitorowania i harmonogram tworzenia kopii zapasowych, a jednoczesne przywrócenie całej platformy aplikacyjnej jest akceptowalne. Wybierz jedno LXC na aplikację, gdy usługi mają różne wymagania dotyczące ryzyka, aktualizacji, pamięci masowej lub odzyskiwania, a wadliwy pakiet, montowanie albo aplikacja nie powinny przerywać działania pozostałej części stosu. Lepszy projekt to najmniejszy moduł odzyskiwania, który potrafisz udokumentować bez mnożenia ukrytych zależności.

Zdefiniuj moduł odzyskiwania przed porównaniem kontenerów

Pierwszą decyzją nie jest to, czy Docker lub LXC zużywa mniej zasobów. Chodzi o to, co należy przywrócić razem po nieudanej aktualizacji, uszkodzeniu bazy danych, awarii montowania lub wymianie hosta. Jedna maszyna wirtualna z Dockerem tworzy duży moduł odzyskiwania obejmujący system operacyjny i silnik kontenerów. Jedno LXC na aplikację tworzy kilka mniejszych modułów, z których każdy ma własny system plików, tożsamość sieciową, limity i obiekt kopii zapasowej.

Przewodnik ZimaSpace po warstwach przechowywania bare metal, Dockera i Proxmox wyjaśnia, dlaczego każda dodatkowa warstwa zmienia miejsce przechowywania danych trwałych. To porównanie rozpoczyna się po wcześniejszym wyborze Proxmox i pokazuje, jak duża powinna być granica odzyskiwania każdej aplikacji.

Jeśli aplikacje nie mogą uruchamiać się niezależnie, ponieważ współdzielą jedną bazę danych, jedną sieć Compose, jednego dostawcę tożsamości lub jedną konfigurację odwrotnego proxy, tworzenie osobnych kontenerów LXC może wygenerować kilka plików kopii zapasowych bez zapewnienia rzeczywistej izolacji. Zmapuj zależności, zanim zaczniesz liczyć kontenery.

Kryterium decyzyjne	Jedna maszyna wirtualna z Dockerem	Jedno LXC na aplikację
Obiekt kopii zapasowej	Jedna większa kopia zapasowa maszyny wirtualnej oraz ochrona danych uwzględniająca aplikację	Jedna mniejsza kopia zapasowa Proxmox dla każdego kontenera aplikacji
Zakres przywracania	Przywraca całą platformę Dockera jednocześnie	Przywraca jedną usługę bez zastępowania niezwiązanych z nią systemów-gości
Współdzielone narzędzia	Jeden demon Dockera, serwer proxy, agent monitorujący i cykl aktualizacji poprawek	Powielone pakiety bazowe, agenty, użytkownicy i reguły sieciowe
Zasięg skutków aktualizacji	Zmiany w jądrze, Dockerze, zaporze sieciowej lub systemie plików mogą wpłynąć na każdą aplikację	Większość zmian pakietów i aplikacji pozostaje wewnątrz jednego kontenera LXC
Narzut zasobów	Jeden system-gościa, ale wszystkie aplikacje konkurują o zasoby wewnątrz niego	Niewielki narzut na kontener, ale z powtarzającymi się bazowymi konfiguracjami usług
Komunikacja między aplikacjami	Proste sieci Dockera i współdzielone projekty Compose	Wymaga routowanych sieci, DNS, danych uwierzytelniających i zasad zapory sieciowej
Najlepsze zastosowanie	Ściśle powiązany stos aplikacji z jednym operatorem i harmonogramem odzyskiwania	Niezależne usługi o różnych wymaganiach dotyczących ryzyka i cyklu życia

Jedna maszyna wirtualna z Dockerem upraszcza tworzenie kopii zapasowej platformy

Pojedyncza maszyna wirtualna może zawierać gościa linuksowego, Docker Engine, pliki Compose, sekrety, konfigurację proxy, obrazy kontenerów i woluminy trwałe. Proxmox może tworzyć kopię zapasową maszyny wirtualnej jako jednego obiektu, co upraszcza wymianę hosta i szerokie wycofanie zmian, gdy cały stos powinien powrócić do tego samego punktu w czasie.

Niedawny poradnik dotyczący przywracania maszyn wirtualnych i kontenerów LXC w Proxmoxie zauważa, że przywracanie LXC jest często lżejsze, ponieważ archiwizuje system plików kontenera, a nie kompletny dysk wirtualny. Odwrotną zaletą maszyny wirtualnej jest kompletność: jedno przywrócenie może jednocześnie odtworzyć system operacyjny gościa i środowisko Dockera.

Ta prostota jest najbardziej odczuwalna, gdy aplikacje celowo tworzą jedną platformę. Stos multimedialny może współdzielić odwrotny serwer proxy, uwierzytelnianie, narzędzia do pobierania, monitoring i punkty montowania pamięci masowej. Przywrócenie tylko jednego elementu może spowodować niezgodności wersji lub danych uwierzytelniających, dlatego jedna skoordynowana kopia zapasowa maszyny wirtualnej może lepiej odpowiadać rzeczywistej granicy zależności.

Oddzielne kontenery LXC zapewniają mniejsze jednostki awarii i przywracania

Jeden kontener LXC na aplikację pozwala zatrzymać uszkodzony pakiet, zapełniony system plików root, uszkodzoną konfigurację lub nieudaną aktualizację w obrębie jednego gościa. Operator może przywrócić ten kontener bez wycofywania niezwiązanych usług, które pomyślnie zmieniły się po utworzeniu tego samego punktu kopii zapasowej.

Praktyczny argument za mniejszym zasięgiem awarii usług w Proxmoxie nie polega na tym, że każda aplikacja automatycznie zasługuje na kontener. Chodzi o to, że izolacja ma wartość, gdy usługi mają różne wymagania dotyczące zaufania, utrzymania lub dostępności.

Korzyść znika, gdy wszystkie kontenery LXC montują ten sam zapisywalny katalog aplikacji, zależą od jednej niechronionej bazy danych albo wymagają tego samego serwera proxy i usługi tożsamości. Oddzielny główny system plików nie jest w stanie powstrzymać awarii rozprzestrzeniającej się przez współdzielone dane uwierzytelniające, pamięć masową lub destrukcyjną automatyzację.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Szczegółowość kopii zapasowych może zwiększyć nakład pracy przy odtwarzaniu

Mniejsze kopie zapasowe pozwalają operatorowi osobno przechowywać, odtwarzać i testować usługi o wysokiej wartości. Kontener LXC z Home Assistantem może mieć częste kopie zapasowe, podczas gdy wymienny pulpit może mieć krótszą politykę przechowywania. Harmonogram tworzenia kopii zapasowych może uwzględniać tempo i konsekwencje zmian, zamiast traktować każdą aplikację jednakowo.

Kosztem jest orkiestracja. Odtworzenie pięciu kontenerów LXC może wymagać właściwej kolejności uruchamiania, stałych adresów, rekordów DNS, montowań pamięci masowej, certyfikatów i danych uwierzytelniających usług. Kopia zapasowa rejestrująca każdego gościa osobno nie zachowuje automatycznie grafu zależności między nimi.

Workflow Proxmox Backup Server firmy ZimaSpace może chronić zarówno maszyny wirtualne, jak i kontenery. Decyzja dotycząca podziału pakietów nadal należy do Ciebie: określ, które usługi muszą współdzielić jeden punkt odzyskiwania, a które powinny być możliwe do odtworzenia niezależnie.

Aktualizacje ujawniają rzeczywisty zasięg awarii

W jednej maszynie wirtualnej z Dockerem aktualizacja systemu operacyjnego, zmiana demona Dockera, zmiana iptables lub nftables, zapełnienie dysku albo problem z systemem plików może zatrzymać każdy kontener. Docker oddziela pakowanie aplikacji, ale jądro gościa, demon, sterownik pamięci masowej i stos sieciowy nadal pozostają współdzielone.

Oddzielne kontenery LXC przenoszą wiele takich zmian do mniejszych środowisk gościa. Jedna aplikacja może korzystać z innej wersji pakietu lub harmonogramu restartów bez modyfikowania środowiska każdej pozostałej usługi. Jest to przydatne w przypadku aplikacji dostępnych publicznie, eksperymentalnego oprogramowania lub usług z agresywnym cyklem aktualizacji.

Każdy kontener LXC nadal współdzieli jądro hosta Proxmox. Awaria jądra hosta, pamięci masowej, mostu sieciowego lub samego Proxmox pozostaje wspólnym zdarzeniem. Jeden kontener LXC na aplikację ogranicza zasięg awarii na poziomie gościa, ale nie zapewnia niezależności od hosta.

Współdzielone bazy danych i serwery proxy mogą wyznaczać lepsze grupowanie niż „jedna aplikacja”

Aplikacje często składają się z kilku komponentów: usługi internetowej, bazy danych, pamięci podręcznej, procesu roboczego, harmonogramu i trasy proxy. Rozdzielenie każdego komponentu do innego kontenera LXC może utrudnić zwykłe odzyskiwanie, ponieważ spójny stan aplikacji obejmuje kilku gości.

Lepszą jednostką może być jeden kontener LXC na stos aplikacji, z Docker Compose uruchomionym wewnątrz tego kontenera dla ściśle powiązanych komponentów. Inną opcją jest jedna maszyna wirtualna Docker dla powiązanych usług niskiego ryzyka oraz osobne kontenery LXC dla baz danych, aplikacji publicznych lub obciążeń zależnych od sprzętu.

Dyskusja społeczności Proxmox na temat liczby aplikacji przypadających na każdego gościa odzwierciedla praktyczną rzeczywistość: podział powinien wynikać z zależności, wymagań bezpieczeństwa i potrzeb związanych z odzyskiwaniem, a nie z uniwersalnej liczby aplikacji.

Trwała pamięć masowa decyduje o kompletności kopii zapasowej

Kopia zapasowa maszyny wirtualnej może obejmować dyski wirtualne, ale pomijać dowiązania NAS, zewnętrzne udziały NFS, przekazane zasoby pamięci masowej lub kopie zapasowe aplikacji przechowywane gdzie indziej. Kopia zapasowa LXC może obejmować jego główny system plików, podczas gdy zbiory danych montowane przez bind mount pozostają poza archiwum. Żadna z tych architektur nie gwarantuje pełnego odzyskania tylko dlatego, że zadanie Proxmox zgłasza powodzenie.

Zinwentaryzuj pliki Compose, sekrety, bazy danych, przesłane treści, certyfikaty, zewnętrzne punkty montowania i miejsca docelowe kopii zapasowych. Zaznacz, czy każda ścieżka znajduje się w kopii zapasowej maszyny wirtualnej lub kontenera LXC, jest chroniona osobną migawką, czy też można ją odtworzyć z konfiguracji.

To jest granica, której nie należy przekraczać: jeśli trwały stan aplikacji znajduje się w jednej współdzielonej, niechronionej ścieżce, zmiana liczby gości nie poprawi możliwości odzyskania danych. Najpierw napraw granicę danych, a dopiero potem optymalizuj szczegółowość kopii zapasowych.

Przeprowadź test awarii dla obu projektów

Wymień każdą aplikację, współdzieloną zależność, ścieżkę trwałych danych i zewnętrzny punkt montowania.
Określ maksymalną akceptowalną przerwę w działaniu oraz utratę danych dla każdej usługi.
Przywróć kompletną maszynę wirtualną Docker do nowego identyfikatora gościa i zweryfikuj cały stos.
Przywróć jeden reprezentatywny kontener LXC bez zmieniania niezwiązanych aplikacji.
Przetestuj kolejność uruchamiania, DNS, certyfikaty, dostęp do bazy danych oraz dostępność punktów montowania.
Celowo przerwij aktualizację jednego gościa i sprawdź, które usługi przestaną działać.
Powtórz proces odzyskiwania, korzystając wyłącznie z pisemnej dokumentacji.

Mierz zarówno liczbę czynności operatora, jak i czas przywracania. Małe archiwum LXC nie upraszcza obsługi, jeśli jego odzyskanie wymaga odtworzenia dziesięciu nieudokumentowanych zależności. Większa kopia zapasowa maszyny wirtualnej nie jest bezpieczniejsza, jeśli jej przywrócenie usuwa prawidłowe zmiany ze wszystkich aplikacji.

Który układ gości pasuje do stosu aplikacji?

Kiedy wybrać jedną maszynę wirtualną Docker

Wybierz jedną maszynę wirtualną, gdy aplikacje współdzielą infrastrukturę, są utrzymywane razem i mogą korzystać z jednego punktu tworzenia kopii zapasowej oraz wycofywania zmian. Wyraźnie określ ścieżki trwałych danych, dodaj kopie zapasowe baz danych uwzględniające aplikację i monitoruj współdzieloną maszynę wirtualną jako krytyczną platformę.

Kiedy wybrać jeden kontener LXC na aplikację lub stos aplikacji

Wybierz oddzielne kontenery LXC, gdy usługi mają różne wymagania dotyczące ryzyka, zaufania, dostępu do sprzętu, aktualizacji lub przechowywania danych. Grupuj ściśle powiązane komponenty i automatyzuj wspólną konfigurację bazową, aby izolacja nie przerodziła się w powtarzalną pracę ręczną.

Kiedy wybrać układ hybrydowy

Umieść powiązane usługi Docker o niskim ryzyku w jednej maszynie wirtualnej, izolując jednocześnie aplikacje publiczne, bazy danych, Home Assistant lub obciążenia zależne od sprzętu w dedykowanych kontenerach LXC albo maszynach wirtualnych. Zwykle zapewnia to bardziej użyteczne granice niż stosowanie jednej architektury do każdej usługi.

FAQ

Czy jeden kontener LXC na aplikację eliminuje potrzebę używania Dockera?

Nie. Kontener LXC może uruchamiać natywny pakiet lub hostować niewielki stos Docker Compose. LXC określa granicę gościa Proxmox, a Docker definiuje sposób pakowania aplikacji wewnątrz tej granicy. Rozwiązują różne problemy związane z izolacją i wdrażaniem.

Czy łatwiej tworzyć kopie zapasowe jednej dużej maszyny wirtualnej?

Łatwiej jest planować i przywracać całość jako jeden obiekt, ale archiwum jest większe, a wycofanie zmian wpływa na każdą aplikację. W przypadku baz danych i danych montowanych z zewnątrz nadal mogą być wymagane oddzielne kopie zapasowe aplikacji.

Czy kontenery LXC można migrować między węzłami Proxmox?

Tak, ale mapowania urządzeń, lokalne montowania bind, sterowniki hosta, ścieżki do magazynu danych i założenia dotyczące sieci mogą wymagać odtworzenia. System plików root można przenieść łatwiej niż cały kontrakt sprzętowo-magazynowy.

Ostateczny werdykt

Użyj jednej maszyny wirtualnej Docker, gdy aplikacje rzeczywiście tworzą jedną platformę i powinny być wspólnie objęte kopiami zapasowymi, aktualizacjami oraz przywracaniem. Użyj oddzielnych kontenerów LXC, gdy usługi wymagają niezależnych punktów przywracania i mniejszych zakresów awarii na poziomie gościa. Najlepszy układ grupuje usługi według współdzielonego stanu i odpowiedzialności za odzyskiwanie, zamiast bezmyślnie wybierać jednego gościa na każdą ikonę.