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


13

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ć?

1
libvirt ma sterownik kontenera LXC i tylko go kontroluje, nie jest to samo w sobie rozwiązanie do wirtualizacji / konteneryzacji.
Cristian Ciupitu

Odpowiedzi:


7

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.


9

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.


1
Dzięki za to. RHEL Atomic Host wygląda w dużej mierze na Docker.io . Czy to oznacza, że ​​Docker i powiązane narzędzia są właściwą ścieżką do przodu?
ewwhite

Red Hat zdecydowanie inwestuje znaczne środki w dokera, ale są także głównymi twórcami libvirt-lxc. Przyjrzałbym się możliwościom każdego z nich i sprawdziłem, które lepiej odpowiadają Twoim potrzebom.
sciurus

1
Tak @ewwhite Poniższy dokument Redhat wspomina dokładnie, że: access.redhat.com/articles/1365153
Susinthiran

1

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.


Pytanie dotyczy RHEL 6, wycofanie oznacza RHEL 7 «Następujące pakiety libvirt-lxc są przestarzałe, począwszy od Red Hat Enterprise Linux 7.1:» więc można tego użyć
taharqa
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.