Vagrant dla projektu Java: czy należy kompilować na maszynie wirtualnej czy na hoście?

Oto pytanie: jeśli używasz Vagrant do projektu Java (lub dowolnego projektu w języku skompilowanym w tym zakresie), czy powinieneś kompilować na maszynie wirtualnej, czy na hoście? Czy chciałbyś, aby Twoje IDE i wszystkie narzędzia programistyczne były uruchamiane również z maszyny wirtualnej, czy na hoście?

Wydaje się, że nie jest dokładnie zdefiniowane , jak środowisko Java IDE i proces kompilacji / wdrażania działają z maszyną wirtualną Vagrant. Ogólnie mam wrażenie, że kod jest edytowany na hoście i uruchamiany na maszynie wirtualnej, co świetnie sprawdza się w językach nieskompilowanych. Inne odpowiedzi w Stackoverflow sugerują, że Vagrant jest mniej przydatny w przypadku języków kompilowanych z powodu dodatkowego kroku kompilacji, ale nadal chcę zobaczyć, co można zrobić.

Kilka rzeczy, które już przemyślałem:

Po co kompilować na maszynie wirtualnej

• jeśli kompilujesz na hoście, java to jeszcze jedno oprogramowanie do zainstalowania
• jeśli kompilujesz na hoście, wersja java na hoście musi być ręcznie aktualizowana z wersją na maszynie wirtualnej
• odpowiednia wersja java na hoście może być niedostępna (powiedzmy na komputerze Mac)

Po co mieć IDE na maszynie wirtualnej

• ściślejsza integracja między środowiskiem a IDE, można używać skrótów do uruchamiania aplikacji
• można podłączyć debugger do aplikacji java bez zdalnego debugowania (jednoetapowe uruchamianie / debugowanie)

Po co kompilować na hoście

• szybsze czasy kompilacji
• chcą, aby maszyna wirtualna była jak najbliżej tego, jak wygląda produkcja

Po co IDE na hoście

• konwencja włóczęgów polega na edytowaniu kodu na hoście i uruchamianiu go na maszynie wirtualnej
• lepsza wydajność interfejsu użytkownika (przekazywanie X i VNC są wolne)

Co myślisz: czy powinienem uruchomić moje IDE z maszyny wirtualnej czy z hosta? Czy powinienem kompilować z poziomu maszyny wirtualnej czy hosta?

Po wielu przemyśleniach i eksperymentach zdecydowałem, gdzie użyć Vagranta i jak integruje się z przepływem pracy programowania w Javie.

W przypadku aplikacji JavaEE / wdrożonych, konfiguracja serwera WWW i serwera bazy danych jest zdecydowanie „wystarczającą” złożonością, aby zagwarantować użycie Vagrant. Dzięki dwóm serwerom i niezliczonym sposobom ich konfigurowania, konfiguracja jest łatwa do utraty synchronizacji między programistami, co powoduje syndrom „pracy na moim komputerze”. W przypadku tego rodzaju oprogramowania najlepiej byłoby edytować i kompilować kod na hoście oraz wdrażać go na maszynie wirtualnej Vagrant, która naśladuje środowisko produkcyjne. Folder wdrożeniowy dla serwera WWW mógłby być nawet połączony symbolicznie z miejscem docelowym kompilacji na hoście, eliminując potrzebę ręcznego ponownego wdrażania. Więc Vagrant może być ważną częścią Twojego cyklu rozwoju,

W przypadku samodzielnych aplikacji Java (takich jak biblioteki lub aplikacje komputerowe) sytuacja nieco się zmienia. W tym przypadku najbardziej sensowne jest edytowanie, kompilowanie i uruchamianie na maszynie hosta, całkowicie rezygnując z używania Vagrant. Jeśli używasz jednego z dużych środowisk Java IDE (Eclipse, Netbeans, IntelliJ ...), masz już zainstalowaną Javę na komputerze. W tym momencie jest bardzo mała korzyść w porównaniu z narzutem związanym z używaniem Vagrant i służy tylko do umieszczenia dodatkowej warstwy złożoności w procesie rozwoju. Dzieje się tak, ponieważ zanim będziesz mógł edytować Javę za pomocą IDE, i tak będziesz w stanie uruchomić wszystko na hoście. Jednym z problemów jest to, że wersja Java wymagana dla projektu może nie odpowiadać wersji, w której działa IDE na hoście. Ogólnie (miejmy nadzieję) nie jest to zbyt duży problem; w chwili pisania tego tekstu JDK6 jest przestarzały, a JDK8 nie został jeszcze wydany (zgadnij, gdzie to nas opuści). Ale jeśli musisz uruchomić wiele wersji, powinieneś być w stanie ustawić JAVA_HOME na hoście w razie potrzeby. Chociaż powoduje to dodatkową złożoność, jest to mniej złożone niż utrzymywanie środowiska wykonawczego Vagrant tylko po to, aby pracować z projektami korzystającymi z różnych wersji języka Java.

Ciekawe pytanie brzmi: co zrobić z aplikacjami internetowymi bez kontenerów. Czy serwer WWW (w tym przypadku wewnętrzny dla aplikacji) powinien być uruchamiany wewnątrz maszyny wirtualnej, tak jak zrobiliśmy to dla zewnętrznego serwera WWW? Lub uruchomić na hoście, tak jak w przypadku samodzielnej aplikacji? W przypadku aplikacji internetowych bez kontenerów nie trzeba się martwić o zewnętrzny serwer sieciowy, ale prawdopodobnie nadal istnieje baza danych. W tej sytuacji możemy przyjąć podejście hybrydowe. Uruchamianie aplikacji internetowej bez kontenera jest zasadniczo tym samym, co uruchamianie samodzielnej aplikacji, więc skompilowanie i uruchomienie kodu na maszynie hosta byłoby efektywne. Jednak w przypadku zaangażowanej bazy danych nadal jest na tyle złożoność i konfiguracja, że ​​warto mieć serwer bazy danych na własnej maszynie wirtualnej Vagrant.

Mamy nadzieję, że daje to programistom Java, którzy są zainteresowani Vagrantem, kontekst o tym, jak go używać.

Interesował mnie ten temat przez ostatni rok :)

Moim rozwiązaniem jest posiadanie włóczęgi konfigurowalnej z flagami. Na przykład jedna z tych flag włącza interfejs GUI na pulpicie, ponieważ niektórzy programiści wolą kodować na maszynie hosta, podczas gdy inni wolą mieć znacznie bardziej zintegrowane środowisko z pulpitem i znajdującym się w nim IDE.

Aby stawić czoła powolności pulpitu, powinieneś zainstalować bardzo przydatną wtyczkę vagrant (tak ... vagrant ma wtyczki, które znacznie poprawiają środowisko programistyczne) w następujący sposób: vagrant plugin install vagrant-vbguest Ta wtyczka zainstaluje dodatek gościa wirtualnego boxu na każdym gościu uczynić go użytecznym podczas korzystania z interfejsu virtualbox. Następnie, aby włączyć GUI, edytuj plik Vagrantfile w następujący sposób:

config.vm.provider "virtualbox" do | vb | vb.gui = prawdziwy koniec

Zamiast przyspieszyć działanie folderu współdzielonego, sugeruję użycie rsync: config.vm.synced_folder "./git", "/ home / vagrant / git", wpisz: "rsync", rsync__exclude: ".git /" W tym sposób, w jaki kod źródłowy jest edytowany na hoście, a następnie zsynchronizowany z gościem.