Tekton Pipeline est un nouveau projet qui vous permet d'exécuter des pipelines CI / CD en utilisant l'approche native Kubernetes. Tekton Pipelines faisait initialement partie du projet «Knative build». Si vous voulez en savoir plus sur ce projet, je vous recommande fortement de visiter leur site Web, qui est disponible sur le lien ici .
Avant de commencer à parler de ce que signifie «natif de Kubernetes» et du fonctionnement de Tekton Pipeline, je voudrais prendre un peu de recul et expliquer brièvement pourquoi l'exécution de pipelines dans des conteneurs plutôt que sur l'hôte est si importante et utile: il y a quelque temps nous avons commencé à transférer les applications avec lesquelles nous travaillons vers des conteneurs. Nous l'avons fait en raison d'avantages tels que l'isolement, les dépendances transparentes, l'évolutivité et l'immuabilité. Cela ne serait-il pas tout aussi utile pour les pipelines CI / CD? Pensez aux «build-hosts», qui fourniraient les outils et les dépendances nécessaires pour une tâche de build spécifique. À propos d'un environnement qui serait le même à chaque lancement et qui n'aurait pas de dépendances avec d'autres projets, ce qui pourrait causer des problèmes. Et aussi, sur les pipelines de mise à l'échelle faciles. C'est pourquoi nous pouvons et devons exploiter des pipelines conteneurisés!
Maintenant que nous avons parlé brièvement de la conteneurisation des pipelines, voyons comment le projet Tekton Pipeline avec son approche native Kubernetes pourrait aider:
Tekton Pipeline nous permet d'exécuter des pipelines conteneurisés dans nos clusters Kubernetes existants. Cela signifie que nous n'avons pas besoin de machines supplémentaires pour faire fonctionner nos pipelines et, par conséquent, nous pouvons mieux utiliser les machines existantes.
C'est génial, mais pour être honnête, cela ne rend pas le pipeline Tekton unique. Par conséquent, Tekton Pipeline va plus loin et stocke tout ce qui concerne nos pipelines dans Kubernetes - en tant que ressource Kubernetes. Cela nous permet de travailler avec nos convoyeurs, ainsi qu'avec toute autre ressource. Pensez au déploiement ou au service, que vous pouvez créer et gérer à l'aide de fichiers kubectl et YAML.
Par où commencer
Comme mentionné ci-dessus, le pipeline Tekton est situé à l'intérieur du cluster Kubernetes. Il est basé sur 5 définitions de ressources personnalisées (CRD), déploiements, cartes de configuration et services. Vous pouvez exécuter la commande suivante pour démarrer:
kubectl apply -f https://storage.googleapis.com/tekton-releases/latest/release.yaml
En plus des ressources ci-dessus, il créera également un espace de noms, une politique de sécurité des pods, un compte de service et des rôles de cluster. Tekton Pipeline est prêt à fonctionner dès que tous les pods du nouvel espace de noms (le nom par défaut est tekton-pipelines) sont prêts.
Bien sûr, vous pouvez visualiser ce fichier YAML et le personnaliser selon vos besoins.
Si vous devez partager des artefacts ou d'autres ressources de pipelines entre les tâches, vous devez configurer le stockage pour celles-ci. Vous pouvez utiliser le PVC, qui vous sera demandé chaque fois que cela sera nécessaire (l'initialisation dynamique du volume est la clé!), Ou le stockage Blob. Vous trouverez plus d'informations sur cette tâche ici .
Premier pipeline
Alors, comment fonctionne Tekton Pipelines? Je vais expliquer la différence entre les définitions de ressources personnalisées Tekton Pipelines dans de petits exemples. Pipeline créera (construira) une petite application sur Go, créera l'image requise puis la poussera dans le Registre. Vous pouvez trouver tous les fichiers pertinents ici .
Tout d'abord, nous créons deux définitions PipelineResouce que nous utiliserons pour définir le référentiel Git et le registre comme destination finale comme code source. Les ressources de pipeline sont facultatives et donc très utiles pour utiliser les mêmes pipelines, mais avec des sources et des destinations différentes.
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
Nous devons maintenant créer une ressource de tâche pour déterminer la séquence des étapes de notre pipeline. Bien sûr, si nécessaire, vous pouvez créer plusieurs tâches. Dans notre exemple, nous utiliserons Kaniko pour créer une image. Ce Dockerfile, comme d'autres ressources pour l'application, se trouve dans le référentiel Git.
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}
Nous pouvons maintenant créer une ressource TaskRun pour lancer une instance de la tâche ci-dessus. Cependant, dans cet exemple, nous utilisons Pipeline , que nous pouvons utiliser pour combiner plusieurs tâches (tâches) d'affilée:
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
Puisque nous avons mis l'image créée dans le registre, vous devez vous assurer que le pipeline peut s'authentifier en définissant ImagePullSecrets pour le compte de service souhaité (dans notre cas, il s'agit du compte de service - par défaut).
Nous avons maintenant tout le nécessaire pour lancer le pipeline. Pour ce faire, nous devons spécifier la dernière définition de la ressource PipelineRun :
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
Vous pouvez utiliser kubectl get pipelineruns -o yaml pour vérifier l'état du pipeline.
De plus
En plus du projet Tekton Pipeline lui-même, il existe également un projet pour la CLI qui facilite le travail avec les pipelines. Vous pouvez également configurer un tableau de bord Web pour afficher et gérer vos pipelines à partir d'un navigateur.
De plus, la même équipe travaille sur un autre projet appelé Tekton Triggers. Ce projet est assez récent (le premier commit remonte à 4 semaines) et est toujours en développement. Les déclencheurs Tekton vous permettent d'appeler Tekton Pipelines en fonction de «déclencheurs». Il peut s'agir de git-commits, de git-issues ou de tout autre webhook (web hooks). Plus d'informations sont disponibles ici .
Lisez également d'autres articles sur notre blog: