我有一个包含一些服务的Web应用程序-Web，DB和作业队列/工作人员。我将所有内容托管在单个Google VM上，并且部署过程非常简单且幼稚:
现在，我开始一个新的Web项目，在这里我喜欢使用docker-compose进行本地开发。但是，我似乎陷入了分析瘫痪，无法决定生产部署的可用选项-我查看了Kubernetes，Swarm，docker-compose，容器注册表等。
我正在寻找可以使我在单机部署中保持高效的食谱。理想情况下，我应该能够在需要时将其扩展到多台计算机，但是到目前为止，简单和节俭(一台计算机)更为重要。我想考虑2个选项-VM已存在时以及何时可以为此应用程序专门分配新的裸VM。
我想知道docker-compose是否是简单Web应用程序的合理选择。人们是否在生产中使用它，如果是这样，从裸VM到推出更新的应用程序的整个过程看起来如何？人们是使用Kubernetes还是Swarm进行简单的单机部署，还是过大？
最佳答案
I wonder if docker-compose is a reasonable choice for a simple web application.
可以肯定的是，是否最好将开发时间花费在Web应用程序上，而不是花在非Web上，例如工作队列和数据库上。另一个星号是开发环境是否可以与热重载或端口转发以及类似的爵士乐一起使用。我说这是一个合理的选择，因为创建适合在集群环境中使用的应用程序的工作的99％是将应用程序容器化的工作。因此，如果该应用程序已经可以在
docker-compose下运行，那么您很有可能可以获取代表docker-compose构建的docker镜像并将其部署到集群中。Do people use it in production
我希望不是;我敢肯定有人使用
docker-compose在生产环境中运行，就像有人使用Windows批处理文件进行部署一样，但不是那个人。Do people use Kubernetes or Swarm for a simple single-machine deployment or is it an overkill?
同样，请勿成为将整个应用程序部署在单个虚拟机上的人，也不要为一旦失败而消灭您所珍视的一切做好心理准备。这就是集群技术旨在防止的部分内容:一个错误使整个应用程序，Web，排队和持久性全部崩溃，一举成名。
现在，为您的情况部署kubernetes是否“过度杀伤”取决于您是否从kubernetes带来的其他好处中获益，而不仅仅是单纯的扩展。我们受益于开发人员的授权，日志聚合，CPU和资源限制，无需引入任何戏剧性即可拆除一个Node的功能， secret 管理，配置管理，以及为大量托管应用程序使用少量Node的能力(与创建每个部署的应用程序一个虚拟机，因为部署没有约束配置文件或端口等的放置。我可以继续，因为kubernetes确实是神奇的。但是，正如许多人会指出的那样，成功运行集群并不是人工成本为零。
关于docker - 在单台机器上自动部署dockerized应用程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51182990/