在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容器中捆綁源代碼

回答

相關問題