Fórumok
Ismertek olyan webszervert, amelyik a VirtualHost konfigokat képes adatbázisból beolvasni, futásidőben?A lighttpd szervernél találtam egy mysql-vhost modult, de az csak a docroot paramétert tudja párosítani a kérelem domainnevéhez. Ilyen modul az Apache-hoz is létezik. Én azonban olyat keresek, mint a PowerDns, ami az összes domain teljes konfigurációját fel tudja olvasni adatbázisból.
A cél, hogy a VirtualHost módosítása ne igényelje a webszerver megakadását. A jelenlegi Apache szerver a graceful kiadása esetén kellemetlenül hosszú ideig olvassa újra, és értelmezi a konfigurációkat.
Hozzászólások
Logikailag nem stimmel amit akarsz ha helyesen ertelmezem az utolso mondataidat.
Ha real-time configot akarsz adatbazisbol, elkerulendo a graceful-t az minden http hivasnal egy db olvasast jelent, ez eleg brutalis overhead.
Ha pedig magat az apache configot akarod db-ben tarolni akkor a graceful-t mindenkeppen le kell futtatnod, ergo ugyanott vagy ahol most.
Erre valami nagyon custom apache modul lenne jo ami valahogy verziozza az adott vhost configjat (kb mint a serial dns-ben) es ha a verzio valtozik akkor ujraolvassa az adott specific vhost konfiguraciojat a db-bol es beletolja az apache-ba. A kerdes meg mindig az hogy a serial-okat hogy tartod nyilvan es milyen idokozonkent frissited, stb. szoval van rajta agyalnivalo boven :)
Igazad van, arra nem gondoltam, hogy ez minden kérelemnél egy adatbázis elkérés lenne, tehát valóban valami köztes tárolóban kell a webszervernek tárolnia a konfigurációkat. Bár a lighttpd közvetlenül adatbázisból olvassa minden kérelemkiszolgálásnál a docroot értékét, és úgy tudom, az mégis egy egészen jól terhelhető webszerver. (Valós környezetből tapasztalatom nincs vele.) A query cache azért sokat segíthet ilyen esetben.
Ha hajlandó vagy forrásból forgatni, akkor OpenResty. nginx fork rengeteg Lua modullal, ami többek között *SQL-ből vagy Redisből tud olvasni.
Annak függvényében hogy mit építesz, ezt azonban érdemes végig gondolni. Ha pl. webhosting szolgáltatásról van szó, akkor kell hozzá vhostonként egy PHP-FPM pool is, amit el kell indítani, illetve a memóriafogyasztás miatt már lehet h nem fér bele a budgetbe.
Érdemesebb lenne elmondani hogy pontosan mire kell, úgy könnyebb tanácsot adni.
--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone
Nincs pontosabb elvárásom. Tényleg csak az zavar, hogy a konfiguráció módosítása túlságosan megakasztja a webszervert. PowerDns, Exim, Dovecot mind képes közvetlenül adatbázisból olvasni a konfigurációs adatokat, így itt egy módosítás semmilyen fennakadást nem okoz. De az is igaz, hogy ezeknek messze nem kell annyi kérelmet kiszolgálni, mint egy webszervernek.
Sztem onszivatas ha nem muszaj. Kulon erolkodni kell, es tobb a dolog ami tonkremehet.
--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone
egy graceful miert akassza meg?
nalam ugy volt, hogy sqlben az osszes vhost, de crontabbal generaltam le egy scripttel a vhostot. Ez egyreszt biztonsagosabb, ha valami lenne az adatbazissal, akkor a configod ott marad. tehat akkor irod felul, ha az export sikeres volt.
Erdemes lehet megvizsgalni, hogy tenyleg szukseges-e annyi vhost es nem lehet e kivaltani serveraliassal. Sok ugyfel erre nem gondol.
+ ezen is lehet optimalizalni;
Anno mikor ilyesmit uzemeltettem, ami kigeneralta a kezdetben apache, kesobb nginx konfigot, az megnezett egy masik tablat, hogy vhost konfig valtozott-e.
A vhostok tablajan meg volt egy on insert, on update meg on delete rule, hogy a tablaba usse at 1-esre hogy updatelni kell a webconfigot.
Amikor meg a cron futott, zar a tablara, select, template general, zar elenged, gracefull reload.
Megy mint a karikacsapas.
+ ha mar ugyis van egy cronjobod, akkor egy fust alatt php-fpm konfigokat is lehet generalni + annak is mehet egy graceful reload.
Jelenleg nálam is adatbázisból generálódnak a konfigurációs fájlok. Van ennek is előnye, de érdekel, van-e más lehetőség is.
HashiCorp Consul KV store + consul-template talán segíthet.
https://www.litespeedtech.com/products/litespeed-web-server
Ha nem ragaszkodsz az apache konfigok használatához, hanem a saját apiján veszed fel a vhostokat, akkor a litespeed képes a menet közbeni konfig változások kezelésére, vagy fizetsz akkor itt a megoldás.
Ha úgy érzed, hogy fejlesztésre adnád a fejeded, akkor itt egy megoldás. docroot-ra már müködik, a többit kell "csak" megcsinálni.
https://sourceforge.net/projects/dbd-modules/ Ez mysql -en alapul.
vagy ha az ldap-ban jobban bízol:
http://modvhostldap.alioth.debian.org/
---...---
TLoF
Félek, nagy fejlesztésre nem mernék vállalkozni. Egyszer (tovább)fejlesztettem egy PHP modult, ami nagyon hasznos volt, és sokat segített illegális php kódok megtalálásában, de a verzióváltások elég nehézkesen mentek ...
Ezért inkább valami csomagkezelőből támogatott megoldást keresek.
Amúgy tetszik a gondolat, lehet, egyszer mégis megpróbálkozom vele.
Milyen változások lennének? Mert ha van egy fix konfigod és csak új hostokat kell létrehozni, arra ott van az apache mass virtual hosting megoldása, ahol 1 mappa = 1 domain/aldomain. Ahogy új mappát hozol létre, már matchel is rá és működik.
Sajnos nem csak a docroot változik virtuális hostonként, hanem például a felhasználó, akinek a nevében fut az apache, a php kiszolgálás (különböző php verziók), alaprételmezett karakterkészlet, logfájlok.
Persze azon is el lehet gondolkozni, hogy olyan virtualHost környezetet kellene kialakítani, ahol elég a mappának változni ... hát, nem látom, hogy ez egyszerűbb lenne-e ...
A különböző php.ini-vel történő kiszolgálásba anno én is belefutottam, nem találtam megoldást. Ha van, érdekelne.
Ha nem különböző PHP verziók, hanem tényleg csak különböző php.ini beállítások kellenek, akkor nem lenne elég az apache vhost konfigokban a PHP_Admin_Flag és PHP_Admin_Value?
--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
Akár elég is lenne, mert open_basedir is megadható így, de mass virtual esetén nem működik a változó, csak itt:
VirtualDocumentRoot "/www/hosts/%0/docs"
Próbáltam ezt open_basedir-nél is megadni, de nem működött.
ISPConfig, és percenként fut a cron-ja, csak a változott configokat generálja le... nekem (kopp-kopp) sose akadt meg a szolgáltatás...
Na igen, igazából ez is érdekelne, hogy ezek az ISP motorok ezt hogyan oldják meg. Az egyik módszer, hogy csak cgi módban szolgálják ki a szerveroldali scripteket, így azok átkonfigurálása nem érinti magát a webszervert. De, hogy a webszerver konfigurációját érintő módosítások után hogyan tud zökkenőmentesen futni, arra tényleg kíváncsi lennék.
Az, hogy csak azt a konfigurációt módosítja, ami megváltozott, az nem magyarázat, mert nem a konfig változása az időigényes, hanem az újraolvasás, és az újraolvasásnál mindig az összes konfigot újraolvassa, bármennyi változott is.
Ha mersz nagyban gondolkodni, akkor én ilyet csinálnék. Minden website külön webszerveren, akár külön gépen fut, több példányban. Lenne előttük egy reverse proxy/load balancer, ami csak az URL-re néz rá, és küldi tovább a kérést. Így külön-külön minden szerver hamar újra tud indulni, a reverse proxy pedig nem sok vizet kavar, ő főleg. Ha nagyon lassan indul újra az Apache, akkor fusson két példányban és rolling restart, vagy a reverse proxy tudjon egy kicsit várakozni, ha épp nem megy a backend. Az Apache configot meg simán lehet scriptből generálni akár, ha épp változás van.
--
A két apache tetszik, és ez talán nem is akkora meló. Egy haproxy mögé a két apache, ami majdnem ugyanabból a konfigból dolgozik, de külön indulnak újra.
Mondjuk, nem tudom, mit kezd a két apache egymással egy szerveren, nem akadnak-e össze, legalább a mod_php session kezelésében, vagy a logolásban.