遲到總比不到好。該故事講關于我們因不支持使用常規的Dockerfile來構建鏡像導致我們差點犯了一個重大錯誤。Werf[1]是一個GitOps工具，可以很好地集成到任何CI/CD系統中，并提供完整的應用程序生命周期管理，允許你：

• 構建和推送鏡像

• 部署應用程序到Kubernetes中

• 根據策略清理未使用鏡像

我們工具的理念是：將低級手段組合到一個統一的系統中讓DevOps工程師控制應用程序。盡可能使用現有的即用型工具(如Helm和Docker)。但是如果沒有合適的任務解決方案呢？答案很簡單，我們自己編寫并維護工具來完成工作。背景：自定義鏡像構建器

Werf鏡像構建器也發生了同樣的故事。Dockerfile是描述構建鏡像過程的事實標準，但我們的需求受到很大限制。這個問題在我們項目的早期階段變得至關重要。在開發用于容器化應用的工具時，我們很快意識到Dockerfile不適合以下特定任務：

遵循構建典型小型Web應用程序的標準工作流程：a)安裝系統范圍的應用程序依賴項，b)安裝特定于應用程序的庫，c)構建資產(assets)，d)最重要的部分，快速高效地更新鏡像中的代碼。

構建器在發生更改時應通過提交修補應用于修改的文件來創建新的鏡像層。

如果某些文件已被修改，則必須重建依賴階段。

這是我們一開始的需求列表，在今天我們的構建器有著許多額外的功能。總而言之，我們沒花多長時間就開始使用首選編程語言開發自定義DSL(見下文)。它必須滿足既定目標，根據文件描述分階段的構建過程并確定不同階段間的依賴。它由相應的那些可將DSL轉變成最終目標的構建器，即即用型Docker鏡像補充。一開始我們使用Ruby實現了DSL，在切換到Golang之后我們用YAML文件形式重寫了它。

Werf的Ruby的配置，這是舊的版本(此時項目被稱為dapp)

Werf的YAML形式配置，這是現在的版本構建器的概念隨時間推移一直在變化。在一開始，我們只是簡單地使用我們的配置動態地生成一些臨時的Dockerfile，然后我們在臨時容器中運行構建指令并進行提交。注意：目前我們使用YAML配置的Stapel構建器(如上所示)已經發展成一個相當強大的工具。雖然它值得一篇文章來詳細描述其本身，但你現在可以先在該文檔[2]中找到更多詳細信息。等一下！

不久之后，我們發現了一個嚴重的錯誤，那就是我們沒有添加使用標準Dockerfiles構建鏡像的能力，我們將它們集成到已建立的基礎架構中以進行完整的應用程序管理(即用于構建，部署和刪除鏡像)。“我們怎么可能在沒有支持Dockerfile的情況下打造為Kubernetes部署鏡像的工具，這是否是一種描述大多數項目鏡像的流行方式？”這個問題依舊困擾著我們。我們沒有回答該問題，而是提出了解決方案。如果你已經有了一個Dockerfile(或一組Dockerfile)且想使用werf呢？注意：順便問一下，你為何要使用werf？至少，它有各種很好的功能來增強和粘合你的CI/CD流程，例如：

• 完整的應用程序管理周期，包括刪除鏡像

• 在單個配置中構建多個鏡像的能力

• 改進的部署Helm兼容圖表的流程

完整的功能列表請點擊項目頁面[3]。因此，直至最近，如果你對使用werf感興趣，我們還希望你將Dockerfiles移植到我們的配置格式。但是現在我們很高興地告訴你，“讓werf來構建你的Dockerfiles吧！”用法

此功能的首次完整實現在werf的v1.0.3-beta.1版本引入。一般流程非常簡單，即用戶在werf配置中指定已存在的Dockerfile的路徑，然后使用werf build命令啟動werf。然后就沒有然后了，werf將會構建鏡像。以下是一個例子。我們在應用的根目錄中定義 Dockerfile：

FROM ubuntu:18.04

RUN echo Building ...

然后我們定義 werf.yaml它將引用上面的 Dockerfile：

configVersion: 1

project: dockerfile-example

---

image: ~

dockerfile: ./Dockerfile

然后我們就可以執行werf build了：

順便說下，你也可以這樣定義werf.yaml以使用多個Dockerfile同時構建鏡像：

configVersion: 1

project: dockerfile-example

---

image: backend

dockerfile: ./dockerfiles/Dockerfile-backend

---

image: frontend

dockerfile: ./dockerfiles/Dockerfile-frontend

Werf配置中同樣支持傳遞額外的構建參數，例如--build-arg和--add-host等。以下是完整Dockerfile鏡像配置的鏈接[4]。它是如何運作的？

在構建鏡像期間，本地層的通用Docker緩存處于活動狀態。重要的是，werf還將Dockerfile配置集成到其基礎架構中。這意味著什么？

所有使用Dockerfile構建的鏡像都包含一個特定的名為dockerfile的階段。(可以在werf文檔中[5]了解“階段”相關內容)

在dockerfile階段，werf會根據Dockerfile配置中的內容計算出簽名。Dockerfile配置的改變將會引起dockerfile階段的簽名改變。在這種情況下，werf使用新的Dockerfile配置啟動此階段的重建。如果簽名保持不變，則werf使用緩存的鏡像。

你可是使用werf publish或werf build-and-publish發布構建出來的鏡像并將其部署到Kubernetes中。已推送到Docker倉庫的鏡像會通過常規werf機制進行清理。這意味著舊鏡像(超過N天)和與不存在的Git分支相關聯的鏡像將被自動刪除，且可以應用其他策略。

你可以在相應的文檔中了解有關這些werf特性的更多信息：

• 發布過程[6]；

• 與Kubernetes的部署過程集成[7]；

• 清理過程[8]。

提示和警告

1. 指令ADD不支持外部URL當前ADD參數不能支持外部的URL。Werf不會啟動重建過程以響應指定URL處的資源更改。我們計劃很快添加此功能。2. 不能將.git目錄包含到鏡像中事實上，將.git目錄添加到你的容器鏡像中不是個好主意，原因如下：

• .git目錄在最終鏡像中的存在違反了12要素應用理念。最終鏡像必須與單個提交鏈接；不應允許其在任意提交上執行git checkout。

• .git目錄增大了鏡像的體積(Git倉庫可能會因為曾經添加刪除過大文件而增大)。相反地，每個特定提交對工作樹大小將不依賴于Git操作的歷史。此外，.git目錄從最終鏡像中添加以及后續的刪除，文件夾將不再起作用，因為無論如何都將生成新的層次(這正是Docker的工作原理)。

• 即使正在處理相同的提交(源自不同的工作樹)，Docker也可能啟動不必要的重建。例如，GitLab在/home/gitlab-runner/builds/HASH/[0-N]/yourproject啟用并行構建時創建單獨的克隆文件夾。不必要的重建是由.git同一存儲庫的各種克隆版本中的文件夾的差異引起的(即使我們構建完全相同的提交)。

最后一點直接影響了werf的使用。Werf需要構建緩存來運行某些命令(例如werf deploy)。執行這些命令時，werf會為werf.yaml文件中指定的鏡像計算各階段簽名，因此它們必須存在于構建緩存中，否則命令將會失敗。.git內容在簽名階段的依賴意味著緩存容易受到無關文件的影響，這是werf無法容忍的錯誤(更多細節[9])。無論如何，通過ADD和COPY指令添加特定和需要的文件仍然是一個很好的做法。它提高了創建的效率和所創建的Dockerfile的可靠性，并提高了緩存(通過上述內容構建Dockerfile)對Git中無關的更改的彈性。總結

我們為特定需求制作自定義構建器之路是艱難的，誠實的和直接的：我們傾向于使用自定義語法開發自己的解決方案，而不是將解決方法置于默認Dockerfile之上。這種方法有其優勢：Stapel構建器就做得很好！但是，在創建自定義鏡像構建器時，我們完全忽略了應用現有Dockerfiles的情況。這個漏洞現在已經解決了。在未來，我們計劃加強對Dockerfiles的支持以及我們的定制Stapel構建器，用于分布式構建和在Kubernetes集群內構建鏡像(即通過使用類似于kaniko的Kubernetes中的運行程序)。所以，如果你碰巧有一些好的Dockerfiles，不要猶豫，快來嘗試werf[1]吧！相關鏈接：

https://github.com/flant/werf

https://werf.io/documentation/reference/build_process.html#stapel-image-and-artifact

https://github.com/flant/werf#complete-features-list

https://werf.io/documentation/configuration/dockerfile_image.html

https://werf.io/documentation/reference/stages_and_images.html#stages

https://werf.io/documentation/reference/publish_process.html

https://werf.io/documentation/reference/deploy_process/deploy_into_kubernetes.html#integration-with-built-images

https://werf.io/documentation/reference/cleaning_process.html

https://werf.io/documentation/reference/stages_and_images.html

原文鏈接：https://medium.com/flant-com/werf-dockerfile-support-e6504211b8e6Kubernetes入實戰培訓

Kubernetes入門與實戰培訓將于2019年11月29日在深圳開課，3天時間帶你系統掌握Kubernetes，學習效果不好可以繼續學習。本次培訓包括：云原生介紹、微服務；Docker基礎、Docker工作原理、鏡像、網絡、存儲、數據卷、安全；Kubernetes架構、核心組件、常用對象、網絡、存儲、認證、服務發現、調度和服務質量保證、日志、監控、告警、Helm、實踐案例等等，點擊下方圖片或者閱讀原文鏈接查看詳情。

總結

以上是生活随笔為你收集整理的dockerfile cd目录_使用Werf和现有的Dockerfiles改善你的CI/CD体验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。