Services QA
| Présentation et définition du projet
Ce projet a été réalisé en entreprise lors de mon alternance réalisée dans le cadre du bachelor “Administrateur Système DevOps” à l’école DevUniversity. Ce projet consistait à développer deux services permettant de mettre en place un environnement de qualification pour les utilisateurs dans le nouvel environnement Cloud.
Le premier service est un système de captation des emails et le deuxième est un serveur ftp.
L’environnement de qualification est un espace dédié aux utilisateurs dans lequel ils executent des nouvelles versions d’outils en suivant des plans de tests. Si la qualification est réussie, les utilisateurs nous donnent l’aval pour les déployer en production. Cette phase de qualification par les utilisateurs n’est pas réalisée de façon systématique après chaque nouvelle version de logiciel. Logiquement, cette phase intervient après la réussite des tests réalisés par le développeur.
| Objectifs et enjeux
Les objectifs étaient de mettre en place deux types de services QA.
Tout d’abord, l’objectif était de mettre en place un système de captation des emails afin de les afficher dans une interface web. Toutes les applications à tester envoient des emails à pleins de différentes listes de distribution. Le but était de ne pas modifier tous les destinateurs lors d’une QA mais de seulement pointer les outils vers une configuration QA qui elle-même pointe vers ce service de mailing.
Ensuite, l’objectif était de mettre en place un service ftp pour simuler l’envoie des données. De même que le service de mailing, l’idée est de modifier la configuration de QA vers ce service ftp.
L’enjeu de ce projet est de pouvoir tester efficacement les outils dans l’environnement Cloud à travers des services annexes. L’enjeu du service de mailing est de ne pas polluer les destinataires avec des projets de qualification alors qu’ils sont en train de continuer à travailler sur l’ancien environnement de production.
| Contexte
Ce projet intervient vers la fin d’un très gros projet de migration vers le Cloud qui a duré trois ans. Ces services ont été demandés pour qualifier ce nouvel environnement Cloud. La qualification de cet environnement était très attendue et surveillée par le management qui a décidé selon les résultats d’acter le basculement vers le Cloud ou de le retarder car le nouvel environnement n’est pas fonctionnel. Cette phase de qualification a duré 3 mois.
Concernant le service ftp, celui-ci m’avait été demandé au moment du projet car il y avait certaines applications qui utilisaient ce type de transfert, cependant le besoin n’est plus d’actualité.
| Risques
Le risque principal était de ne pas arriver à déployer des services fonctionnels avant le début de la qualification. Cela aurait retardé la qualification et donc la potentiellement la date de migration. Ce risque était minime car ce travail m’avait été demandé plus de 6 mois avant le début de la qualification.
Concernant les services, ceux-ci devaient être disponible tout au long de la qualification avec le moins d’interruption possible. En effet, la solution devait être résiliente afin de ne pas retarder les tests de qualification ou induire des problèmes qui ne sont pas représentatifs d’incidents de production. Pour limiter ce risque, j’ai décidé d’utiliser une architecture micro-services simple, avec un système de mailing déjà existant comportant une bonne communauté. J’ai aussi réalisé de nombreux tests avant de mettre à disposition ces services.
| Etapes du projet
Choix technique
Dans un premier temps, j’ai cherché une solution existante qui proposait un système de captation de mails. Les critères principaux étaient que la solution devait être sécurisée et déployable via une image Docker. Elle devait aussi posséder de nombreuses documentations ou une large communauté. Ce système devait aussi proposer une interface web intuitive afin que les utilisateurs puissent consulter les mails. J’ai d’abord choisi mailhog mais nous avons observé des comportements inadaptés concernant le tri par date. Nous avons alors décidé d’opter pour la solution mailpit.
La solution mailpit expose deux ports. Le port 1025 est celui où mailpit écoute les connexions SMTP (Simple Mail Transfer Protocol). SMTP est le protocole utilisé pour pouvoir envoyer et recevoir des messages électroniques. Les applications en QA envoient des mails en utilisant ce port réseau, ce qui permet à mailpit d’intercepter les mails, les stocker et les afficher dans interface qui est exposée via le port 8025.
Ensuite, j’ai choisi de réaliser le service ftp via une image Docker créée à partir d’une version légère de Python. Pour cela, j’ai utilisé la librairie pyftpdlib qui m’a permis de paramétrer mon serveur et sécuriser son implémentation.
Ensuite, j’ai choisi de réaliser le service ftp via une image Docker créée à partir d’une version légère de Python. Pour cela, j’ai utilisé la librairie pyftpdlib qui m’a permis de paramétrer mon serveur et sécuriser son implémentation.
Architecture micro-services et orchestrateur podman-compose
J’ai réalisé la solution à travers une architecture micro-services comprenant 3 services. Le service mailpit pour le système de captation des mails, le service ftp et un service nginx permettant de rendre l’interface du système de mailing accessible via un url customisé.
L’orchestrateur podman-compose est un équivalent proposé par RedHat de docker-compose. Podman-compose permet une utilisation sans droit root et possède d’autres fonctionnalités comme l’utilisation d’éléments « pod » ressemblant à ce que Kubernetes peut proposer (mais fonctionnalité limitée).
Persistance des données
La persistance des données est très importante notamment sur le système de captation des emails. L’orchestrateur podman-compose a permis de facilement mettre en place une persistance. En effet, j’ai créé un volume dédié à travers le fichier podman-compose.yml. Le volume est monté sur un espace dédié aux données applicatives. Cet espace est très important et nous n’avions pas fixé de maximum d’espaces afin d’être sûrs que la solution soit toujours fonctionnelle pendant les trois mois de qualification. Un deuxième volume a aussi été créé afin d’assurer la persistance des données du serveur ftp.
Accessibilité
L’interface devait être accessible à environ 300 utilisateurs dont certains ne sont pas qualifiés en informatique. Il a été décidé de mettre en place une url simple avec le nom de domaine de l’entreprise. Par défaut, l’accès à l’interface de mailing est accessible via IP:port.
Pour cela, j’ai créé un certificat SSL. Tout d’abord, j’ai commencé par créer un fichier .key contenant une clé. Puis j’ai réalisé une demande via un fichier .csr généré à partir de la clé .key. Ensuite, j’ai réalisé une demande aux équipes internes chargées de la génération du certificat. Enfin, j’ai installé le certificat sur le serveur et configuré le conteneur Nginx pour pointer sur ce certificat.
Cette accessibilité via un domaine customisé a pu être possible grâce à la fonctionnalité « Reverse proxy » de Nginx. En effet, Nginx reçoit le trafic sécurisé, déchiffre la connexion puis transmet à l’application. L’utilisateur ne s’en rend pas compte et navigue à travers le domaine customisé.
Sécurité
Concernant le service ftp, j’ai créé un utilisateur générique qui a les accès pour déposer et lire sur le serveur distant. J’ai fait en sorte de renseigner les informations de cet utilisateur à travers le fichier podman-compose.yml et non directement dans l’image Docker. Pour cela, j’ai utilisé la fonctionnalité « secret » de Podman qui permet de stocker des informations sensibles sur l’hôte au niveau du stockage interne de Podman. Dans le fichier podman-compose.yml, seul le nom du « secret » est renseigné et Podman se charge de faire la résolution au moment de l’exécution.
Tests
Concernant les tests, j’en ai réalisé de nombreux afin d’acter la mise à disposition de ces services.
Pour le service Mailpit, j’ai réalisé des tests d’envois de mail dans le but de voir s’ils s’affichent bien à travers l’interface. J’ai essayé l’envoi depuis plusieurs serveurs et plusieurs applications. C’est à ce stade que nous nous sommes rendus compte que le premier choix Mailhog ne permettait pas un affichage optimal.
Différents tests ont aussi été réalisés pour le service ftp (accès, lecture et téléchargement).
Après la validation de tous les tests, la solution a été mise à disposition et rajoutée par les utilisateurs dans leurs procédures de qualification du nouvel environnement Cloud.
| Les acteurs
Concernant le choix technique, les solutions ont été définies avec l’ensemble de l’équipe. La réalisation du projet a été réalisé par moi-même. Mes capacités en autonomie m’ont permis de mener efficacement ce projet.
Les utilisateurs ayant ensuite utilisé ces services ont étés nombreux car ils sont environ 300 personnes pour l’interface de mailing et une vingtaine pour le service ftp.
| Les résultats
Ce projet a bien été anticipé et réalisé dans les temps. La solution a été résiliente car il n’y a pas eu d’interruption ou d’incident tout au long de la phase de qualification. Le nombre de mails capturés par le système de mailing durant cette phase de qualification n’a pas été mesuré mais il y a surement eu plusieurs milliers de mails.
Mes compétences en algorithmie m’ont permis de créer efficacement le service ftp en langage Python.
| Les lendemains du projet
Le service ftp n’est plus utilisé car les derniers serveurs ftp ont été migrés vers des serveurs sftp qui sont plus sécurisés. Cependant, le service Mailpit est toujours utilisé et permet aux utilisateurs de testers des nouvelles versions de logiciel dans un environnement dédié. Ce service a été utilisé lors de la phase de qualification du projet « Standardisation d’un flow« .
Une deuxième instance de service Mailpit a ensuite été déployée dans l’environnement PREQA utilisé seulement par les développeurs.
| Mon regard critique
Ce projet a été pour moi très enrichissant et m’a permis de continuer à développer des compétences d’orchestration de mise en place d’architecture micro-services. Je pense que les choix techniques ont plutôt été adaptés. Je pense qu’on pourrait encore améliorer cette solution en automatisant le déploiement de l’application et en ajoutant du monitoring qui testerait régulièrement un envoi de mail.