翻譯 | 緻Great
Jenkins X的無伺服器風格，或者有人稱之為Jenkins X Next Generation，試圖重新定義我們如何在Kubernetes叢集中進行持續傳遞和GitOps。
它通過将相當多的工具組合成一個易于使用的捆綁包來實作這一點。絕大多數使用者，無需了解相關元件獨立運作的複雜性，也無需了解它們是如何內建的。隻需将版本疊代推向Git，其餘工作都會由系統自動完成。
為了一窺究竟，接下來就讓我們一同探索，無伺服器Jenkins X平台中涉及的流程群組件。通過了解一項任務從Git webhook起始的流動，将會幫助我們對其工作原理有更加深入的了解。同時，也會在我們接下來深入介紹各個全新元件時，提供幫助。
就像靜态Jenkins一樣，一切都起始于向Git庫的一次push操作。随後，一個webhook請求被發送至叢集中。不同的是，并沒有用來接收這些請求的Jenkins。相反，我們有Prow。它會做很多事情，但在webhook這個場景下，它的工作是接收請求并決定下一步該做什麼。這些請求不僅限于push操作，還包含了我們可以通過pull request評論指定的斜杠指令（例如/approve）。
Prow由幾個不同的元件組成（例如，Deck，Hook，Crier，Tide等等）。然而，我們并不會深入介紹各個元件的職責。此刻，最需要留意的重要事項是Prow是群集的入口。它接收所有的Git請求，包含産生于Git動作的（例如push）與産生于評論中斜杠指令的。
Prow在收到請求後可能會做很多事情。如果它來自Git注釋中的指令，它可能會重新運作測試，合并拉取請求，配置設定人員或許多其他Git相關操作之一。如果webhook通知它已經進行了新的推送，它将向Jenkins X Pipeline Operator發送一個請求，該請求将確定運作與定義的管道相對應的建構。最後，Prow還向Git報告了建構的狀态。
這些特征并不是Prow可能執行的唯一動作類型，但是現在，你可能得到了一般的Gist。Prow負責Git與叢集内部流程之間的通信。
當Prow Hook收到來自Git webhook的請求時，它會将其轉發給Jenkins X Pipeline Operator。Operator的職責是從庫中取回用于初始化流程的jenkins-x.yml檔案，并将其轉換為Tekton Tasks和Pipelines。反過來，它們定義了将變更push到Git後，應該被執行的完整流水線。
Pipeline Operator存在的原因是為了簡化我們持續傳遞流程的定義。Tekton完成了繁重的工作，但這是一個非常低級的解決方案。它不應該直接使用。編寫Tekton定義可能非常痛苦和複雜。Pipeline Operator通過易于學習和使用YAML格式來定義管道簡化了這一過程。
Tekton為每次推送建立一個PipelineRun，每次推送都發送到一個相關的分支（例如，master分支，PR等），同時執行驗證推送所需的所有步驟。Tekton運作測試，在系統資料庫中存儲二進制檔案（例如，Docker Registry，Nexus和ChartMuseum），并将釋出部署到臨時（PR）或永久（臨時或生産）環境。
完整的流程如下圖所示：
正如上面已經提到的，并非每個人都需要了解事件的流程，也不需要深入了解流程中涉及的所有元件。對于大多數使用者來說，唯一需要了解的是，将更改推送到Git将導緻執行jenkins-x.yml管道中定義的建構。這就是Jenkins X的美麗。它通過簡化複雜的過程簡化了我們的生活。
本文節選自《DevOps 2.6工具包：Jenkins X》一書。
原文連結：https://technologyconversations.com/2019/04/15/going-serverless-with-jenkins-x-exploring-prow-jenkins-x-pipeline-operator-and-tekton/