— 我們的開源 GitOps CLI 實用程序，用於建置和向 Kubernetes 交付應用程式。正如承諾的那樣， 標誌著 werf 開始添加新功能並改進其常用方法。現在，我們很高興地宣布 v1.1 版本的發布，這是開發過程中的一大步，也是為未來儲備的。 集電極 werf。該版本目前可用 .
此版本的核心在於階段儲存的新架構以及兩種建構器（針對 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 Registry 的互動方式，並記錄耗費大量時間的位置：
未來計劃
警告！ 以下功能與註釋一起描述 v1.1 已在此版本中提供，其中許多功能將在不久的將來推出。更新將透過自動更新進行 。這些功能不會影響 v1.1 功能的穩定部分，它們的出現不會需要使用者對現有配置進行手動幹預。
全面支援各種 Docker Registry 實作（新）
- 版本：v1.1
- 日期：三月
目標是讓使用者在使用 werf 時能夠不受限制地使用自訂實作。
目前，我們已經確定了以下一系列解決方案，並打算保證提供全力支援：
- 預設（庫/註冊表）*，
- AWS ECR，
- Azure*，
- Docker 中心，
- 大中華區零售*
- GitHub 包，
- GitLab 註冊表*，
- 港口*，
- 碼頭。
標有星號的解決方案是目前 werf 完全支援的解決方案。其餘解決方案也受支持，但有限制。
主要有兩個問題：
- 某些解決方案不支援使用 Docker Registry API 刪除標籤，這會阻止使用者使用 werf 中實作的自動清理功能。 AWS ECR、Docker Hub 和 GitHub Packages 都是如此。
- 有些解決方案不支援所謂的巢狀儲存庫（Docker Hub、GitHub Packages 和 Quay）或支援它們，但使用者必須使用 UI 或 API（AWS ECR）手動建立它們。
我們將使用解決方案的原生 API 來解決這些問題和其他問題。這項任務還包括對整個 werf 工作週期進行測試，並針對每個問題進行測試。
分散式影像組裝（↑）
- 版本：v1.2 v1.1（此功能實現優先權已提高）
- 日期：三月至四月 三月
目前，werf v1.0 和 v1.1 只能在一個專用主機上用於鏡像建置和發布操作以及應用程式部署到 Kubernetes。
為了開啟 werf 分散式操作的可能性，當 Kubernetes 中的應用程式的組裝和部署在多個任意主機上啟動，並且這些主機在建置（臨時運行器）之間不保存其狀態時，werf 需要實現使用 Docker Registry 作為階段儲存的能力。
在此之前，當 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 的所有關鍵功能（三向合併和無 Tiller）都已在 Werf 中實現。此外，Werf 還 除了上述提到的之外。但是，這一轉變仍在我們的計劃中，並將得到實施。
用於描述 Kubernetes 配置的 Jsonnet（↓）
- 版本：v1.2
- 日期：一月至二月 四月至五月
Werf 將支援 Jsonnet 格式的 Kubernetes 設定描述。同時，werf 將保持與 Helm 的兼容，並提供選擇描述格式的選項。
原因在於，許多人認為 Go 的模板學習起來難度較高，而且這些模板背後程式碼的可理解性也較差。
也考慮實作其他 Kubernetes 配置描述系統（例如 Kustomize）的可能性。
在 Kubernetes 內部工作（↓）
- 版本：v1.2
- 日期：4月至5月 5月至6月
目標：使用 Kubernetes 中的運行器 (runner) 實現鏡像組裝和應用程式交付。也就是說，可以直接從 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
