在Docker容器中捆绑源代码

我已经安装了我的应用程序在docker容器中运行，我对此非常兴奋。在Docker容器中捆绑源代码

在开发中，我可以超级快速地构建容器，因为容器的源代码和资产都在容器上下文之外 - 那么我只需在docker run命令中使用-v标志将wwwroot目录映射到容器中。它很棒！

但是，现在我已经设置了一个Elastic Beanstalk应用程序（为docker配置），并且正在寻找部署我的容器。我在想-v的生产方式不是正确的，我可能需要有一个单独的Dockerfile用于生产，它的物理的COPY是我的源代码到容器中？那么也许这就是我推送到码头集线器的容器，并以某种方式发送到Elastic Beanstalk。

还是有更好的方法吗？我一直无法找到明确的方向来解决这个问题。

来源

2016-02-25 Brian FitzGerald

对于生产，您需要一个Dockerfile，将Web应用程序所需的资源（源代码或二进制文件）复制到容器中。否则，将其部署到本地计算机以外的任何地方都将无法工作。

理想情况下，开发和生产Dockerfiles应该是相同的。这样，您的开发就发生在与生产匹配（尽可能接近）的环境中。

来源

2016-02-25 15:03:58

复制资产进行生产很有意义，谢谢。但是在开发中，将资产复制到容器中意味着您需要重新编译每次代码更改，难道不会？看起来像一个真正的痛苦。 –

大多数开发包括重复的“构建”阶段（更改代码，构建，测试，重复）。建立你的容器（和复制资产）就是这样。 –

伟大的观点，感谢分享。我们确实有一个构建过程，但是只有在我们准备好提交时才运行构建，而在每次代码更改之后不需要运行构建程序，以便查看运行新代码的应用程序（在准备提交之前）。无论如何，我感谢您的洞察力，并且我现在看到Docker映像构建过程如何运行到整个应用程序构建过程中。 –

最佳实践指定Dockerfile应尽可能短暂。因此，国旗-v实际上是共享代码的正确方式。该代码不应该成为图像。

来源

2016-02-25 15:08:27 Auzias

即使在生产环境中，代码也不应该在图像中？那么它应该在哪里？ –

在同一主机（或可用存储）上并通过卷共享。如果你曾经嵌入过你的代码，那么在每次提交时你都需要一个新的映像（，你甚至还有版本兄弟？）。 Docker旨在简化开发和部署之间的步骤，这意味着系统状态，软件包和系统本身，而不是比所有必需的生态系统快得多的代码。因此代码通过-v共享而不是嵌入。 – Auzias

哈哈强笑话工作。是的，你所描述的方法对我来说似乎很自然，因为我们的应用程序代码自然会比生态系统更频繁地改变FAR。也就是说，我认为你所描述的实际上被认为是不好的做法，因为Docker容器的可移植性不如突然取决于它运行的环境，并且不再是完全“独立”的实体。 –

在Docker容器中捆绑源代码

回答

相关问题