ugrás a tartalomhoz

Asztali gépen virtual host-ok, de minek?

PetyaKmet · 2014. Nov. 6. (Cs), 10.48
Sziasztok!

Most próbálok áttérni win7-ről ubuntura, s ott kialakítani egy (drupalos) webfejlesztői környezetet.
Telepítettem az APACHE-PHP-MySQL 3-astaz asztali gépemre, beállítottam a /var/www/html/ mappa jogosultságait, a rövid URL-ket, a php.init, a Sublime szereksztőt, a drusht. Minden működik is.
Az oldalak elérhetők a localhost/mappanév alatt.

A kérdésem, hogy ezeket a virtual host-okat (vagy miket) be kell, be érdemes állítanom?
Ez mire jó amúgy?
‹ windows 8 alarm clock Python GUI? ›
 ■
1

A virtual host címe az

Hidvégi Gábor · 2014. Nov. 6. (Cs), 11.59
A virtual host címe az esetedben a localhost, azaz jelenleg csak egy van a rendszeredben.

A virtuális hostokat az etc/hosts nevű fájlban tudod felvenni (és az apache extra/httpd-vhosts.conf fájlban konfigurálni), és akkor a böngészőben úgy tudsz rájuk hivatkozni, mint például http://sajat_host/.
2

Köszönöm a választ, de jól

PetyaKmet · 2014. Nov. 6. (Cs), 12.15
Köszönöm a választ, de jól értem?

Tehát azért jó, mert akkor az asztali gépemen ha beütöm azt, hogy xyzkft.hu akkor valójában a helyi oldalt hozza be amit fejlesztek a saját gépemen.
S ez meg azért jó, hogy például a link hivatkozások, helyesek legyenek, mint késöbb az éles szerveren?

S ha az interneten levő xyzkft.hu éles oldalát szeretném megtekinteni?
3

Azt nem tudom, hogy virtual

Hidvégi Gábor · 2014. Nov. 6. (Cs), 12.31
Azt nem tudom, hogy virtual host nevébe lehet-e pontot tenni. Jómagam arra szoktam használni, hogy készítek egy lokális http://xyzkft/ címet a fejlesztéshez és teszteléshez.

Közben utánanéztem, lehet pont a virtualhost nevében, a hosts fájlomban van jópár hasonló sor:
127.0.0.1 cdn.atdmt.com
Ezzel például a skype hirdetéseit tudom kiszűrni.

Windowson a hosts fájl elérhetősége:
C:\WINDOWS\system32\drivers\etc\hosts
4

Az apache-nak van egy alap

szabo.b.gabor · 2014. Nov. 6. (Cs), 12.35
Az apache-nak van egy alap docroot-ja (/var/www) ide pakolászni a projektjeidet nem ideális, mert a mappájuk benne lesz az elérési útban, elérik egymás dolgait a projektek, más lesz a teszt környezeted, mint az éles.

Vhost-ot csinálhatsz bármilyen mappára, ekkor az éles rendszerhez jobban hasonló dolgot tudsz felépíteni.

Az /etc/hosts-ba írhatsz olyat is, hogy xykft.dev, az is menni fog.

Egy fokkal még bonyolultabb, de adott esetben kezelhetőbb (pl gép újratelepítés, gazda gép frissítés), ha a van egy virtuális teszt szervered a gépen.
5

elérik egymás dolgait a

Hidvégi Gábor · 2014. Nov. 6. (Cs), 12.54
elérik egymás dolgait a projektek
Te olyan kódot írsz, ami körbeszimatol? : )

más lesz a teszt környezeted, mint az éles
Ez igaz, amiatt használtam még virtualhostokat, mert így a rewrite szabályok kicsit egyszerűbbek voltak.
7

máshogy megközelítve

szabo.b.gabor · 2014. Nov. 6. (Cs), 13.43
Mi van ha az adott projekted gyökérkönyvtára nem a projekt docRootja (ott elvileg csak css, js, meg index.php van ideális esetben) és mondjuk tesztelni akarod, hogy a védett fájljaid tényleg csak bejelentkezett felhasználók látják..
6

Kezdő vagyok linuxban, de

PetyaKmet · 2014. Nov. 6. (Cs), 13.27
Kezdő vagyok linuxban, de gondolom, hogy ez lényegtelen, hogy az Ubuntu 14.04 -en már /var/www/html/-t látok.
--
Tehát, azért javallot, hogy az éles rendszerhez hasonló környezett kapjon az oldal.
Ehhez kis segítséget kérnék: honnan tudom, hogy az éles rendszeren mik azok a beállítások, amit itt nálam is a virtual hostoknál el kell végeznem?
Valamilyen fájl, vagy mappa után kell kutakodnom?
8

A 14.04-ben talán apache2.4

szabo.b.gabor · 2014. Nov. 6. (Cs), 13.59
A 14.04-ben talán apache2.4 meg php5.5 van, nem tudom pontosan.

Szerveren lehet, hogy apache2.2 és php5.3 lesz (de ez mindegy is). Lehetnek különbségek. amúgy egy phpinfo() azért megmondja mivel állsz szemben.

Ilyen szintű dolgokat (mármint verzió különbséget) virtualhostból beállítani nem igazán lehet (biztos van aki tud, de nem kézenfekvő).

Feltelepíted a virtualbox-ot, és felraksz rá egy 12.04 szervert pl (vagy bármit). beállítgatod szépen. Egyrészt tök egyszerűen tudsz mentéseket csinálni a gép állapotáról telepítések közben, másrészt nem gányolod teli a gépedet, meg olyan oprendszert használsz amit akarsz, veszel egy Mac-et, átrakod a virtuális géped és mehet tovább a meló. A virtuális gépedről meg nfs-en vagy akárhogy megosztod a projekt mappákat, és azokat már a gazdagép szerkesztőjével nyomathatod.

Gyakorlod a szerver konfigot, be tudsz lépni ssh-val a saját gépeden futó szerverre, mekkora májerség már :D.

A saját gépeden feltelepített fejlesztőkörnyezethez képest annyi a plusz melód, hogy meg kell oldanod a mappák megosztását, valamint a virtuális gépeden a net elérést (én ezt úgy csináltam, hogy van egy host-only kártya, ezen hallgat az apache, és van egy másik ami NAT-olva van, ezen keresztül éri el a szerver a netet). gép újra telepítésnél viszont nem kell semmit sem csinálnod, csak importálni a virtuális gépet..
9

Adalék

Hidvégi Gábor · 2014. Nov. 6. (Cs), 14.19
Nagyon jó, amit írsz, talán még azzal lehetne megfejelni, hogy a virtuális gépen belül a weboldalak külön virtuális meghajtóra kerüljenek, így könnyebb másolni őket.
10

vhost

szabo.b.gabor · 2014. Nov. 6. (Cs), 15.17
Szerintem itt már egy virtualhost létrehozása elég.
11

Először is köszönöm a hosszú

PetyaKmet · 2014. Nov. 6. (Cs), 15.18
Először is köszönöm a hosszú választ. :) Próbálom fordítani a kezdők nyelvére:

Tehát Te azt javaslod, hogy
- hozzak létre egy virtuális gépet a virtualbox segítségével
- beállítgatok azon mindent szépen, hogy menjen rajta minden ami a webfejlesztői környezethez kell, fussanak a projekt weboldalak szépen. Mintha az lenne az éles (interneten levő) szerver.
- Azon beállítom a virtuális hostokat is
- ezeket a projekt mappákat a gazda gép számára elérhetővé teszem. Tehát hogy FTP-vel, SSH-val, meg SFTP vel be tudjak jelentkezni rá a gazda gépről

Azon gondolkozom, hogy így a gazdagépről lesz-e a tesztelés, vagy a virtuális gépről?
A böngésző, amelyik majd tesztelni fog melyik gépen fusson (a gazda vagy a virtuálison) , s mi is lesz majd beírva a címsorba?
12

sztem egy ssh hozzáférés

szabo.b.gabor · 2014. Nov. 6. (Cs), 15.23
sztem egy ssh hozzáférés (apache újraindítás, jogok beállítása, konfigurálgatás), meg egy nfs megosztás elég (mountolod a gazda gépen, hogy az ide-vel egyszerűen el tudd érni a fájlokat).

unit tesztek virtuális gépen futnak. böngészős tesztek meg gazda gépről (ugye a virtuális gépen nem is lesz grafikus felület meg böngésző jó eséllyel)

és igen a projekteknek hozz létre virtualhostot a virtuális gépen :D
pl projektem.dev

a gazda gépen az /etc/hosts ba beírod, hogy
192.168.56.3 projektem.dev

(vagy ami a virtuális géped ip-je)

és akkor a böngésződbe a gazdagépen meg azt írod, hogy http://projektem.dev és menni fog elvileg. :D
14

NFS helyett érdemes lehet

bamegakapa · 2014. Nov. 6. (Cs), 15.28
NFS helyett érdemes lehet SSHFS-ben is gondolkodni.
15

Tudtam, hogy van itt olyan is

szabo.b.gabor · 2014. Nov. 6. (Cs), 15.38
Tudtam, hogy van itt olyan is aki tényleg ért hozzá :D.

Én csak nagyjából megfogalmaztam magamnak, hogy mire van szükségem aztán az első megfelelő eszközzel meg is elégedtem :)

Amúgy mik az előnyök?
17

Amúgy mik az előnyök? Az SSH

Joó Ádám · 2014. Nov. 6. (Cs), 16.06
Amúgy mik az előnyök?


Az SSH hozzáférésen kívül semmit nem kell konfigurálni a szerveren (az meg amúgy is van).
18

Ha már itt tartunk, a

Joó Ádám · 2014. Nov. 6. (Cs), 16.10
Ha már itt tartunk, a teljesség kedvéért: érdemes a szerver konfigurációt automatizálni valamilyen konfigurációmenedzsment eszközzel, illetve a mappák megosztása helyett automatizálni a deploymentet is. Az elején sok munka, de többszörösen megtérül.
19

Nem is beszélve a

bamegakapa · 2014. Nov. 6. (Cs), 16.17
Nem is beszélve a verziókezelésről, ami nélkül öngyilkosság nekifogni az egésznek.
23

Apropó öngyilkosság, ugye van

Joó Ádám · 2014. Nov. 6. (Cs), 16.34
Apropó öngyilkosság, ugye van rendszeres offsite backup?
24

És akkor még épphogy csak

bamegakapa · 2014. Nov. 6. (Cs), 16.40
És akkor még épphogy csak belekezdtünk :).
27

„Ha újrakezdhetném, nem

Joó Ádám · 2014. Nov. 6. (Cs), 16.43
„Ha újrakezdhetném, nem kezdeném újra.”
28

Ez túlzás. Kevés emberes

Hidvégi Gábor · 2014. Nov. 6. (Cs), 16.43
Ez túlzás. Kevés emberes projekteknél napi mentés is elég lehet.
31

Én egy egyszemélyes

bamegakapa · 2014. Nov. 6. (Cs), 17.03
Én egy egyszemélyes próba-móka projektnek sem kezdek már neki Git nélkül. Nem csak a mentés miatt. Pedig egy ideig hogy utáltam :).

(feltéve hogy ezt a verziókezelős kommentemre írtad)
34

Mindenki másképp csinálja.

Hidvégi Gábor · 2014. Nov. 6. (Cs), 17.10
Mindenki másképp csinálja.
35

Nagy előny az, hogy gyorsan

bamegakapa · 2014. Nov. 6. (Cs), 17.14
Nagy előny az, hogy gyorsan ki tudsz próbálni valamit, aztán ha mégse jön be, könnyen visszaállni tetszőleges működő állapotba. Ráadásul pontosan látod, mit, miért és mikor csináltál (ehhez nem árt a kommit üzenetekbe egy kis energiát fektetni :)).

Az elején mondjuk van egy kicsit fájdalmas beletanulási időszak.
37

Én is fájdalmasan tanultam

Joó Ádám · 2014. Nov. 6. (Cs), 17.25
Én is fájdalmasan tanultam meg, hogy egyemberes projekteknél is használni kell, pont mert, ahogy írod, hosszan lehet ücsörögni a semmibe meredő szemekkel, amikor rájössz, hogy mégis kéne az a kód, amivel egy teljes napot dolgoztál, aztán úgy tűnt, hogy mégsincs rá szükség…

Ha már két ember dolgozik egy kódbázison, akkor pedig tényleg játék a tűzzel nem használni verziókezelést a koordinációhoz.
38

Addig jár a korsó a kútra,

Hidvégi Gábor · 2014. Nov. 6. (Cs), 17.33
Addig jár a korsó a kútra, míg el nem törik.
40

Az okos ember a saját kárán

Joó Ádám · 2014. Nov. 6. (Cs), 17.36
Az okos ember a saját kárán tanul, a bölcs másokén.
46

Git nélkül én sem vágok bele

szabo.b.gabor · 2014. Nov. 7. (P), 09.28
Git nélkül én sem vágok bele semmibe. Egy jó kis branching model.
20

deployment automatizáció +1

szabo.b.gabor · 2014. Nov. 6. (Cs), 16.23
deployment automatizáció +1 (pl git post-update hook), konfiguráció menedzsment is biztos jó, de sztem fejlesztéshez a mappa megosztás a jó, ne kelljen már minden lépésnél deployt nyomni.
22

Én a deploymenthez Rsync-et

Joó Ádám · 2014. Nov. 6. (Cs), 16.32
Én a deploymenthez rsync-et használok, és bizony, minden változtatáskor meghívom a szkriptet, ami burkolja. Amúgy sincs sok választásom, mert a kódot és statikus fájlokat is le kell fordítani. Ez a popszakma már csak ilyen.
25

így persze jogos..

szabo.b.gabor · 2014. Nov. 6. (Cs), 16.40
így persze jogos..
29

Vagrant

complex857 · 2014. Nov. 6. (Cs), 16.49
Nekem nagyon úgy hangzik mintha Vagrant-ról volna szó. Ezzel pofonegyszerűen csinálhatsz újrafelhasználható kis virtuális gépeket minden projectnek. Magukat a virtuális gépeket készen kapod oprendszer alappal, majd 1-2 config sorral szépen ki lehet forwardolni host gépre 1-1 portot (port forwarding) amin eléred webszerver kimenetét és alapból szerkesztheted virtuális gép filejait host gépről (synced folders).

A konkrét projected installációjára meg van puppet és chef támogatás is (vagy csak simán egy shell script), ezeket amúgy is érdemes megcsinálni, mint te is írtad, mert később megtérül a befektetett munka.

Bár nekem az indító kérdés alapján ágyúval-verébre esetnek tűnik projektenként külön-külön virtuális gépet csinálni, főleg ha a projektjei azonos környezetre (lamp stack-re) épülnek.
39

Amikor nekikezdtem, ránéztem

Joó Ádám · 2014. Nov. 6. (Cs), 17.34
Amikor nekikezdtem, ránéztem a Vagrantra is, de őszintén nem értem, mit ad hozzá az egészhez. A frissen telepített oprendszer képet a port forwarding beállításokkal egyszer kell megcsinálni, a VirtualBoxot és az Ansible-t egy-egy paranccsal lehet indítani. Mire jó a Vagrant?
41

Windows-on hatalmas segítség.

T.G · 2014. Nov. 6. (Cs), 20.54
Windows használóként nekem a Vagrant hatalmas segítség. Windows-os fejlesztőknél szerintem kötelező, ha az éles szerver Linux.
42

Miért vagrant

complex857 · 2014. Nov. 6. (Cs), 22.30
Szerintem a legnagyobb plusz amit hozzáad az a reprodukálhatóság.

Vagrant legnagyobb hasznát én csoportmunkánál láttam ahol oda lehetett adni új kollégának a vagrant filet és akármi is legyen a épp a gépén ~10 percen belül ugyanazon a környezeten tud dolgozni mint a többiek.
Ehhez persze kell, hogy provisioning meg legyen csinálva, szóval első "vagrant up" után kód checkoutolva repóbol, db a helyén, serviceok futnak, lehet pötyögni. Ha valamit elbarmol rajta akkor ki lehet hajítani és újra felhúzni ismert állapotot.

Ha nem csak egy szokásos lamp stacken fut a projected, hanem mondjuk "nginx + php-fpm + mysqld + memcached + openfire + hubot" (mert így néz ki élesben egyik cuccunk) akkor ezeket szakmányban kéne felhúzni gépekre (főleg windowsokra amikhez kevésbé értek) az roppant fájdalmas volna nekem.
43

Nem érted. Én ugyanezt

Joó Ádám · 2014. Nov. 6. (Cs), 23.10
Nem érted. Én ugyanezt csinálom: van egy tiszta képfájlom az operációs rendszerrel, és egy Ansible playbookom (ami lehetne Chef recipe, Puppet manifest, Salt formula, akármi). A képfájlt importálom VirtualBoxba, elindítom a virtuális gépet, checkout a repóból, fordítok, lefuttatom a playbookot, megy a deploy. Kész a környezet.

Azt nem látom, hogy mit ad a Vagrant, azon kívül, hogy most őt hívom meg.
44

Nos lehet valóba nem

complex857 · 2014. Nov. 6. (Cs), 23.45
Nos lehet valóba nem, de ha jól értem a kérdésed akkor, azokon ha elfelejtjük azokat a dolgokat amiket provisioning része csinál, nagyjából egy fancy virtualbox configurator marad alap verzióban.
Ez van annyival megfejelve, hogy lehet több gépet belőni egy confiból, vagy ugyanabból a configból hyper-v, docker vagy vmware (mintha ez már a fizetős verzióban lenne csak) gépeket is tud építeni illetve, erre vagy van szükséged vagy nincs (én magam sose használtam).

Lehet ezen a ponton ingerküszöb kérdése a dolog.
Nekem amikor már harmadszorra kell ugyanazt megcsinálni, mert van egy otthoni gép, egy irodai, meg kollégát is be kell vonni, majd kiderül, hogy megyünk ügyfélhez és legyen rajta a cucc a laptopon... már elszakad a cérna, de tény, hogy nehezen tudnám elválasztani a dolgot provisioning által csinált elemektől.

Napi munkafolyamat részeként valóban tökmindegynek tűnik, hogy virtualbox kis felületén ütök rá a "start" gombra, vagy terminálba pötyögöm be, hogy "vagrant up", de ezek az eszközök elvileg addig izgalmasak amíg eljutsz oda, hogy már csak ennyit kelljen tenned. A vagrantfileokkal sose kell mást tenned (főleg ha valaki más írja őket :P), míg manuál telepítésnél igen. De még ha te magad is írod őket, második alkalommal már csak az up, míg ha kézzel csinálod akkor újra 10 (?) kattintás settings-ben. Hogy megéri-e ezért megtanulni a config file formátumát azt már azt rád bízom (:
45

Alakul, de úgy érzem, még

Joó Ádám · 2014. Nov. 7. (P), 00.15
Alakul, de úgy érzem, még mindig elbeszélünk egymás mellett :)

Az rendben van, hogy egy konfigból lehet többféle virtualizációs eszközt kezelni, biztos van, akinek erre van igénye, de megint felmerül bennem, hogy mit tartalmaz az a konfig?

Nekem amikor már harmadszorra kell ugyanazt megcsinálni, mert van egy otthoni gép, egy irodai, meg kollégát is be kell vonni, majd kiderül, hogy megyünk ügyfélhez és legyen rajta a cucc a laptopon... már elszakad a cérna, de tény, hogy nehezen tudnám elválasztani a dolgot provisioning által csinált elemektől.


Épp ez az, amit nem értek: onnantól, hogy elindult a gép, a provisioningre megvannak a kész eszközök (Puppet, Chef, Salt, Ansible…), amik egy sorból telepítik akár egyszerre az otthonit, az irodait, a kolléga gépét és a laptopot.

Napi munkafolyamat részeként valóban tökmindegynek tűnik, hogy virtualbox kis felületén ütök rá a "start" gombra, vagy terminálba pötyögöm be, hogy "vagrant up"
VBoxManage startvm weblabor --type headless
:P

De még ha te magad is írod őket, második alkalommal már csak az up, míg ha kézzel csinálod akkor újra 10 (?) kattintás settings-ben.


Mármint itt a virtuális gép beállításaira gondolsz? Erre az én módszerem, hogy az elején az oprendszer telepítése után beállítok mindent, és exportálom az egészet. Ha valami változik (új port forwarding szabály például), akkor import, beállítások szerkesztése, és ismét export. Ezeket a dolgokat írja le a vagrantfájl?
47

Igen, azokat:

complex857 · 2014. Nov. 7. (P), 10.03
Ezeket a dolgokat írja le a vagrantfájl?
Igen, a provisioningot leszámítva nálam 4 dolog szokott a Vagrantfileokba kerülni:
  • Alaprendszer "box"-ja. Többnyire valami készen kapott, mert lusta vagyok sajátokat építeni alaprendszerekhez vagy magam installálni iso-ból az oprendszert.
    config.vm.box = "ubuntu/trusty32"
  • Port forwardingok:
    config.vm.network "forwarded_port", guest: 80, host: 8080
  • Osztott könyvtárak:
    config.vm.synced_folder "www", "/var/www/"
  • Virtualbox beállítások, általában memóriát szoktam csak piszkálni:
    config.vm.provider "virtualbox" do |vb|
  vb.customize ["modifyvm", :id, "--memory", "512"]
end
Minden más (igazából izgalmas) már provisioning dolga.
Vannak más beállítható dolgok még amiket sose használtam mint ssh jelszavak, keyek és hasonlók, vagy hálózati beállítások. Ezek gyanítom akkor volnának hasznosak ha mondjuk ec2 instance-okat akar csinálni az ember ugyanabból a configból.

Szóval, igen tényleg ez minden (ha a provisioningot nem nézed).
13

Én úgy látom a kérdezőnek nem

spapp · 2014. Nov. 6. (Cs), 15.25
Én úgy látom a kérdezőnek nem azzal van a legnagyobb problémája, hogy a kínálkozó lehetőségek közül melyiket válassza.
A legnagyobb gond, hogy alapvető elméleti hiányosságai vannak. Pl: Linux, hogyan működik a web, webszerver, stb... Én az javaslom, hogy előbb azokat kellene pótolni, mert úgy nehéz segíteni, hogy még az is gond, hogy mi az a virtual host...
A kérdésem, hogy ezeket a virtual host-okat (vagy miket) be kell, be érdemes állítanom?
Ez mire jó amúgy?

Azt javaslom, hogy vegyél egy jó könyvet, végezz el 1-2 tanfolyamot.

Egyébként a válaszaim:
1. nem kell, de érdemes, hasznos, célszerű
2. Virtual hosting
16

sztem a 11-es hozzászólás

szabo.b.gabor · 2014. Nov. 6. (Cs), 15.40
sztem a 11-es hozzászólás alapján, azért érti nagyjából hogy miről van szó.
21

Nagyjából értem, hogy miről

PetyaKmet · 2014. Nov. 6. (Cs), 16.29
Nagyjából értem, hogy miről van szó, és köszönöm is a válaszokat.

Alapból az asztali gépemen állítottam be a dolgokat (persze nem tudtam, hogy miket, csak a leírások alapján próbáltam végigmenni.)
S örültem, hogy hasonlóan mint az előző - win7 és a xampp - párossal életet tudtam lehelni néhány projektbe.

Azt nem értettem, hogy mi ez a 'virtual host' dolog, s ezért jött fel a kérdés.

Válaszaitokból látszik, hogy másik módszerrel (virtuális gép létrehozása, s azon belül dolgozni) hatékonyabb lesz majd a munka.
26

Válaszaitokból látszik, hogy

Hidvégi Gábor · 2014. Nov. 6. (Cs), 16.42
Válaszaitokból látszik, hogy másik módszerrel (virtuális gép létrehozása, s azon belül dolgozni) hatékonyabb lesz majd a munka.
Nem feltétlenül, vannak hátrányai is:
  • valamennyivel lassabban fognak futni a scriptek, lassabb lesz a mentés és a böngészőből való elérés a plusz réteg miatt
  • a gépeden egy csomó memóriának búcsút inthetsz, ami akkor jelenthet gondot, ha mellette erőforrásigényes programokat is futtatsz, például photoshoppot
  • ha a webes fájlokat nem teszed külön virtuális meghajtóra, akkor a teljes virtuális merevlemez gigabájtokat foglalhat el, aminek a másolása, biztonsági másolat készítése lassú lehet
Hosszú évekig fejlesztettem windowson, hasonló környezetben, mint amit fent írtál, mindenféle gond nélkül.
30

valamennyivel lassabban

Joó Ádám · 2014. Nov. 6. (Cs), 17.00
valamennyivel lassabban fognak futni a scriptek, lassabb lesz a mentés és a böngészőből való elérés a plusz réteg miatt


Észrevehetetlen a különbség. A fájlokat pedig nem is kellene a virtuális gépre menteni – fejlesztői gép és szerver különüljenek el teljesen, a virtuális gép álljon a lehető legközelebb a majdani éles környezethez. Ezzel nem csak a különbségekből adódó hibalehetőség szűnik meg, hanem már a fejlesztés közben kialakul a későbbi üzemeltetés gyakorlata (pl. deployment).

a gépeden egy csomó memóriának búcsút inthetsz, ami akkor jelenthet gondot, ha mellette erőforrásigényes programokat is futtatsz, például photoshoppot


Ez részben igaz, én is megérzem néha a magam öt éves gépén, de te döntöd el, mennyi memóriát allokálsz a virtuális gépnek. Manapság, 4-8-16 gigabájtos laptopok mellett ez nem okozhat gondot. Ha mégis kevés a memória, egy-két másodperc alatt lemezre menthető a virtuális gép állapota, és aztán ugyanígy visszatölthető.

ha a webes fájlokat nem teszed külön virtuális meghajtóra, akkor a teljes virtuális merevlemez gigabájtokat foglalhat el, aminek a másolása, biztonsági másolat készítése lassú lehet


A projekt fájlok a fejlesztői gépen vannak, a szerverkonfiguráció a leírófájl formájában a projekt része, így a virtuális gépről nem kell biztonsági mentést készíteni, mert egy tiszta oprendszer képfájl és a leíró birtokában percek alatt felépíthető az előző állapot.

Hosszú évekig fejlesztettem windowson, hasonló környezetben, mint amit fent írtál, mindenféle gond nélkül.


Ameddig csak fejlesztesz és nem üzemeltetsz, illetve ugyanazt a stacket használod mindenhol, addig el lehet ezzel lenni, bár a fejlesztői és éles rendszer közti különbségből adódóan nem hiszem, hogy sosem volt problémád (szerintem mindannyiunknak volt). Amint viszont különböző technológiákkal dolgozol, vagy különböző projektek konfigurációjáért is te felelsz, egyszerűen kézbentarhatatlan a saját gépeden reprodukálni az összes környezetét.
32

Ok, félreértettem, azt

Hidvégi Gábor · 2014. Nov. 6. (Cs), 17.09
Ok, félreértettem, azt hittem, hogy a fejlesztés is történjen virtuális gépen. Ennyi erővel viszont lehetne a tesztelés az éles szerveren is, ha már nagyon ugyanaz a környezet a fontos. Én mindenesetre nem futottam még bele olyanba, hogy operációs rendszerek közti eltérés okozott volna hibát.
36

Ok, félreértettem, azt

Joó Ádám · 2014. Nov. 6. (Cs), 17.16
Ok, félreértettem, azt hittem, hogy a fejlesztés is történjen virtuális gépen.


Ha jól értettem, Gábor ezt javasolta, én ezzel nem értek egyet.

Ennyi erővel viszont lehetne a tesztelés az éles szerveren is, ha már nagyon ugyanaz a környezet a fontos.


Éles szerveren nem tesztelünk, oda csak a már tesztelt szoftver kerül :) A távoli tesztszervert elérni pedig lassú, vagy adott esetben akár lehetetlen is lehet (ha épp nincs hálózatod).

Én mindenesetre nem futottam még bele olyanba, hogy operációs rendszerek közti eltérés okozott volna hibát.


Elég, ha a PHP verzió, beállítások vagy a telepített kiterjesztések különböznek. Vagy a fájlrendszer jogosultságok. Vagy az egyéb telepített szoftverek, amikre az alkalmazásod támaszkodik. De az is lehetséges, hogy olyan szoftvert fejlesztesz, amit nem is tudnál a saját gépeden futtatni.
33

Ami a sebességet illeti, ma

bamegakapa · 2014. Nov. 6. (Cs), 17.09
Ami a sebességet illeti, ma azért nem olyan drága a memória. Szerintem az ember a munkaeszközébe igenis fektessen pénzt, mert nap mint nap azt fogja használni. Ha lassú a munkagép, ott valami nagyon nincs rendben.