Docker撰寫何時使用圖像構建

Question

Docker撰寫documentation及其example use case非常適合您找出拆分不同工作環境（開發，生產等）的各種可能性。

web: 
    image: example/my_web_app:latest 
    links: 
    - db 
    - cache 

db: 
    image: postgres:latest 

cache: 
    image: redis:latest 

但是，我不清楚何時使用圖像而不是構建。

這是唯一可用的描述，與他們唯一的image: example/my_web_app:latest例如雲：

另一種常見的情況是運行即席或管理任務 對在撰寫應用一個或多個服務。此示例 演示運行數據庫備份。

自己的例子時休息使用build: .

據我所知，有超過建築圖像時開啓首次容器起來的時候，因爲圖像已經準備建立爲您提供更好的性能。但是，我可以預見許多問題：

• [開發]開發人員可能會更改Dockerfile配置（並且在推送任何更改之前需要先進行測試）。
• [開發]源代碼文件將改變（但我想你可以通過共享卷容易修復）。
• [製作]你可能並不總是想要在:latest版本（或者你是否？）。
• [any]通過使用圖像（和:latest標籤），您無法控制您正在觸摸的文件版本。但是每當你打開docker-compose up它就會更新到最新的工作版本。

一些以前的觀點可能不完全正確。隨意拆除它們。

Answer 1

通常你想使用build .在下列情況：

• 發展
• 自動化測試

這是正常進行，當你正在開發或測試和代碼不生產準備。例如測試失敗，代碼不能編譯，編碼錯誤等。

通常情況下，您只會在準備運送部署時創建圖像。此時，您將創建該映像，並通過其標記對其進行版本升級，並將其推送到您的個人DTR或Docker Hub。

當使用docker中的版本進行組合時，您不會綁定到:latest，您可以指定任何要保證在任何給定環境中運行正確版本的版本。例如，生產環境中，可能希望創建稱爲docker-production.yaml一個撰寫文件，其被配置像這樣：

web: 
    image: "example/my_web_app:${TAG}" 
    links: 
    - db 
    - cache 
db: 
    image: postgres:9.5.2 
cache: 
    image: redis:3.0.7 

哪裏${TAG}是在運行時被取代的在環境變量，例如docker-compose up -d -f docker-production.yaml。您可以閱讀更多關於變量替換here。

撰寫的力量是，您可以創建具有可變替代項的構建文件，由您的構建系統自動啓動，不再將其限制爲:latest甚至是硬編碼版本。

注：

1. 如何團隊運行他們的製造，運輸，部署差別很大，因爲他們 找出最適合他們和他們的產品，因此上述 build .場景對於所有的情況可能不準確，但是對於我的公司如何使用撰寫文章準確的是 。
2. 這假設build .在docker-compose context而不是docker build上下文。

Answer 2

正如@ GHETTO.CHiLD所說，這取決於您的需求和您的工作流程。其實我們不執行手動構建。我將解釋我們如何管理這個以及爲什麼。它完全符合我們的流程，但不適用於其他情況。

• 我們不會手動生成圖像。我們有CI（）
• 我們有2種類型的圖像，開發/測試和生產。

• 有一個docker-compose.yml用於開發，可以簡化環境管理。他們只運行docker-compose up，它從註冊表中獲取映像並將其掛載到容器中。

  version: "2" 
  
  services: 
      web: 
      build: 
       context: ../../ 
       dockerfile: dockerfiles/dev/Dockerfile 
      image: registry.my.domain/my_image:dev 
      volumes: 
       - ../../:/opt/app 
      working_dir: /opt/app 
  

• 如果他們做了更改Dockerfile（例如，他們需要一個新的圖書館），他們可以建立自己的機器（docker-compose build）的圖像，但圖像不是針對註冊表推動。

• 當他們很高興時，他們推送新的代碼（其中包括Dockerfile），CI將構建新的圖像並運行測試。
• CI每次都在同一主機中構建圖像，因此它可以利用緩存。如果Dockerfile沒有更改，則構建不到一秒鐘。
• 當創建新標籤時，CI使用$TAG作爲圖像標籤構建生產圖像。
• 對於生產，我們使用orchestrator，而不是一個Compose YAML。我們不希望在項目存儲庫中存儲可能在docker-compose.yml中的敏感數據。要進行升級，我們只需從註冊表中提取新標籤（我們可以自動執行此操作，但是我還沒有信心在未進行人爲測試之前部署到生產環境中：D）。

當然，您可以在每次開發時創建圖像，但有些項目可能需要很長時間才能構建。例如，Python3 + pandas可能需要25分鐘才能構建，所以如果經常需要在項目之間進行切換，這會讓人感到沮喪。另一方面，拉一張圖片不到一分鐘。

我們使用這種方法，因爲GitLab給我們的CI，書記官處和選手建立圖像和運行測試。你可以不用它，但你需要自己集成所有組件。流程並不完美，但有一些缺點，但在我們的場景中很小。