时间戳

首页 > 解决方案 > 在单台机器上自动部署 dockerized 应用程序

docker - 在单台机器上自动部署 dockerized 应用程序

问题描述

我有一个由一些服务组成的网络应用程序——网络、数据库和一个作业队列/工作人员。我将所有内容都托管在单个 Google VM 上，我的部署过程非常简单和幼稚：

现在，我开始了一个新的 Web 项目，我喜欢在其中使用 docker-compose 进行本地开发。然而，我似乎在决定生产部署的可用选项之间陷入分析瘫痪——我查看了 Kubernetes、Swarm、docker-compose、容器注册表等。

我正在寻找一个能让我通过单机部署保持生产力的方法。理想情况下，我应该能够在时机成熟时将其扩展到多台机器，但现在简单和保持节俭（一台机器）更重要。我想考虑 2 个选项 - 当 VM 已经存在以及可以专门为此应用程序分配新的裸 VM 时。

我想知道 docker-compose 对于简单的 Web 应用程序是否是一个合理的选择。人们是否在生产中使用它？如果是，从裸 VM 到推出更新的应用程序的整个过程是什么样的？人们是否使用 Kubernetes 或 Swarm 进行简单的单机部署，还是过度杀伤？

标签： dockerkubernetesdocker-composegoogle-compute-enginedocker-swarm

解决方案

我想知道 docker-compose 对于简单的 Web 应用程序是否是一个合理的选择。

当然，如果最好将开发时间花在 Web 应用程序上，而不是花在诸如作业队列和数据库之类的非 Web 内容上，那是可以的。另一个星号是开发环境是否适用于热重载或端口转发以及那种爵士乐。我说这是一个合理的选择，因为创建适合在集群环境中使用的应用程序的 99% 的工作是容器化应用程序的工作。因此，如果该应用程序已经docker-compose在docker-compose.

人们在生产中使用它吗

我希望不是; 我确信有些人docker-compose习惯于在生产中运行，就像有些人使用 Windows 批处理文件进行部署一样，但不要成为那个人。

人们是否使用 Kubernetes 或 Swarm 进行简单的单机部署，还是过度杀伤？

同样，不要成为将整个应用程序部署在单个虚拟机上的人，也不要为一次失败而抹杀你所重视的一切做好心理准备。这就是集群技术旨在防止的部分内容：一个错误一举摧毁了整个应用程序、Web、队列和持久性。

现在，针对您的情况部署 Kubernetes 是否“过大”取决于您是否从Kubernetes 带来的其他东西中受益，而不仅仅是扩展。我们受益于开发人员授权、日志聚合、CPU 和资源限制、在不引入任何戏剧性的情况下关闭一个节点的能力、秘密管理、配置管理、使用少量节点来处理大量托管应用程序（不像创建一个每个部署的应用程序只有一个虚拟机，因为部署对配置文件或端口的放置没有任何规定）。我可以继续，因为 Kubernetes 真的很神奇；但是，正如许多人会指出的那样，成功运行集群并不是零人力成本。

推荐阅读