是我們的開源 GitOps CLI 實用程序，用於建立應用程式並將其交付到 Kubernetes。 按照承諾， 標誌著向werf添加新功能和修改傳統方法的開始。 現在我們很高興推出 v1.1 版本，這是開發的一大步，也是未來的基礎 集電極 韋爾夫。 該版本目前可用 .
此版本的基礎是新的階段儲存架構和兩個收集器（針對 Stapel 和 Dockerfile）工作的最佳化。 新的儲存架構開啟了從多個主機實作分散式組件以及在同一主機上實現平行組件的可能性。
工作的最佳化包括在計算階段簽章階段消除不必要的計算，並將計算檔案校驗和的機制變更為更有效的機制。 此最佳化減少了使用 werf 建置專案的平均時間。 當所有階段都存在於快取中時，進行空閒構建 階段儲存，現在速度真的很快。 大多數情況下，重新啟動建置將花費不到 1 秒的時間！ 這也適用於驗證團隊工作過程中各個階段的程序。 werf deploy и werf run.
此外，在此版本中，還出現了按內容標記圖像的策略 - 基於內容的標籤，現在預設啟用，也是唯一推薦的。
讓我們仔細看看werf v1.1的關鍵創新，同時告訴您未來的計畫。
werf v1.1 發生了什麼變化？
用於從快取中選擇階段的新階段命名格式和演算法
新的藝名生成規則。 現在，每個階段建置都會產生一個唯一的階段名稱，該名稱由兩部分組成：簽名（與 v2 中一樣）加上唯一的臨時識別碼。
例如，完整的舞台圖像名稱可能如下所示：
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
……或者一般來說：
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
在這裡：
-
SIGNATURE是一個階段簽名，它代表階段內容的標識符，並且取決於導致該內容的 Git 編輯歷史記錄； -
TIMESTAMP_MILLISEC是建構新影像時產生的有保證的唯一影像識別碼。
從快取中選擇階段的演算法是基於檢查 Git 提交的關係：
- Werf 計算某個階段的簽章。
- В 階段儲存 對於給定的簽名可能有幾個階段。 Werf 選擇與簽章相符的所有階段。
- 如果當前階段連結到 Git（git-archive，帶有 Git 補丁的自訂階段：
install,beforeSetup,setup; 或 git-latest-patch），然後 werf 僅選擇與作為當前提交（為其呼叫構建）的祖先的提交關聯的那些階段。 - 從剩餘的合適階段中選擇一個 - 按建立日期最舊的階段。
不同 Git 分支的階段可以有相同的簽章。 但 werf 將阻止與不同分支關聯的快取在這些分支之間使用，即使簽章匹配。
.
在舞台儲存中創建和保存舞台的新演算法
如果在從快取中選擇階段時，werf沒有找到合適的階段，則啟動組裝新階段的過程。
請注意，多個進程（在一台或多台主機上）可以大約在同一時間開始建置相同階段。 Werf 使用樂觀阻塞演算法 階段儲存 將新收集的圖像保存在 階段儲存。 這樣，當新階段建置準備就緒時，werf 就會阻塞 階段儲存 僅當合適的圖像不再存在時才保存新收集的圖像 （透過簽章和其他參數 - 請參閱從快取中選擇階段的新演算法）.
保證新組裝的圖像具有唯一的識別符 TIMESTAMP_MILLISEC （請參閱新的階段命名格式）。 萬一在 階段儲存 將找到合適的圖像，werf 將丟棄新編譯的圖像並使用快取中的圖像。
換句話說：完成建構影像的第一個進程（最快的進程）將有權將其儲存在階段儲存中（然後這個單一影像將用於所有建置）。 緩慢的建置過程永遠不會阻止更快的過程保存當前階段的建置結果並繼續下一個建置。
.
改進了 Dockerfile 建構器的性能
目前，從 Dockerfile 建置的映像的階段管道由一個階段組成 - dockerfile。 計算簽章時，計算檔案的校驗和 context，這將在組裝過程中使用。 在此改進之前，werf 遞歸地遍歷所有文件，並透過對每個文件的上下文和模式求和來獲得校驗和。 從 v1.1 開始，werf 可以使用儲存在 Git 儲存庫中的計算校驗和。
該演算法基於 。 該演算法考慮了中的記錄 .dockerignore 並僅在必要時遞歸遍歷文件樹。 因此，我們已經與讀取檔案系統以及演算法對大小的依賴解耦了 context 並不重要。
該演算法還會檢查未追蹤的文件，並在必要時將其納入校驗和中。
改進了導入檔案時的效能
werf v1.1 的版本在下列情況下使用 rsync 伺服器： 。 以前，導入是使用主機系統的目錄掛載分兩步驟完成的。
macOS 上的匯入效能不再受到 Docker 磁碟區的限制，並且匯入在與 Linux 和 Windows 相同的時間內完成。
基於內容的標記
Werf v1.1 支援所謂的按圖像內容標記 - 基於內容的標籤。 產生的 Docker 映像的標籤取決於這些映像的內容。
運行命令時 werf publish --tags-by-stages-signature 或 werf ci-env --tagging-strategy=stages-signature 發布的所謂的圖像 舞台簽名 圖像。 每張圖像都標記有自己的該圖像的各個階段的簽名，該簽名是按照與每個階段的常規簽名相同的規則分別計算的，但它是圖像的通用標識符。
影像階段的簽名取決於：
- 該圖像的內容；
- 導致此內容的 Git 變更的歷史。
Git 儲存庫始終具有不會更改影像檔案內容的虛擬提交。 例如，僅包含註釋的提交或合併提交，或變更 Git 中不會匯入映像中的檔案的提交。
當使用基於內容的標記時，即使鏡像的內容沒有改變，由於鏡像名稱的變化而導致 Kubernetes 中的應用程式 Pod 不必要重啟的問題也得到了解決。 順便說一句，這是阻止將一個應用程式的許多微服務儲存在單一 Git 儲存庫中的原因之一。
此外，基於內容的標記是比在 Git 分支上標記更可靠的標記方法，因為產生的影像的內容不依賴 CI 系統中用於組裝同一分支的多個提交的管道的執行順序。
這一點很重要: 從現在開始 階段簽名 - 唯一推薦的標記策略。 它將在命令中預設使用 werf ci-env （除非您明確指定不同的標記方案）。
。 還將有一份單獨的出版物專門介紹此功能。 更新 （3 月 XNUMX 日）：詳細文章 .
記錄層級
用戶現在有機會控制輸出、設定日誌記錄等級並使用偵錯資訊。 新增選項 --log-quiet, --log-verbose, --log-debug.
預設情況下，輸出包含最少資訊：
當使用詳細輸出時（--log-verbose）你可以看到 werf 是如何運作的：
詳細輸出（--log-debug），除了werf調試資訊外，還包含使用過的庫的日誌。 例如，您可以查看與 Docker 註冊表的互動是如何發生的，也可以記錄花費大量時間的地方：
未來的計劃
警告！ 下面描述的選項已標記 v1.1 將在此版本中提供，其中許多將在不久的將來提供。 更新將透過自動更新進行 。 這些功能不會影響 v1.1 功能的穩定部分；它們的出現不需要使用者手動幹預現有配置。
完全支援各種 Docker 註冊表實現（新）
- 版本：v1.1
- 日期：三月
目標是讓使用者在使用 werf 時不受限制地使用自訂實作。
目前，我們已經確定了以下一組解決方案，我們將保證全力支持：
- 預設（庫/註冊表）*，
- AWS ECR
- 天藍色*,
- 碼頭工人中心
- GCR*，
- GitHub 包
- 亞搏體育appGitLab註冊表*，
- 港口*，
- 碼頭。
目前 werf 完全支援的解決方案標有星號。 對其他人來說，有支持，但有限制。
可以確定兩個主要問題：
- 某些解決方案不支援使用 Docker 註冊表 API 刪除標籤，從而阻止使用者使用 werf 的自動清理功能。 對於 AWS ECR、Docker Hub 和 GitHub 套件來說也是如此。
- 某些解決方案不支援所謂的巢狀儲存庫（Docker Hub、GitHub Packages 和 Quay），但使用者必須使用 UI 或 API (AWS ECR) 手動建立它們。
我們將使用解決方案的本機 API 來解決這些問題和其他問題。 這項任務還包括覆蓋造船操作的整個週期，並對每個週期進行測試。
分散式鏡像建構 (↑)
- 版本：v1.2 v1.1（提高了實現該功能的優先權）
- 日期：三月至四月
目前，werf v1.0和v1.1只能在一台專用主機上使用，用於建置和發布鏡像以及將應用程式部署到Kubernetes的操作。
為了開啟werf 分散式工作的可能性，當Kubernetes 中的應用程式的建置和部署在多個任意主機上啟動並且這些主機在建置之間（臨時執行器）不保存其狀態時，werf 需要實作使用下列功能的能力： Docker 註冊表作為暫存。
此前，當werf計畫還叫dapp時，就有這樣的機會。 然而，我們在 werf 中實現此功能時遇到了一些需要考慮的問題。
注意。 此功能不需要收集器在 Kubernetes Pod 內部工作，因為為此，需要擺脫對本機 Docker 伺服器的依賴（在 Kubernetes pod 中是無法存取本機 Docker 伺服器的，因為進程本身是在容器中運行的，而 werf 不支援也不會支援）透過網路與Docker 伺服器一起工作）。 對運行 Kubernetes 的支援將單獨實作。
對 GitHub Actions 的官方支援（新）
- 版本：v1.1
- 日期：三月
包括 werf 文件（部分 參考 и 說明），以及使用 werf 的官方 GitHub Action。
此外，它還允許 werf 處理臨時運行器。
使用者與 CI 系統互動的機制將基於在拉取請求上放置標籤以啟動某些操作來建立/推出應用程式。
使用werf本地開發和部署應用程式(↓)
- 版本：v1.1
- 日期：一月至二月
主要目標是實現用於在本地和生產中部署應用程式的單一統一配置，無需複雜的操作，開箱即用。
werf還需要有一種操作模式，可以方便地編輯應用程式程式碼並立即接收正在運行的應用程式的回饋以進行偵錯。
新的清潔演算法（NEW）
- 版本：v1.1
- 日期：四月
在目前版本的werf v1.1中的程序 cleanup 基於內容的標記方案沒有提供清理影像的規定 - 這些影像會累積。
此外，目前版本的 werf（v1.0 和 v1.1）對在標記方案下發布的映像使用不同的清理策略：Git 分支、Git 標記或 Git 提交。
發明了一種基於 Git 提交歷史記錄的新影像清理演算法，該演算法對所有標記方案進行統一：
- 為每個 git HEAD（分支和標籤）保留與 N1 個最新提交相關聯的 N2 個以上圖像。
- 為每個 git HEAD（分支和標籤）儲存與 N1 個最新提交相關的 N2 個階段影像。
- 儲存任何 Kubernetes 叢集資源中使用的所有映像（設定檔和命名空間的所有 kube 上下文都會被掃描；您可以使用特殊選項限制此行為）。
- 儲存 Helm 版本中儲存的資源配置清單中所使用的所有影像。
- 如果某個鏡像未與 git 中的任何 HEAD 關聯（例如，因為相應的 HEAD 本身已被刪除）並且未在 Kubernetes 叢集和 Helm 版本中的任何清單中使用，則可以將其刪除。
並行影像建置（↓）
- 版本：v1.1
- 日期：一月至二月 四月*
目前版本的 werf 收集中所述的圖像和工件 werf.yaml，依序。 有必要並行化組裝影像和工件的獨立階段的過程，並提供方便且資訊豐富的輸出。
* 注意：由於實現分散式組裝的優先順序增加，截止日期已發生變化，這將增加更多的水平擴展功能，以及將 werf 與 GitHub Actions 結合使用。 並行組裝是下一個最佳化步驟，在組裝一個專案時提供垂直可擴展性。
過渡到 Helm 3 (↓)
- 版本：v1.2
- 日期：二月至三月
包括遷移到新的程式碼庫 以及一種經過驗證的、便捷的方式來遷移現有的安裝。
* 注意：切換到 Helm 3 不會為 werf 添加重要功能，因為 Helm 3 的所有關鍵功能（3 路合併和無操作器）已在 werf 中實現。 此外，werf還有 除了那些指出的之外。 然而，這項轉變仍在我們的計劃中並將予以實施。
用於描述 Kubernetes 配置的 Jsonnet (↓)
- 版本：v1.2
- 日期： 一月至二月 四月至五月
Werf 將支援 Jsonnet 格式的 Kubernetes 設定描述。 同時，werf 將保持與 Helm 的兼容性，並且可以選擇描述格式。
原因是許多人認為 Go 模板的入門門檻很高，而且這些模板程式碼的可理解性也受到影響。
引入其他 Kubernetes 配置描述系統（例如 Kustomize）的可能性也在考慮之中。
在 Kubernetes 內部工作 (↓)
- 版本：v1.2
- 日期： 四月至五月 五月至六月
目標：確保使用 Kubernetes 中的運行器建立鏡像並交付應用程式。 那些。 可以直接從 Kubernetes Pod 建置、發布、清理和部署新鏡像。
要實現這個能力，首先需要能夠建構分散式鏡像 （見上一點）.
它還需要支援建構器在沒有 Docker 伺服器的情況下的操作模式（即類似 Kaniko 的建置或在使用者空間中建置）。
Werf 不僅支援使用 Dockerfile 在 Kubernetes 上進行構建，還支援使用具有增量重建功能的 Stapel 建構器和 Ansible。
邁向開放發展
我們熱愛我們的社區（, ）並且我們希望越來越多的人幫助werf變得更好，了解我們前進的方向，並參與到開發中。
最近決定改用 為了揭示我們團隊的工作流程。 現在您可以看到近期計劃以及以下領域的當前工作：
- ;
- ;
- ;
- .
針對以下問題，我們做了很多工作：
- 刪除了不相關的。
- 現有的內容被採用單一格式，並具有足夠數量的細節和細節。
- 新增了有關想法和建議的新問題。
如何啟用v1.1版本
該版本目前可用 （在頻道中 穩定 и 堅如磐石 然而，隨著穩定的發生，釋放將會出現 ea 本身已經足夠穩定可以使用，因為透過管道 阿爾法 и 測試）。 活性 透過以下方式：
source $(multiwerf use 1.1 ea)
werf COMMAND ...結論
Stapel 和 Dockerfile 建構器的新階段儲存架構和建構器最佳化開啟了在 werf 中實現分散式和平行建置的可能性。 這些功能很快就會出現在同一個 v1.1 版本中，並將透過自動更新機制自動可用（對於用戶 ).
在這個版本中，加入了基於圖像內容的標記策略— 基於內容的標籤，這已成為預設策略。 主命令日誌也已重新設計： werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
下一個重要步驟是新增分散式組件。 自v1.0 以來，分散式建置已成為比並行建置更高的優先級，因為它們為werf 增加了更多價值：建構器的垂直擴展和對各種CI/CD 系統中的臨時建構器的支持，以及為GitHub Actions 提供官方支援的能力。 因此，並行組裝的實施期限發生了變化。 然而，我們正在努力盡快實現這兩種可能性。
關注新聞！ 並且不要忘記訪問我們 要建立一個問題，找到一個現有的問題並加上一個加號，建立一個 PR，或只是觀察專案的開發。
聚苯乙烯
另請閱讀我們的博客：
- «»
- «“;
- 關於werf創新的一系列註解：
- «“;
- «“;
- «“;
- «“。
來源： www.habr.com