Docker最佳实践:容器的单个过程 [英] Docker best practices: single process for a container

查看:64
本文介绍了Docker最佳实践:容器的单个过程的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Docker 最佳实践指南指出:

"...您应该只在单个容器中运行单个进程..."

Nginx和PHP-FPM是否应在单独的容器中运行?还是这意味着微服务架构只能在容器中运行一项服务或应用"?

将这些服务放在一个容器中似乎更易于部署和维护.

解决方案

根据用例,您可以在单个容器中运行多个进程,尽管我不建议这样做.>

从某种意义上说,在不同的容器中运行它们甚至更加简单.将容器保持小巧,无状态,并且只需完成一项工作就可以更轻松地维护所有容器.让我告诉你我的容器工作流程在类似情况下的情况.

所以:

  1. 我有一个带有nginx的容器,该容器暴露于外界(:443,:80).在此级别上,可以轻松管理配置,tls证书,负载均衡器选项等.
  2. 该应用程序包含一个(或多个)容器.在那种情况下,带有应用程序的php-fpm容器.Docker映像是无状态的,容器安装并共享静态文件的卷,依此类推.此时,您可以随时销毁并重新创建应用程序容器,从而保持负载均衡器的正常运行.此外,您可以在同一个代理(nginx)后面拥有多个应用程序,并且管理其中一个不会影响其他应用程序.
  3. 数据库的一个或多个容器...具有相同的好处.
  4. Redis,Memcache等

具有这种结构,部署是模块化的,因此每个服务"都是分离的,并且在逻辑上与系统的其余部分无关.

作为副作用,在这种情况下,您可以对应用程序进行零停机时间部署(更新).这背后的想法很简单.当必须进行更新时,可以使用更新后的应用程序创建docker映像,运行容器,运行所有测试和维护脚本,如果一切顺利,则将新创建的容器添加到链(负载均衡器)中,然后轻声地杀死旧的.就是这样,您有了更新的应用程序,用户甚至根本没有注意到它.

The Docker best practices guide states that:

"...you should only run a single process in a single container..."

Should Nginx and PHP-FPM run in separate containers? Or does that mean that micro service architectures only run one service or "app" in a container?

Having these services in a single container seems easier to deploy and maintain.

解决方案

Depending on the use case, you can run multiple processes inside a single container, although I won't recommend that.

In some sense it is even simpler to run them in different containers. Keeping containers small, stateless, and around a single job makes it easier to maintain them all. Let me tell you how my workflow with containers is in a similar situation.

So:

  1. I have one container with nginx that is exposed to the outside world (:443, :80). At this level it is straightforward to manage the configurations, tls certificates, load balancer options etc.
  2. One (or more) container(s) with the application. In that case a php-fpm container with the app. Docker image is stateless, the containers mount and share the volumes for static files and so on. At this point, you can at any time to destroy and re-create the application container, keeping the load-balancer up and running. Also, you can have multiple applications behind the same proxy (nginx), and managing one of them would not affect the others.
  3. One or more containers for the database... Same benefits apply.
  4. Redis, Memcache etc.

Having this structure, the deployment is modular, so each and every "service" is separated and logically independent from the rest of the system.

As a side effect, in this particular case, you can do zero-downtime deployments (updates) to the application. The idea behind this is simple. When you have to do an update, you create a docker image with the updated application, run the container, run all the tests and maintenance scripts and if everything goes well, you add the newly created container to the chain (load balancer), and softly kill the old one. That's it, you have the updated application and users didn't even notice it at all.

这篇关于Docker最佳实践:容器的单个过程的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆