Konfigurujemy VPS - część 11, dygresja o możliwości ćwiczeń

Czy można jakoś poćwiczyć konfigurowanie małej maszynki typu VPS bez płacenia? Oczywiście można. Najprostszym rozwiązaniem jest postawienie takiego systemu na własnym domowym pececie.

Sposobów na to jest kilka. Niektóre działają także, gdy na domowej maszynie mamy Windows.

Osoby, które doskonale wiedzą, co to jest Vmware czy KVM, może zainteresować fragment dotyczący tworzenia obrazu systemu.

Obsługa wirtualizacji

Najbardziej znanymi programami obsługującymi wirtualizację są Vmware (do niedawna symbol tych technik) oraz VirtualBox. Oba działają zarówno pod Windows, jak pod Linuksem, oba pozwalają także na stawianie zarówno Windows jak Linuksa jako gościa, oba wizualizują uruchamianą wirtualną maszynę w okienku, oba zapewniają obsługę przy pomocy intuicyjnych menu i okien dialogowych. Z punktu widzenia zastosowania o którym piszę - nie ma większej różnicy, którego z nich użyjemy (a także, czy użyjemy VirtualBox w wersji open-source, czy zamkniętej).

Inną opcją (tym razem dostępną tylko pod Linuksem) jest KVM, dość nowe i w pełni open-source rozwiązanie wirtualizacji, wykorzystujące rozszerzenia procesorów z ostatnich lat. Można go używać samodzielnie albo w połączeniu z zapewniającym podstawowy interfejs okienkowy Virt-Managerem.

Porządnej dyskusji co lepsze (Vmware, VirtualBox czy KVM) się nie podejmę (zresztą, to nie koniec dylematu, Vmware ilością odmian oszałamia, VirtualBox ma wersję open-source oraz bogatszą komercyjną). W największym uproszczeniu: Vmware i VirtualBox są wygodniejsze w konfiguracji i zarządzaniu maszynami, za to słabiej zintegrowane z dystrybucjami (co np. często owocuje kłopotami przy aktualizowaniu jądra do nowszych wersji). KVM jest bezpośrednio wspierane przez autorów dystrybucji (min. Ubuntu ma go promować jako domyślne rozwiązanie wirtualizacyjne), ma kilka fajnych cech (jak wygodna obsługa uruchamiania bez wyświetlania okna) ale ogólnie jest bardziej surowe.

Do celów opisywanych w tym artykule zupełnie wystarczy każdy z tych programów.

Instalacja

Instalacja Vmware to doklikanie się do odpowiedniej wersji do pobrania i uruchomienie instalatora.

Instalacja Virtualboksa może przebiegać podobnie, w przypadku, gdy na domowej maszynie mamy Debiana lub Ubuntu, najmniej zachodu wymaga:

$ sudo apt-get install virtualbox-ose

Komercyjną wersję także można instalować z pakietów - patrz instrukcja na stronie autorów.

KVM zadziała tylko, gdy mamy jądro co najmiej 2.6.16 i odpowiedni procesor. Czy mamy odpowiedni system można sprawdzić zaglądając do /proc/cpuinfo - jeśli jest tam flaga vmx albo svm, KVM zadziała. Najprościej:

$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo

(jeśli powyższe polecenie cokolwiek wypisało, nasz system spełnia wymagania).

Instalację wszystkich potrzebnych pakietów zapewnia:

$ sudo apt-get install \
     ubuntu-virt-server ubuntu-virt-mgmt

a zbliżony efekt będzie miało:

$ sudo apt-get install kvm libvirt-bin ubuntu-vm-builder \
     qemu bridge-utils virt-viewer

Tworzenie obrazu systemu

Ubuntu zawiera poręczny skrypt generujący gotowy obraz dysku z już zainstalowanym i wstępnie skonfigurowanym surowym systemem.

Wykorzystanie tego mechanizmu nie jest niezbędne (zamiast tego można po prostu przeprowadzić instalację systemu od zera) ale może być pouczające. Efekt będzie bardzo zbliżony do tego, co możemy zastać na kupionym VPS.

Aby zeń skorzystać, instalujemy pakiet ubuntu-vm-builder.

$ sudo apt-get install ubuntu-vm-builder

Sam obraz budujemy poleceniem vmbuilder.

Wersja dla Vmware i VirtualBoksa:

$ sudo vmbuilder \
        vmserver \
        ubuntu \
        --suite hardy \
        --components 'main' \
        --arch 'i386' \
        --mem '96' \
        --rootsize '4096' \
        --swapsize '192' \
        --hostname 'testvps' \
        --name 'Jan Kowalski' \
        --user 'janek' \
        --pass 'haslo' \
        --domain 'mekk.waw.pl' \
        --verbose \
        --tmp /home/marcink/tmp \
        --dest $HOME/mojvirt

Wersja dla KVM:

$ sudo vmbuilder \
        kvm \
        ubuntu \
        --suite hardy \
        --components 'main' \
        --arch 'i386' \
        --mem '96' \
        --rootsize '4096' \
        --swapsize '192' \
        --hostname 'testvps' \
        --name 'Jan Kowalski' \
        --user 'janek' \
        --pass 'haslo' \
        --domain 'mekk.waw.pl' \
        --verbose \
        --tmp /home/marcink/tmp \
        --dest $HOME/mojvirt \
        --libvirt qemu:///system

Trwa to kilka, czasem nawet kilkanaście minut i ściąga sporo danych przez sieć (skrypt przeprowadza zautomatyzowaną instalację). Przed uruchomieniem warto dokładnie sprawdzić poprawność opcji.

Bardzo ważny jest pierwszy parametr, określający rodzaj tworzonego obrazu. Gdy jest to vmserver powstaje obraz w formacie Vmware, gdy kvm w formacie odpowiednim dla KVM.

Opisywany niekiedy w helpach parametr vbox nie działa. Za to bez żadnych problemów można uruchomić pod VirtualBoksem obraz vmserver.

Drugi parametr ustala rodzaj dystrybucji, przynajmniej przy uruchamianiu z Ubuntu nie mamy wyboru, a --suite jej wersję (proponuję hardy bo jest to wersja LTS, często stosowana na serwerach i często dostępna w ofertach hostingowych). Nieprzypadkowo wybrałem też architekturę i386 - 32-bitowe aplikacje zajmują mniej pamięci niż 64-bitowe, przy ciasnym systemie jest to istotne.

Warto na to zwrócić uwagę przy wyborze hostingu! Przynajmniej przy używaniu małego VPS korzystniejszy jest obraz 32-bitowy. Wspominam o tym, bo część dostawców daje tu wybór (np. promowane przeze mnie przy okazji tego cyklu Linode), a niektórzy oferują wyłącznie dystrybucje 64-bitowe (np. Slicehost).

Opcję --libvirt dodajemy tylko, gdy chcemy zarządzać maszyną przy pomocy programu virt-manager.

Pozostałe parametry powinny być dość intuicyjne, np. --rootsize ustala rozmiar wirtualnego dysku.

Opcje --name, --user i --pass to charakterystyki domyślnego użytkownika. To na niego będziemy się logować, będzie on też miał prawo zrobić sudo -i (dokładnie taką samą konwencję zapewnia wiele ofert VPS).

Parametrów jest jeszcze trochę, opis wszystkich dostajemy wołając:

$ vmbuilder vmserver ubuntu --help

Można np. od razu zadać klucz SSH wrzucany na konto domyślnego użytkownika, zażądać preinstalowania zadanych pakietów, ustawić konfigurację sieciową (--ip '192.168.1.51' --gw '192.168.1.1' --dns '212.76.39.205') itd. Opcje te służą głównie osobom, które budują maszyny wielokrotnie i chcą uniknąć ich konfiguracji po zbudowaniu.

Poskładanie opcji vmbuilder-a ułatwia pomocnicza stroniczka generująca tekst tego polecenia.

vmbuilder stworzy w katalogu zadanym opcją --dest pliki obrazu w odpowiednim formacie (.vmdk dla Vmware, .qcow2 dla KVM).

Jako ciekawostkę dodam, że po:

$ sudo apt-get install python-vm-builder-ec2

pojawia się możliwość generowania obrazów w formacie zgodnym z Amazon EC2.

Stworzenie i uruchomienie maszyny wirtualnej

Kolejnym krokiem jest stworzenie samej wirtualnej maszyny i jej uruchomienie. Omówię to na przypadkach VirtualBoksa oraz KVM.

VirtualBox

Uruchamiamy program virtualbox, nakazujemy stworzenie nowej maszyny i przechodzimy sekwencję dialogów. Szczegółowy opis sobie daruję, jest ich w sieci wiele - patrz na przykład to omówienie z licznymi screenshotami. Ilość pamięci RAM regulujemy wdg. tego, jak słabą maszynę chcemy testować (np. 128MB lub 256MB).

Jeśli tworzyliśmy obraz dysku metodą z poprzedniego rozdziału, klikamy przy pytaniu o wirtualny dysk twardy przycisk Istniejący, w wyświetlonym menedżerze wirtualnych dysków wybieramy Dodaj i po prostu lokalizujemy na dysku stworzony przez vmbuilder plik .vmdk. Jeśli nie, tworzymy nowy dysk sensownej dla testów wielkości (np. 5GB).

Jeżeli nie tworzyliśmy obrazu, musimy zainstalować system od zera. Po prostu:

• ściągamy obraz dysku instalacyjnego dystrybucji Linuksa, którą chcemy testować (np. Ubuntu Server),

• konfigurujemy CD-ROM w wirtualnej maszynie jako podpięty do tego właśnie obrazu ISO (wszystkie omawiane programy mają taką możliwość),

• uruchamiamy wirtualną maszynę i przeprowadzamy proces instalacji (wybierając absolutne minimum opcji, unikając instalacji środowiska graficznego itp).

Maszyna uruchamia się i działa.

KVM (virt-manager)

Maszynę KVM można uruchomić na trzy sposoby - z palca, przy pomocy graficznego programu virt-manager albo shellowego virsh. Najwygodniejsze jest to drugie.

Program virt-manager odpalamy:

$ sudo virt-manager

(używanie bez uprawnień roota też jest możliwe ale wymaga pomęczenia się z konfiguracją, nie ćwiczyłem tego). Po uruchomieniu trzeba prawo-kliknąć linijkę localhost (System) i wybrać Connect.

Pojawi się nasza maszyna (o ile użyliśmy opcji --libvirt). Dalsza obsługa jest dość intuicyjna. Przycisk Open otwiera okno maszyny pozwalając ją uruchomić, przycisk Details pozwala ustalić charakterystyki maszyny (rozmiar pamięci, wirtualne dyski, obsługa VNC itd itp).

Z grubsza te same operacje, które wyżej odklikiwaliśmy, można wykonać również terminalowo, przy pomocy programu virsh (virt-manager i virsh używają biblioteki libvirt, w ramach której rozwijane jest uogólnione API do zarządzania wirtualnymi maszynami różnych typów).

libvirt i virt-manager to ciekawe i rozbudowane projekty, w tym artykule tylko je wspominam. Mamy min. narzędzia takie jak virt-install, virt-clone, virt-image, nieco dziwaczne Connect jest odpryskiem od możliwości zarządzania zdalnymi wirtualnymi maszynami.

Prosty przykład użycia niektórych z tych programów można znaleźć tutaj.

KVM (ręcznie)

Z palca robimy na przykład:

$ kvm -m 96M -name MojTestVPS disk0.qcow2

Plik disk0.qcow2 to efekt działania vmbuilder-a (albo jakiejś innej techniki tworzenia dysków dla KVM). -m zadaje rozmiar pamięci. -name nazwę okna.

Wszystkie opcje kvm są opisane w man kvm-qemu. Do konfiguracji sieci wrócę za chwilę, tu wspomnę możliwości alternatywnego podejścia do prezentacji interfejsu.

Kursor myszy uwalniamy naciskając naraz Ctrl i Alt.

Uruchomienie maszyny bez wyświetlania okna:

$ kvm -m 128M -nographic disk0.qcow2

Tak odpalony wirtualny system będzie widoczny tylko przez sieć.

Można dodać jeszcze -daemonize by uruchomił się w tle, niezależnie od terminala.

Uruchomienie maszyny z podglądem przez VNC:

$ kvm -m 64M -vnc :7 disk0.qcow2

Taka maszyna nie wyświetli okna ale będzie mogła być podglądana przez VNC (tu - nasłuchując na porcie 5907, czyli z podglądaniem vncviewer glowna.maszyna:7). Efekt stanowi ciekawą alternatywę dla wirtualnej sesji na serwerze.

Można napisać -vnc localhost:7, co uniemożliwi zdalny dostęp z innych maszyn. Można też zabezpieczyć sesję hasłem pisząc -vnc :7,password (jedyny sposób na ustawienie tego hasła, jaki znam, to odklikanie go w virt-managerze).

Wygodnym sposobem na wypracowanie wiersza poleceń kvm jest ... uruchomienie virt-managera i podejrzenie wygenerowanej przezeń komendy (np. przy pomocy ps waux | grep kvm).

Może wyglądać np. tak:

/usr/bin/kvm -S -M pc -m 96 -smp 1 -name testvps -monitor pty -boot c -drive file=/home/marcin/mojvirt/disk0.qcow2,if=ide,index=0,boot=on -net nic,macaddr=52:54:00:d2:be:4f,vlan=0 -net tap,fd=11,script=,vlan=0,ifname=vnet1 -serial none -parallel none -usb -vnc 127.0.0.1:0

Sieć

Sieć między wirtualną maszyną a resztą świata można skonfigurować na kilka sposobów. Terminologia niekiedy się różni, ale w każdym z produktów mamy do dyspozycji:

• maskaradę (NAT) - program zarządzający wirtualizacją przekłada żądania generowane przez wirtualny system, można inicjować połączenia z wnętrza wirtualnej maszyny ale nie można łączyć się z zewnątrz do niej (czasem można to rozwiązać zwrotnym przekierowaniem wybranych portów) - sytuacja trochę przypomina laptopa z prywatnym adresem w sieci domowej dopiętej do internetu przez maskaradujący ruter (tu laptopem jest wirtualny system, siecią domową programowy interfejs, a ruterem główna maszyna),

• pseudosieć ograniczoną do wirtualnych maszyn (internal, host-only) - kilka wirtualnych systemów może komunikować się między sobą ale nie mają łączności ze światem zewnętrznym,

• mostkowanie (bridge) - macierzysty interfejs głównej maszyny przechodzi w tryb pracy pozwalający posiadanie przez wirtualny system prawdziwego adresu IP z sieci w której działa główna maszyna, staje się ona pełnoprawnym elementem sieci lokalnej.

Wybór następuje w ramach interfejsów konfigurowania maszyn (w przypadku KVM przez odpowiednie opcje uruchomieniowe). Szczegółów nie będę tu opisywał, bo różnią się nie tylko między poszczególnymi programami ale nawet pomiędzy różnymi ich wersjami.

Wewnątrz wirtualnej maszyny zazwyczaj wystarczy zdefiniować interfejs jako obsługiwany przez DHCP (i tak właśnie szykuje ją domyślnie vmbuilder). Programy obsługujące wirtualizację odpowiednio obsłużą zapytania DHCP. Ustawianie adresu explicite może być potrzebne tylko przy mostkowaniu.

KVM, a także starsze i open-source wersje VirtualBoksa wymagają przy pracy w trybie mostka samodzielnego przekonfigurowania interfejsu sieciowego (Vmware oraz najnowszy komercyjny VirtualBox radzą sobie własnymi modułami jądra).

Najprostsza obecnie działająca metoda pod Ubuntu to:

$ sudo apt-get install bridge-utils

a następnie edycja pliku /etc/network/interfaces polegająca na zastąpieniu eth0 przez br0 i dodaniu klauzul związanych z mostkowaniem. Przykładowo, jeśli mieliśmy:

auto eth0
iface eth0 inet static
    address 192.168.1.2
    netmask 255.255.255.0        
    gateway 192.168.1.1
    dns-nameservers 112.76.39.204 112.76.33.137

należy zamiast tego wprowadzić (usuwając orginalne eth0):

auto br0
iface br0 inet static
    address 192.168.1.2
    netmask 255.255.255.0        
    gateway 192.168.1.1
    dns-nameservers 112.76.39.204 112.76.33.137
    bridge_ports eth0
    bridge_fd 9
    bridge_hello 2
    bridge_maxage 12
    bridge_stp off

po czym zrestartować interfejsy (sudo invoke-rc.d networking restart) i ... zacząć od weryfikacji, czy nadal działa sieć na głównej maszynie.

Uwaga: możemy napotkać problemy gdy używamy (na głównym systemie) shorewalla czy innego firewalla. Zmienia się oznakowanie interfejsów sieciowych, co wymaga rekonfiguracji reguł, do tego w przypadku shorewalla potrzebne są specjalne uzupełnienia związane z mostkowaniem (routeback).

Już w kontekście uruchamiania wirtualnej maszyny, przy używaniu KVM należy przejrzeć plik /etc/kvm/kvm-ifup (to tam znajdują się dyrektywy aktywujące interfejs używany przez wirtualny system).

Dalsza konfiguracja

Dalsza konfiguracja wirtualnej maszyny może przypominać to, co po trochu w ramach cyklu o konfigurowaniu VPS pracowicie opisuję. Dla naturalności ćwiczenia zachęcam, by nie instalować żadnych środowisk graficznych i pracować terminalowo.

Oczywiście można uruchamiać kilka wirtualnych maszyn - czy to na zmianę (w ramach ćwiczeń różnych konfiguracji), czy równocześnie (testując pomysły na aplikacje rozproszone).

Ciąg dalszy nastąpił.