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

92

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?

java vagrant Sójka
źródło

Odpowiedzi:

61

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ć.

Sójka
źródło
w przypadku hosta systemu operacyjnego Windows i maszyny wirtualnej z systemem operacyjnym Linux, co myślisz o uruchamianiu IntelliJ na maszynie wirtualnej z systemem Linux, działającej na hoście (Windows) przez X11?
Kevin Meredith
3
Świetne pytanie: nie wspomniałem o tym, ale przeprowadziłem wiele testów z uruchomieniem IDE wewnątrz Vagrant VM i stwierdziłem, że wydajność była okropna ... ponieważ kliknięcie menu zajęło około 12 sekund, aby odpowiedzieć. Próbowałem takich rzeczy, jak: określ szybszy szyfr, użyj kompresji dla X11 i zwiększ pamięć RAM wideo VM, tylko po to, aby uzyskać czas odpowiedzi do 4 sekund, który nadal był bezużyteczny. Więc myślę, że Vagrant nie jest przeznaczony do prowadzenia IDE.
Jay
Myślę, że powinieneś spróbować - nie włączyłem akceleracji VirtualBox 2D, ponieważ jest to dla hostów Windows (i nie miałem hosta Windows). Inne pomysły dotyczące wydajności, których nie udało mi się wypróbować, obejmują: podobno dostawca VMWare ma specjalne optymalizacje grafiki, mógłby wypróbować VRDP, który może mieć lepszą wydajność niż X11, serwer NX ma być szybszy niż X11, i wreszcie jest spice- space.org. Jeśli znajdziesz coś, co działa dobrze, napisz tutaj, ponieważ chciałbym o tym usłyszeć!
Jay
2
Nie testowałem IntelliJ wewnątrz maszyny wirtualnej gościa (i może nie dać współpracownikowi doświadczenia z jego powolnością w gościu). Jednak przeczytałem co następuje w „Vagrant - działa i działa”: Shared folders incur a heavy performance penalty within the virtual machine when there is heavy I/ O, so they should only be used for source files. Any compilation step, database files, and so on should be done outside the shared folder filesystem inside the guest filesystem itself.Oświadczenie tej książki (napisane przez twórcę Vagranta) wydaje się przemawiać przeciwko kompilacji na hoście VM, prawda?
Kevin Meredith
4
Cytat wspomina o „dużym spadku wydajności w maszynie wirtualnej” i nie wspomina o globalnym spadku wydajności dla hosta, więc myślę, że kontekst tutaj dotyczy wydajności / operacji wewnątrz maszyny wirtualnej . W tym kontekście interpretuję ten cytat jako przewidywanie wydajności, gdy krok kompilacji jest wykonywany wewnątrz gościa, w przeciwieństwie do zalecania kompilacji na gościu lub na hoście. Czy możesz powiedzieć więcej o kontekście tego cytatu? Czy książka odnosi się konkretnie do tego scenariusza? Oczywiście wszystko to podlega faktycznym testom :)
Jay
3

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.

Saverio Ferrara
źródło