Wprowadzenie do kontenerów systemd-nspawn: chroot na sterydach

Kontenery to technologia, która umożliwia izolację aplikacji przez wirtualizację na poziomie systemu operacyjnego. Pozwala to na uruchamianie wielu izolowanych instancji systemów na jednym hoście bez potrzeby dodatkowego narzutu związanego z pełną wirtualizacją maszyn wirtualnych. W świecie Linuxa, kontenery zyskały dużą popularność dzięki swojej wydajności i elastyczności, pozwalając deweloperom i administratorom systemów na łatwe pakowanie, dystrybucję oraz zarządzanie aplikacjami w spójnym i przenośnym środowisku.

Systemd-nspawn to narzędzie wchodzące w skład pakietu systemd, które służy do uruchamiania lekkich kontenerów systemowych w środowisku Linux. Jest integralną częścią systemu init systemd, co oznacza, że jest dostępne na większości nowoczesnych dystrybucji Linuxa. Narzędzie to pozwala na uruchamianie odizolowanych przestrzeni systemowych, które mają własny zestaw procesów i usług, a nawet możliwość uruchamiania różnych dystrybucji Linuxa w ramach jednego fizycznego hosta.

Czym różni się systemd-nspawn od innych rozwiązań jak Docker czy LXC?

Systemd-nspawn różni się od Docker i LXC kilkoma aspektami:

• Poziom izolacji: Systemd-nspawn zapewnia izolację na poziomie systemu plików, sieci i procesów, jednak nie jest tak głęboko zintegrowany z funkcjonalnościami jądra Linux, jak LXC czy Docker, które oferują bardziej zaawansowane funkcje, takie jak cgroups dla zarządzania zasobami.
• Prostota: Systemd-nspawn jest prostsze w użyciu dla tych, którzy już są zaznajomieni z ekosystemem systemd. Nie wymaga dodatkowych narzędzi do zarządzania kontenerami, co może być korzystne dla mniejszych projektów lub dla użytkowników, którzy preferują prostotę.
• Zastosowanie: W przeciwieństwie do Docker, który jest skoncentrowany na aplikacjach jako kontenerach, systemd-nspawn lepiej nadaje się do uruchamiania pełnych systemów operacyjnych dla celów testowych lub deweloperskich.
• Integracja z systemd: Jako część systemd, nspawn naturalnie integruje się z jego usługami, co umożliwia łatwe zarządzanie kontenerami jako usługami systemowymi.

Systemd-nspawn jest narzędziem kontenerowym dostarczanym wraz z systemd, które służy do tworzenia i zarządzania lekkimi kontenerami systemowymi na platformach Linux. To narzędzie pozwala uruchamiać odizolowane środowiska systemowe, które współdzielą to samo jądro systemu operacyjnego z hostem, ale mają własne, niezależne środowisko użytkownika, procesy, system plików i konfigurację sieci. Systemd-nspawn wykorzystuje funkcje jądra Linux, takie jak namespaces do izolacji przestrzennej i cgroups do kontroli zasobów, oferując tym samym znaczną izolację między kontenerami a systemem gospodarza.

Porównanie systemd-nspawn do chroot – jakie są dodatkowe możliwości?

Chroot jest jednym z najstarszych mechanizmów izolacji w środowiskach Unix i Linux, który pozwala zmienić katalog główny (root directory) dla wybranego procesu i jego potomków. Jest to podstawowa forma izolacji, ograniczona jedynie do ścieżek dostępu do plików. W przeciwieństwie do chroot, systemd-nspawn oferuje szerszą izolację i kontrolę nad zasobami systemowymi:

• Izolacja przestrzeni użytkownika: Obejmuje nie tylko system plików, ale także procesy, użytkowników i sesje, a także sieci.
• Kontrola zasobów: Integracja z cgroups pozwala na kontrolę użycia CPU, pamięci RAM, przestrzeni dyskowej i innych zasobów przez każdy kontener.
• Zarządzanie usługami systemowymi: Możliwość uruchamiania i zarządzania kontenerami jako usługami systemd, co ułatwia automatyzację i monitorowanie.

Przykładowa konfiguracja prostego kontenera z systemem bazowym.

Zakładając, że na systemie Linux chcemy utworzyć prosty kontener systemd-nspawn, który będzie izolował środowisko systemu Ubuntu, poniżej przedstawiam kroki konfiguracyjne:

1. Instalacja wymaganych pakietów i przygotowanie systemu

sudo apt install debootstrap systemd-container
sudo mkdir -p /var/lib/machines/

2. Inicjalizacja kontenera (w tym celu jako system bazowy kontenera wykorzystam Ubuntu Jammy)

sudo debootstrap jammy /var/lib/machines/developer

3. Ustawienie hasła root dla kontenera

sudo systemd-nspawn -D  /var/lib/machines/developer
passwd

4. Uruchomienie kontenera

sudo systemd-nspawn -b -D /var/lib/machines/developer

Poniżej zamieszczam animacje z uruchomienia kontenera:

Uruchamianie kontenera systemd-nspawn jako usługi systemowej

Uruchomienie kontenera systemd-nspawn jako usługi systemowej jest kolejnym aspektem efektywnego zarządzania kontenerami, umożliwiając automatyzację, monitorowanie i łatwe zarządzanie cyklem życia kontenerów. Oto jak można skonfigurować i zarządzać kontenerem systemd-nspawn jako usługą systemową za pomocą systemd. Poniższe polecenie uruchamia kontener jako usługę działającą w tle wliczając to restart systemu:

sudo systemctl enable --now [email protected]

Aby sprawdzić status uruchomionej usługi kontenera, użyj polecenia:

sudo systemctl status [email protected]

Kontener można łatwo restartować lub zatrzymać za pomocą poleceń:

sudo systemctl restart [email protected]
sudo systemctl stop [email protected]

Logi działania kontenera są dostępne poprzez journalctl, co ułatwia monitorowanie i diagnozowanie problemów:

sudo journalctl -u [email protected]

Konfiguracja logowania do kontenera systemd-nspawn przez SSH

Oferując dostęp SSH do kontenera systemd-nspawn, można skorzystać z różnych metod konfiguracji, które umożliwiają bezpieczne i kontrolowane zarządzanie dostępem użytkowników. Oto trzy opcje, które można rozważyć:

Opcja 1: Ustawienie katalogu chroot i konfiguracja sshd_config dla izolacji użytkownika SSH.
Zalety:

• Prosta i łatwa konfiguracja.

Wady:

• Konieczność utworzenia nowego użytkownika SSH na hoście.
• Usługi uruchomione w środowisku chroot muszą być zarządzane z poziomu hosta.

Opcja 2: Ustawienie kontenera przy użyciu systemd-nspawn z przekierowaniem SSH.
Zalety:

• Usługi można zarządzać i uruchamiać jak zwykłe usługi systemd wewnątrz kontenera.
• Host może ograniczyć zasoby (RAM, CPU) przypisane do kontenera.

Wady:

• Wymaga dodatkowych kroków przy ustawianiu kontenera (np. włączenie automatycznego logowania).
• Zarówno host, jak i kontener muszą posiadać tego samego użytkownika.
• Nie działają scp ani rsync z poziomu klienta.

Opcja 3: Ustawienie kontenera przy użyciu systemd-nspawn z własnym serwerem SSH na innym porcie.
Zalety:

• Podobne zalety do opcji 2, ale scp/rsync działają bezproblemowo.
• Użytkownik musi być ustawiony tylko po stronie kontenera.

Wady:

• Wymaga dodatkowych kroków przy konfiguracji kontenera.

Wybór odpowiedniej opcji zależy od konkretnych wymagań i preferencji w zakresie zarządzania bezpieczeństwem i dostępnością zasobów. W dalszej części artykułu przedstawię opcje 2.

Opcja 2: Ustawienie kontenera przy użyciu systemd-nspawn z przekierowaniem SSH

1. Stworzenie użytkownika art po stronie hosta

sudo adduser  art 

2. Stworzenie użytkownika po stronie kontenera

sudo systemd-nspawn -b -D /var/lib/machines/developer
useradd -m -s /bin/bash art

3. Skonfigurowanie przekierowania ssh
   Na końcu pliku /etc/ssh/sshd_config dodajemy

Match User art
    ForceCommand machinectl shell art@developer

4. Dodanie konfiguracji polkit
   Tworzymy plik /etc/polkit-1/localauthority/90-mandatory.d/99-machine.pkla z zawratością:

[Permit art to spawn shell in container]
Identity=unix-user:art
Action=org.freedesktop.machine1.shell
ResultAny=yes
ResultActive=yes
ResultInactive=yes

5. Restart serwera ssh

sudo systemctl restart ssh

Przykład działającego logowania:

Import oraz export kontenerów przy użyciu systemd-nspawn

Zarządzanie kontenerami za pomocą systemd-nspawn obejmuje także możliwość importowania oraz eksportowania kontenerów. Te funkcje umożliwiają migrację między systemami oraz tworzenie kopii zapasowych. Poniżej opisałem, jak można przeprowadzić import oraz export kontenerów przy użyciu systemd-nspawn.

Import kontenerów

Import kontenera polega na wprowadzeniu istniejącej instancji kontenera, która została wcześniej wyeksportowana lub utworzona na innym systemie, do lokalnego środowiska systemd-nspawn. Importowanie może być realizowane za pomocą narzędzia machinectl, które jest częścią systemd i umożliwia zarządzanie maszynami wirtualnymi i kontenerami.

1. Przygotowanie obrazu kontenera: Obraz może być w formacie RAW, tarball (TAR), lub innym wspieranym formacie. Obraz powinien zawierać system plików, który jest zgodny z oczekiwaniami systemd-nspawn.
2. Użycie polecenia machinectl:

sudo machinectl import-tar <nazwa_kontenera>.tar

Export kontenerów

Export kontenera to proces tworzenia przenośnego obrazu z istniejącego kontenera, który można następnie zaimportować na inny system lub zachować jako kopię zapasową. Exportowanie również korzysta z machinectl.

sudo machinectl export-tar nazwa_kontenera ścieżka_do_zapisu_obrazu.tar

Polecenie export-tar tworzy archiwum tar zawierające cały system plików kontenera. Obraz może być następnie przenoszony między systemami lub przechowywany jako backup.

Praktyczne zastosowanie

Systemd-nspawn, jako narzędzie kontenerowe, może być stosowane w różnych środowiskach i scenariuszach, od środowisk deweloperskich po produkcyjne. Poniżej rozważę realne zastosowania systemd-nspawn oraz porównam wydajność i zarządzanie zasobami tego narzędzia z innymi popularnymi rozwiązaniami kontenerowymi.

Przykłady realnych zastosowań systemd-nspawn w produkcji i development

1. Izolowane środowiska developerskie: Systemd-nspawn jest idealnym narzędziem do tworzenia izolowanych środowisk developerskich, gdzie każdy developer może mieć własne, odseparowane środowisko z wszystkimi potrzebnymi zależnościami, bez wpływu na główny system operacyjny lub pracy innych developerów. Takie podejście minimalizuje konflikty w zależnościach i ułatwia testowanie aplikacji w środowiskach bliskich produkcyjnemu.

2. Środowiska testowe i QA: W środowiskach Quality Assurance (QA) systemd-nspawn może służyć do szybkiego tworzenia i niszczenia kontenerów do celów testowych, umożliwiając łatwe replikowanie środowisk i izolowanie zmian. Kontenery można konfigurować z różnymi wersjami oprogramowania, symulując różne warunki operacyjne, które mogą wystąpić w produkcji.

3. Produkcyjne wdrożenia mikroserwisów: W architekturze mikroserwisowej, gdzie każdy mikroserwis może być uruchamiany w osobnym kontenerze, systemd-nspawn może zapewnić prostotę zarządzania i izolację, będąc jednocześnie mniej zasobożernym niż pełne maszyny wirtualne.

Porównanie wydajności i zarządzania zasobami w kontenerach systemd-nspawn

1. Wydajność: Systemd-nspawn, dzięki wykorzystywaniu mniejszej ilości abstrakcji niż tradycyjne maszyny wirtualne, oferuje wyższą wydajność, ponieważ kontenery dzielą jądro systemu hosta i nie wymagają dodatkowego narzutu związanego z emulacją sprzętu. W porównaniu z innymi narzędziami kontenerowymi, takimi jak Docker lub LXC, systemd-nspawn może oferować porównywalną wydajność przy prostszej konfiguracji, ale z mniejszą liczbą funkcji związanych z zarządzaniem siecią i zasobami.

2. Zarządzanie zasobami: Systemd-nspawn integruje się z systemd na hoście, co umożliwia korzystanie z cgroups do zarządzania zasobami. Kontenery mogą być ograniczone pod względem zużycia CPU, pamięci, przestrzeni dyskowej i pasma sieciowego. W porównaniu z Dockerem, systemd-nspawn jest mniej skomplikowany w konfiguracji i zarządzaniu, choć może oferować mniej granularne kontrolowanie zasobów i izolacji. W zastosowaniach produkcyjnych, gdzie zarządzanie zasobami i izolacja są kluczowe, Docker może być bardziej odpowiedni ze względu na bardziej zaawansowane funkcje zarządzania siecią i bezpieczeństwem. Jednakże, dla mniejszych projektów lub tam, gdzie prostota i mniejszy narzut są bardziej pożądane, systemd-nspawn stanowi skuteczną alternatywę.

Podsumowanie

Systemd-nspawn, będąc narzędziem do zarządzania kontenerami systemowymi, oferuje wiele zalet, które sprawiają, że jest wartościowym rozwiązaniem w różnych scenariuszach użycia:

1. Prostota i integracja z systemd: Jako narzędzie zintegrowane z systemd, systemd-nspawn łatwo współpracuje z istniejącymi konfiguracjami systemowymi i usługami, co umożliwia łatwe zarządzanie kontenerami jako usługami systemowymi.
2. Lekka izolacja: Systemd-nspawn oferuje efektywną izolację systemów operacyjnych bez znacznego narzutu związanego z wirtualizacją sprzętową, dzięki czemu jest szybszy niż tradycyjne maszyny wirtualne.
3. Elastyczność w zarządzaniu zasobami: Możliwość kontroli nad zasobami, takimi jak CPU i pamięć RAM za pomocą cgroups, pozwala na efektywne zarządzanie wydajnością kontenerów.

Możliwe problemy i ich rozwiązania

Mimo wielu zalet, użytkownicy systemd-nspawn mogą napotkać również na pewne wyzwania:

1. Ograniczona funkcjonalność sieciowa: W porównaniu do bardziej rozbudowanych narzędzi kontenerowych, takich jak Docker, systemd-nspawn oferuje mniej opcji w zakresie zaawansowanej konfiguracji sieci. Rozwiązaniem tego problemu może być użycie dodatkowych narzędzi do zarządzania siecią, takich jak iptables czy firewalld, do ręcznej konfiguracji sieci w kontenerach.
2. Mniejsza społeczność i wsparcie: Jako że systemd-nspawn nie jest tak powszechnie używane jak Docker, dostępne zasoby, dokumentacja i wsparcie społeczności mogą być mniej rozbudowane. Aktywne uczestnictwo w społecznościach Linux i systemd może pomóc w łatwiejszym znalezieniu rozwiązań i wsparcia.
3. Zarządzanie zabezpieczeniami: Chociaż systemd-nspawn zapewnia pewien poziom izolacji, nie jest on tak silny jak izolacja oferowana przez niektóre inne narzędzia. Regularne aktualizacje, odpowiednia konfiguracja i stosowanie praktyk bezpieczeństwa są kluczowe do minimalizowania ryzyka.

Systemd-nspawn stanowi solidne narzędzie dla tych, którzy szukają prostego, ale efektywnego rozwiązania do izolacji aplikacji i środowisk w systemie Linux. Jego integracja z systemd i niski narzut operacyjny czynią go atrakcyjnym wyborem w szczególności dla środowisk produkcyjnych i deweloperskich, gdzie zarządzanie zasobami i prostota są niezwykle istotne.

Bibliografia

1. https://www.docker.com/
2. https://kubernetes.io
3. https://wiki.archlinux.org/title/chroot
4. https://wiki.archlinux.org/title/Polkit
5. https://wiki.archlinux.org/title/systemd-nspawn
6. https://kilabit.info/journal/2022/chrooting_ssh_user_into_systemd-nspawn/