Webszerver konfig adatábzisból

Web, mail, IRC, IM, hálózatok

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.

  • 2048 megtekintés

( Sixday v | 2017. 03. 16., cs – 13:54 )

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.

( janoszen v | 2017. 03. 16., cs – 14:09 )

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.

( zolo | 2017. 03. 16., cs – 14:24 )

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.

( TLoF | 2017. 03. 17., p – 17:57 )

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.

( Proci85 v | 2017. 03. 17., p – 21:24 )

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 ...

( bandy | 2017. 03. 21., k – 15:32 )

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.

( joco01 v | 2017. 03. 21., k – 16:11 )

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.