Ok tôi nghĩ rằng tôi đã tìm ra vấn đề.
Wordpress sử dụng hai biến để xác định:
- url nào dẫn đến vị trí trang wordpress của bạn (
WP_HOME)
- url nào được sử dụng để tải tài nguyên cho trang wordpress của bạn (
WP_SITEURL)
Điều đầu tiên tôi phải làm cho bộ chứa wordpress là đảm bảo rằng các url này khớp với url bộ chứa bên trong, tức là $BLOG_SERVER. Bởi vì tôi sử dụng docker-compose, thật dễ dàng để chèn url này bằng cách sử dụng các biến môi trường thông qua WORDPRESS_CONFIG_EXTRA tranh luận.
wordpress-blog:
hình ảnh: wordpress:5
phụ thuộc:
- blog-db
môi trường:
WORDPRESS_DB_HOST: blog-db
WORDPRESS_DB_NAME: blog
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_CONFIG_EXTRA: |
xác định ('WP_HOME', 'http://wordpress-blog');
xác định ('WP_SITEURL', 'http://wordpress-blog');
khối lượng:
- wordpress:/var/www/html
Điều đó đã xong, bây giờ chúng ta có thể tập trung vào proxy.
Trước khi tôi đi theo con đường của proxy ngược hoàn toàn, tôi đã giả định rằng proxy bằng cách nào đó sẽ đảm nhận mọi yêu cầu cho /Blog/ và trả lại các trang từ trang web được ủy quyền trông như thể chúng được phục vụ trực tiếp từ wordpress. Một điều tôi không tính đến là giả định này cũng giả định trang kết xuất phía máy chủ.
Bắt đầu với cái mới Máy chủ ảo cấu hình, bây giờ nó trông như thế này:
<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>
Điều tiếp theo tôi phải làm để proxy này bắt đầu hoạt động như một proxy là thêm dòng này:
ProxyPreserveTắt máy chủ
Điều này đảm bảo rằng tất cả các phản hồi/yêu cầu chúng tôi nhận được từ wordpress không giống như chúng đến từ chúng tôi (proxy). Lý do cho điều này sẽ sớm trở nên rõ ràng khi chúng ta bắt đầu xử lý html ủy quyền.
tiếp theo Proxy Pass chỉ thị đã được chuyển ra khỏi Địa điểm container, và trực tiếp vào Máy chủ ảo.
ProxyPass "/blog/" "${BLOG_SERVER}/"
ProxyPass "/" "${REACT_SERVER}/"
Lý do cho điều này là bởi vì Địa điểm các khối đã khớp với các yêu cầu rất muộn và đôi khi / con đường chiến thắng trên /Blog/ con đường. Tôi cần nó đáng tin cậy hơn, vì vậy tôi quyết định tự chỉ định các proxy (tôi đã xem một ví dụ đây), sau đó sửa đổi các đường dẫn bên trong Địa điểm thùng đựng hàng.
Tại thời điểm này, proxy ngược bây giờ là đang làm việc! Tuy nhiên, html trong các trang có các liên kết trỏ đến url nội bộ của trang wordpress. Đây là nơi mod_proxy_html đến. Nó có thể được sử dụng để viết lại tất cả các liên kết trong html để trỏ đến proxy ngược. Bất cứ nơi nào nó tìm thấy một liên kết trỏ đến trang blog nội bộ, liên kết đó sẽ được thay thế bằng một liên kết sử dụng proxy ngược.
ProxyHTMLBật Bật
ProxyHTMLExtended On
ProxyHTMLURLMap "${BLOG_SERVER}/"
SetOutputFilter INFLATE;proxy-html;DEFLATE
Dòng cuối cùng có thể gây ra nút cổ chai vì về cơ bản, nó giải nén tải trọng từ trang blog, viết lại tất cả các url để trỏ đến proxy ngược, sau đó nén chúng lại. Nếu bạn không muốn điều này, một cách khác để thực hiện nó là sử dụng:
RequestHeader bỏ đặt Mã hóa chấp nhận
Ngay cả khi đã có tất cả những điều này, giải pháp vẫn chưa hoàn hảo vì bất kỳ tệp javascript nào được tải trên trang tạo yêu cầu tới trang web nội bộ sẽ không chuyển yêu cầu của chúng tới proxy.
Một giải pháp cho vấn đề này là sử dụng giải pháp đầu tiên được đề xuất bởi câu trả lời hiện tại về câu hỏi này, và thay đổi WP_SITEURL để trỏ trực tiếp đến proxy ngược.
Một giải pháp khác là sử dụng một Nhân viên phục vụ đến chặn yêu cầu mạng. Tôi thích giải pháp này vì nó không liên kết chặt chẽ trang blog với proxy ngược. Tôi có thể tưởng tượng rằng sẽ không quá xa vời nếu đưa nhân viên dịch vụ vào bất kỳ trang html nào được yêu cầu từ proxy và yêu cầu nhân viên dịch vụ đó chặn tất cả các yêu cầu khớp với url của trang blog nội bộ và thay thế chúng bằng url proxy ngược.
Tôi đã đi với cả hai. Sau nhiều lần cân nhắc, tôi nghĩ lưu trữ wordpress trong một tên miền phụ sẽ tốt hơn cho nhu cầu của tôi. Một cái gì đó như blog.example.com là những gì tôi có thể làm, nhưng nó sẽ hoạt động vào một ngày khác.
Tóm lại, proxy ngược rất khó triển khai đúng cách với apache. Tôi không biết liệu cỏ có xanh hơn ở bên nginx hay không, nhưng có lẽ một ngày nào đó chúng ta sẽ kiểm tra nó. Giải pháp mà tôi đang thực hiện dành cho nội dung chỉ dành cho phía máy chủ, vốn đã được chứng minh là một ứng cử viên hoàn hảo để được ủy quyền, nhưng tiếc là nội dung được tải động sẽ yêu cầu nhiều công việc hơn.
nguồn
Các mô-đun Apache được kích hoạt để ủy quyền html
LoadModule deflate_module modules/mod_deflate.so
LoadModule mô-đun xml2enc_module/mod_xml2enc.so
LoadModule proxy_html_module modules/mod_proxy_html.so
