Utiliser Tekton avec Azure Kubernetes Service pour créer des pipelines CI/CD – Partie 1

Comprendre les tâches Tekton

Introduction

En développement logiciel, un pipeline consiste en un processus automatisé qui contribue aux phases de construction, de test et de déploiement du code. L’automatisation permet de réduire les erreurs humaines et d’avoir des processus constants et reproductibles dans le temps.

Pour ce faire, les entreprises ont adopté l’intégration et la livraison continues pour automatiser le cycle de vie des applications. Pour désigner cela, on parle couramment de pipelines ou workflows CI (Continuous Integration) /CD (Continuous Delivery).

Les outils disponibles pour supporter les pipelines CI/CD existent depuis déjà bon nombre d’années mais avec l’évolution des infrastructures et particulièrement l’expansion de Kubernetes dans les entreprises, de nouveaux outils natifs Kubernetes sont apparus comme par exemple Jenkins X et Tekton. C’est d’ailleurs sur Tekton, également nommé Tekton Pipelines, que porte cet article.

Ainsi, nous allons voir dans cet article comment utiliser Tekton dans un cluster Kubernetes instancié avec Azure Kubernetes Service pour créer des pipelines CI/CD.

Sources GitHub

Les sources des exemples utilisés dans cet article sont disponibles sous le dépôt GitHub accessible depuis cette URL : https://github.com/cderue/tekton-aks-part-one

Présentation de Tekton

Tekton est un framework Open Source prévu pour s’intégrer nativement avec Kubernetes et supporter la création de pipelines CI/CD en utilisant un modèle déclaratif. Initié par Google, ce projet est hébergé par la CDF (Continuous Delivery Foundation) et a pour vocation de moderniser les approches CI/CD en proposant des standards industriels pour les phases de compilation, de test, de déploiement et autres avec divers fournisseurs cloud ou sur site en faisant abstraction de la mise en œuvre sous-jacente.

Qu’est-ce qu’un pipeline Tekton ?

Un pipeline Tekton est un ensemble d’objets Kubernetes qui forment un pipeline CI/CD dont les briques élémentaires constitutives sont portées par des conteneurs. Pour pouvoir créer ces objets dans Kubernetes, Tekton fournit à Kubernetes des extensions CRD (Custom Resource Definition).

Pour créer un pipeline Tekton, les objets Kubernetes nécessaires sont déclarées à l’aide de fichiers au format YAML dont le contenu pourrait par exemple ressembler au contenu montré ci-dessous :

Source: https://github.com/openshift/pipelines-tutorial

Ces fichiers YAML peuvent  ainsi être facilement gérés dans un système de contrôle de source. Cette approche nouvelle pour décrire des pipelines à l’aide d’instructions écrites dans des fichiers est qualifiée dans la littérature informatique de pipeline-as-code

Un pipeline Tekton permet de créer un pipeline CI/CD simple ou complexe en se basant sur les 5 concepts majeurs fournis sous forme de CRD et listés ci-dessous :

  • Task : permet de définir un ensemble d’étapes comme par exemple compiler du code, exécuter des tests, construire des images Docker, etc.
  • TaskRun : permet de lancer une tâche unique donnée en référence.
  • Pipeline : permet de définir un ensemble de tâches qui composent un pipeline
  • PipelineResources : permet de définir un objet d’entrée (comme un dépôt Git par exemple) ou de sortie (comme une image Docker) nécessaire à un pipeline.
  • PipelineRun: permet de procéder à l’exécution d’un pipeline. Cette ressource précise le pipeline a exécuter et les ressources (PipelineResources) nécessaires en entrée et en sortie.

Créer un cluster Azure Kubernetes Service

Pour pouvoir présenter les premières fonctionnalités de Tekton, nous allons au préalable créer un cluster Kubernetes en utilisant Azure Kubernetes Service (AKS). AKS permet de créer un cluster Kubernetes managé dans le cloud Microsoft Azure.

Il est important de noter ici que Tekton est agnostique de la plateforme et peut s’installer sur un cluster Kubernetes dans AWS, Google Cloud, IBM Cloud ou autre fournisseur cloud et même on-premise.

Pour pouvoir fonctionner, Tekton nécessite un cluster avec Kubernetes 1.15 ou une version supérieure.

Pour créer un cluster avec AKS , il est possible d’utiliser le portail Azure (www.portal.azure.com) ou la ligne de commande.

Très brièvement, l’exemple de ligne de commande ci-dessous montre comment créer un nouveau cluster AKS avec Kubernetes 1.15  :

az aks create --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.15 --node-count 1 --enable-addons monitoring --generate-ssh-keys

Installer Tekton et Tekton Pipelines CLI

Pour installer Tekton sur le cluster AKS créé dans le paragraphe précédent, il suffit d’exécuter la commande suivante depuis un terminal avec la ligne de commande Kubernetes :

kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

Pour vérifier que Tekton est installé, il suffit d’exécuter la commande suivante depuis un terminal :

kubectl get pods --namespace tekton-pipelines

Le terminal affiche la sortie ci-dessous :

NAME                                          READY  STATUS  RESTARTS  AGE
tekton-pipelines-controller-65459f5b4d-59nlg  1/1    Running   0       67m
tekton-pipelines-webhook-84d67645d-pr94p      1/1    Running   0       67m

Ensuite, il est nécessaire d’installer la ligne de commande Tekton (Tekton Pipelines CLI) qui permet d’interagir avec Tekton afin d’obtenir des informations sur les pipelines déployés. Tekton Pipelines CLI est disponible pour les systèmes d’exploitation courants (Windows, MacOS et Linux). La procédure d’installation de Tekton Pipelines CLI en fonction du système d’exploitation est disponible depuis cette URL : https://github.com/tektoncd/cli

Créer une première tâche

Nous allons maintenant créer un première tâche Tekton. Pour ce faire, nous allons créer une tâche simple qui affiche « Hello World » depuis un conteneur Linux qui supporte les commandes PowerShell. L’image utilisée pour ce conteneur est disponible depuis le dépôt officiel Docker Hub de Microsoft.

Dans notre exemple, cette tâche Tekton est déclarée dans un fichier nommé task.yaml situé à la racine des sources Github fournies avec cet article. Le contenu de ce fichier est montré ci-dessous :

La version de l’API utilisée est v1alpha1 car c’est la version implémentée dans la version 0.11 installée lors de l’écriture de cet article. La version v1beta1 existe pour les versions de Tekton ultérieures à la version 0.11.

Voici quelques explications sur le contenu du fichier task.yaml :

  • L’attribut kind détermine le type d’objet à créer, ici un objet de type Task.
  • L’attribut metadata/name définit le nom de la tâche. Ici la tâche se nomme powershell-helloworld-task.
  • L’attribut spec/steps décrit les différentes étapes de la tâche. Ici une seule étape nommée helloworld spécifie l’image à prendre pour créer le conteneur Docker qui exécutera la tâche. Les attributs command et args permettent de lancer la commande PowerShell qui affichera le texte « Hello World ».

Pour créer la tâche dans Kubernetes, il suffit de lancer la commande suivante depuis un terminal avec la ligne de commande Kubernetes :

kubectl apply -f task.yaml

Le terminal affiche la sortie ci-dessous :

task.tekton.dev/powershell-helloworld-task created

Attention ici car la création d’une tâche n’entraîne pas son exécution. Le prochain paragraphe montre comment procéder au lancement d’une tâche.

Exécuter une tâche

Une fois la tâche créée, il peut-être pertinent d’exécuter cette tâche de manière isolée sans avoir à exécuter tout le pipeline qui inclut cette tâche. Pour ce faire, nous allons déclarer un nouvel objet de type TaskRun.

Le fichier nommé task-run.yaml situé à la racine des sources Github fournies avec cet article contient la déclaration nécessaire pour créer un objet de type TaskRun . Ce fichier est montré ci-dessous :

Voici quelques explications sur le contenu du fichier task.yaml :

  • L’attribut kind détermine le type d’objet à créer, ici un objet de type TaskRun.
  • L’attribut metadata/name définit le nom de l’objet
  • L’attribut spec/taskRef permet de définir la tâche à exécuter en renseignant son nom. Ici la tâche powershell-helloworld-task  créée précédemment est donnée en référence.

Il ne reste plus désormais qu’à lancer la tâche en exécutant la commande suivante depuis un terminal  avec la ligne de commande Kubernetes :

kubectl apply -f task-run.yaml

Le terminal affiche la sortie ci-dessous :

taskrun.tekton.dev/powershell-helloworld-task-run created

Pour vérifier que la tâche powershell-helloworld-task s’est exécutée avec succès, il suffit de saisir la commande ci-dessous depuis un terminal :

tkn taskrun describe powershell-helloworld-task-run

Dans cet exemple, la ligne de commande Tekton est utilisée pour afficher le statut de la tâche . Si cette tâche créée s’est terminée correctement, le terminal doit afficher le type de sortie montrée ci-dessous :

Conclusion

Dans cette première partie d’une série d’articles consacrés à Tekton, nous avons vu que Tekton permet de définir et d’exécuter de manière simple des tâches qui lorsque nous les assembleront plus tard dans d’autres exemples formeront des pipelines CI/CD plus ou moins complexes.

L’installation de Tekton sur Kubernetes se révèle particulièrement triviale par rapport à l’installation d’outils traditionnels de CI/CD plus complexes à mettre en œuvre en particulier dans Kubernetes.

Dans la seconde partie de cette série, nous verrons comment créer un premier pipeline Tekton pour supporter toutes les phases du cycle de vie d’une application.

Pour aller plus loin

Comment devenir un Expert Docker/Kubernetes dans le monde Microsoft ?

Ce post part d’une réflexion relatée à mon boss et à mes anciens collègues de différentes sociétés suite à la réception d’une newsletter Microsoft Azure….

Microsoft nous spam avec kubernetes… Y a pas à dire, Microsoft s’est converti à k8s.

En tant que MVP (Most Valuable Pipiche), je vous donne un feedback from the field sur Docker/Kubernetes. On m’a poussé à apprendre Docker & Azure en 2017 chez Neos-SDI et j’ai galéré… Mais ça a changé ma vie depuis 3 ans.

Après des semaines d’expérimentations avec ses choses-là (Docker, Azure et maintenant Kubernetes) , je suis arrivé à un constat : on a du boulot pour 10 ans sans forcer. Et donc qui dit boulot du business !

Par contre, le challenge c’est de faire évoluer les gens et là, ça va changer les habitudes des Devs NET traditionnelles. Comme disait Aimé Jacquet, sélectionneur de France 98, « Faut que tu muscules ton jeu sinon tu vas au-devant de sévères déconvenues ! ».

NET pour Windows, c’est mort. Faut faire de l’Azure, du Linux, du Docker/Kubernetes.

La recette à Pic :
Il faut vous mettre aux architectures micro-services (View on the web, Download pdf)
Il faut que vous maitrisiez la modernisation des applications .NET vers Azure (Download pdf)
Il faut faire des applications Web Modernes avec ASP.NET Core  et Azure (View on the web, Download pdf)
Il faut mettre en éveil l’Architecte qui est en vous:
Il faut regarder les samples officiels Microsoft comme eShopOnContainers, eShopWeb, SmartHotels360 et décortiquer la doc
Récupérer le code sur GitHub:
https://github.com/mspnp/microservices-reference-implementation
https://github.com/dotnet-architecture/eShopOnContainers
https://github.com/dotnet-architecture/eShopOnWeb
https://github.com/microsoft/SmartHotel360

Synthèse :

La solution est multi-plateformes (Windows, Linux) et multi-technologies:

  • Shipping/Delivery est en ASP.NET Core Web API avec support Redis
  • Shipping/DroneScheduler est fait en ASP.NET Core Web API avec support CosmosDB (ils ont pas pu s’empêcher…)
  • Shipping/injection est fait en Java/springframework
  • Shipping/package est fait en TS/node avec support MongoDB

Il y a le dev et le Ops : le YAML & co.

Le code des DockerFile est dense (limite complexe)

=> Il faut former les gens à Docker : c’est indispensable. Docker/Windows, Docker/Linux => mettre le paquet sur Docker

  • On peut d’ailleurs se servir de ce sample training officiel Docker/K8s.

Microsoft demande aux développeurs d’avoir des skills :

  • Windows, Linux
  • Docker, Kubernetes
  • Node, TS, Java, C#
  • MongoDB, Redis, CosmosDB

Le monde est de plus en plus complexe. Qui comme moi va passer son week-end à lire des books pour se former… ? Tout le monde n’est pas passionné. La barre est haute au niveau des skills .Je suis conscient que cela va nous donner du boulot pour les 10 ans à venir par contre la question reste posée : (hier, j’ai vu 2 cv asp.net qui m’ont pas fait rêver…) => on en fait quoi de ces gens-là ? Déjà que quand tu leur dit arrêter de faire EF, ils couinent…

On va leur demander de faire autre chose que du Web API bête et méchant : on leur demande d’être des architectes et de vrai développeurs avec un mindset open. Fini de jouer…

La clé de tout ça : la formation. Il est difficile de recruter des gens prêt à l’emploi : c’est très rare. Ils sont déjà en poste ou coûte très cher. Il faut former les gens. C’est la clé.

Mon avis personnel :

Aujourd’hui, tout existe, repos GitHub, Microsoft Learn, Microsoft Doc, les books gratuits MS Press, ceux qu’on rippe, ceux qu’on achète : on a tout ! La Technologie marche bien. Ce n’est pas le problème. Mais le problème c’est l’humain. Il faut faire prendre la mayonnaise, le faire adhérer, lui faire prendre conscience que c’est son intérêt d’upgrader ses skills.

Ça va être long et douloureux. Déjà que pour faire du Windows Server/IIS/SQL Server, le développeur Microsoft standard est léger… alors là, avec du Docker, Azure, NET Core, Linux, je suis pessimiste. On va ramer. On va essayer.

Informations technique :

Regardons le code du service Delivery, c’est pas dur :

Regardons le code que GetAsync :

On a un wrapper Redis : c’est le assuré via le package Nuget StackExchange.Redis

IDatabase est le wrapper Redis :

La conclusion de ce post est la suivante:

Formez vous à Docker/Kubernets, c’est l’avenir. Utilisez les samples de référence comme canevas de départ dans vos projets.

La newsletter Microsoft du jour: Lien: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/microservices/aks

Le Cloud par Keelan C.

Dans le numéro de Programmez de Novembre 2019, Keelan nous fait partager sa vision du cloud sous forme d’Edito.

« Le Cloud computing a énormément évolué cette dernière décennie et ne se contente plus, bien heureusement, de proposer une simple approche IaaS (Infrastructure as a Service). Les cloud providers ont compris que la valeur ne se situait pas au niveau du device mais au-dessus de ce dernier en  proposant de vrais services à valeur ajoutée. Ces derniers permettent de réduire le TTM (Time To Market) tout en optimisant le coût d’exploitation, pour peu que les architectes en charge des développements respectent les bonnes pratiques et utilisent finement les leviers d’optimisation. C’est la promesse du PaaS (Platform as a Service), du CaaS (Container as a Service) et autre FaaS (Function as a Service).

Qui dit nouvelle plateforme dit nouvelle architecture. Nous avons ainsi vu apparaître les micro-services, architecture permettant de se séparer des applications plus ou moins monolithiques pour offrir à la place un ensemble de petites fonctionnalités (services), indépendantes les unes des autres, interrogeable. Le principe est simple : 1 fonctionnalité = 1 service (d’où le préfixe de micro), la communication se faisant à l’aide d’un contrat d’API.

Dans le monde Microsoft Azure, 4 approches sont disponibles pour mettre en œuvre ces micro-services :

Service Fabric, AKS (Azure Kubernetes), Azure function ou encore la solution d’API management.

Les Azure .Net Rangers vous proposent au travers de ce dossier d’étudier votre première application architecturée autour des micro-services et hébergée dans des containers Docker sur la plateforme Azure de Microsoft, afin de tirer également partie des bénéfices de déploiement, scalabilité et contrôle des coûts apportés par cette solution.»