Tests automatisés des microservices dans Docker pour l'intégration continue

Dans les projets liés au développement d'architectures de microservices, le CI/CD passe d'une option agréable à une nécessité urgente. Les tests automatisés sont une partie intégrante de l'intégration continue, et une approche adéquate peut offrir à l'équipe de nombreuses soirées agréables avec la famille et les amis. Dans le cas contraire, le projet risque de ne jamais être achevé.

On peut couvrir tout le code d'un microservice avec des tests unitaires et des objets fictifs, mais cela ne résout qu'une partie du problème et laisse de nombreuses questions et complexités, notamment lors des tests liés aux données. Comme toujours, les plus épineux sont : le test de la cohérence des données dans la base de données relationnelle, le test de l'interaction avec les services cloud et les hypothèses erronées lors de l'écriture des objets fictifs.

Tout cela, et un peu plus, se résout par le test de l'intégralité d'un microservice dans un conteneur Docker. Un avantage incontestable pour assurer la validité des tests est que les mêmes images Docker qui seront mises en production sont soumises aux tests.

L'automatisation de cette approche pose un certain nombre de problèmes, dont la solution sera décrite un peu plus bas :

• conflits de tâches parallèles sur un même hôte Docker ;
• conflits d'identifiants dans la base de données lors des itérations de test ;
• attente de la disponibilité des microservices ;
• agrégation et sortie des journaux vers des systèmes externes ;
• test des requêtes HTTP sortantes ;
• test des websockets (avec SignalR) ;
• test de l'authentification et de l'autorisation OAuth.

Ceci est un article inspiré de ma présentation SECR 2019. Donc, pour ceux qui n'ont pas envie de lire, voici l'enregistrement de la présentation..

Dans cet article, je vais expliquer comment, à l'aide d'un script, lancer dans Docker le service à tester, la base de données et les services Amazon AWS, puis exécuter les tests sur Postman et, une fois terminés, arrêter et supprimer les conteneurs créés. Les tests sont exécutés à chaque modification du code. Ainsi, nous nous assurons que chaque version fonctionne correctement avec la base de données et les services AWS.

Le même script est lancé à la fois par les développeurs sur leurs postes de travail Windows et par le serveur Gitlab CI sous Linux.

Pour que l'intégration de nouveaux tests soit justifiée, elle ne doit nécessiter l'installation d'outils supplémentaires ni sur l'ordinateur du développeur, ni sur le serveur où les tests sont lancés lors des commits. Docker résout ce problème.

Le test doit fonctionner sur un serveur local pour les raisons suivantes :

• Le réseau n'est jamais totalement fiable. Sur mille requêtes, une peut échouer ;
  Dans ce cas, le test automatique ne passera pas, le fonctionnement s'arrêtera, et il faudra rechercher la cause dans les logs ;
• Des requêtes trop fréquentes ne sont pas acceptées par certains services tiers.

De plus, il est indésirable d'utiliser l'environnement de test pour les raisons suivantes :

• Un mauvais code fonctionnant sur l'environnement peut non seulement le briser, mais aussi des données que le code correct ne peut pas traiter ;
• Peu importe combien nous essayons de revenir sur toutes les modifications effectuées par le test, quelque chose peut mal se passer pendant le test (sinon, pourquoi tester ?).

À propos du projet et de l'organisation du processus

Notre entreprise a développé une application web en microservices, fonctionnant dans Docker sur le cloud Amazon AWS. Le projet utilisait déjà des tests unitaires, mais des erreurs survenaient souvent que les tests unitaires ne détectaient pas. Il était nécessaire de tester un microservice entier avec sa base de données et les services Amazon.

Le projet suit un processus standard d'intégration continue, incluant des tests du microservice à chaque commit. Après l'assignation d'une tâche, le développeur apporte des modifications au microservice, le teste manuellement et exécute tous les tests automatiques disponibles. Si nécessaire, le développeur modifie les tests. Si aucun problème n'est détecté, un commit est effectué dans la branche de cette tâche. Après chaque commit, des tests sont automatiquement lancés sur le serveur. La fusion dans la branche principale et l'exécution des tests automatiques sur celle-ci se font après une révision réussie. Si les tests sur la branche principale passent, le service est automatiquement mis à jour dans l'environnement de test sur Amazon Elastic Container Service (l'environnement de test). Cet environnement est nécessaire pour tous les développeurs et testeurs, et il est indésirable de le briser. Les testeurs vérifient dans cet environnement un correctif ou une nouvelle fonctionnalité en effectuant des tests manuels.

Architecture du projet

L'application est composée de plus de dix services. Certains d'entre eux sont écrits en .NET Core, d'autres en NodeJs. Chaque service fonctionne dans un conteneur Docker sur Amazon Elastic Container Service. Chacun a sa propre base de données Postgres, et certains utilisent également Redis. Il n'y a pas de bases de données communes. Si plusieurs services ont besoin des mêmes données, ces données sont transmises à chacun de ces services via SNS (Simple Notification Service) et SQS (Amazon Simple Queue Service) au moment de leur modification, et les services les enregistrent dans leurs bases de données distinctes.

SQS et SNS

SQS permet, via le protocole HTTPS, d'ajouter des messages dans une file d'attente et de lire les messages de cette file.

Si plusieurs services lisent une même file d'attente, chaque message est destiné à un seul d'entre eux. Cela est utile lors du lancement de plusieurs instances d'un même service pour répartir la charge entre elles.

Si vous souhaitez que chaque message soit livré à plusieurs services, chaque destinataire doit avoir sa propre file d'attente, et pour dupliquer des messages dans plusieurs files d'attente, SNS est nécessaire.

Dans SNS, vous créez un topic et vous abonnez, par exemple, une file SQS. Vous pouvez envoyer des messages au topic. Dans ce cas, le message est envoyé à chaque file abonnée à ce topic. SNS n'a pas de méthode pour lire les messages. Si, lors du débogage ou des tests, vous devez savoir ce qui est envoyé à SNS, vous pouvez créer une file SQS, l'abonner au topic souhaité et lire la file.

API Gateway

La plupart des services ne sont pas directement accessibles depuis Internet. L'accès se fait via API Gateway, qui vérifie les droits d'accès. C'est également notre service, et il y a aussi des tests pour cela.

Notifications en temps réel

L'application utilise SignalR, pour montrer aux utilisateurs les notifications en temps réel. Cela est réalisé dans le service de notifications. Il est accessible directement depuis Internet et fonctionne avec OAuth, car intégrer le support des WebSockets dans le Gateway s'est révélé peu pratique par rapport à l'intégration d'OAuth et du service de notifications.

Approche bien connue du test

Les tests unitaires remplacent des éléments tels que la base de données par des objets mock. Si un microservice, par exemple, essaie de créer une entrée dans une table avec une clé étrangère, mais que l'entrée à laquelle cette clé se réfère n'existe pas, alors la requête ne peut pas être exécutée. Les tests unitaires ne peuvent pas le détecter.

Dans L'article de Microsoft propose d'utiliser une base de données en mémoire et d'injecter des objets mock.

La base de données en mémoire est l'un des SGBD pris en charge par Entity Framework. Elle est conçue spécialement pour les tests. Les données dans une telle base ne sont conservées que jusqu'à la fin du processus qui l'utilise. Il n'est pas nécessaire de créer des tables, et l'intégrité des données n'est pas vérifiée.

Les objets factices simulent une classe substituable juste dans la mesure où le développeur du test comprend son fonctionnement.

La façon d'assurer le démarrage automatique de Postgres et d'effectuer la migration lors du démarrage du test n'est pas précisée dans l'article de Microsoft. Ma solution le fait et, de plus, aucun code n'est ajouté dans le microservice spécialement pour les tests.

Passons à la solution

Au cours du développement, il est devenu clair que les tests unitaires ne suffisent pas pour identifier rapidement tous les problèmes, il a donc été décidé d'aborder cette question différemment.

Configuration de l'environnement de test

La première tâche consiste à déployer l'environnement de test. Voici les étapes nécessaires pour lancer le microservice :

• Configurer le service à tester pour l'environnement local, les variables d'environnement spécifient les informations d'identification pour se connecter à la base et à AWS ;
• Lancer Postgres et effectuer la migration en exécutant Liquibase.
  Dans les SGBD relationnels, avant d'enregistrer des données dans la base, il est nécessaire de créer un schéma de données, en d'autres termes, des tables. Lors de la mise à jour de l'application, les tables doivent être adaptées à la forme utilisée par la nouvelle version, idéalement sans perte de données. Cela s'appelle une migration. La création de tables dans une base initialement vide est un cas particulier de migration. La migration peut être intégrée dans l'application elle-même. Tanto dans .NET que dans NodeJS, il existe des frameworks pour la migration. Dans notre cas, pour des raisons de sécurité, les microservices n'ont pas le droit de modifier le schéma de données, et la migration est effectuée à l'aide de Liquibase.
• Lancer Amazon LocalStack. C'est une implémentation des services AWS à exécuter localement. Pour LocalStack, il existe une image prête à l'emploi sur Docker Hub.
• Exécuter le script pour créer dans LocalStack les entités nécessaires. Les scripts Shell utilisent AWS CLI.

Pour les tests, le projet utilise Postman. Il était déjà utilisé auparavant, mais son lancement se faisait manuellement et l'application était testée une fois déployée sur l'environnement. Cet outil permet d'effectuer des requêtes HTTP(S) arbitraires et de vérifier la conformité des réponses avec les attentes. Les requêtes sont regroupées dans une collection et l'ensemble de la collection peut être lancé en une seule fois.

Comment fonctionne le test automatique

Pendant le test, tout fonctionne dans Docker : le service testé, Postgres, l'outil de migration et Postman, ou plutôt sa version en ligne de commande - Newman.

Docker résout un certain nombre de problèmes :

• Indépendance par rapport à la configuration de l'hôte ;
• Installation des dépendances : Docker télécharge les images depuis Docker Hub ;
• Retour du système à l'état initial : il suffit de supprimer les conteneurs.

Docker-compose il regroupe les conteneurs dans un réseau virtuel, isolé d'Internet, où les conteneurs se trouvent les uns les autres par leurs noms de domaine.

Le test est géré par un script shell. Pour exécuter le test sous Windows, nous utilisons git-bash. Ainsi, un seul script suffit à la fois pour Windows et Linux. Git et Docker sont installés chez tous les développeurs du projet. Lors de l'installation de Git sous Windows, git-bash est installé, donc tout le monde l'a aussi.

Le script exécute les étapes suivantes :

• Construction des images Docker

  pour construire les images et

• Démarrage de la base de données et de LocalStack

  docker-compose up -d

• Migration de la base de données et préparation de LocalStack

  docker-compose run

• Démarrage du service testé

  docker-compose up -d

• Exécution du test (Newman)
• Arrêt de tous les conteneurs

  docker-compose down

• Publication des résultats sur Slack
  Nous avons un chat où arrivent les messages avec une coche verte ou une croix rouge et un lien vers le log.

Les étapes suivantes impliquent les images Docker suivantes :

• Le service testé est la même image que pour la production. La configuration pour le test se fait via des variables d'environnement.
• Pour Postgres, Redis et LocalStack, nous utilisons des images prêtes à partir de Docker Hub. Il existe également des images prêtes pour Liquibase et Newman. Nous construisons les nôtres sur leur base, en y ajoutant nos fichiers.
• Pour préparer LocalStack, nous utilisons une image prête de l'AWS CLI, sur la base de laquelle une image contenant le script est créée.

En utilisant volumes, il n'est pas nécessaire de construire une image Docker juste pour ajouter des fichiers dans le conteneur. Cependant, les volumes ne conviennent pas à notre environnement, car les tâches Gitlab CI s'exécutent elles-mêmes dans des conteneurs. À partir de ce type de conteneur, nous pouvons gérer Docker, mais les volumes montent uniquement des dossiers de l'hôte, et non d'un autre conteneur.

Problèmes que l'on peut rencontrer

Attente de disponibilité

Lorsque le conteneur avec le service est démarré, cela ne signifie pas qu'il est prêt à accepter des connexions. Il faut attendre la connexion pour continuer.

Cette tâche est parfois résolue à l'aide d'un script wait-for-it.sh, qui attend la possibilité d'établir une connexion TCP. Cependant, LocalStack peut renvoyer une erreur 502 Bad Gateway. De plus, il se compose de nombreux services, et si l'un d'eux est prêt, cela ne dit rien sur les autres.

Solution: scripts de préparation de LocalStack, qui attendent une réponse 200 à la fois de SQS et de SNS.

Conflits de tâches parallèles

Plusieurs tests peuvent s'exécuter simultanément sur un même hôte Docker, donc les noms des conteneurs et des réseaux doivent être uniques. De plus, les tests issus de différentes branches d'un même service peuvent également fonctionner en même temps, donc il n'est pas suffisant de définir des noms dans chaque fichier compose.

Solution: le script attribue une valeur unique à la variable COMPOSE_PROJECT_NAME.

Particularités de Windows

Lors de l'utilisation de Docker sur Windows, il y a plusieurs points que je voudrais souligner, car cette expérience est importante pour comprendre les raisons des erreurs.

1. Les scripts shell dans le conteneur doivent avoir des fins de ligne en format Linux.
   Le symbole CR pour le shell est une erreur de syntaxe. D'après le message d'erreur, il est difficile de comprendre que c'est à cause de cela. Lors de l'édition de tels scripts sous Windows, un éditeur de texte approprié est nécessaire. De plus, le système de contrôle de version doit être configuré correctement.

Voici comment configurer git :

git config core.autocrlf input

1. Git-bash émule les répertoires standards de Linux et, lors de l'appel d'un fichier exe (y compris docker.exe), il remplace les chemins absolus Linux par des chemins Windows. Cependant, cela n'a pas de sens pour les chemins non situés sur la machine locale (ou dans le conteneur). Ce comportement ne peut pas être désactivé.

Solution: ajouter un slash supplémentaire au début du chemin : \/\/bin au lieu de \/bin. Linux comprend de tels chemins, pour lui plusieurs slashes sont équivalents à un seul. Mais git-bash ne reconnaît pas ces chemins et n'essaie pas de les convertir.

Sortie des logs

Lors de l'exécution des tests, il serait souhaitable de voir les logs à la fois de Newman et du service testé. Étant donné que les événements de ces logs sont liés, les combiner dans une seule console est beaucoup plus pratique que deux fichiers séparés. Newman se lance via docker-compose run, et donc sa sortie apparaît dans la console. Il reste à faire en sorte que la sortie du service y parvienne également.

La solution initiale consistait à faire docker-compose up sans le flag -d, mais, en utilisant les possibilités du shell, d'envoyer ce processus en arrière-plan :

docker-compose up <service> &

Cela fonctionnait tant qu'il n'a pas été nécessaire d'envoyer les logs de Docker vers un service tiers. docker-compose up a cessé d'afficher les journaux dans la console. Cependant, la commande fonctionnait docker attach.

Solution:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<service>_1 &

Conflit d'identifiants lors des itérations du test

Les tests s'exécutent à plusieurs itérations. La base n'est pas effacée. Les enregistrements dans la base ont des ID uniques. Si nous écrivons des ID spécifiques dans les requêtes, nous obtiendrons un conflit lors de la deuxième itération.

Pour éviter cela, soit les ID doivent être uniques, soit nous devons supprimer tous les objets créés par le test. Certains objets ne peuvent pas être supprimés, conformément aux exigences.

Solution: générer des GUID par des scripts dans Postman.

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

Ensuite, dans la requête, utiliser le symbole {{myUUID}}, qui sera remplacé par la valeur de la variable.

Interaction via LocalStack

Si le service testé lit une file d'attente SQS ou y écrit, le test doit également fonctionner avec cette file.

Solution: requêtes de Postman vers LocalStack.

Les API des services AWS sont documentées, ce qui permet de faire des requêtes sans SDK.

Si le service écrit dans la file, nous la lisons et vérifions le contenu du message.

Si le service envoie des messages à SNS, à l'étape de préparation, LocalStack crée également une file et s'abonne à ce sujet SNS. Tout cela revient à ce qui est décrit ci-dessus.

Si le service doit lire un message de la file, à l'étape précédente du test, nous écrivons ce message dans la file.

Test des requêtes HTTP sortantes du microservice testé

Certains services fonctionnent via HTTP avec autre chose qu'AWS, et certaines fonctions AWS ne sont pas mises en œuvre dans LocalStack.

Solution: dans ces cas, cela peut être utile MockServer, qui a une image prête dans Docker Hub. Les requêtes et les réponses attendues sont configurées par une requête HTTP. L'API est documentée, donc nous faisons des requêtes depuis Postman.

Test de l'authentification et de l'autorisation OAuth

Nous utilisons OAuth et JSON Web Tokens (JWT). Pour le test, un fournisseur OAuth dont nous pouvons exécuter localement est nécessaire.

Toute interaction du service avec le fournisseur OAuth se résume à deux requêtes : d'abord, la configuration est demandée /.well-known/openid-configuration, puis la clé publique (JWKS) est demandée à l'adresse indiquée dans la configuration. Tout cela est du contenu statique.

Solution: notre fournisseur OAuth de test est un serveur de contenu statique avec deux fichiers dessus. Le token a été généré une seule fois et a été commis dans Git.

Particularités du test de SignalR

Postman ne fonctionne pas avec les WebSockets. Un outil spécial a été créé pour tester SignalR.

Le client de SignalR peut être autre chose qu'un navigateur. Il existe une bibliothèque cliente pour .NET Core. Le client, écrit en .NET Core, établit une connexion, passe l'authentification et attend une séquence de messages spécifique. Si un message inattendu est reçu ou si la connexion est interrompue, le client se termine avec le code 1. Lors de la réception du dernier message attendu, il se termine avec le code 0.

Newman fonctionne en même temps que le client. Plusieurs clients sont lancés pour vérifier que les messages sont livrés à tous ceux qui en ont besoin.

Pour démarrer plusieurs clients, on utilise l'option —scale dans la ligne de commande docker-compose.

Avant de lancer Postman, le script attend que tous les clients établissent une connexion.
Nous avons déjà rencontré le problème d'attente de connexion. Mais là, il s'agissait de serveurs, alors qu'ici, c'est un client. Un autre approche est nécessaire.

Solution: le client dans le conteneur utilise le mécanisme HealthCheck, pour informer le script sur l'hôte de son statut. Le client crée un fichier à un certain chemin, disons, /healthcheck, dès que la connexion est établie. Le script HealthCheck dans le fichier docker ressemble à ceci:

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

Commande docker inspect affiche pour le conteneur l'état normal, l'état de santé et le code de sortie.

Après la fin de Newman, le script vérifie que tous les conteneurs avec le client se sont terminés, et ce, avec le code 0.

Le bonheur existe

Après avoir surmonté les complexités décrites ci-dessus, nous avons un ensemble de tests fonctionnant de manière stable. Dans ces tests, chaque service fonctionne comme un tout, interagit avec la base de données et avec Amazon LocalStack.

Ces tests protègent l'équipe de 30+ développeurs des erreurs dans une application avec une interaction complexe entre 10+ microservices lors de fréquents déploiements.

Source : habr.com