Docker + Apache + PHP-FPM 静态内容

Question

我正在使用 Slim/Twig 将 PHP 中的一些站点移动到 docker 容器。在旧服务器中，一个请求传入纤薄路由，请求发送回 html，然后浏览器调用以获取 apache 接管的资源 CSS、图像等。转移到 Docker，httpd conf 本质上是这样的：ProxyPassMatch "^/(.*\.php\/(.*)?)$" "fcgi://php:9000/var/www/html/public/index.php/$2"仍在解决所有这些问题，但这基本上转发了一个像http://192.168.33.20:8080/index.php/adminto这样的请求fcgi://php:9000/var/www/html/public/index.php/$2，Slim 选择了路径的所有其余部分，admin并返回了由 twig 呈现的正确视图。我遇到的问题是资源。我通过composer在php应用程序中拥有大部分css和前端框架。因此浏览器再次调用：/index.php/vendor/twbs/bootstrap/dist/js/bootstrap.bundle.js HTTP/1.1" 404得到一个是404因为 Slim 不知道这个路径是什么，而 apache 只是转发。我看过什么和缺点：将资源放在 Apache 上，但这基本上像服务器一样将 Apache 和 php 结合起来。创建一个容器来处理这些文件，即另一个非负载均衡器 Apache 来处理这些请求。这仍然是耦合的，也意味着我需要找到一种方法来潜在地在蓝绿色部署中存储多个版本。将一个卷挂载到 Apache lb。不知道为什么我放弃了这个。应该是版本问题。创建一个可以搜索资源的路由。到目前为止，我最喜欢的想法是增加了代码复杂性。所以我的问题是在 Docker 中有一种标准的方法来处理这个问题吗？

Answer 1

我的标准做法是通过框架路由控制资源访问。一个示例实现（在 Lumen 中）：

$router->get('/asset[/{path:.*}]', 'AssetController@load');

示例请求和响应如下所示：

GET /asset/js/app.js HTTP/1.1

Host: localhost:8080

Connection: keep-alive

Pragma: no-cache

Cache-Control: no-cache

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

Accept: */*

Referer: http://localhost:8080/spa/example

Accept-Encoding: gzip, deflate, br

Accept-Language: en-US,en;q=0.9

HTTP/1.1 200 OK

Server: nginx

Content-Type: application/javascript

Content-Length: 21056410

Connection: keep-alive

Last-Modified: Sun, 31 Jul 63 19:34:21 +0000

Cache-Control: private, must-revalidate

Date: Wed, 31 Jul 2019 19:34:21 GMT

Accept-Ranges: bytes

X-XSS-Protection: 1; mode=block

X-Content-Type-Options: nosniff

Content-Security-Policy: default-src  'self'; connect-src  'self'; img-src  'self'; style-src 'unsafe-inline' fonts.googleapis.com 'self'; font-src fonts.gstatic.com 'self'; script-src 'unsafe-inline'  'self' 'unsafe-eval'

您的控制器（例如，AssetController在我之前的示例中）会注意将 URL 路径转换为文件系统路径（注意..和其他技巧，使用realpath并将其与代码的安装基本路径进行比较），设置Content-Type和Content-Length标题，任何相关的缓存标头，然后流式传输文件。

虽然这确实增加了复杂性和一定数量的开销，但它提供了通过业务逻辑限制资源的灵活性。

如果性能是一个问题，您可以促进对 Web 服务器的访问或屏蔽 CDN 和代理内容后面的路由。