Ok, cred ca mi-am dat seama de problema.
Wordpress folosește două variabile pentru a determina:
- Care adresă URL duce la locația site-ului dvs. wordpress (
WP_HOME)
- Ce adresă URL este folosită pentru a încărca resurse pentru site-ul dvs. wordpress (
WP_SITEURL)
Primul lucru pe care a trebuit să-l fac pentru containerul wordpress a fost să mă asigur că aceste adrese URL se potrivesc cu adresa URL a containerului intern, adică. $BLOG_SERVER. Deoarece folosesc docker-compose, a fost ușor să injectez această adresă URL folosind variabile de mediu prin intermediul WORDPRESS_CONFIG_EXTRA argument.
wordpress-blog:
imagine: wordpress:5
depinde de:
- blog-db
mediu inconjurator:
WORDPRESS_DB_HOST: blog-db
WORDPRESS_DB_NAME: blog
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_CONFIG_EXTRA: |
define('WP_HOME', 'http://wordpress-blog');
define('WP_SITEURL', 'http://wordpress-blog');
volume:
- wordpress:/var/www/html
Acum că s-a terminat, ne putem concentra pe proxy.
Înainte să merg pe calea proxy-ului invers complet, am presupus că proxy-ul va prelua cumva fiecare cerere de /blog/ și returnează pagini de pe site-ul proxy care vor arăta ca și cum ar fi fost difuzate direct din wordpress. Un lucru pe care nu l-am luat în considerare a fost că și această presupunere a presupus pagini randate pe partea serverului.
Începând cu noul VirtualHost configurație, așa arată acum:
<VirtualHost *:80>
ProxyPass "/blog/" "${BLOG_SERVER}/"
ProxyPass "/" "${REACT_SERVER}/"
<Location "/">
ProxyPreserveHost On
ProxyErrorOverride On
ProxyPassReverse "${DEV_SERVER}/"
</Location>
<Location "/blog/">
ProxyPreserveHost Off
ProxyPassReverse "${BLOG_SERVER}/"
ProxyPassReverseCookiePath "/" "/blog/"
ProxyErrorOverride On
ProxyHTMLEnable On
ProxyHTMLExtended On
ProxyHTMLURLMap "${BLOG_SERVER}/"
SetOutputFilter INFLATE;proxy-html;DEFLATE
# ProxyPassReverseCookieDomain "%{HTTP_HOST:${BLOG_SERVER}}" %{HTTP_HOST}
</Location>
</VirtualHost>
Următorul lucru pe care a trebuit să-l fac pentru ca acest proxy să înceapă să se comporte ca un proxy a fost să adaug această linie:
ProxyPreserveHost dezactivat
Acest lucru asigură că toate răspunsurile/solicitările pe care le primim de la wordpress nu arată ca și cum ar fi venit de la noi (proxy). Motivul pentru aceasta va fi în curând evident când vom începe să ne ocupăm de proxy html.
În continuare ProxyPass directivele au fost mutate din Locație container și direct în VirtualHost.
ProxyPass „/blog/” „${BLOG_SERVER}/”
ProxyPass „/” „${REACT_SERVER}/”
Motivul pentru aceasta este pentru că Locație blocurile întârziau foarte mult în potrivirea cererilor, iar uneori / calea învinge asupra /blog/ cale. Aveam nevoie ca acesta să fie mai de încredere, așa că am decis să merg cu specificarea proxy-urilor pe cont propriu (am văzut un exemplu Aici), apoi modificând căile din interiorul Locație recipient.
În acest moment, proxy-ul invers este acum lucru! Cu toate acestea, html-ul din pagini avea legături care indicau adresa URL internă a site-ului wordpress. Aici este locul mod_proxy_html intră. Poate fi folosit pentru a rescrie toate linkurile în html pentru a indica proxy-ul invers. Oriunde găsește un link care indică site-ul blogului intern, linkul este înlocuit cu unul care folosește proxy invers.
ProxyHTML Enable Activat
ProxyHTMLExtended Activat
ProxyHTMLURLHarta „${BLOG_SERVER}/”
SetOutputFilter INFLATE;proxy-html;DEFLATE
Ultima linie ar putea introduce un blocaj deoarece, în esență, decomprimă sarcina utilă de pe site-ul blogului, rescrie toate adresele URL pentru a indica proxy-ul invers, apoi le comprimă din nou. Dacă nu doriți acest lucru, o altă modalitate de a realiza acest lucru este să utilizați:
RequestHeader dezactivat Accept-Encoding
Chiar și cu toate acestea la locul lor, soluția încă nu era perfectă, deoarece orice fișier javascript încărcat pe pagină, care face o solicitare către site-ul intern, nu va avea solicitările lor direcționate către proxy.
O soluție la acest lucru ar fi să mergeți cu prima soluție propusă de răspunsul curent pe această întrebare și în schimbare WP_SITEURL pentru a indica direct proxy-ul invers.
O altă soluție este folosirea unui Lucrator de service la interceptarea cererilor de rețea. Îmi place această soluție pentru că nu cuplează strâns site-ul blogului cu proxy-ul invers. Mi-aș putea imagina că nu ar fi o idee prea exagerată (heh) să injectăm lucrătorul de serviciu în orice pagini html solicitate de la proxy și să îl punem pe acel lucrător de serviciu să intercepteze toate solicitările care se potrivesc cu adresa URL a site-ului blogului intern și să înlocuiască ei cu URL-ul proxy invers.
Nu am mers cu niciuna dintre acestea. După multă deliberare, cred că găzduirea wordpress într-un subdomeniu ar fi mai bună pentru nevoile mele. Aș putea alege ceva de genul blog.example.com, dar asta ar fi de lucru pentru o altă zi.
În concluzie, proxy-urile inverse sunt dificil de implementat corect cu apache. Nu știu dacă iarba este mai verde pe partea nginx, dar poate cândva o vom verifica. Soluția pe care o căutam presupunea conținut exclusiv pe server, care s-ar fi dovedit a fi un candidat perfect pentru a fi proxy, dar, din păcate, conținutul încărcat dinamic va necesita mai multă muncă.
Surse
Modulele Apache activate pentru proxy html
LoadModule deflate_module modules/mod_deflate.so
LoadModule xml2enc_module modules/mod_xml2enc.so
LoadModule proxy_html_module modules/mod_proxy_html.so
