掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
作者：張春 翻譯 2021-05-13 18:23:53
云計算
云原生 我們都知道每個重大的項目都需要CI/CD，我很確定沒有必要解釋為什么。不過，在決定在何處構(gòu)建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的生命周期。
考慮到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
9090/TCP,8080/TCP 2m13s - service/tekton-pipelines-webhook ClusterIP 10.105.247.0
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
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
9097/TCP 2m24s - service/tekton-pipelines-controller ClusterIP 10.98.218.218
9090/TCP,8080/TCP 6m57s - service/tekton-pipelines-webhook ClusterIP 10.101.192.94
9090/TCP,8008/TCP,443/TCP,8080/TCP 6m57s - service/tekton-triggers-controller ClusterIP 10.98.189.205
9090/TCP 6m56s - service/tekton-triggers-core-interceptors ClusterIP 10.110.47.172
80/TCP 6m56s - service/tekton-triggers-webhook ClusterIP 10.111.209.100
443/TCP 6m56s - NAME CLASS HOSTS ADDRESS PORTS AGE
- ingress.networking.k8s.io/dashboard
* localhost 80 2m24s - NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
- hpa.autoscaling/tekton-pipelines-webhook Deployment/tekton-pipelines-webhook
/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
8080/TCP 8m40s - service/el-http-event-listener ClusterIP 10.98.88.164
8080/TCP 8m40s - NAME CLASS HOSTS ADDRESS PORTS AGE
- ingress.networking.k8s.io/http-listener
* 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
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動版官網(wǎng)