Uruchamianie serwera deweloperskiego na wirtualnej maszynie

W mojej codziennej pracy przy programowaniu aplikacji webowych mam wiele lokalnie skonfigurowanych wirtualnych hostów do obsługi poszczególnych projektów. Niestety wszystkie aplikacje działają w tym samym środowisku (wersja Apache, PHP, RoR, MySQL, itp.), a ewentualne zróżnicowanie jest problematyczne. Niedawno przeniosłem jednak projekty do wirtualnej maszyny, gdzie mogę mieć dowolną konfigurację środowiska nie zmieniając mojej lokalnej.

Co dokładnie daje mi takie rozwiązanie? Mam zainstalowany serwer linuksowy (Ubuntu w moim przypadku) na podstawowej maszynie i tam skonfigurowane wszystkie projekty. Są tam też uruchomione domyślne wersje serwerów z repozytorium. Jeżeli jednak potrzebuję sprawdzić działanie serwisu w innej wersji oprogramowania (np. PHP 6.0), robię klon wirtualnej maszyny, konfiguruję takie oprogramowanie, jakie potrzebuję i… voila, moje aplikacje uruchamiane są w nowym środowisku. Mój lokalny system jest niezmienony, a powrót do poprzedniej konfiguracji to poprostu wyłączenie nowego serwera i włączenie poprzedniego. Bardzo wygodne!

Największą zaletą tego rozwiązania jest to, że nie muszę zmieniać mojego środowiska programistycznego. Wszystkie pliki umieszczone są cały czas na mojej stacji roboczej i mogę na niej uruchamiać dowolne oprogramowanie do tworzenia kodu (np. NetBeans, RadRails czy gedit) oraz testowania (przeglądarki WWW).  I to wszystko za pomocą darmowego oprogramowania! Czy może być lepiej?

Instalacja i uruchomienie

Pracuję na systemie Linux Ubuntu i w nim testowałem ustawienia, ale wszystko powinno działać również pod innymi systemami operacyjnymi (być może po małym dostosowaniu). Na wirtualnym serwerze instaluję Linux Ubuntu Server z podobną uwagą, jak przy stacji roboczej – po małym dostosowaniu powinny działać inne systemy i dystrybucje.

Do obsługi wirtualnych maszyn korzystam z VirtualBox. Najnowsza wersja dostępna w chwili pisania tego tekstu to 4.1.6. W repozytorium Ubuntu jest tylko nieco starsza wersja, ale polecam nie korzystać z niej, a zamiast tego ściągnąć paczkę .deb ze strony producenta i zainstalować. Systemowa wersja robi problemy z instalacją VirtualBox Guest Additions, które są potrzebne do skonfigurowania współdzielonych katalogów.

Po uruchomieniu VirtualBoksa, tworzymy nową wirtualną maszynę, nadajemy jej nazwę i wybieramy system operacyjny (u mnie to Linux – Ubuntu). Na następnej stronie wybieramy ile pamięci RAM udostępniamy dla serwera. Wartość należy dostosować do własnych potrzeb oraz możliwość stacji roboczej i można ją zmieniać później (należy uważać przy uruchamianiu systemów Windows na wirtualnych maszynach – zmiana ilości RAM może mieć wpływ na aktywację licencji). W następnym kroku tworzymy dysk twardy. Warto ustawić dysk o dynamicznym rozmiarze, który na początku będzie zajmował tak mało miejsca na dysku, jak się da i w razie potrzeby będzie zwiększany. 2GB to minimum, bo trochę ponad 1GB to system operacyjny, a później dobrze jest mieć zapas na dodatkowe oprogramowanie (u mnie jest to domyślne 8GB). Wirtualna maszyna jest już skonfigurowana i gotowa do uruchomienia!

Następny krok to instalacja systemu operacyjnego. Opis instalacji serwera pominę, bo nie jest to związane z samą deweloperską maszyną wirtualną. Opisów instalacji serwera jest w Internecie dużo, można znaleźć też gotowe pliki VirtualBoksa z systemem.

Połączenie stacja robocza <-> wirtualny serwer

Pliki ze stacji roboczej muszą być widoczne dla wirtualnego serwera, żeby można było uruchamiać tworzone aplikacje, ale jednocześnie muszą pozostać na stacji roboczej, aby można je było wygodnie edytować. Rozwiązać to można na różne sposoby, ja jednak najbardziej lubię korzystać ze współdzielonych katalogów VirtualBoksa. Potrzebujemy do tego skonfigurowanej sieci, uprawnień do podłączania katalogów współdzielonych oraz zainstalowanych VirtualBox Guest Additions.

Aby systemy mogły widzieć się wzajemnie w sieci lokalnej w konfiguracji wirtualnej maszyny należy ustawić sieć na korzystanie z Bridged Adapter. Na serwerze najlepiej jest ustawić statyczne IP albo za pomocą DHCP (jeśli uda się skonfigurować, mój router na to nie pozwala) albo przez konfigurację sieci serwera. Mój /etc/network/interfaces ma zawartość:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address    192.168.1.220
    netmask    255.255.255.0
    network    192.168.1.0
    broadcast  192.168.1.255
    gateway    192.168.1.1

dzięki czemu serwer ma zawsze IP 192.168.1.220 i jest widoczny z mojej stacji roboczej (a nawet całej sieci lokalnej). Konfiguracja sieci (w szczególności poszczególne adresy IP) będzie się różniła w zależności od ustawień pozostałych urządzeń i infrastruktury.

Żeby móc w pełni korzystać z ustawień VirtualBoksa musimy dodać użytkownika stacji roboczej do grupy vboxusers (polecenie wykonujemy na naszej stacji roboczej, nie na serwerze!):

(sudo) adduser username vboxusers

Następny krok to instalacja VirtualBox Guest Additions na serwerze. Automatyczny instalator, jeśli się dobrze orientuję, jest tylko dla interfejsów graficznych, dlatego po zamontowaniu ISO musimy ręcznie uruchomić instalator VBoxLinuxAdditions.run z katalogu głównego płyty. Do pomyślnego uruchomienia potrzebnych jest kilka pakietów zainstalowanych w systemie (m.in. nagłówki jądra systemu). Dokładne ustawienia mogą zależeć od maszyny i najlepiej jest czytać komunikaty błędów i uzupełniać braki. Podobnie jak sama instalacja systemu, ten krok jest związany z konfiguracją serwera, a nie wirtualnej maszyny i w opisie go pominę.

Gdy maszyny „widzą się” już w sieci i mamy wszelkie potrzebne uprawnienia oraz zainstalowane komponenty i dodatki, przechodzimy do konfiguracji katalogów współdzielonych w maszynie wirtualnej w ustawieniach w oknie programu VirtualBox. Ja dodałem cały mój katalog ~/workspace, gdzie mam kod wszystkich aktualnie rozwijanych aplikacji, jako udział o nazwie workspace z włączonymi opcjami Auto-mount i Make Permanent. Dzięki temu przy każdym uruchomieniu serwera mam dostęp na serwerze do moich plików pod ścieżką /media/sf_workspace.

Ostatnia rzecz to konfiguracja serwera HTTP, w moim przypadku to Apache 2.X. W pliku konfiguracji /etc/apache2/httpd.conf (lub odpowiadającym mu na innych serwerach) dodajemy wpis:

Group vboxsf

(i resetujemy lub przeładowujemy konfigurację serwera HTTP) aby serwer miał dostęp do odczytu/zapisu plików w udziale (vboxsf to domyślna grupa, która ma tam uprawnienia). Do tej grupy można dodać też konto, przez które logujemy się na serwerze, żeby móc również z niego przeglądać pliki.

Dalej pozostaje już tylko skonfigurować poszczególne projekty na serwerze, co już całkowicie zależy od bardzo wielu rzeczy (łącznie z technologią, w jakiej tworzona jest aplikacja). Ze stacji roboczej można kierować ruch na domeny konfigurując lokalny DNS (lub /etc/hosts na adres IP wirtualnego serwera.

Krótkie podsumowanie

W moim przypadku to bardzo dobrze sprawdzające się narzędzie ułatwiające rozwijanie i testowanie moich aplikacji. W PHP mogę sprawdzać różne wersje interpretera, Zend Server zamiast zwykłego Apache i inne ustawienia. W RoR to głównie różne wersje Ruby i Ruby on Rails. Największa wada to większe zużycie pamięci RAM i pamięci dyskowej. W wykorzystaniu procesora nie widzę dużych różnich.