Discuții Pro/Contra Vagrant

Continuarea discuției de aici

Why vagrant? de ce nu direct “on the metal” via homebrew - instalezi php, mysql, nginx etc. iar pentru a separa diferite proiecte fiecare cu propriile dependente poti folosi ceva gen phpenv

Vagrant, docker au sens local pt. a testa intr-un environment similar cu productia insa daca pt. fiecare proiect ai macar doua envs (staging, production) vagrant devine complet inutil pe localhost (also is slow as heck).

Vagrant + provizionare (indiferent ca alegeti ansible, chef, puppet) e foarte util pentru lucrul in echipa. Asigura un environment identic pe mai multe masini, in timp ce instalarea locala poate insemna faptul ca fiecare developer isi seteaza propriul mediu de dezvoltare putin diferit fata de al colegilor.

1 Like

Daca fiecare face deploy pe staging este complet irelevant:

bonus point actually.

Nu-ți imaginezi de câte ori am avut probleme (ori eu ori restul din echipele cu care am lucrat) cu „la mine pe local merge, probabil e o problemă în stage”…

1 Like

Nici eu nu eram fan, dar eu evit sa fac update la OS ca sa nu reinstalez environementul. Am fost ultimul om cu w2000, vista si acuma w7. Cu vagrant cel putin teoretic in 20 de minute il am setat identic pe masina noua.

2 Likes

Guys era vorba de OS X si clar depinde si de XP-ul programatorului desi IMHO anyone working with web apps, in special back-end ar trebui sa poata configura un server si implicit un env. custom in OS X sau his Linux distro of choice.

tl;dr:

  • don’t be cheap get a staging VM
  • develop fast on your machine and deploy continuously to staging

Vagrant e o idee foarte faină în teorie. Dar în practică lasă foarte mult de dorit din cauza tehnologiilor care le folosește:

  • Shared folders: încet. Dacă te-ai obișnuit cu SSD-uri și avioane nu o să te mulțumească niciodată. Poți sa iți iei ce SSD vrei tu (eu am pe PCIe și nu face nici o diferență), sistemul ala de fișiere virtual e varză. Poți sa iți iei adio de la symlinks, hardlinks sau permisii normale.

  • Probleme de management: am pățit eu și colegii mei de nenumarate ori ca vagrant sa uite de VM-ul din VirtualBox și să creeze alta instanță aiurea. Dacă nu ești pregătit să recreezi VM-ul des (sau nu ai nevoie de așa ceva) atunci Vagrant nu e pentru tine.

  • Folosește VirtualBox - cel mai slab hypervizor (dpdv al performanței și host-integration fiindcă e Type2). Am scris o soluție la problema cu shutdown-ul.

1 Like

@ionelmc, shared folders este lent în anumite situații care am impresia că depind de mărimea aplicației rulate (e.g. WordPress în vagrant merge fără probleme, Discourse în vagrant este inutilizabil). Apoi, shared folders nu reprezintă singura opțiune. Mai există NFS (pe non-windows) și rsync (care a redus timpul de încărcare la discourse de la un minut la vreo 15 secunde).

Folosesc Vagrant de vreo doi ani și am avut două probleme:

  • nu mai pornea vm după ce am făcut git pull la ultimul provision. Problema era că fișierele aveau line-ending CRLF și nu le citea linux bine: Dashbrew - Vagrant Box
  • după ce am instalat un plugin ce promitea că face update la virtual box tools și nu se mai pupau versiunile din Vagrantfile cu cele reale.
  • Virtualbox NU este singura opțiune. Știe și de Hyper-V și de Vmware (dar varianta asta costă, atât pentru vmware cât și pentru pluginul vagrant).

Nu exclud să fie probleme (mai ales că @denisrendler a deschis un topic cu o problemă vagrant), dar până în acest moment eu nu am avut vreuna.

Am renuntat la Vagrant la inceputul anului in favoarea unui server de dev. Old school stuff. Am incercat si docker pe OS X dar nu e chiar acelasi lucru ca pe Linux. Performance wise.
Cu vagrant ajunsesem sa nu mai pot lucra din cauza marimii proiectului si a multiplelor servicii care trebuiau pornite(ElasticSearch, ActiveMQ+10 consumeri).

Ultima chestie pe care am patit-o e ca proiectul nu mai incapea in box. A trebuit sa reconfigurez tot atunci si am pierdut 2 zile. Am zis “pana aici” Vagrant.

P.S. Stiu 2 companii mari de produs din Romania care au renuntat la masini virtuale in favoarea serverelor de dev. Stiu ei ceva si nu vor sa ne spuna :smiley:

1 Like

Nu spun că Vagrant (sau Docker) ar fi soluția tuturor problemelor existente, ci doar că pentru mine este cea mai potrivită soluție :smile:

Cu serverul de dev eu nu ințeleg o chestie: se elimină complet un env local, pe mașina programatorului? Sau este doar încă un pas în lanțul local → dev → stage → producție?

1 Like

Se elimina complet env local. Apoi fiecare lucreaza cum doreste el pe mediul lui. Unii lucreaza cu vim direct pe server, altii cu PHPStorm pe local in sync cu serverul, etc. Ideea e ca serverul dev sa fie clona a productiei(+afisare erori) sa nu ai probleme gen “la mine merge”. Apoi mai folosim un alt server comun de DB+ES+Active MQ/Rabbit MQ/beanstalkd.

Nici eu nu zic ca serverul de dev iti rezolva toate problemele :smiley:
Pentru proiecte pe care le incepi acum(greenfield, cum le place hr-izdelor sa zica )mici pana la medii chiar, vagrant e ok. Docker ar fi si mai ok daca ar merge si pe OS X la fel ca pe Linux.
Dar cand proiectul ajunge mai mare, este in productie de ceva timp si foloseste ceva servicii externe, vagrant ramane in urma pentru ca nu e gandit pentru asta.
Dar ma rog, cam asta e experienta mea. Nici nu am “mad devops skills” sa imi fac env cu lxc sau mai stiu eu ce minuni au aparut acum iar combinatia de mai sus am vazut ca functioneaza la case mai mari.

P.S. Apropo de performanta,a incercat cineva Vagrant cu Magento? Iti creste barba de hipster pana termini un modul.

1 Like

sa sar intr-o tangenta: a facut cineva profiling pe Magento OSS? Why the hell is it so slow?

Am incercat eu acum ceva timp si nu au fost probleme, folosisem Vagrantfile-ul asta: https://github.com/r-baker/simple-magento-vagrant

de asta cu symlink-urile m-am lovit si eu, si nu-l folosesc de foarte mult timp.