Am scris acum ceva timp un articol despre un tip de găzduire care scalează la infinit și poate susține orice nivel de trafic.
E un stack construit de oamenii de la BitPoke, prima fază a proiectului e aproape gata, adică o soluție tehnică funcțională, fără erori. A doua fază e un dashboard atât pentru admin cât și pentru client.
Am mutat în week-end blogul meu și pe cel al soției pe un cluster cu acest stack pe care l-am creat pe Google Cloud, ca să testez, și pare a fi în regulă până acum.
Cum funcționează
Fiecare site WordPress rulează într-un container (pod), izolat complet de alte site-uri WordPress, fiecare cu resursele sale.
Un pod are alocat un nr. de PHP workers (2, 3, 10, 20 etc); cu cât are mai mulți cu atât poate să susțină mai mult trafic. Deci prima și cea simplă metodă de scalare este cea verticală, se alocă mai mulți workeri ca să țină mai mult trafic.
A doua metodă de scalare e cea orizontală – se creează un nr. de replici ale site-ului WordPress (2, 3, 20 etc) iar load balancer-ul împarte traficul între acestea.
Pentru a funcționa chestia asta cu replicarea e nevoie ca setup-ul să fie unul mai „ciudat”, în sensul că e diferit de ceea ce știm și cum lucrăm noi, proprietarii obișnuiți de site-uri.
Core-ul WordPress e managed, proprietarul site-ului nu are acces. Biblioteca media WordPress e separată de partea de cod, stă pe un bucket de pe Google Cloud Storage (poate fi și AWS S3). Baza de date rulează pe un pod diferit de pod-ul în care rulează codul PHP WordPress.
Parte de cod (folderul wp-content fără uploads) e un repository pe Github (sau Gitlab sau orice alt provider).
Modificările pe partea de cod nu se pot face din wp-admin, nu se pot instala, șterge sau modifica teme sau pluginuri. Orice modificare se face doar prin GIT.
De exemplu, actualizarea unui plugin s-ar face în felul următor.
Ai pe calculator un server local de test (eu folosesc Local) și ai acolo site-ul tău WordPress. Faci update la plugin, verifici să nu se bușească nimic, dacă e ok faci push la codul actualizat pe repository-ul din Github.
Pe baza repository-ului actualizat, stack-ul creează un nou pod cu un nou site WordPress, actualizat, în timp ce pod-ul vechi este distrus în background.
Programatorii cred că sunt familiarizați cu această metodă modernă de a face actualizări de cod, e folosită nu doar pentru site-uri și WordPress, însă pentru proprietarii obișnuiți de site-uri este o schimbare de paradigmă destul de dificil de digerat.
Dar ăsta e dezavantajul dacă se dorește ca site-ul să susțină orice nivel de trafic fără să cadă. Avantajele sunt scalabilitate ridicată, uptime ce se apropie de 100% și viteză de încărcare.
De aceea consider că soluția asta e una modernă pentru profesioniști, nu e pentru toată lumea.
Ce părere aveți de soluția asta?
Lasă un răspuns