CI/CD avec conteneurs

Cheatsheet · d'après le Refcard DZone no 277 (Shay Shmeltzer et Andrea Morena, Oracle, 2018) Module 3 · Techniques Docker
évolutif

Les trois continus

Intégration continue (CI) : fusionner le travail des développeurs dans une seule ligne de code, à cycle fréquent.

Livraison continue (CD) : produire un logiciel empaqueté à partir du code, à la même fréquence.

Déploiement continu : pousser ce paquet sur la plateforme d'exécution. Automatiser TOUTE la chaîne donne le maximum de bénéfices, mais la cible peut rester l'environnement QA, la production demeurant un geste manuel.

Bâtir et publier l'image

docker build -t mon-application:version .

Le job de build vérifie que la définition est bonne et tague l'image pour gérer les versions.

docker login registre.exemple.com docker push mon-application:version

Publier vers un registre public (Docker Hub) ou privé. Le Dockerfile vit dans Git : Infrastructure as Code.

Déclencher le job à chaque changement de la branche master, ou chaque nuit vers les instances QA.

Provisionner le cluster (Terraform)

cp terraform.example.tfvars terraform.tfvars

Partir de l'exemple et décrire son infonuagique : locataire, usager, gabarits de machines.

terraform init terraform plan terraform apply

Le cluster Kubernetes complet se lève en environ 5 minutes; le kubeconfig attend dans ./generated.

Déployer sur Kubernetes

kubectl create -f mon-application.yaml

LA commande clé : déployer l'application depuis son fichier de définition.

kubectl get nodes kubectl get pods kubectl describe pods

Surveiller nœuds, services et pods créés; describe pour inspecter en détail.

Pourquoi des conteneurs dans le pipeline ?

Légers et portables : usage optimal de l'infrastructure, déploiement beaucoup plus rapide qu'avec des machines virtuelles.

Environnements jetables en un clic : provisionner puis détruire un banc de test pour chaque exécution du pipeline.

Déploiement sans accroc : plus de conflits de pilotes ou de bibliothèques; moins de friction entre développement et exploitation; liberté totale d'outils; les erreurs manuelles disparaissent avec l'automatisation.

Le script de déploiement du pipeline

kubectl get nodes kubectl create -f nodejs_micro.yaml sleep 120 kubectl get services nodejsmicro-k8s-service kubectl get pods kubectl describe pods
kubectl create -f : déployer l'application décrite dans le fichier YAML sleep 120 : laisser le temps au cluster de démarrer les pods kubectl get / describe : vérifier services et pods, inspecter au besoin

Dans le pipeline CI/CD, un premier job construit et publie l'image Docker; un second exécute ce script vers le cluster cible.

Master : la machine qui contrôle les nœuds Kubernetes; toutes les affectations de tâches en partent Node : machine qui exécute les tâches demandées, sous le contrôle du master Pod : groupe d'un ou plusieurs conteneurs déployés sur un même nœud, partageant IP, nom d'hôte et ressources Replication controller : décide combien de copies identiques d'un pod doivent tourner sur le cluster Service : découple la définition du travail des pods; route automatiquement les requêtes vers le bon pod, où qu'il soit Kubelet : service sur chaque nœud qui lit les manifestes et garde les conteneurs définis en marche kubectl : l'outil de configuration en ligne de commande de Kubernetes

420-5A4-MT · Serveurs évolutifs · cliquer une commande la copie