Na poły wirtualne środowisko developerskie

Wymiana dysku systemowego na SSD była dla mnie okazją do wprowadzenia zmian w domowym Linuksie. Jedną z nich było postawienie zupełnie nowego środowiska developerskiego. Z powodzeniem używam go już od niemal dwóch miesięcy i jestem z niego zadowolony, więc żywię skromną nadzieję, że opisując je może komuś pomogę.

Przez długie lata jeden system służył mi do Internetu, programowania, rozrywki i wszelkich innych zastosowań. Miałem na nim zainstalowany komplet przeglądarek, wybór baz danych (m.in. PostgreSQL, MySQL, MongoDB), trochę serwerów (Lighttpd, ProFTPd, IceCast), interpretery i kompilatory różnych języków programowania (PHP, Python, g++…) plus sporo różnych narzędzi. Takie rozwiązanie ma kilka wad:

  • Na desktopie mam przeważnie nowsze wersje programów niż na serwerze produkcyjnym, więc czasami pojawiają się problemy z kompatybilnością.
  • Bazy, serwery i inne bajery pożerają zasoby nawet jeśli ich w danej chwili nie potrzebuję, bo nie programuję.
  • Kompilowanie programów ze źródeł, instalowanie dziwnych paczek, grzebanie w konfiguracji programów nawet przy zachowaniu staranności prędzej czy później tworzy w systemie bajzel, w efekcie którego rzeczy przestają działać lub działają w osobliwy sposób.
  • Mam tylko jedno środowisko, żeby spróbować kod z inną wersją PHP albo innym serwerem www muszę uciekać się do karkołomnych/upierdliwych konfiguracji.


Przypuszczam, że większość programistów ma podobny asortyment aplikacji na swoich komputerach, a zatem i podobne problemy. Żeby je rozwiązać postanowiłem wykorzystać dobrodziejstwa wirtualizacji, z którą romansowałem już od dłuższego czasu. Obecnie na systemie „na co dzień” z narzędzi developerskich mam tylko edytory (NetBeans, Geany) i narzędzia do kontroli wersji oraz oczywiście same pliki projektów. Całą resztę wydelegowałem na maszyny wirtualne. Do wirtualizacji wykorzystuję VirtualBoksa ze względu na bezbolesną instalacją i konfigurację, ale ten sam efekt można osiągnąć korzystając z innych rozwiązań. Na maszynach wirtualnych mam podmontowane katalogi projektów przez system plików vboxsf, dzięki czemu odpada konieczność kopiowania plików z głównego systemu do wirtualnego. Wspomniane powyżej wady znikają ponieważ:

  • Na maszynie wirtualnej mogę mieć identyczne środowisko jak na serwerze produkcyjnym, dokładnie te same wersje programów, a nawet takie detale jak identyfikatory systemowe użytkowników.
  • Maszynę wirtualną odpalam tylko gdy jest mi potrzebna, nieaktywna zajmuje tylko trochę miejsca na dysku.
  • Mogę mieć kilka niezależnych maszyn wirtualnych do różnych projektów lub zastosowań, np. osobną maszynę do projektów w Symfony 2, a osobną do Django. Grzebanie w konfiguracji na jednej nie wpływa na inne. Ponadto dzięki mechanizmowi migawek systemu mogę łatwo cofnąć nieudane zmiany.

Co więcej maszyny wirtualne dają nowe możliwości, niemożliwe (lub trudne/upierdliwe) do uzyskania na pojedynczym systemie. Można chociażby przygotować sobie środowisko testowe dla złożonej aplikacji, która ma kilka serwerów www łączących się z kilkoma zreplikowanymi serwerami bazodanowymi i kilkoma serwerami memcache.

Podobne rozwiązanie zastosowałem na służbowym komputerze, jednak w tym wypadku była to w większej części konieczność. Otóż wedle korpo-zasad każdemu, od handlowca po programistę, ma wystarczyć ta sama konfiguracja Windows 7 (32 bitowa, 2,92 GB dostępnej pamięci, miodzio). Na początku próbowałem przygotować sobie środowisko developerskie w oparciu o WAMP-a. Niestety nasz projekt wymaga do działania nieco bardziej rozbudowanego środowiska niż Apache + MySQL + PHP, np. za wyszukiwanie odpowiada Solr. Szukanie skompilowanych modułów PHP, rozwiązywanie problemów z niekompatybilnymi wersjami, użeranie się z konsolą w Windows i tym podobne przygody wyczerpały moją cierpliwość (a może umiejętności administracji Windows). Dlatego sięgnąłem po rozwiązanie z maszyną wirtualną. Jedyna istotna różnica polega na tym, że pliki projektu znajdują się na maszynie wirtualnej, a jego katalog jest udostępniany przez Sambę. W Windowsie ten udział mam zmapowany jako dysk sieciowy i z niego NetBeans czyta sobie dane. Jeśli mnie pamięć nie myli takie rozwiązanie wybrałem z dwóch powodów:

  • Pliki udostępniane wirtualnemu Linuksowi z Windowsa przez udział vboxsf chyba nie akceptowały uprawnień. Tzn. przez odpowiednią maskę w fstab mogłem sobie ustawić uprawnienia dla wszystkich plików i katalogów, ale zmiana uprawnień dla pojedynczych plików i katalogów z poziomu Linuksa nie działała.
  • Chyba były problemy ze ścieżkami, wydaje mi się, że ścieżki z Windowsa jakoś przenikały do systemu plików Linuksa. Ale może coś mi się pomyliło.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *