Développer sur une VM, est-ce bien sérieux ?

a marqué ce sujet comme résolu.

Bonjour ! :)

Pour faire du développement avec Ruby et Ruby on Rails, il existe des solutions pour Windows (comme RubyInstaller). Cependant, d’après ce que j’ai pu comprendre, on arrive très rapidement à tout un tas de problèmes, de trucs qui marchent pas, etc.

Il est alors possible de se tourner vers une machine virtuelle (par exemple, VirtualBox) où on y installe un Linux ce qui permet alors de développer avec ces technos sans problème.

Mais voilà, je me demandais si développer sur une VM Linux est fiable, si c’est une bonne idée ou non.

Avez-vous un retour d’expérience dessus ?

+0 -0

(pour les perfs) une solution qui est envisageable :) plutot que d’avoir une VM avec interface graphique, faire une VM sans interface graphique

et sur ton OS principal il existe une extension (fin 2) sur Vscode "Remote-SSH" et "Remote - SSH: Editing Configuration Files" qui permet de développer sur une machine distante

je l’utilise par exemple pour Dev sur une machine qui accèdes a des ressources auquel je n’ai pas accès , ça marche bien (y compris la compilation, l’exécution) les 2 seuls défaut c’est qu’il y a une action supplémentaire quand tu démarres VsCode et c’est pas compatible avec VsCodium (version non microsoft)

Salut,

Quid de WSL sinon ? De ce que je comprends, il devrait y avoir de meilleurs perfs qu’une VM puisque la couche entre le noyau et le matériel est beaucoup plus fine.

+3 -0

Là où je bosse, j’ai des collègues qui sont amenés à bosser sur des VM, ne serais que pour tester le code sur l’architecture cible. Donc oui ça ce fait, mais niveau perf, ils peut y avoir un faussé.

Tu peux également avoir une contrepartie, c’est d’utiliser des conteneurs (Docker entre autre)

J’ai eu fait professionnellement, pour de l’embarqué et pour des environnements particuliers de clients, ça fonctionne très bien pour développer. La configuration peut parfois être un peu chiante mais une fois faite ça roule.
Je pense que tu n’as pas à t’inquiéter, surtout avec des techno populaires.

EDIT:

(pour les perfs) une solution qui est envisageable :) plutot que d’avoir une VM avec interface graphique, faire une VM sans interface graphique

et sur ton OS principal il existe une extension (fin 2) sur Vscode "Remote-SSH" et "Remote - SSH: Editing Configuration Files" qui permet de développer sur une machine distante

je l’utilise par exemple pour Dev sur une machine qui accèdes a des ressources auquel je n’ai pas accès , ça marche bien (y compris la compilation, l’exécution) les 2 seuls défaut c’est qu’il y a une action supplémentaire quand tu démarres VsCode et c’est pas compatible avec VsCodium (version non microsoft)

depfryer

à ce moment autant utiliser WSL non ? à moins qu’il y ait des problèmes l’accès aux ports/réseaux ?

+0 -0

En fait, professionnellement, tu peux souvent être amené à travailler sur une VM cliente.

Ça a plusieurs avantages et plusieurs inconvénients.

Pour le développeur l’avantage principal est qu’il est simple de changer de machine, par exemple augmenter la puissance de la machine. L’inconvénient principal c’est que jamais tu n’es administrateur de ta VM.

En fait, j’ai déjà travaillé dans une VM dans une VM… Pendant 6mois, sous Windows Java et c’était stable.

Alors une simple VM Linux, sur une machine puissante, je ne vois aucun problème. À la limite si tu veux faire de la programmation système ça risque de poser 2/3 trucs à gérer mais c’est tout.

+0 -0

Hello hello!

Sous Windows tu as maintenant WSL2, et c’est clairement le meilleur moyen (et le recommandé par Microsoft) de développer sous Windows.

Cela étant dit le principal problème des VMs (et de WSL1) ne sont pas vraiment le CPU. C’est en réalité les ios, c’est-à-dire la capacité de lecture de fichiers. Et ce problème est principalement existant sur les système Windows/MacOS qui virtualisent du Linux. (Linux-Linux il y a des solutions très opti, mais pour des raisons évidentes, personne ne fait ça pour développer ^^)

Ces problèmes sont importants donc si tu as des projets qui font beaucoup d’accès disque. C’est le cas de la plupart des (gros) projets PHP par exemple.

Si tu compiles du C++ tu sentiras moins la différence je présume.

Pour terminer je dirais que le mieux c’est docker (qui, je crois, a une option WSL2 depuis peu !).

Note: WSL2 nécessite la mise à jour 2004 de Windows :) .

Même les I/O ne sont pas forcément un problème. En 2015 le développement (en particulier la compilation) Android était sensiblement plus rapide sur une VM Linux que directement sur la machine hôte.

SpaceFox

Si, sur une VM t’es au moins 10x plus lent, c’est d’ailleurs le problème contre lequel luttent hardument les utilisateurs de docker for mac. J’ai constaté sur tous mes projets. Depuis j’utilise docker for mac mais je fais tourner mes serveurs PHP avec symfony cli sinon c’est l’enfer en terme de perfs. (comprendre 10x plus lent)

Merci à tous pour vos réponses. Désolé, je n’ai pas pris le temps de vous répondre avant.

Donc si je comprend bien, on peut développer sur une VM de manière professionnelle. Ok, c’est noté. J’avais jusqu’à présent utilisé les VM pour tester des distributions Linux et je ne pensais pas que ça pouvait aussi être utilisé pour du dev.

Sinon WLS, je l’avais essayé il y à quelques temps, mais j’ai eu quelques problèmes. Surement du au fait que je ne savais pas trop l’utiliser.

Avant de vous répondre, j’ai trouvé quelque chose que j’ai eu le temps d’essayer : Vagrant.

Alors j’ai pas encore trop bien compris ce que c’est exactement… il faudra que je me renseigne un peu plus dessus (là, j’ai fait des tests vites fait).

En revanche, j’ai réussi à créer une machine Linux avec et installé Ruby et Ruby on Rails, j’ai exporté la "Box" (le nom des machines apparemment) pour pouvoir la réinstaller quand je veut, et donc créer autant de VM avec déjà tout d’installé, et enfin j’ai pu (très facilement) faire en sorte de lier un dossier Windows à un dossier dans ma VM.

Au final, en connexion SSH entre Windows et le Linux ainsi que l’utilisation de Cmder (un onglet "Linux" et un onglet "Windows"), j’ai vraiment l’impression de développer sur Windows mais avec les avantages de Linux. :D

Bon, par contre, j’ai pas saisi si je peux supprimer mon fichier Vagrantfile, ni à quoi il sert, ni si je peux le déplacer. J’ai pas compris non plus ce qu’est ce .vagrant créé juste à côté de ce fichier, ni même si je peux déplacer mon dossier "data", celui qui est relié à mon /home/vagrant/data de ma VM.

Mais sinon, ça à l’air super chouette, car je n’ai pas à m’embêter à switcher "graphiquement" entre Windows et Linux.

Pour ce qui est de Docker, j’avais jeter un coup d’oeil, mais j’ai arrêté dès la première commande. J’avais rien compris, mais il faut dire aussi que j’était pas trop intéressé pour comprendre. ^^

+0 -0

@SpaceFox: En cross compilation tu veux dire ?

ache

Heu, Android c’est toujours de la cross compilation. Tu compiles sur PC pour Android.

Si, sur une VM t’es au moins 10x plus lent, c’est d’ailleurs le problème contre lequel luttent hardument les utilisateurs de docker for mac. J’ai constaté sur tous mes projets. Depuis j’utilise docker for mac mais je fais tourner mes serveurs PHP avec symfony cli sinon c’est l’enfer en terme de perfs. (comprendre 10x plus lent)

Nek

Alors tu as un énorme problème de virtualisation. 10x plus lent sur les I/O, c’est pas normal du tout. Surtout sur des systèmes de prod ou tu as des outils très perfectionnés de virtualisation des I/O qui te rendent la perte de performance très limitée.

Mais je ne parle même pas de ça ici. Ce dont je parle, c’est que les I/O disque de Windows sur les petits fichiers sont tellement lents que Linux virtualité, sur un disque Windows (donc des accès réels de 64 k — de mémoire — schedulés par la VM) sont plus performants que les accès direct à des petits fichiers sous Windows. J’ai fait assez de tests et assez de développements sur ces machines pour te le garantir et te garantir la cause (on gagnait aussi 10% sur les tâches CPU-limite juste avec la meilleure JVM).

PS : avec les bons cache disque (cache disque du disque dur virtuel activé), un disque dur virtuel peut être même plus rapide que son équivalent physique. Le développement est même l’un des très rares cas où activer ce cache est intéressant.

PPS : je parle de vraies VM. Docker, c’est encore autre chose, notamment dans la gestion des disques. Notamment la gestion des couches qui ralentit à mort les I/O (comme quand on a une VM avec des tonnes de snapshot).

Heu, Android c’est toujours de la cross compilation. Tu compiles sur PC pour Android.

Du coup, si on parle d’application au sens Android, je comprend pas. Je pensais qu’on parlait d’exécutables.

Avec le reste de ton message je comprend mieux. Sous Windows, utiliser un VM Linux pour compiler l’application est selon toi plus rapide que compiler une application depuis Windows. Ok.

+0 -0

Salut.

[…] il existe des solutions pour Windows (comme RubyInstaller). Cependant, d’après ce que j’ai pu comprendre, on arrive très rapidement à tout un tas de problèmes, de trucs qui marchent pas, etc.

FougereBle

Si c’est ça la raison, pour moi ça tient pas tellement la route… Et puis tu te bases sur un ressenti (« d’après ce que j’ai pu comprendre »).

Est-ce que tu as essayé de te débrouiller seul à installer un environnement de développement sous Windows ? Est-ce que tu as perdu des heures à le faire ? Pour moi, la question, elle se pose plutôt là.

Pour ce qui est de la VM, tu as des témoignages positifs, mais attention aux problèmes de performance certes. Je ne connais pas Ruby et encore moins RoR, mais j’ai déjà essayé de développer en VM Linux sur un projet qui utilisait du Javascript, et j’ai été davantage frustré que soulagé (c’était il y a 3 ans, cela dit, les choses ont peut-être changé depuis).

Sinon ce que j’aime bien avec les VM c’est que tu peux faire un snapshot d’un environnement de développement qui te convient, et le transporter un peu ou tu veux.

Pour moi c’est donc « bien sérieux ». Mais si le souci c’est l’intégration de l’écosystème Ruby / RoR dans Windows, alors pour moi le problème vient de RoR et de sa difficulté de prise en main. Je tenais à souligner ce détail.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte