To w ogóle jest jakaś różnica?

Tak. Na dość płytkim podejściu do tematu można odnieść wrażenie, że te dwa rozwiązania są dość podobne do siebie.

Nic bardziej mylnego!

Różnice są dość znaczne, zarówno od kwestii technicznej, jak i samego sposobu myślenia.

Idea maszyny wirtualnej

Niezależnie od wybranego hypervisora, maszyna wirtualna… czekaj. Wybranego co? Musimy wprowadzić na tym etapie już jedno pojęcie, jakim jest hypervisor. To oprogramowanie, które odwala za nas całą robotę w momencie, w którym postanowimy uruchomić kolejną niezbędną dystrybucję Linuksa. Albo postanowimy coś popsuć. Wikipedia podpowiada coś o przerwaniach, emulacji i innej sytuacji. Na tym etapie nie zawracaj sobie tym głowy. Nie znaczy, że to nie jest istotne, ale to nie czas na to. Po prostu myśl o tym, jak o oprogramowaniu pozwalającym na uruchamianie innych systemów operacyjnych wewnątrz tych programów.

Oprogramowaniem, które spotkasz na swojej drodze, będzie prawdopodobnie coś z poniższej listy:

• Virtualbox
• Hyper-V od Microsoftu
• KVM wraz z QEMU (choć tutaj definicja może być trochę… niejasna)
• VMware Workstation
• Proxmox
• VMware ESXi

Oczywiście produktów jest zdecydowanie więcej.

Skupmy się na pewnym podziale. Jeśli nie przespałeś ostatnich 69 lat pod kamieniem, prawdopodobnie spotkałeś się z którąś z powyższych pozycji. Jedne można uruchamiać jak system operacyjny, inne są programem, który instalujesz jak każdą kolejną przeglądarkę.

Niezależnie od wyboru, pozwalają uruchomić w izolowanym od reszty komputera (od systemu hosta) całe środowisko, wraz z udawaniem sprzętu, zasobów dyskowych, kart sieciowych, wszystko na poziomie sprzętu. Możesz tak oszukać system gościa (czyli ten w wirtualce), aby nie zorientował się, że jest w maszynie wirtualnej.

Trzeba wspomnieć jednak o wyższym poziomie abstrakcji, gdzie można udawać inne procesory, architektury i cały sprzęt. Tak, patrzę na ciebie QEMU. Jednak taki proces to emulacja i nie powinien być bezpośrednio łączony z wirtualizacją.

Systemy gościa to te same systemy, co instalowane bezpośrednio na komputerze (bare metal). Zainstalujesz prawdopodobnie to samo Ubuntu, z tego samego obrazu na swoim komputerze, jak i w maszynie wirtualnej. I zainstalujesz to Ubuntu wraz z jądrem, sterownikami, bibliotekami i całym dobrodziejstwem inwentarza.

Hypervisor typu I

Instalujesz je jak każdy inny system operacyjny. Co to znaczy? Pakujesz takiego Proxmoxa na dysk i masz gotowy zestaw do wirtualizowania maszyn. Nie znajdziesz tutaj GUI znanego z każdego innego systemu operacyjnego, a zarządzanie odbywa się przez interfejs tekstowy (CLI na podłączonym monitorze, albo poprzez SSH), bądź przez WWW.

Co do kwestii instalacji jakiegoś środowiska graficznego na maszynie z takim Proxmoxem… Nikt nie mówi, że się nie da. Podobnie nie ma zakazu srania do paczkomatu, ale nie wolno srać do paczkomatu. Nie instaluj tam żadnego Gnoma czy innego KDE. Nie i już.

Takie podejście niesie za sobą sporo zalet. Nie masz zbędnych elementów systemu. Bo tak naprawdę nie potrzebujesz serwera wydruku, kalendarza, zestawu gier karcianych, klienta poczty i odtwarzacza filmów. Potrzebujesz czegoś maksymalnie lekkiego, co nie wciągnie cennych zasobów, nie spowolni działania maszyny wirtualnej i wprowadzi pewne ulepszenia związane z poprawą wydajności i stabilności.

Sztandarowym przykładem takiego oprogramowania jest Proxmox oraz VMware ESXi. W domowym kurwido… homelabie wystarczy w zupełności Proxmox w darmowej odmianie. Jakie mam ku temu argumenty?

• Jest dobrze udokumentowany
• Jest za darmo
• Jest sprawdzony
• Pod spodem siedzi Debian, który jest mocno oskryptowany (to rażące uproszczenie)
• Jest dość stabilny
• Funkcjonalność wystarczy do domu i to ze sporym zapasem

A VMware ESXi? Produkty VMware to właściwie industry standard ale to nie znaczy, że jest idealny. Osobiście do produktów VMware nie mam szczęścia, nie przepadam za nimi w swoim domu (w pracy co innego, ale na szczęście mam tego bardzo mało) i uważam, że jeśli nie potrzebujesz iść w ekosystem od Vmware, to Proxmox jest bardzo dobrym wyborem.

No i mam focha na Broadcoma za to, że zrobili kilka zakupów, w tym właśnie VMware. Zrobili przy tym kilka brzydkich ruchów, podjęli nieprzemyślane decyzje i w mig zburzyli obraz standardu przemysłowego.

Uważam, że w domowej zabawie Proxmox może być pierwszym wyborem. Do pewnego etapu mechaniki rządzące się w pewnych rozwiązaniach mogą nazywać się podobnie, ale działać w zbliżony sposób.

Hypervisor typu II

Tutaj sytuacja ma się zgoła inaczej. Instalujesz w swoim systemie operacyjnym program, wewnątrz którego uruchamiasz kolejne maszyny wirtualne. I tak możesz wewnątrz Windowsa 11 odpalić najnowsze BSD pingujące odpalone obok Ubuntu. A w tle odpalić przeglądarkę internetową z YouTube czy innego Netflixa.

Bo możesz i do tego to służy.

To świetne narzędzia, które sprawdzają się w szybko uruchamianych, krótko żyjących rozwiązaniach. Przykładem może być nauka instalacji i konfiguracja serwera WWW w Debianie. Możesz także emulować całe sieci – dlaczego na Linuksie nie zbudować routera i nie sprawdzić, co się dzieje pod maską?

Do takich rozwiązań zostało to stworzone i hostowanie czegokolwiek produkcyjnie (nawet w domu) zakrawa trochę o masochizm. I sadyzm. Jednoczesnie.

Jednocześnie musisz pamiętać o pewnych konsekwencjach takiego rozwiązania. Pod maszyną wirtualną nie masz jedynie lekkiego OS służącego wyłącznie do gmerania w wirtualkach, a opasłą kobyłę, z pięknym GUI, toną aplikacji, milionem powiadomień i śmietnika w postaci plików.

Oczywiście da się na tym coś na stałe posadzić. Sam tak zaczynałem – Debian + VirtualBox (później także Docker) i jakieś usługi typu DNS i serwer wydruku. Ale to było niewygodne rozwiązanie. Dużo wygodniejsze okazało się użycie Proxmoxa (zarządzanie przez WWW i humanitarne CLI).

Nie oznacza to jednak, że hypervisory typu II nie posiadają żadnego zarządzania przez CLI czy WWW. O nie nie. Nawet przeciętny Virtualbox pozwala na bardzo dużo poprzez interfejs tekstowy. Chcesz więcej, niż 4 karty sieciowe? A proszę bardzo. Więcej VRAM? Łap. Jakieś dzikie ustawienia sieciówek? No dawaj. Ale nadal – to nie jest wygodne w ogólnym rozrachunku.

Czym warto się zainteresować na początek? Virtualbox jest dość dobrym rozwiązaniem. Sama aplikacja i całe jej środowisko nie należy do najszybszych i do najstabilniejszych. Ma swoje problemy, często dość kretyńskie (np. przechwycenie kursora myszki, ukrycie go i zawieszenie wirtualki bo tak), ale w ogólnym rozrachunku jest trochę jak piwo Tyskie. Czy jest dobre? Zdania ekspertów są podzielone ale pijąc coś lepszego prawdopodobnie porównasz to do Tyskiego, bo to znany większości punkt odniesienia. I podobnie jest z Virtualboxem. Jest pewnego rodzaju punktem odniesienia (prawdopodobnie wszystko co potem poznasz, będzie lepsze pod jakiś względem), ale uruchomisz to wszędzie, obsłuży wszystko, da się to rozklikać i nie wymaga zaawansowanej wiedzy.

Dość powiedzieć, że mój tata, wieloletni, choć nie do końca świadomy użytkownik Ubuntu czasami rozklikuje sobie Virtualboxa aby uruchomić Windowsa 7, innym razem Windowsa 11 a innym razem starego Windowsa XP. I nie wymaga to żadnej specjalistycznej wiedzy.

Jesli jednak zapragniesz zrobić trochę więcej ambitnych rzeczy, Virtualbox pozwoli Ci na to, bez rozwalania całego dotychczasowego środowiska.

Kontenery

Pamiętasz, kilka akapitów wyżej napisałem coś o udawaniu całej warstwy sprzętowej i dobrodziejstwie inwentarza maszyn wirtualnych i systemów operacyjnych tam instalowanych.

Wyobraź sobie jednak, że na swoim serwerze posiadasz Proxmoxa (pod którym leży cichutko Debian, ale niech to zostanie między nami), a w nim masz uruchomione kilka maszyn wirtualnych (serwer WWW, serwer plików/NAS, serwer wydruku, LDAP, jakieś reverse proxy i jakieś coś do rysowania ładnych wykresów). Każda maszyna wirtualna to udawany sprzęt, uruchomione jądro, uruchomione sterowniki, załadowane biblioteki. I to razy sześć. Sześć razy to samo, bo wszystko siedzi na Ubuntu. Widzisz już pewien problem?

Co gdyby tak zrobić coś takiego, aby było to załadowane raz, obsłużone raz, a skupić się na różnicach wynikających z budowy danej aplikacji?

Właśnie wynalazłeś kontenery. Podnosisz jeden system operacyjny, wrzucasz coś do zarządzania kontenerami, w to aplikacje i to wszystko.

Nadal nie rozumiesz? Wyobraź sobie sklep. Sklep potrzebuje murów, dachu, instalacji elektrycznej, wodnej, kanalizacyjnej, mebli, jakiejś kasy, ogrzewania, ochrony, monitoringu, internetu… No i pewnie miliona innych rzeczy, które trzeba budować od zera. Widzisz analogię do maszyny wirtualnej? Teraz popatrz na galerię handlową. To właśnie taki zarządca kontenerów. Zapewnia lokal, mury, dach, adres, dostęp do mediów, ogrzewania w ramach jednego budynku posiadającego pierdyliard lokali. Otwierając w galerii sklep interesuje Cię wyposażenie sklepu, nie budowa dachu. I to jest konteneryzacja. Restauracja obok nie postawi swojego dachu i nie doprowadzi wody na nowo, bo nie ma takiej potrzeby. Galeria to zapewnia. Tak samo jest z kontenerami. Taki Docker zapewnia gadanie i używanie tego samego jądra systemu, co maszyna hosta.

Czym warto się zainteresować?

• Oczywiście Docker. Stał się standardem w kontekście kontenerów. Jest prosty, można go niewielkim wysiłkiem zmusić do działania jak IAC (Docker Compose), posiada ogromną baze użytkowników, został przeorany na wszystkie strony, wsparcie jest ogromne, po prostu działa. Nie wymaga także ogromnych zasobów, szczególnie gdy Twoim systemem hosta jest jakiś Linux. W przeciwnym wypadku pomiędzy kontenerami a systemem operacyjnym będzie transparentna wirtualka z linuchem. Możesz uruchamiać całe aplikacje (WordPress dla przykładu), całe systemy operacyjne (Debian, Alpine Linux), które są raczej bazą do tworzenia własnych obrazów. W pewien sposób taki poziom abstrakcji pozwala na wybudowanie całkiem sprawnej aplikacji, która jest bardzo przenośna, łatwa w aktualizacji i nie wymaga więcej uwagi, niż jest to minimalnie wymagane.
• LXC. Jeśli kilka akapitów powyżej wspomniałem o Proxmoxie, to muszę wspomnieć o tych kontenerach. To, co różni podejście LXC od Dockera, to dostarczanie raczej jedynie samego systemu operacyjnego, niż aplikacji mogących działać w nim. Używam ich do tworzenia maszyn i serwerów, w których dopiero działa Docker ze swoimi kontenerami. Zaletą jest to, że taki cały Debian w formie obrazu waży jakieś 130 MB, potrzebuje niewiele zasobów do uruchomienia (sporo aplikacji zmieścisz na 2 GB ramu) i jest właściwie przeźroczysty. Dobra alternatywa dla całych maszyn wirtualnych, szczególnie, gdy po raz 2137 tworzysz VM i powtarzasz te same kroki

Na cholerę mi te wirtualizacje i jakieś kontenery?

Oczywiście możesz uruchamiać jeden komputer, z jednym systemem operacyjnym i uruchamiać na nim jedną usługę. Nikt nie broni. Ba, wybierając małą jednostkę nawet nie poczujesz 2 takich urządzeń. Może i przeżyjesz trójkę takich urządzeń.

Ale co w przypadku 10 usług i aplikacji?

Co do domu?

Cokolwiek. Do widzenia, koniec wpisu.

Polecam komputer z Proxmoxem, w nim przynajmniej jeden kontener LXC w którym posadzisz Dockera z kontenerami. Dlaczego? Pozwoli na wycięcie sporej ilości zajmowanych zasobów, zachowuje się w domu jak każda inna wirtualka, oszczędza czas i jest zwyczajnie wygodne. Ale maszynę wirtualną polecam niezależnie od wybranych rozwiązań. To najbliższe bare metal, choć ze zawsze optymalne rozwiązanie.