Infeeny, une société du groupe Econocom est un nouveau pure-player Microsoft. Vous voulez travailler dans des grands comptes sur des projets innovants, rejoignez-nous ! Nos consultants sont formés, éduqués, suivis, coachés via des events internes ou chez Microsoft. Ils passent des certifications. La formation et le coaching sont nos engagements les plus précieux. Nous faisons des articles technique pour Programmez via le partenariat avec la communauté technique des NET Azure Rangers, nous organisons des évents internes, nous sommes sur les salons avec Microsoft via les “Ask the Expert” via le programme MVP. Nous bénéficions du référencement Econocom dans le CAC40. Cela fait une énorme différence avec les autres pure-players qui sont des PMEs pour la plupart… Faites la différence entres les différents acteurs, choissiez le dynamisme de Infeeny.
En tant que leader technique NET, j’évolue dans un monde ou le Cloud Azure a une part prépondérante. Nous utilisons les technologies comme NET/NET Core, AKS (kubernetes), Docker, API Managament, Cognitive Services, Windows, Linux, SQL Server, SharePoint, Office 365, etc.
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.
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 :
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.
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 :
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 :
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.
Dans le le Programmez de Avril 2020, retrouvez un article technique qui vous expliquera en détail comment faire un déploiementd e Web API C# NET Core sur docker/kubernetes sous Linux Ubuntu 19.10.
On y détaillera les étapes suivantes:
la création du Web API en C# NET Core
la configuration docker et le dockerfile
le build de l’image
le push en registry locale de l’image docker
la configuration helm en YAML (Infra as Code) pour déployer le Web API
la supervision du cluster dans le portail k8s
l’utilisation de kubectl pour avoir les informations des services
Visual Studio Code sous Linux avec une fenêtre Terminal
Après 3 semaines d’études de Kubernetes sous Linux, j’y vois déjà plus clair au niveau du tooling. Le fonctionnement sous Linux est indispensable pour bien comprendre comment cela fonctionne : le cluster, les pods, le proxy, les services, kubectl
bash sous Ubuntu 19.10Visual Studio Code avec une fenêtre Terminal en ssh depuis Windows
L’apprentissage de Kubernetes est assez complexe au premier abord car les docs sont tordues. On est loin de la prise en main façon Microsoft. J’ai du me faire mal et lire un book Kubernetes Up & Running de O’Reilly et la version française que mon éditeur DUNOD m’a envoyé gratuitement (merci).
Sinon c’était des recherches sur le web pour trouver les commandes à renseigner dans le bash terminal. On avance doucement. Sur le papier c’est pas dur:
création du Web API en NET Core C# NET via console dotnet new WebAPI
création & build de l’image Docker
push de l’image en registry privée locale
création d’un déploiement avec helm sur k8s en pointant sur l’image en registry privée
vérification dans le portail k8S que tout est ok (vert)
kubectl get services => récupération du port du NodePort du service
chrome: host_linux:nodeport/webapi et ça marche !
ça c’est la théorie car la machine Linux, quand elle veut pas, y a moment de solitude. On n’est pas dans un environnement intégré Microsoft avec des assistants et de l’ai de partout. Là, c’est Terminal bash et tu te dém…. !
Si vous suivez mes tutos, vous vous en sortirai. Au pire des cas, vous m’envoyez un email. 🙂
(Cet article est une overview. Tous les détails seront dans l’article en préparation pour Programmez).
Voilà le titre est assez long mais il représente bien le challenge.
Pourquoi ce post ? Je veux maîtriser Kubernetes. On nous baratine avec ça. Donc il faut s’y mettre, pas le choix. Microsoft nous parle de k8s matin midi et soir. Dans Azure, c’est incontournable. OK mais moi je dis plus fort :
j’ai le code source de k8s
je peux le downloader gratuitement
pourquoi j’irais dans Azure et que cela me coûterait mon crédit de 150$ mensuel ?
Et si je le faisais tourner sous Linux ? En local ?
Première étape, commander un PC Dell portable pour Ubuntu. ça c’est fait : j’ai un plan ! Un portable Pentium 8 GB de RAM, 1 TB de disk: 330€ euros. J’ai acheté un disque SSD à 50 euros et j’ai remplacé le SATA HD par le SSD et là, c’est machine de compétition pour une somme modique.
Ensuite, il faut aller sur https://ubuntu.com/ downloader Ubuntu 19.10. On télécharge Rufus pour booter sur une clé USB et le tour est joué.
Ensuite il faut installer gcc, g++, go, docker, microk8s et ensuite on joue.
Avec NET Core installé, on créé une Web API : dotnet new webapi – o App
On build le truc dans une image Docker:
Je build la chose: sudo docker image build –pull -t aspnet3k8s:v1
j’ai pushé l’image dans une registry privée:
sudo docker tag aspnet3k8s:v1 localhost:32000/aspnet3k8s
sudo docker push localhost:32000/aspnet3k8s
Pour le déploiement de l’image Docker dans Kubernetes, il faut au préalable l’avoir poussée dan une registry privée.
Ensuite on va faire de l’infra as code avec du YAML pour pousser le deploiement dans kubernetes. L’IaC est variabilisée et les valeurs sont les suivantes:
Je fais le déploiement avce helm, le package manager kubernetes:
christophep@christophep-Inspiron-15-3573:~/dev$ helm install aspnet3release4 ./chart/ NAME: aspnet3release4 LAST DEPLOYED: Sat Feb 1 04:21:00 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None
On check les status avec :
microk8s.kubectl get all –selector app=aspnet3core
Conclusion: Ce PoC montre qu’installer Kubernetes est simple et gratuit pour le développement. Nul n’est besoin d’aller dans Azure et de consommer du crédit en $. Linux fait l’affaire. De plus, avec .NET Core, les développeurs Microsoft ne perdent pas leur bossoles. Le déploiement est fait via de l’infra as code et le paramétrage se fait en ligne de commande. IL y donc du Dev et du Ops.
