laravel - Docker 容器集群

Question

我使用 laravel homestead 解决方案进行开发，但现在我想迁移到 docker。问题是我的容器应该如何“膨胀”。当我说“臃肿”时，我的意思是每个容器应该有多少模块/服务。例如，我创建了四个这样的自定义容器:

php
  -> php-fpm
  -> composer
  -> memcached
  -> redis
 mysql
  -> mysql
 nginx
  ->nginx
 node
  ->gulp
  ->bower
  ->npm
  ->grunt

问题是，这是否是正确的集群，或者我应该为 grunt、bower、memcached 等创建单独的容器？如何决定什么放在一起以及什么分开容器？有什么规则吗？开发应该和生产一样吗？

Answer 1

如何将应用组件分解到容器中取决于您的目标。您的目标是让您的服务器更易于管理/管理吗？您主要对如何在应用程序获得更多流量时成功扩展应用程序感兴趣吗？如果扩展是您最关心的问题，这里有一些建议:

1. 将 nginx 放入自己的容器中是有意义的，因为它的主要作用是 function as a load balancer 。大多数情况下，nginx 所做的就是将请求传递给 PHP 服务进行处理。由于您的应用程序可能需要处理 session ，并且您不希望容器共享 session 数据，因此您应该使用 ip_hash 策略来委托(delegate)请求。这样您就不会遇到随机数和 CSRF token 不被识别的问题。
2. 由于您的 PHP 容器将完成大部分工作，因此您可能应该将它们单独保存在容器中。如果延迟成为问题，您始终可以启动一个新的 PHP 容器并将其添加到虚拟集群中以帮助承担负载。任何与 session 管理相关的东西，比如 Redis 或 memcached，也可以放入这个容器中。这样，每个容器都拥有减少延迟和消除瓶颈所需的所有工具。
3. 您需要将实际的 Laravel 应用程序文件放入单个容器中，并使其卷在其他容器之间共享。这样，如果您的应用程序执行诸如处理文件上传之类的操作，则无需将这些文件复制到多个容器。您可能希望将 Composer 和 Artisan 放在这里，因为这些程序处理的任务主要与维护 Laravel 应用程序中的文件有关。 Dylan Lindgren suggests putting artisan and composer into their own containers .
4. 由于您的数据也在整个应用程序中共享，因此您可能还应该为数据库拥有一个单独的容器。我想您可能会考虑将数据库与 Laravel 应用程序文件捆绑在一起，但不这样做可能更容易，因为您将能够相对轻松地找到各种数据库的预配置容器。
5. 对于节点，您甚至可能在生产服务器上不需要它。由于基于 Node/npm 的组件通常仅用于在部署之前组合和压缩资源(JS 和 CSS)，因此您可以在开发计算机上对资源进行所有预处理，并制作压缩/缩小的 CSS/JS 文件Laravel 容器的一部分。由于所有 CSS/JS 相关处理都发生在客户端，因此它们本质上可以被视为静态文件。

这是一个图表来表示这一点:

请注意，您可以根据需要添加任意数量的 PHP/Redis/Memcached 容器来处理额外的服务器负载。这些容器甚至不一定必须位于同一台物理服务器上，您可以在同一台物理服务器上获得额外的内存和处理能力。

如果您不希望应用程序的负载达到需要所有这些来管理它的程度，那么坚持使用传统方法可能会更容易。 Docker 仍然相对较新，并不真正推荐用于生产环境，尽管像我一样，您可能真的很想弄清楚它如何有用。

Docker 的一大优点是您可以在本地开发容器并可以将它们“按原样”部署到云中。因此，在本地您将拥有所有这些容器(您甚至可以交换其中一些容器，例如您的数据库和/或服务器)，然后部署就变成了在生产服务器上运行容器的新实例的问题.

我希望这可以帮助您更好地理解如何制定将应用程序的各个部分分解到容器中的策略。 Docker 对于 Laravel 领域来说仍然相对较新，因此我确信这些实践将在未来一两年内迅速改变，并可能最终实现自动化。