Tekton Pipeline ist ein neues Projekt, mit dem Sie CI / CD-Pipelines nach dem Kubernetes-Ansatz ausführen können. Tekton Pipelines war ursprünglich Teil des Projekts „Knative build“. Wenn Sie mehr über dieses Projekt erfahren möchten, empfehle ich den Besuch der Website, die unter dem Link hier verfügbar ist .
Bevor wir darüber sprechen, was Kubernetes-native bedeutet und wie Tekton Pipeline funktioniert, möchte ich einen Schritt zurücktreten und kurz erläutern, warum das Ausführen von Pipelines in Containern und nicht auf dem Host so wichtig und nützlich ist: Vor einiger Zeit Wir haben begonnen, die Anwendungen, mit denen wir arbeiten, in Container zu übertragen. Wir haben dies aufgrund von Vorteilen wie Isolation, transparenten Abhängigkeiten, Skalierbarkeit und Unveränderlichkeit getan. Wäre das nicht genauso nützlich für CI / CD-Pipelines? Stellen Sie sich "Build-Hosts" vor, die die Tools und Abhängigkeiten bereitstellen, die für eine bestimmte Build-Aufgabe benötigt werden. Informationen zu einer Umgebung, die bei jedem Start gleich ist und keine Abhängigkeiten zu anderen Projekten aufweist, die Probleme verursachen könnten. Und auch über das einfache Skalieren von Pipelines. Deshalb können und sollten wir containerisierte Pipelines betreiben!
Nachdem wir uns kurz mit der Containerisierung von Pipelines befasst haben, wollen wir nun erläutern, wie das Tekton-Pipeline-Projekt mit seinem nativen Kubernetes-Ansatz helfen kann:
Mit Tekton Pipeline können wir Container-Pipelines in unseren vorhandenen Kubernetes-Clustern betreiben. Dies bedeutet, dass wir keine zusätzlichen Maschinen für den Betrieb unserer Pipelines benötigen und daher die vorhandenen Maschinen besser nutzen können.
Es ist großartig, aber um ehrlich zu sein, das macht die Tekton-Pipeline nicht einzigartig. Daher geht Tekton Pipeline noch einen Schritt weiter und speichert alles, was mit unseren Pipelines zu tun hat, in Kubernetes - als Kubernetes-Ressource. Auf diese Weise können wir mit unseren Förderbändern sowie mit jeder anderen Ressource arbeiten. Denken Sie an Deployment oder Service, die Sie mithilfe von Kubectl- und YAML-Dateien erstellen und verwalten können.
Wo soll ich anfangen?
Wie oben erwähnt, befindet sich die Tekton-Pipeline im Kubernetes-Cluster. Es basiert auf 5 benutzerdefinierten Ressourcendefinitionen (Custom Resource Definitions, CRDs), Bereitstellungen, ConfigMaps und Diensten. Sie können den folgenden Befehl ausführen, um zu starten:
kubectl apply -f https://storage.googleapis.com/tekton-releases/latest/release.yaml
Zusätzlich zu den oben genannten Ressourcen erstellt er auch Namespace, Pod-Sicherheitsrichtlinie, Dienstkonto und ClusterRoles. Die Tekton-Pipeline ist betriebsbereit, sobald alle Pods im neu erstellten Namespace (der Standardname lautet tekton-pipelines) bereit sind.
Natürlich können Sie diese YAML-Datei anzeigen und an Ihre Bedürfnisse anpassen.
Wenn Sie Artefakte oder andere Pipelineressourcen für Aufgaben freigeben müssen, müssen Sie Speicher für diese einrichten. Sie können PVC verwenden, das jedes Mal angefordert wird, wenn es erforderlich ist (dynamische Volumeninitialisierung ist der Schlüssel!) Oder Blob-Speicherung. Weitere Informationen zu dieser Aufgabe finden Sie hier .
Erste Pipeline
Wie funktionieren die Tekton-Pipelines? Ich werde den Unterschied zwischen den benutzerdefinierten Ressourcendefinitionen der Tekton-Pipelines in kleinen Beispielen erläutern. Pipeline erstellt (erstellt) eine kleine Anwendung auf Go, erstellt das erforderliche Image und schiebt es dann in die Registrierung. Hier finden Sie alle relevanten Dateien.
Zunächst erstellen wir zwei PipelineResouce- Definitionen, mit denen wir das Git-Repository und die Registry als endgültiges Ziel als Quellcode definieren. Pipeline-Ressourcen sind optional und daher sehr nützlich, um dieselben Pipelines mit unterschiedlichen Quellen und Zielen zu verwenden.
apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: git-repo spec: type: git params: - name: revision value: master - name: url value: https://gitlab.com/nmeisenzahl/tekton-demo --- apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: image-registry spec: type: image params: - name: url value: registry.gitlab.com/nmeisenzahl/tekton-demo/demo:latest
Jetzt müssen wir eine Task- Ressource erstellen, um die Reihenfolge der Schritte in unserer Pipeline zu bestimmen. Natürlich können Sie bei Bedarf mehrere Aufgaben erstellen. In unserem Beispiel verwenden wir Kaniko , um ein Image zu erstellen. Diese Docker-Datei befindet sich wie andere Ressourcen für die Anwendung im Git-Repository.
apiVersion: tekton.dev/v1alpha1 kind: Task metadata: name: build-docker-image spec: inputs: resources: - name: git-repo type: git params: - name: pathToDockerFile description: Path to Dockerfile default: /workspace/git-repo/Dockerfile - name: pathToContext description: The build context used by Kaniko default: /workspace/git-repo outputs: resources: - name: image-registry type: image steps: - name: build-and-push image: gcr.io/kaniko-project/executor:v0.10.0 env: - name: "DOCKER_CONFIG" value: "/builder/home/.docker/" command: - /kaniko/executor args: - --dockerfile=${inputs.params.pathToDockerFile} - --destination=${outputs.resources.image-registry.url} - --context=${inputs.params.pathToContext}
Jetzt können wir eine TaskRun- Ressource erstellen, um eine Instanz der obigen Task zu starten. In diesem Beispiel verwenden wir jedoch Pipeline , mit der wir mehrere Aufgaben (Tasks) hintereinander kombinieren können:
apiVersion: tekton.dev/v1alpha1 kind: Pipeline metadata: name: demo-pipeline spec: resources: - name: git-repo type: git - name: image-registry type: image tasks: - name: build-docker-image taskRef: name: build-docker-image params: - name: pathToDockerFile value: /workspace/git-repo/Dockerfile - name: pathToContext value: /workspace/git-repo resources: inputs: - name: git-repo resource: git-repo outputs: - name: image-registry resource: image-registry
Da wir das erstellte Image in die Registrierung aufgenommen haben, müssen Sie sicherstellen, dass sich die Pipeline authentifizieren kann, indem Sie ImagePullSecrets für das gewünschte Dienstkonto festlegen (in unserem Fall ist dies Dienstkonto - Standard).
Jetzt haben wir alles Notwendige, um die Pipeline zu starten. Dazu müssen wir die letzte Definition für die PipelineRun- Ressource angeben:
apiVersion: tekton.dev/v1alpha1 kind: PipelineRun metadata: name: demo-pipeline-run-1 spec: pipelineRef: name: demo-pipeline resources: - name: git-repo resourceRef: name: git-repo - name: image-registry resourceRef: name: image-registry
Sie können kubectl get pipelineruns -o yaml , um den Status der Pipeline zu überprüfen.
Außerdem
Neben dem Tekton-Pipeline-Projekt selbst gibt es auch ein Projekt für die CLI , das die Arbeit mit Pipelines erleichtert. Sie können auch ein webbasiertes Dashboard einrichten, um Ihre Pipelines in einem Browser anzuzeigen und zu verwalten.
Darüber hinaus arbeitet dasselbe Team an einem anderen Projekt namens Tekton Triggers. Dieses Projekt ist ziemlich neu (das erste Commit war vor 4 Wochen) und befindet sich noch in der Entwicklung. Mit Tekton-Triggern können Sie Tekton-Pipelines basierend auf "Triggern" aufrufen. Dies können Git-Commits, Git-Issues oder beliebige andere Webhooks (Web Hooks) sein. Weitere Informationen finden Sie hier .
Lesen Sie auch andere Artikel in unserem Blog: