Docker容器集群

我正在使用laravel宅基地解决方案进行开发,但现在我想迁移到docker.问题是如何"膨胀"应该是我的容器.当我说"臃肿"时,我指的是每个容器应该有多少模块/服务.例如,我创建了四个自定义容器,如下所示:

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

问题是,如果这是正确的聚类或我应该创建单独的容器让我们说为grunt,bower,memcached等？如何决定什么在一起以及分隔容器？有规则吗？应该和生产一样发展吗？

如何将应用程序组件分解为容器取决于您的目标.您的目标是使您的服务器更易于管理/管理吗？您是否主要对如何成功扩展应用程序感兴趣,因为它可以获得更多流量？如果扩展是您最关心的问题,以下是一些建议:

将nginx放入自己的容器中是有道理的,因为它的主要作用是充当负载均衡器.在大多数情况下,所有nginx都会将请求传递给您的PHP服务进行处理.由于您的应用程序可能需要处理会话,并且由于您不希望容器共享会话数据,因此应使用ip_hash策略来委派请求.这样你就不会遇到nonce和CSRF令牌无法识别的问题.

由于您的PHP容器将完成大部分工作,因此您应该将它们自己保存在容器中.如果延迟成为问题,您可以随时启动新的PHP容器并将其添加到虚拟群集中以帮助承担负载.与会话管理相关的任何内容(如Redis或memcached)也可以放入此容器中.这样,每个容器都拥有减少延迟所需的所有工具,并开辟瓶颈.

您需要将实际的Laravel应用程序文件放入单个容器中,并使其卷与其他容器共享.这样,如果您的应用程序执行处理文件上载等操作,则无需将这些文件复制到多个容器.您可能希望将作曲家和工匠放在这里,因为这些程序处理的任务主要与维护Laravel应用程序中的文件有关.Dylan Lindgren建议将工匠和作曲家放入自己的容器中.

由于您的数据也在整个应用程序中共享,因此您可能还应该为数据库设置单独的容器.我想您可能会考虑将您的数据库与Laravel应用程序文件捆绑在一起,但由于您可以相对轻松地找到各种数据库的预配置容器,因此可能更容易不这样做.

至于节点,您可能甚至不需要在生产服务器上使用它.由于基于节点/ npm的组件通常仅用于在部署之前组合和压缩资源(JS和CSS),因此您可以在开发机器上执行所有资产预处理并生成压缩/缩小的CSS/JS文件Laravel容器的一部分.由于所有与CSS/JS相关的处理都发生在客户端,因此它们基本上可以被视为静态文件.

这是一个代表这个的图表:

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

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

Docker的一个很酷的事情是你在本地开发容器,并且可以"按原样"将它们部署到云中.所以,在本地你就拥有了所有这些容器(你甚至可以换掉其中一些容器,比如你的数据库和/或服务器),然后部署只需要在生产服务器上运行容器的新实例.

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