理解生产中的Docker

我一直在学习如何使用Docker来设置开发环境，但是 好奇这些想法如何转化为一个生产堆栈。例如，我有一个Laravel（Php）应用程序，它使用MySQL、Redis和Nginx

所以在生产中，假设我在AWS上的负载平衡器后面通常有2个应用程序ec2实例。当使用Docker设置类似的生产情况时

1） 因为我将使用RDS和Elasticache，所以不需要这些容器。所以基本上，我只需要PHP Fpm和Nginx的容器

2） 为了获得高可用性，我在ELB后面还有2个（或至少1个以上）ec2实例。因此，我假设每个实例都会运行上述容器（PHP和Nginx）。但这听起来与我以前的VM设置没有什么不同，在VM设置中，每台服务器都运行为应用程序服务所需的内容。准确吗

---

3） 对于VM，我通常将代码烘焙到AMI中，并将这些AMI添加到启动配置和自动扩展组中，该组将根据需要启动实例。因此，对于部署，我将拆除旧的ec2实例并启动新实例。有了Docker，由于这些容器将在ec2实例上运行，我是否仍然需要启动/拆除虚拟机，或者我只是更换容器并保持虚拟机运行？

在Docker环境之外保留RDS、Elasticache和其他完全管理的服务是合理的。是的，对于高可用性，您需要多个运行docker守护进程的EC2实例

真正的优势不是让两个EC2实例分别运行两个web服务器docker容器。当您将应用程序分解为微服务时，真正的优势就来了，在微服务中，多个容器组合在一起构建您的web应用程序，从而提供服务

除此之外，DevOps流与EC2中的传统web应用程序部署（具有自动缩放和负载平衡）不同，并且具有许多优点。例如，您的源代码也将包含容器代码，这将保证环境在您的登台和生产中统一工作。此外，您的源代码管理中还将有指向分支/标记的图像，这允许获取新版本的新更新（增量下载）

如果您要在AWS中设置docker，建议使用它以减少管理开销

没错，您只需要在容器中运行代码，它就可以访问远程服务。你唯一需要考虑的是确保它们之间的连接性。

你又对了，你需要把你以前在虚拟机中的所有东西都放在Docker容器中，这样你的代码才能像以前一样工作。无论如何，使用Docker容器可以在同一EC2实例上运行应用程序的多个实例。当然，您的应用程序将尝试在同一端口上运行，因此需要一些额外的网络层来管理端口，但这是可能的。所有EC2实例都需要安装docker

您只需拉取新的Docker映像并使用新映像重新启动容器，而无需创建AMI并关闭和旋转EC2实例。这意味着与EC2实例流中的分钟相比，只需要几秒钟。这意味着您有一种非常快速的方法来恢复buggy部署，并为可以达到0%停机时间的设置打开大门

---

谢谢你的信息。因此，从目前的情况来看，由于我的应用程序只是一个基本的API，可能还没有适合micorservices的位置，我可能不会从Docker中真正受益？是的，如果它是一个简单的API，您可以暂时保留它。当它变得复杂时，你可以开始对接应用程序，然后慢慢地将chuck设备分块到microservices。谢谢你提供的信息。所以现在看来，因为我的应用程序不需要太多的容器，我可能只会从快速部署中受益——至少在我需要更多的容器之前——最大的优势是快速部署。这在很大程度上取决于您部署到生产环境的频率以及拥有接近100%的正常运行时间对您的重要性。如果你有很少的部署，你可能不会从迁移到Docker那么多。“DoCKER”中的“快速部署”实际上取决于其他因素以及你所考虑的“部署”。实际上，Docker实际上为流程添加了一些步骤，人们通常应该在端到端部署时间中包括这些步骤。构建Docker映像（这通常是对当前构建过程的一个添加，并且会增加一些时间），将映像推送到注册表（该映像需要可供服务器拉取），然后在所有服务器上拉取该映像。最终，Docker可能不会比您当前的方法更快。值得思考。当然，部署速度是一个较长的讨论。无论如何，这些步骤都需要以某种方式完成。OP正在构建AMI，并在部署时关闭/打开EC2实例。这可以说比构建图像并拉取图像要慢。当然，向Docker迁移（管理注册表、DockerFile等）需要做一些工作，这就是为什么我说这取决于用例。这些都是有趣的地方。尽管如此，我们仍在使用Jenkins进行连续部署，并推动每天最多5次的生产。从AMI构建到地面启动，每一次部署可能需要10分钟左右