碼頭圖像層次管理

Question

在我的IT團隊通過碼頭部署許多應用程序的一種情況下。我們有我們自己的碼頭圖片，以及來自互聯網註冊表的其他圖片。

一（基地）圖像可能是一個操作系統圖像，而另一個可能是一個運行時框架（用於Java，紅寶石，等...），還有一個可能是一些專用工具（如git，一些庫）。然後，最後，我們有我們的應用程序的圖像。

這意味着我們的容器層次結構是這樣的：

1. 應用FROM工具和(ADD . /app)
2. 工具FROM框架
3. 框架FROM OS
4. OS爲基礎容器

每容器有它自己的D ockerfile。

然後如果我們需要創建另一個app2，我們可以重新使用我們的框架容器。好。

但如果app3走來，用很少的差異相似frameworks2容器從框架，那麼我們就結束了與其它圖像framework2。

這使得使用版本圖像及其基礎來控制應用程序的版本變得非常困難。

最後，我只選擇了一個Dockerfile。從操作系統的應用程序，它使一切，它的Dockerfile與應用版本。

任何人有其他想法？

Answer 1

我們使用最像您的碼頭工具，但我們並沒有將每個應用程序構建到圖像上。

我們有一個基本的os鏡像，還有很多框架鏡像，比如php52，php53，Python2.7，nodejs等等。

盡我們所能，使每個框架圖像包含我們的開發人員需要他的開發語言的所有依賴項。

當開發人員需要激活一個應用程序時，他只需將他的代碼推送到我們的git中，並從他的開發語言的框架圖像中啓動容器。因爲在我們使用docker之前，我們已經使用kvm很長時間了，並且幾乎收集了所有依賴項，我們的開發人員需要在不同的kvm映像中進行打包。所以我們在docker中這樣做，他們只需要關注他們的代碼。

我認爲將每個應用程序構建爲一個圖像太過沉重，而且幾乎沒有版本控制。如果您構建了一些基礎框架映像，並且他們需要更新依賴項時，則只能更新基礎框架映像，並且從新映像重新啓動容器比傳統虛擬化（例如kvm）更快。儘管這可能會導致圖像變大，但我認爲它比擁有太多圖像並且難以控制它們要好。

我的英文不好，我希望我能準確解釋我的想法並做一些幫助。