容器化模式最佳实践答案

【问题标题】：Containerization pattern best practice容器化模式最佳实践
【发布时间】：2016-10-17 20:10:37
【问题描述】：

我正在使用 https://hub.docker.com/r/tiangolo/uwsgi-nginx 图像对 Python webapp 进行 dockerizing，该图像使用 supervisor 来控制 uWSGI 实例。

我的应用实际上需要一个额外的主管调解进程才能运行（LibreOffice headless，我通过 appy 模块生成文档），我想知道实现它的正确模式是什么。

在我看来，我可以根据我的需要使用额外的主管配置扩展上面的图像（以及所有必要的操作系统级安装步骤），但这与运行最少的一般原则相矛盾给定容器中不同进程的数量。但是，由于我的 Python 应用程序设计为仅在本地与 LibreOffice 通信，因此我不确定如何使用更加容器化的方法来实现它。感谢您的任何帮助或建议。

【问题讨论】：

LibreOffice 交互有什么作用？
@R0MANARMY 它使用appy 模块生成文档（我已经编辑了我的问题）。

标签： python nginx docker uwsgi supervisord

【解决方案1】：

每个容器一个进程的建议是合理的 - Docker 只监视它在容器运行时启动的进程，因此如果您有多个进程，Docker 不会监视它们。这也是一个更好的设计 - 您拥有具有单一职责的轻量级、专注的容器，并且您可以独立管理它们。

user2105103 是对的，但您使用的图像已经失去了这种优势，因为它运行 Python 和 Nginx，您可以使用 LibreOffice 无头扩展它并在不更改代码的情况下打包整个应用程序。

如果您转向更“最佳实践”的方法，您将拥有一个跨 Docker 网络中的三个容器运行的分布式应用程序：

nginx - 网络代理，这是应用程序的公共入口点。 Nginx 可以做路由、缓存、SSL 终止、速率限制等。
app - 你的 Python 应用程序，仅在 Docker 网络中可见。接收来自nginx 的请求并使用libreoffice 进行文档操作；
libreoffice - 以无头模式运行，API 暴露，但仅在 Docker 网络中可用。

您需要为此更改代码，引入 PyOO 之类的内容，以便从应用容器远程使用 LibreOffice API。

【讨论】：

FWIW，Yelp 为一个容器中有 2 个进程创建了 pretty good case，但其中只有一个进程“真正工作”。

【解决方案2】：

您已经破坏了“每个容器一个进程”——只需添加另一个进程。这不是硬性规定，甚至不是每个人都同意的规定。

扩展，或者更好地编写您自己的自定义容器。这样一来，您就拥有它、理解它，并针对您的目的进行了优化。

【讨论】：