使用Tekton的云原生CI/CD
本文轉(zhuǎn)載自微信公眾號「新鈦云服」,作者張春 翻譯。轉(zhuǎn)載本文請聯(lián)系新鈦云服公眾號。
我們都知道每個重大的項目都需要CI/CD,我很確定沒有必要解釋為什么。不過,在決定在何處構(gòu)建CI/CD時,有很多工具、平臺和解決方案可供選擇。您可以選擇Jenkins、Travis、CircleCI、Bamboo和許多其他的,但是如果您正在為運行在Kubernetes上的云本地應用程序構(gòu)建CI/CD,那么使用適當?shù)墓ぞ咄瑫r運行云本地CI/CD是很有意義的。
其中一個允許您在Kubernetes上本機運行CI/CD的解決方案是Tekton,因此在本文中,我們將開始關于使用Tekton構(gòu)建CI/CD的系列文章,首先介紹、安裝和定制Tekton,以開始我們在Kubernetes上使用云本地CI/CD的旅程。
TL;DR:使用Tekton啟動您的CI/CD所需的所有資源、腳本和文件都可以在https://github.com/MartinHeinz/tekton-kickstarter找到。
正如標題和介紹所暗示的,Tekton是云原生CI/CD工具。它最初是在谷歌開發(fā)的,被稱為Knative管道。它在Kubernetes上作為一組自定義資源(crd)運行,如管道或任務,其生命周期由Tekton的控制器管理。事實上,它本機運行在Kubernetes上,這使它成為管理/構(gòu)建/部署任何部署在Kubernetes上的應用程序和資源的理想選擇。
這表明它適合管理Kubernetes的工作負載,但是為什么不使用其他更流行的工具呢?
常用的CI/CD解決方案,如Jenkins、Travis或Bamboo并不是為了在Kubernetes上運行而構(gòu)建的,或者缺乏與Kubernetes的適當集成。這使得部署、維護和管理CI/CD工具本身以及使用它來部署任何kubernetes本地應用程序變得困難和/或令人煩惱。
另一方面,由于Kubernetes運營商與所有其他容器化應用程序并排在一起,因此Tekton可以非常輕松地進行部署,并且每個Tekton管道都是另一個Kubernetes資源,其管理方式與舊式Pod或Deployments相同。
這也使Tekton可以很好地與GitOps做法配合使用,因為您可以采用所有管道和配置并以git的形式進行維護,而對于至少一種上述工具則不能這么說。資源消耗也是如此-考慮到整個Tekton部署只是幾個pod-與其他CI / CD工具相比,在管道不運行時消耗很少的內(nèi)存和CPU。
話雖如此,很顯然,如果您要在Kubernetes上運行所有工作負載,那么最好在CI / CD中使用一些Kubernetes原生工具。Tekton是唯一的選擇嗎?不,當然,您可以使用其他工具,其中之一就是JenkinsX,這是從本地開始使用Kubernetes進行持續(xù)交付的一種自以為是的方式。
它包含許多工具,如果您對替代工具沒有強烈的偏好,可以使您的生活更輕松,但是如果您要自定義技術(shù)堆棧,也可能會很煩人。盡管JenkinsX仍然在后臺使用Tekton,所以您最好還是學習使用Tekton,然后再決定是否還需要JenkinsX提供的所有其他組件
另一個選擇是Spinnaker,它是一個多云解決方案,已經(jīng)存在了很長一段時間。它使用插件來集成各種各樣的提供商,其中之一就是Kubernetes。但是,它不是一個構(gòu)建引擎——它不提供測試代碼、構(gòu)建應用程序映像或?qū)⑺鼈兺扑偷絩egistry的工具,對于這些任務,您仍然需要一些其他CI工具。
現(xiàn)在,讓我們仔細看看Tekton的組成-Tekton的核心僅包含幾個CustomResourceDefinitions(CRD),它們是Tasks和Pipelines,它們充當TaskRuns和PipelineRuns的藍圖。這四個(加上其他一些即將被棄用或現(xiàn)在不相關的)足以開始運行一些管道和任務。
但是,考慮到大多數(shù)設置都需要構(gòu)建,部署以及因此還需要由某些事件觸發(fā)的管道,通常這還不夠。因此,我們還安裝了Tekton觸發(fā)器,該觸發(fā)器提供了其他資源,即-EventListener,TriggerBinding和TriggerTemplate。這三個資源為我們提供了偵聽特定事件(例如(GitHub)webhooks,CloudEvents或cron作業(yè)發(fā)送的事件)的方式,并啟動了特定的管道。
最后一個(也是非??蛇x的組件)是Tekton Dashboard,它是一個非常簡單的GUI,但是卻是檢查所有CRD(包括任務,管道和觸發(fā)器)的非常方便的工具。它還允許搜索和過濾,這在查找TaskRun和PipelineRun時會很有幫助。您還可以使用它從現(xiàn)有的任務和管道創(chuàng)建TaskRun和PipelineRun。所有這些部分都由控制器部署和Pod管理,這些部署和Pod負責上述CRD的生命周期。
##Setting
考慮到Tekton由多個組件組成,安裝可能會有些復雜,并且可以通過多種方式完成。 通常,您至少要安裝管道和觸發(fā)器,最明顯的方法是使用原始Kubernetes清單安裝它,但是您可以采用更簡單的方法,并從OperatorHub安裝Tekton Operator,后者已經(jīng)包括所有部分。
作為任何安裝方法的前提,我們顯然需要一個集群,在這里,我們將使用KinD(Docker中的Kubernetes)進行本地管道開發(fā)。 我們將為KinD使用以下自定義配置,因為我們將需要部署Ingress控制器并公開端口80/443,以便能夠訪問Tekton Triggers事件偵聽器。
- # kind-tekton.yaml
- kind: Cluster
- apiVersion: kind.x-k8s.io/v1alpha4
- nodes:
- - role: control-plane
- kubeadmConfigPatches:
- - |
- kind: InitConfiguration
- nodeRegistration:
- kubeletExtraArgs:
- node-labels: "ingress-ready=true"
- extraPortMappings:
- - containerPort: 80
- hostPort: 80
- protocol: TCP
- - containerPort: 443
- hostPort: 443
我們可以使用以下命令創(chuàng)建集群:
- ~ $ kind create cluster --name tekton --image=kindest/node:v1.20.2 --config=kind-tekton.yaml
- ~ $ kubectl cluster-info --context kind-tekton
- ~ $ kubectl config set-context kind-tekton
- ~ $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml
- ~ $ kubectl wait --namespace ingress-nginx --for=condition=ready pod --selector=app.kubernetes.io/component=controller --timeout=90s
現(xiàn)在,對于Tekton Pipeline和Triggers的實際部署-我提到了通過Tekton Operator進行安裝,這似乎是最快和最好的方式來啟動和運行預先配置的所有內(nèi)容,但是,該操作員(在撰寫本文時)沒有任何東西。實際文檔,因此您需要進行大量挖掘才能找到有關工作方式的任何解釋,對于我個人而言,這并不是什么大問題。但是,這里真正的問題是,OperatorHub中的Operator不是最新的,我找不到當前的構(gòu)建/映像,這或多或少地使它無用。
我敢肯定,當Tekton Operator更成熟時,這種情況會在某個時候改變(因此請注意它的存儲庫),但是在那之前,應該使用其他安裝選項。如果您恰巧在OpenShift上運行,則可以使用的選項是Red Hat Pipeline Operator,它也是-Kubernetes Operator,但在這種情況下,由Red Hat策劃并為OpenShift定制。只需單擊幾下即可在Web控制臺中安裝它,因此,如果您可以訪問OpenShift群集,則應嘗試一下。
使用此功能的一個缺點是發(fā)行周期較慢,因此您將不得不使用最新版本的Tekton。如果不能選擇OpenShift或只想在Kubernetes上運行,則使用原始清單進行安裝就可以了,這是這樣做的方式:
- ~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml # Deploy pipelines
- ~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml # Deploy triggers
- ~ $ kubectl get svc,deploy --namespace tekton-pipelines --selector=app.kubernetes.io/part-of=tekton-pipelines
- NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
- service/tekton-pipelines-controller ClusterIP 10.106.114.94 <none> 9090/TCP,8080/TCP 2m13s
- service/tekton-pipelines-webhook ClusterIP 10.105.247.0 <none> 9090/TCP,8008/TCP,443/TCP,8080/TCP 2m13s
- NAME READY UP-TO-DATE AVAILABLE AGE
- deployment.apps/tekton-pipelines-controller 1/1 1 1 2m13s
- deployment.apps/tekton-pipelines-webhook 1/1 1 1 2m13s
如果您希望在此安裝中也包含Tekton儀表板,那么您需要再應用一組清單
- ~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/dashboard/latest/tekton-dashboard-release.yaml # Deploy dashboard
- ~ $ kubectl get svc,deploy -n tekton-pipelines --selector=app=tekton-dashboard
- NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
- service/tekton-dashboard ClusterIP 10.111.144.87 <none> 9097/TCP 25s
- NAME READY UP-TO-DATE AVAILABLE AGE
- deployment.apps/tekton-dashboard 1/1 1 1 25s
除此之外,我們還需要額外的入口才能到達儀表盤:
- apiVersion: networking.k8s.io/v1
- kind: Ingress
- metadata:
- name: dashboard
- namespace: tekton-pipelines
- annotations:
- nginx.ingress.kubernetes.io/rewrite-target: '/$2'
- spec:
- rules:
- - http:
- paths:
- - path: /dashboard(/|$)(.*)
- pathType: Prefix
- backend:
- service:
- name: tekton-dashboard
- port:
- number: 9097
默認情況下,先前應用的儀表板資源默認情況下是在tekton-pipelines命名空間中創(chuàng)建的,并且包括使用端口9097的名為tekton-dashboard的服務,這是上面Ingress中引用的值。 此Ingress還具有重寫規(guī)則,以在/ dashboard / ...路徑而不是/處顯示儀表板。
這是因為我們要對事件偵聽器的Webhook使用默認的/(根)路徑(后面將介紹主題)。要驗證Dashboard是否確實處于活動狀態(tài)并且一切都在運行,您可以瀏覽到localhost / dashboard /(假設您正在使用KinD),并且應該看到類似以下內(nèi)容(減去實際管道):
如果所有這些設置似乎都花了很多力氣,那么您可以獲取tekton-kickstarter存儲庫并運行make,一分鐘之內(nèi)即可完成所有上述準備。部署完成后,我們已經(jīng)完成所有(非常)基本的工作,因此,讓我們在CLI中四處看看,看看我們實際使用您所命令的內(nèi)容進行了部署...
探索自定義資源如果按照上述步驟進行操作(或僅使用了啟動存儲庫中的make target),那么您的集群中現(xiàn)在應該有很多新資源。Tekton的所有組件將位于tekton-pipelines名稱空間中,并應包括以下內(nèi)容:
- ~ $ kubectl get deploy,service,ingress,hpa -n tekton-pipelines
- NAME READY UP-TO-DATE AVAILABLE AGE
- deployment.apps/tekton-dashboard 1/1 1 1 2m24s
- deployment.apps/tekton-pipelines-controller 1/1 1 1 6m57s
- deployment.apps/tekton-pipelines-webhook 1/1 1 1 6m57s
- deployment.apps/tekton-triggers-controller 1/1 1 1 6m56s
- deployment.apps/tekton-triggers-core-interceptors 1/1 1 1 6m56s
- deployment.apps/tekton-triggers-webhook 1/1 1 1 6m56s
- NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
- service/tekton-dashboard ClusterIP 10.108.143.42 <none> 9097/TCP 2m24s
- service/tekton-pipelines-controller ClusterIP 10.98.218.218 <none> 9090/TCP,8080/TCP 6m57s
- service/tekton-pipelines-webhook ClusterIP 10.101.192.94 <none> 9090/TCP,8008/TCP,443/TCP,8080/TCP 6m57s
- service/tekton-triggers-controller ClusterIP 10.98.189.205 <none> 9090/TCP 6m56s
- service/tekton-triggers-core-interceptors ClusterIP 10.110.47.172 <none> 80/TCP 6m56s
- service/tekton-triggers-webhook ClusterIP 10.111.209.100 <none> 443/TCP 6m56s
- NAME CLASS HOSTS ADDRESS PORTS AGE
- ingress.networking.k8s.io/dashboard <none> * localhost 80 2m24s
- NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
- hpa.autoscaling/tekton-pipelines-webhook Deployment/tekton-pipelines-webhook <unknown>/100% 1 5 1 6m57s
這些包括所有部署,服務以及自動擴展程序,在請求數(shù)量更多的情況下,它們可以幫助提高可用性。 如果需要HA,那么您也可以查看docs部分,其中介紹了如何配置Tekton for HA。
除了上面顯示的資源之外,您還可以在默認名稱空間中找到事件偵聽器及其資源。 它們可以與核心組件共享名稱空間,但是像這樣拆分它們可以使您根據(jù)使用的應用程序/項目來保持管道及其webhooks的劃分:
- kubectl get deploy,service,ingress,hpa -n default
- NAME READY UP-TO-DATE AVAILABLE AGE
- deployment.apps/el-cron-listener 1/1 1 1 8m40s
- deployment.apps/el-http-event-listener 1/1 1 1 8m40s
- NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
- service/el-cron-listener ClusterIP 10.100.238.60 <none> 8080/TCP 8m40s
- service/el-http-event-listener ClusterIP 10.98.88.164 <none> 8080/TCP 8m40s
- NAME CLASS HOSTS ADDRESS PORTS AGE
- ingress.networking.k8s.io/http-listener <none> * localhost 80 8m40s
Tekton的安裝還帶來了幾個CRD,這些CRD用于管理所有任務,管道和觸發(fā)器:
- kubectl get crd | grep tekton
- clustertasks.tekton.dev 2021-02-27T20:23:35Z
- clustertriggerbindings.triggers.tekton.dev 2021-02-27T20:23:36Z
- conditions.tekton.dev 2021-02-27T20:23:35Z
- eventlisteners.triggers.tekton.dev 2021-02-27T20:23:36Z
- extensions.dashboard.tekton.dev 2021-02-27T20:28:08Z
- pipelineresources.tekton.dev 2021-02-27T20:23:35Z
- pipelineruns.tekton.dev 2021-02-27T20:23:35Z
- pipelines.tekton.dev 2021-02-27T20:23:35Z
- runs.tekton.dev 2021-02-27T20:23:35Z
- taskruns.tekton.dev 2021-02-27T20:23:35Z
- tasks.tekton.dev 2021-02-27T20:23:35Z
- triggerbindings.triggers.tekton.dev 2021-02-27T20:23:36Z
- triggers.triggers.tekton.dev 2021-02-27T20:23:36Z
- triggertemplates.triggers.tekton.dev 2021-02-27T20:23:36Z
您可以使用這些CRD使用kubectl get或kubectl describe列出和檢查任務和管道。對于Kubernetes的每個用戶,與資源進行交互的自然方法是使用kubectl,但是Tekton也擁有自己的CLI工具tkn。 您可以從此發(fā)行頁面下載它。此CLI允許您與Tekton資源進行交互,而不必處理CRD。 例如,您可以列出或檢查管道:
- ~ $ tkn pipeline list
- NAME AGE LAST RUN STARTED DURATION STATUS
- database-backup 12 hours ago job-qxcwc 39 minutes ago 8 minutes Failed
- deploy 12 hours ago --- --- --- ---
- ~ $ tkn pipeline describe deploy
- # ... Long and verbose output
除了檢查資源,你還可以使用它來啟動taskrun或PipelineRuns,然后讀取日志,而不需要查找單個的pod:
- ~ $ tkn task start send-to-webhook-slack
- ? Value for param `webhook-secret` of type `string`? slack-webhook
- ? Value for param `message` of type `string`? Hello There!
- TaskRun started: send-to-webhook-slack-run-d5sxv
- In order to track the TaskRun progress run:
- tkn taskrun logs send-to-webhook-slack-run-d5sxv -f -n default
- ~ $ tkn taskrun logs send-to-webhook-slack-run-d5sxv -f -n default
- [post] % Total % Received % Xferd Average Speed Time Time Time Current
- [post] Dload Upload Total Spent Left Speed
- 100 23 0 0 100 23 0 111 --:--:-- --:--:-- --:--:-- 111
正如您在上面看到的,如果您一開始沒有指定參數(shù),它甚至會提示您輸入?yún)?shù)!
不過,有一件事讓我非常惱火,那就是與kubectl相比,這個CLI工具使用的參數(shù)順序相反。kubectl的順序是kubectl ,而tkn是tkn ,這是一個非常方便的工具。
*本文翻譯自https://martinheinz.dev/blog/45