我有一个Web应用程序，包括一些服务 - Web，DB和作业队列/工作者。我在一台Google VM上托管所有内容，我的部署过程非常简单和天真：
现在，我正在开始一个新的web项目，我喜欢使用docker-compose进行本地开发。但是，我似乎很难分析瘫痪决定生产部署的可用选项 - 我查看了Kubernetes，Swarm，docker-compose，容器注册表等。
我正在寻找一种能够让我在单机部署中保持高效的配方。理想情况下，我应该能够在时机成熟时将其扩展到多台机器，但简单和保持节俭（一台机器）现在更重要。我想考虑两个选项 - 当VM已经存在以及何时可以专门为此应用程序分配新的裸VM。
我想知道docker-compose是否是一个简单的Web应用程序的合理选择。人们是否在生产中使用它？如果是这样，整个过程如何从裸VM到推出更新的应用程序？人们使用Kubernetes或Swarm来进行简单的单机部署还是过度杀伤？
我想知道docker-compose是否是一个简单的Web应用程序的合理选择。
可以肯定的是，开发时间最好是专注于Web应用程序而不是非Web内容（例如作业队列和数据库）。另一个星号是开发环境是否适用于热重载或端口转发以及那种爵士乐。我说这是一个合理的选择，因为创建适用于集群环境的应用程序的99％的工作是容纳应用程序的工作。因此，如果应用程序已经在docker-compose下工作，那么很有可能您可以获取代表docker-compose构建的docker镜像并将其推送到群集。
人们是否在生产中使用它
我希望不是;我确信有人使用docker-compose在生产中运行，就像有人使用Windows批处理文件来部署，但不是那个人。
人们使用Kubernetes或Swarm来进行简单的单机部署还是过度杀伤？
同样，不要成为在单个虚拟机上部署整个应用程序的人，或者是因为一次失败而无法消除您重视的所有内容而做好心理准备的人。这是集群技术旨在防范的一部分：一次性完成整个应用程序，Web，排队和持久性的错误。
现在是否为你的情况部署kubernetes是否“过度杀伤”取决于你是否从kubernetes带来的其他东西中获益，仅仅是扩展。我们从开发人员授权，日志聚合，CPU和资源限制，能够在不引入任何戏剧，秘密管理，配置管理的情况下关闭一个节点，为大量托管应用程序使用少量节点获益（与创建每个已部署应用程序的单个虚拟机，因为部署对配置文件或端口或其他任何内容的放置都没有规定）。我可以坚持下去，因为kubernetes真的很神奇;但是，正如许多人会指出的那样，成功运行集群并不是零成本。
我与之合作的许多公司正在将整个生产环境转向Kubernetes。这是有道理的，因为所有云提供商目前正在推动Kubernetes，我们可以非常肯定Kubernetes是基于云的部署的未来。如果您的应用程序要在任何私有云或公共云中运行，我个人会选择Kubernetes作为它的操作平台。如果您计划添加其他服务，您将可以轻松地连接它们，并根据对应用程序的越来越多的请求来扩展您的基础架构。但是，如果您已经知道您不希望扩展您的应用程序，那么使用Kubernetes集群来运行它可能会过于强大，尽管Google Cloud等可以轻松地通过几次点击来设置这样的集群。
关于Kubernetes的自动化开发工作流程，您可以看看我对这个问题的回答：How to best utilize Kubernetes/minikube DNS for local development