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.