LAMP szerver virtualizálás

Én építettem egy A verziót, ment is évekig, de a teljesítménye nem volt túl meggyőző (a sok guest overhead-je és az adatbázis szerver hálózatos elérése tűnt szűk keresztmetszetnek)
Ezek után kb. azt javasolnám, hogy egy guest a LAMP, egy másik guest a levelezés.

Nálam szét vannak szedve. Az okok:

- a levelezőalkalmazás (Roundcube) nem használja túlzottan az adatbázist
- nem muszáj hálózati kapcsolatot csinálnom, lehet helyi socket (ez nem minden környezetben oldható meg)
- marha kényelmes úgy frissíteni, hogy mindig csak egy-egy komponenst kell a gépen érdemben matatni
- a db-t más alkalmazások is használják, más konténerekből
- ha nagyon muszáj akkor pl. tudok csinálni (app) clustert, és azt lábanként frissíteni, kb. leállás nélkül
- nagyon kényelmes a komplett virtuális gépet mentenem frissítés előtt, és ha leállítom a webmailt, akkor így az nem érinti más alkalmazások működését

Egy web+adatbázis+levelezés szerver tud annyira komplex lenni, hogy tökön szúrd magad, ha pl. egyszuszra frissíteni kell.

Egy ilyen kombó tartalmazhat:
- LDAP címtárat,
- Adatbázis szervert,
- SMTP szervert,
- IMAP/POP3 szervert,
- SASL hitelesítő szervert,
- Vírusirtót,
- Tartalom/SPAM szűrőt,
- Webszervert,
- PHP és egyéb futtató környezeteket,
- Csoportmunka-megoldásokat, (Web/Cal/CardDAV)
- Fájl alterációs szolgáltatásokat (FAM, Gamin, stb.) kvótázást, stb.
- Tűzfal- és csomagszűrő szolgáltatásokat,
- ...

Nyilván lehetséges ezeket egy virtuális gépben futtatni, de - a méretektől függően - menedzselhetőség szempontjából áldás lehet ezt ha nem is háromfelé, de legalább kétfelé szedni.

Aztán, ott van még a biztonság kérdése. Pl. egy webszerveren biztos nem engedném kifelé közvetlenül a TCP/25-öt, (meg mást sem) egy levelezőszerveren meg muszáj. Oké, persze a mai korszerű csomagszűrőkkel lehet per-process szabályokat is csinálni, de miért kellene bonyolultan, ha egyszerűen is lehet?

[Feliratkozás]

+1

Szerintem:

B, Az egész LAMP+levelezés egy virtuális szerverre kerül.
- container1: web
- container2: adatbázis
- container3: levelezés

Amikor utoljára át akartam szervezni a sajátomat, még volt pár rés a pajzson, a debian-stable stock megoldásban, csodálkoztam is, hogy bejutott a stable-be, amikor szép white-hat - white-paper is volt róla, hogy ez így miért nem jó. De ennek már két éve ... a debian-stable security team ennyi idő alatt fel szokta göngyölíteni ezeket, de őszintén, nem követtem azóta, mert akkor lett volna csak többletenergiám szétszervezni (annyira nem volt többletenergiám, hogy széthegesszem a konzerv debian megoldást) egy igencsak sok szolgáltatást futtató gépet... azaz watch your 6 ...

+: kisebb overhead
-: igazán akkor jó ha fizikai vasra megy

?: ki tudja, hogy a stock debian stable lxc _most_ mennyire secure?

Ha nem csak a negatívumokat akarod élvezni akkor egyértelműen A.
Ha most kezded a dolgot javaslom a Proxmoxot hypervisornak, nagyon kényelmes.
CT-ket kell csinálni nem VM-eket, minimális overhead-et okoz egy natív telepítéshez képest.

--
Gábriel Ákos
http://i-logic.hu