Kontenery Linux (LXC) na Red Hat / CentOS EL6 - lxc-create versus libvirt?

Trudno jest pozostać w dobrych łaskach Red Hata i nadal planować długowieczność systemu ...

Od ponad roku jestem zwolennikiem Linux Containers (LXC) . Moje początkowe instalacje były oparte na informacjach zebranych z samouczków online, takich jak ten i ten . To koncentruje się wokół lxc-create, lxc-start|stopi lxc-destroypoleceń i modyfikację istniejących szablonów OpenVZ .

Działa to dobrze i szczęśliwie działa w produkcji. Jednak przywołuję dodatkowe systemy i postanowiłem sprawdzić aktualną dokumentację Red Hat dotyczącą kontenerów w EL6. Byłem zaskoczony, widząc ich oficjalne stanowisko w tej sprawie.

W Czy RHEL 6 zapewnia narzędzia LXC potrzebne do korzystania z kontenerów Linux? , Red Hat opisuje LXC jako podgląd technologii i sugeruje użycie libvirt do zarządzania tworzeniem i zarządzaniem kontenerami .

Jednak Oracle opowiada się za zupełnie inną techniką konteneryzacji w swoim Unbreakable Linux.

Wygląda na to, że brakuje pewnej funkcjonalności w metodzie libvirt, ale moje początkowe podejście z poleceniami lxc- * było trochę procesem ręcznym ... Nie mogę do końca powiedzieć, co jest poprawne lub „zaakceptowane” sposoby zarządzania kontenerami na EL6 .

• Jaka jest obecnie powszechna opinia na temat systemów typu LXC i RHEL?
• Jak się pan wdrożenie ich w swojej organizacji?
• Czy są jakieś zalety jednego podejścia w porównaniu do drugiego?
• Czy mogą one współistnieć?

Jaka jest obecnie powszechna opinia na temat systemów typu LXC i RHEL?

Osobiście uważam, że obecna konfiguracja trochę mi brakuje. LXC wydaje się bardziej na czele - z pewnością bardziej utrzymany.

Jak je wdrażasz?

Jeśli chodzi o oferowanie go jako opcji wirtualizacji, nie jestem. Brakuje mi obecnej konfiguracji technologicznej.

• Brak przestrzeni nazw użytkownika.
• Niektóre punkty montowania nie rozpoznają przestrzeni nazw (cgroups, selinux)
• Wartości w / proc są wprowadzającymi w błąd globaliami systemowymi, które nie uwzględniają partycjonowania zasobów w przestrzeniach nazw.
• Przerwy w audycie.

Uważam jednak, że to naprawdę miłe narzędzie do ograniczania poziomu aplikacji. Używamy przestrzeni nazw i cgroups bezpośrednio do przechowywania zasobów sieciowych i IPC dla niektórych aplikacji internetowych uruchamianych przez użytkowników. Zapewniamy własny interfejs do jego kontroli. W RHEL7 rozważam przeniesienie tej funkcji do libvirt-lxcnowszych wersji libvirtobsługi koncepcji list ACL użytkowników.

Jeśli chodzi o wirtualizację w postaci w pełni zainicjowanego systemu, czekam na zapoznanie się z tym, co jest oferowane w RHEL7, ale szczerze mówiąc, czuję, że możemy zobaczyć wystarczająco dobre rozwiązanie, gdy będziemy w późniejszym mniejszym wydaniu RHEL7, a następnie być może tylko w stanie podglądu technologii.

Miej oko na systemd-nspawncoś, co mówi mi w ciągu najbliższych 18 miesięcy, a może to zajmie jego miejsce, jest to najlepsze narzędzie do przeprowadzenia w pełni wirtualizacji zawartej w systemie Linux, czy to dzięki temu, że autorzy systemowi wyjaśniają, że nie jest teraz bezpieczny! I nie byłby zaskoczony, gdy libvirtkrople libvirt-lxcostatecznie i tak oferuje owijkę wokół systemd-nspawnplasterki Systemd zdefiniowane.

Ponadto, należy zachować ostrożność, ponieważ w ciągu ostatnich 6 miesięcy dużo mówi się o ponownym wdrażaniu cgroups jako interfejsu programisty jądra, a nie interfejsu systemu plików (być może przy użyciu netlink lub czegoś takiego, nie sprawdzono), więc systemd powinien być bardzo gorący na ogonie bardzo szybko.

Czy są jakieś zalety jednego podejścia w porównaniu do drugiego?

Myślę, że opcja LXC (nie libvirt-lxc) jest lepiej utrzymana. Po odczytaniu libvirt-lxckodu źródłowego czuje się, że się spieszy. Tradycyjny LXC z pewnością ma nowsze funkcje, które zostały lepiej przetestowane. Oba wymagają pewnego stopnia kompatybilności z uruchomionym w nich systemem init, ale podejrzewam, że LXC będzie nieco bardziej „pod klucz” niż libvirt-lxcopcja, szczególnie jeśli chodzi o uruchomienie w nich dystrybucji.

Czy mogą one współistnieć?

Jasne, pamiętaj, że dla wszystkich celów i celów, oba robią to samo. Organizowanie przestrzeni nazw, grup grup i punktów montowania. Wszystkimi prymitywami zajmuje się samo jądro. Obie lxcimplementacje oferują po prostu mechanizm współpracy z dostępnymi opcjami jądra.

Red Hat pcha ogromne konteneryzacje. Budują wokół niego zupełnie nowy produkt, Red Hat Enterprise Linux Atomic Host .

Aby uzyskać mniej radykalne podejście, zapoznaj się z ich Przewodnikiem zarządzania zasobami i wersją beta RHEL7 beta ; zauważysz, że popycha libvirt-lxc i nie wspomina o narzędziach lxc.

W lxc- * wykonywalne są pakowane w LXC pakietu w EPEL . Jest to jednak stara wersja „długoterminowego wsparcia”. Nie masz nawet opcji „-f” w lxc-ls. Po prostu zainstalowałbym Ubuntu dla moich hostów LXC.

Wygląda na to, że RHEL zarządza LXC za pomocą libvirt-lxc, ale najwyraźniej jest przestarzały .

Zauważyliśmy, że Ubuntu obsługuje wiele nowych wersji lxc / lxd, podczas gdy Redhat koncentruje się na KVM i dokerze.