Wyszukiwanie w witrynie

Zbuduj 10MB maszyny wirtualne NetBSD, które uruchamiają się w 10ms używając smolBSD

Szybkie podsumowanie

smolBSD buduje minimalne maszyny wirtualne NetBSD, które uruchamiają się w około 10 milisekund. Otrzymujesz kompletny system UNIX z zarządzaniem pakietami, standardowymi narzędziami i znajomymi procesami pracy. Cała maszyna wirtualna mieści się w 10 megabajtach.

Działa na Linux, macOS i NetBSD. Nie jest wymagany specjalny sprzęt. Możesz tworzyć obrazy używając składni Dockerfile i uruchamiać je na QEMU lub Firecracker.

smolBSD nie jest kontenerem. Nie jest unikernem. To narzędzie, które tworzy prawdziwe obrazy systemu operacyjnego, tylko że niezwykle małe i szybkie.

Czym jest smolBSD?

smolBSD to „meta-system operacyjny” służący do tworzenia minimalnych, szybko uruchamiających się maszyn wirtualnych opartych na NetBSD (mikro-VM). Umożliwia użytkownikom tworzenie niestandardowych środowisk UNIX, od mikrousług o pojedynczym zastosowaniu po pełne obrazy systemu operacyjnego.

Jaki problem rozwiązuje smolBSD?

Większość maszyn wirtualnych uruchamia się w ciągu 1-2 sekund. Brzmi to szybko, dopóki nie trzeba uruchomić setek z nich dla zadań serverless lub testowania.

Kontenery uruchamiają się szybciej, ale współdzielą jądro hosta. Czasami potrzebna jest prawdziwa izolacja.

Unikernel, takie jak MirageOS, uruchamiają się szybko, ale wymagają przepisania aplikacji w określonych językach. Tracisz dostęp do standardowych narzędzi UNIX i menedżerów pakietów.

smolBSD daje ci prędkość kontenerów przy izolacji maszyn wirtualnych. Zachowujesz pełny użytkownik NetBSD. Masz dostęp do standardowych narzędzi, skryptów powłoki i menedżera pakietów pkgin.

Czyni to narzędzie elastycznym dla programistów, którzy chcą szybkości mikro-VM bez utraty funkcji tradycyjnego systemu.

Jak to naprawdę działa

smolBSD opiera się na NetBSD, darmowym, szybkim, bezpiecznym i wysoce przenośnym systemie operacyjnym UNIX. Projekt wykorzystuje kilka specyficznych optymalizacji, aby osiągnąć ekstremalnie szybkie uruchamianie.

But PVH

Tradycyjne maszyny wirtualne uruchamiają się przez BIOS, następnie przez bootloader, a potem przez jądro. PVH (sprzęt para-wirtualizowany) pomija uruchamianie przez bootloader i przechodzi bezpośrednio do jądra. Hypervisor wczytuje jądro bezpośrednio do pamięci.

To eliminuje sekundy czasu inicjalizacji.

Jądro MICROVM

smolBSD używa wyspecjalizowanego jądra o nazwie netbsd-MICROVM. Na początku 2025 roku większość tych funkcji została połączona z główną gałęzią rozwojową NetBSD.

Jądro jest zredukowane do niezbędnych sterowników i funkcji. Brak zbędnych podsystemów. Brak nadmiaru.

Minimalna inicjalizacja

Systemy Linux często używają systemd, który może potrzebować setek milisekund na uruchomienie usług. smolBSD całkowicie omija ciężkie systemy init.

Dla usług, które wymagają natychmiastowej dostępności, smolBSD zawiera narzędzie o nazwie nitro. Uruchamia Twoją usługę natychmiast po załadowaniu jądra. Brak procesów w tle. Brak narzutu menedżera usług.

Rezultat: uruchomienie serwera SSH w 10-14 milisekund na średniej klasy procesorze x86 z 2025 roku.

Zainstaluj wymagania wstępne na Linuksie

Potrzebujesz kilku pakietów. Na Debianie lub Ubuntu zainstaluj te wymagane pakiety:

sudo apt install curl jq git bmake qemu-system-x86_64 \
  sudo binutils libarchive-tools gdisk socat

Uwaga: W Debian 13 nazwa pakietu dla qemu to qemu-system-x86, nie qemu-system-x86_64.

Sklonuj repozytorium smolBSD i jesteś gotowy do tworzenia obrazów.

Proszę pamiętać, że bmake to BSD make. Standardowy GNU make nie będzie działać. Nazwa pakietu to zazwyczaj po prostu „bmake” w większości dystrybucji.

Zainstaluj wymagania wstępne na macOS

macOS nie może natywnie tworzyć obrazów systemu plików. Systemy plików ext2 i ffs używane przez NetBSD nie są obsługiwane przez macOS.

Zainstaluj bmake za pomocą Homebrew lub MacPorts. Zainstaluj QEMU dla swojej docelowej architektury.

Zamiast budować obraz budowniczego lokalnie, pobierz już zbudowany:

bmake fetchimg

To jest jedyna różnica. Wszystko inne działa tak samo jak na Linuksie.

Tworzenie pierwszego obrazu za pomocą smolBSD

Najszybszy sposób, aby zrozumieć smolBSD, to zbudowanie minimalnego obrazu ratunkowego.

git clone https://github.com/NetBSDfr/smolBSD
cd smolBSD
sudo bmake SERVICE=rescue build

To tworzy bootowalny obraz o rozmiarze 10 megabajtów. Proces budowania uruchamia tymczasową maszynę wirtualną nazwaną builder micro-VM. Ta maszyna builder tworzy twój system plików, instaluje pakiety i konfiguruje system.

Po pomyślnym zbudowaniu zobaczysz output podobny do poniższego:

[...]
🔲 destination architecture: amd64 / x86_64
➡️ creating root filesystem (20M)
/dev/rld0: Partition 1 added: 49f48d5a-b10e-11dc-b99b-0019d1879648 1024 38912
newfs: Warning: changing optimization to space because minfree is less than 5%
/dev/rdk1: 19.0MB (38912 sectors) block size 4096, fragment size 512
    using 4 cylinder groups of 4.75MB, 1216 blks, 2304 inodes.
super-block backups (for fsck_ffs -b #) at:
32, 9760, 19488, 29216,
extracting sets/amd64/rescue.tar.xz.. done
extracting sets/amd64/etc.tar.xz.. done
🧊 system root filesystem will be read-only
✅ image ready: images/rescue-amd64.img
✅ build finished, Ctrl-A X to exit
➡️ killing the builder microvm
qemu-system-x86_64: terminating on signal 15 from pid 939 (<unknown process>)

Twórz minimalne maszyny wirtualne Unix NetBSD za pomocą smolBSD

Kiedy kompilacja się zakończy, otrzymasz obraz dysku w katalogu images/.

$ ls images/
build-amd64.img  rescue-amd64.img

Uruchom to:

sudo ./startnb.sh -i images/rescue-amd64.img

Masz teraz działający system NetBSD.

Używanie składni Dockerfile

smolBSD zawiera skrypt o nazwie docker2svc.sh. Konwertuje on pliki Dockerfile na konfiguracje usług smolBSD.

Utwórz plik o nazwie Dockerfile.webserver:

FROM base,etc
LABEL smolbsd.service=webserver
LABEL smolbsd.minimize=y
RUN pkgin up && pkgin -y in nginx
CMD ["/usr/pkg/sbin/nginx", "-g", "daemon off;"]

Przekształć to:

./docker2svc.sh Dockerfile.webserver

Zbuduj to:

bmake SERVICE=webserver build

Linia FROM określa, które „zestawy” NetBSD mają być uwzględnione. Zestawy są sposobem NetBSD na pakowanie systemu bazowego. Zestaw base zawiera podstawowe narzędzia. Zestaw etc zawiera pliki konfiguracyjne.

Dyrektywy LABEL informują smolBSD o nazwie usługi i o tym, czy należy zminimalizować rozmiar obrazu.

Polecenie RUN jest wykonywane podczas budowania wewnątrz maszyny wirtualnej buildera. Tutaj instalujesz pakiety.

CMD określa, co zostanie uruchomione po starcie maszyny wirtualnej.

Rozumienie rozmiaru obrazu

Jak już stwierdziłem, minimalny obraz smolBSD ma około 10 megabajtów. Bardziej kompletny system z powszechnymi narzędziami może mieć 50-100 megabajtów.

Kontrolujesz rozmiar za pomocą zmiennej MINIMIZE:

bmake SERVICE=myapp MINIMIZE=y build

To zmniejsza obraz dysku do faktycznego użycia plus 10%. Jeśli Twój system plików używa 50MB, otrzymasz obraz o rozmiarze 55MB.

Możesz również ustawić określony rozmiar:

bmake SERVICE=myapp MINIMIZE=+20 build

Tworzy to obraz z 20 MB wolnego miejsca ponad to, które jest używane.

Lub ustaw to na stałe w pliku options.mk usługi:

IMGSIZE=50

Kompromis: mniejsze obrazy oznaczają mniej miejsca na logi, pliki tymczasowe lub dane w trakcie działania. Planuj odpowiednio.

Gotowe usługi, których możesz użyć

smolBSD zawiera kilka gotowych do użycia usług.

nbakery: Pełne środowisko deweloperskie z pkgin, doas i tmux. Buduj i uruchamiaj w 5 minut. Używaj go do przenośnego rozwoju na laptopie, w chmurze i systemach CI.

bozohttpd: Statyczny serwer sieciowy. Domyślnie udostępnia pliki z /var/www. Zbuduj go, przypisz port 80 do swojego hosta, a będziesz mieć natychmiastowy hosting statyczny.

nitrosshd: Serwer SSH, który uruchamia się natychmiastowo przy użyciu narzędzia nitro. Brak działających w tle usług. Idealny dla hostów przeskokowych SSH lub bezpiecznych punktów wejściowych.

rescue: Minimalny system 10MB. Przydatny do debugowania, odzyskiwania lub jako baza do własnych kompilacji.

Sieci i mapowanie portów

Mapuj porty przy uruchamianiu maszyny wirtualnej:

./startnb.sh -f etc/bozohttpd.conf -p ::8080-:80

To mapuje port hosta 8080 na port VM 80. Składnia to ::host_port-:vm_port.

Lub zdefiniuj to w swoim pliku Dockerfile:

EXPOSE 8080:80

Do dwukierunkowej komunikacji gniazdowej między hostem a gościem użyj usługi mport. Host otrzymuje plik gniazda Unix. Gość otrzymuje plik urządzenia, taki jak /dev/ttyVI01. Dane można wysyłać, wykonując echo do urządzenia.

Jest to przydatne do kanałów sterujących, rejestrowania lub niestandardowych mechanizmów IPC.

Tworzenie dla różnych architektur

NetBSD działa na tak wielu architekturach. smolBSD dziedziczy tę przenośność.

Buduj dla ARM64:

bmake SERVICE=rescue ARCH=evbarm-aarch64 build

System budowania pobiera odpowiednie jądro i ustawia je automatycznie. Uruchom je za pomocą qemu-system-aarch64.

Należy pamiętać, że nie wszystkie optymalizacje są dostępne na wszystkich architekturach. Czas uruchamiania wynoszący 10 milisekund dotyczy konkretnie x86 z obsługą PVH. ARM64 uruchamia się szybko, ale nie aż tak szybko.

Używanie Firecracker

Firecracker to hyperwizor microVM firmy Amazon. Napędza AWS Lambda i Fargate.

smolBSD działa z Firecracker bez żadnych dodatkowych ustawień. Mechanizm bootowania PVH jest dokładnie tym, czego oczekuje Firecracker.

Potrzebujesz:

  • Najnowszy binarny plik Firecracker
  • Procesor x86 z rozszerzeniami VT
  • Jądro netbsd-MICROVM

Wydajność jest doskonała. Można spodziewać się czasów uruchamiania wynoszących 10-14 milisekund na nowoczesnym sprzęcie.

To sprawia, że smolBSD jest odpowiedni do prawdziwych zadań bezserwerowych. Uruchamiaj maszynę wirtualną na każde żądanie. Przetwarzaj je. Zamykaj ją. Narzut jest znikomy.

Jak działa Builder Micro-VM

Kiedy uruchamiasz bmake build, smolBSD uruchamia tymczasową maszynę wirtualną. To jest budowniczy.

Konstruktor montuje Twój system plików hosta w trybie tylko do odczytu. Pobiera zestawy NetBSD, jeśli jest to potrzebne. Tworzy systemy plików, instaluje pakiety i konfiguruje docelowy obraz.

Dlaczego używać maszyny wirtualnej do budowania? Spójność. Linux i macOS mają różne narzędzia systemu plików. Nie mogą natywnie tworzyć systemu plików ffs NetBSD.

Maszyna wirtualna builder zapewnia ustandaryzowane środowisko. Każda kompilacja odbywa się w ten sam sposób niezależnie od systemu operacyjnego hosta.

Na Linuksie możesz samodzielnie zbudować obraz budowniczego:

bmake buildimg

Na macOS musisz go pobrać:

bmake fetchimg

Obraz budowniczego jest ponownie używany w trakcie budowy. Tworzysz go lub pobierasz tylko raz.

Czym smolBSD nie jest

1. smolBSd nie jest środowiskiem uruchomieniowym kontenerów

smolBSD tworzy obrazy maszyn wirtualnych. Każda VM ma własne jądro. Pełna izolacja.

2. Nie jest frameworkiem unikernel

Otrzymujesz kompletny zestaw użytkownika NetBSD. Standardową powłokę. Menedżera pakietów. Normalne narzędzia UNIX.

3. Nie jest zamiennikiem Dockera

Procesy robocze są podobne, ale podstawowa technologia jest inna. Używaj smolBSD, gdy potrzebujesz izolacji jądra lub gdy kontenery nie pasują.

4. Nieoptymalne dla trwałych obciążeń.

Skupiono się na szybkim czasie uruchamiania i minimalnym rozmiarze. Długotrwałe usługi działają dobrze, ale to nie jest główny przypadek użycia.

Ograniczenia i ryzyka

  • Sieciowanie może być skomplikowane: Mapowanie portów i konfigurowanie mostków sieciowych wymaga znajomości twojego hipernadzorcy.
  • Ograniczona społeczność: Z tego, co wiem, NetBSD ma mniejszą społeczność niż Linux (mogę się jednak mylić). Mniej pakietów. Mniej dokumentacji. Spodziewaj się, że niektóre problemy będziesz musiał rozwiązać sam.
  • Narzędzia w jakości alfa: smolBSD jest stosunkowo nowe. Spodziewaj się niedociągnięć. Podstawowa funkcjonalność działa, ale dopracowywanie trwa.
  • Nadal istnieje narzut zasobów: Maszyna wirtualna o wielkości 10 MB jest malutka w porównaniu z tradycyjnymi maszynami wirtualnymi. Nadal jest większa niż kontener. Narzut pamięci obejmuje cały jądro.
  • Aktualizacje zabezpieczeń wymagają przebudowy: Nie można łatwo załatać działającej maszyny wirtualnej smolBSD. Proces polega na przebudowie obrazu i ponownym wdrożeniu. Jest to zaprojektowane w ten sposób, ale różni się od tradycyjnego zarządzania systemem.

Częste błędy

1. Używanie standardowego make zamiast bmake

GNU make zakończy się niejasnymi błędami. Zawsze używaj bmake.

2. Nie pobieranie obrazu buildera na macOS

Nie można tego zbudować lokalnie. Najpierw uruchom bmake fetchimg.

3. Zapomnienie o dodaniu kluczy SSH przed budowaniem

Jeśli zbudujesz usługę SSH bez dodania swojego klucza publicznego, nie będziesz mógł się zalogować. Dodaj klucze do service/sshd/etc/ przed uruchomieniem bmake build.

cat ~/.ssh/id_ed25519.pub >> service/sshd/etc/mykey.pub

4. Nadmierne powiększanie obrazów

Domyślny rozmiar obrazu może być większy niż potrzebny. Użyj MINIMIZE=y, aby zmniejszyć obrazy do rzeczywistego użycia.

5. Oczekiwana gęstość na poziomie kontenera

VM-y wciąż są VM-ami. Każdy z nich ma narzut jądra. Możesz uruchomić setki lub tysiące na jednym hoście, ale nie dziesiątki tysięcy jak w przypadku kontenerów.

6. Niezrozumienie docelowego urządzenia rozruchowego

Czas rozruchu wynoszący 10 milisekund dotyczy działającej usługi, a nie ekranu logowania. Usługa musi być skonfigurowana tak, aby uruchamiała się natychmiast z Nitro.

Weryfikacja i testowanie

Po zbudowaniu obrazu przetestuj czas uruchamiania:

time ./startnb.sh -i images/myservice-amd64.img

Wynik pokazuje czas rzeczywisty, użytkownika i systemowy. Czas rzeczywisty obejmuje uruchomienie i start maszyny wirtualnej.

W przypadku usług opartych na nitro, usługa powinna być dostępna w ciągu milisekund. Na przykład, przetestuj usługę SSH:

./startnb.sh -f etc/nitrosshd.conf -p ::2222-:22 &
sleep 1
ssh -p 2222 root@localhost

Jeśli połączenie powiedzie się natychmiast, nitro działa poprawnie.

Sprawdź rozmiar obrazu:

ls -lh images/

Porównaj rzeczywisty rozmiar z oczekiwanym rozmiarem na podstawie ustawień MINIMIZE.

Kiedy korzystać z smolBSD

1. Przetwarzanie bezserwerowe i brzegowe

Szybki czas uruchamiania sprawia, że smolBSD jest idealny do wykonywania na żądanie. Uruchamiaj maszyny wirtualne w razie potrzeby. Minimalna kara za zimny start.

2. Przenośne środowiska programistyczne

Zbuduj raz, uruchamiaj wszędzie. Kontroluj wersje całego środowiska. Udostępniaj dokładne konfiguracje w zespołach.

3. Testowanie i CI/CD

Twórz czyste środowiska w ułamkach sekundy. Uruchamiaj testy w pełnej izolacji. Brak współdzielonego stanu jądra między uruchomieniami.

4. Piaskownica bezpieczeństwa

Uruchamiaj nieznany kod w prawdziwej maszynie wirtualnej przy minimalnym narzucie. Lepsza izolacja niż w kontenerach.

5. Nauka NetBSD

smolBSD zapewnia łatwy punkt wejścia do NetBSD bez instalowania go na sprzęcie fizycznym.

Kiedy nie używać smolBSD

1. Długotrwałe usługi produkcyjne

Tradycyjne maszyny wirtualne lub kontenery są lepiej dostosowane. Narzędzia są bardziej dojrzałe. Wzorce operacyjne są ustalone.

2. Obciążenia Windows lub Linux

smolBSD opiera się na NetBSD. Jeśli potrzebujesz Linuxa lub Windowsa, użyj ich.

3. Maksymalna gęstość

Kontenery zapewniają lepszą gęstość. Jeśli musisz uruchomić 10 000 instancji na jednym hoście, kontenery są rozwiązaniem.

4. Aplikacje stanowe z dużymi zbiorami danych

Minimalistyczny projekt zakłada małe, efemeryczne obciążenia. Duże bazy danych lub przechowywanie plików powinny działać gdzie indziej.

5. Zespoły nieznające systemu UNIX

Krzywa uczenia się istnieje. Jeśli Twój zespół zna Dockera, ale nie zna UNIX-a, przejście może nie być tego warte.

Szybkie czasy uruchamiania bez unikerneli

smolBSD reprezentuje inne podejście do problemu szybkiego uruchamiania. Zamiast redukować system do samego jądra jak unikernel, redukuje pełny system operacyjny.

Zachowujesz środowisko UNIX. Zachowujesz menedżera pakietów. Zachowujesz znane narzędzia.

Wadą jest prostota. Brak specjalnych bibliotek. Brak niestandardowych systemów budowania. Tylko NetBSD, ograniczone do niezbędnych rzeczy.

Dzięki temu operacje, debugowanie i rozwój stają się łatwiejsze. Warto również zauważyć czas uruchamiania wynoszący 10 milisekund.

Wniosek

smolBSD jest doskonałym wyborem dla obciążeń bezserwerowych, pipeline'ów CI/CD i przetwarzania brzegowego. Oferuje przewidywalny i powtarzalny sposób wdrażania oprogramowania.

Nie jest zastępstwem dla serwera Linux lub BSD ogólnego przeznaczenia, gdy potrzebujesz szerokiego wachlarza skomplikowanych procesów działających w tle.

Używaj smolBSD, gdy potrzebujesz szybkości i izolacji bez złożoności unikerneli. Unikaj go, jeśli potrzebujesz pełnego pulpitu lub wsparcia dla starszego sprzętu. Jest to ostre narzędzie do konkretnych zadań.

Jak już wspomniano, smolBSD nie zastąpi kontenerów. Nie musi. To inne narzędzie do innych problemów.

Zasoby:

  • Repozytorium GitHub smolBSD
  • Strona internetowa smolBSD