Exercice 3
Microservices
Dans les exercices 1 et 2, l’application utilisée était un serveur web monolithique. Les fonctionnalités de Kubernetes permettent de déployer une application selon l’architecture microservices. L’application pour cet exercice est très simple, un serveur accepte la requête, ajoute son nom, le temps de traitement et un UPSTREAM URI puis la transfère à un autre. Nous utiliserons cette applicaton car elle est facilement enchaînable pour créer plusieurs microservices. Le dernier serveur de la chaîne envoie une requête vers l’externe.
Mise en place
Assurez vous d’être dans votre répertoire “home/user” avec cd ~ et clonez le repo https://github.com/matbilodeau/labos-cloud. Déplacez le répertoire de l’exercice vers votre répertoire “kubetest” mv labos-cloud/exemples/laboKube/microservice1/ kubetest puis entrez-y cd /kubetest/microservice1 et explorez le contenu. Le répertoire “image” contient le fichier Dockerfile et l’application (“index.js” et “package.json”). Ce répertoire est séparé dans un sous-dossier pour ne pas être pris en compte par la commande kubectl apply -f . où le “.” réfère au répertoire courant sans les sous-dossiers. Les fichiers manifests de base sont fournis pour créer un déploiement et un service. Ici on regroupe les déploiements ensemble et les services ensemble; les bonnes pratiques mentionnent simplement de regrouper les ressources ayant un lien commun. Ici elles sont liées selon leur type. Modifiez le fichier “deployments.yaml” pour avoir 3 déploiements: un frontend-prod, un middleware-prod et un backend-prod. Le UPSTREAM_URI défini où faire suivre la requête; utilisez le motif suivant: frontend -> middleware -> backend -> http://worldclockapi.com/api/json/utc/now . Kubernetes crée automatiquement des entrées DNS pour les services, on peut donc appeler les services directement par leur nom (ex. “middleware”). Modifiez le fichier “services.yaml” pour avoir 3 services soit frontend, middleware, backend. Laissez les dernières lignes du fichier en commentaire telles quelles (débutent avec un #).
Construction de l’image et déploiement
Construisez l’image à partir du Dockerfile avec un nom:tag approprié pour votre repo et publiez-là. N’oubliez pas de modifier le manifest en conséquence sinon votre déploiement utilisera l’image pré-construite disponible publiquement. Créez votre cluster en spécifiant le type de machine “n1-standard-1”, 4 nodes, un addon pour le HttpLoadBalancing , “autoupgrade” et “autorepair” activés. Appliquez les modifications contenues dans les manifests du répertoire courant. Si vous préférez créer spécifiquement le contenu d’un manifest, utilisez kubectl create -f chemin/fichier.yaml et kubectl delete -f chemin/fichier.yaml pour supprimer. Vérifiez que vous avez bien les 3 pods et les 3 services.
Services réseau
Pour communiquer avec le cluster, nous avons besoin d’une porte d’entrée. Les exercices précédents utilisaient un Ingress mais ce service ne peut pas diriger de trafic vers les services de type ClusterIP. Le service de type LoadBalancer pourra diriger le trafic vers un service de type ClusterIP, ce dernier permet aux pods de communiquer entre eux. Les instructions pour créer le LoadBalancer sont en commentaire (#) dans le fichier “services.yaml” et vous n’avez qu’a retirer le # et ajouter les bonnes valeurs selon le modèle dans la documentation; aucune autre valeur que celles fournies n’est nécessaire pour faire fonctionner l’application. Vous pouvez utiliser kubectl apply -f chemin/fichier.yaml pour mettre à jour les ressources. Le résultat final devrait ressembler à l’image ci-dessous.
Vous pouvez supprimer votre cluster quand vous aurez terminé.