Novatopo est une place de marché consacrée aux activités de sport ou de loisirs, comme l’escalade, les escape game ou la course d’orientation. Pour assurer la scalabilité et la résilience de son infrastructure, la start-up a fait le choix du Cloud AWS. Dans un précédent article, Romain de Dion nous expliquait pour quelles raisons il avait choisi le Cloud. Aujourd’hui, Lucien Peslier, développeur front-end, revient sur le processus de refonte de l’infrastructure mené avec D2SI et sur sa montée en compétence sur AWS.

Lucien est développeur front-end chez Novatopo depuis un an. Après avoir obtenu sa licence professionnelle TAIS (développement web) en alternance, il a travaillé dans une agence de communication à Strasbourg avant de rejoindre Novatopo. Curieux et en quête perpétuelle de nouveauté, il cherche à optimiser ce qu’il fait en permanence.  Outre ses missions spécifiques de développeur, il prend également en charge la partie Devops.

Quelle était votre expérience du Cloud AWS ?

Notre infrastructure était sur AWS mais nous n’utilisions que très peu de fonctionnalités du Cloud. Le lancement des instances et la plupart des actions étaient manuelles. Idem pour la configuration d’infrastructure, à laquelle j’avais pris part : tout était manuel. Par conséquent, je ne comprenais pas vraiment ce qu’était AWS et son intérêt. J’étais pourtant intéressé par l’infrastructure, mais sans compétence sur le sujet.

Comment êtes-vous passé à une nouvelle infrastructure ?

Jérémie (D2SI) a mis en place l’infrastructure telle qu’elle est aujourd’hui, et il nous a fourni une documentation très complète. J’ai pu me former au fur et à mesure sur AWS en prenant en main la plateforme, et ainsi comprendre le fonctionnement des services.

Par la suite, j’ai continué à enrichir la nouvelle infrastructure : j’ai intégré les retours du product owner, j’ai automatisé plus de choses sur la partie CI/CD. J’ai aussi mis en place un nouveau système de déploiement avec Code Deploy. Tout cela sur la base de ce qui a été livré par D2SI. L’accompagnement de Jérémie et la documentation m’ont donné toutes les notions nécessaires pour développer des améliorations.

Comment s’est déroulé la passation ?

J’ai demandé à Jérémie de nous fournir une procédure à suivre en cas de souci en production. Comment faire si on doit remonter l’infrastructure en urgence? Jérémie m’a expliqué les étapes de résolution d’une panne, où trouver les logs dans Cloudwatch, et nous avons parcouru ensemble les différentes configurations Terraform pour en comprendre le fonctionnement. Nous avons ensuite pratiqué ensemble, et avec la documentation en complément c’était une bonne base pour commencer. 

Qu’est-ce que tu as apprécié dans l’accompagnement de D2SI ?

J’ai apprécié qu’il y ait un vrai accompagnement en dehors du travail livré. Tout était documenté, expliqué, et nous avons eu de nombreux échanges avec Jérémie. Il n’y avait rien de laissé au hasard. L’infrastructure était également très sécurisée, il n’y avait pas de risque de faire de mauvaise manipulation. Jérémie a aussi mis en mis en place de nombreuses vérifications sur le système de déploiement, cela m’a permis de ne pas faire d’erreurs, moi qui débutais dans le devops.

Qu’est-ce que la refonte de l’infrastructure a changé ?

Tout est automatisé. Il n’y a plus aucun hasard, tout est clair. Maintenant, s’il se passe quelque chose, on peut immédiatement identifier la source du problème grâce aux logs. Avant, c’était flou : il n’y avait pas de documentation, uniquement des procédures manuelles, et nous étions dépendants d’un prestataire pour relancer un service. Cela posait aussi des problèmes de sécurité, puisqu’on pouvait se connecter à l’instance directement. Maintenant, nous avons des bastions où toutes les actions sont loggées, et qui sont le seul point d’entrée vers une instance. Et il est impossible d’accéder au bastion sans clé SSH enregistrée sur un Github. Tout est sécurisé et nous avons une vision sur chaque événement. L’intervention de D2SI nous a permis de comprendre le réel intérêt du Cloud et des outils AWS.

Cela vous a donné envie de continuer à approfondir les services AWS ?

J’ai commencé à étudier les services AWS qui pourraient nous être utiles, et c’est comme ça que j’ai mis en place Code Deploy qui nous assure de n’avoir aucun downtime et automatise encore un peu plus le processus. Le service AWS lance la nouvelle instance, vérifie que les conteneurs Docker répondent bien, puis il route le trafic vers la nouvelle instance et détruit l’ancienne. Nous utilisons aussi beaucoup de lambdas, pour créer des fonctions qui interagissent avec notre CI/CD et récupèrent des données sur AWS. Toutes nos données AWS passent par une Lambda avant d’être renvoyées à Circle CI, notre outil d’intégration continue.Nous utilisons aussi API Gateway pour récupérer certaines données d’AWS. Par mesure de sécurité, il n’est plus possible de récupérer des données manuellement, nous avons donc créé des droits spécifiques avec IAM pour chaque fonctionnalité.

Est-ce compliqué d’intégrer les bonnes pratiques du Cloud quand on est développeur frontend ?

J’ai regardé ce qui avait mis en place par Jérémie, j’ai essayé de comprendre et de le reproduire, pour voir ensuite comment l’infrastructure se comportait. C’est ma façon de fonctionner, j’ai besoin d’essayer, de tester concrètement. Terraform permet de planifier et de voir le résultat, ça m’a permis d’expérimenter et d’apprendre les bonnes pratiques. De la même façon, j’ai appris comment créer des stratégies spécifiques pour des actions, comme récupérer un fichier sur S3. 

Quels sont les services AWS utilisés aujourd’hui ?

Nous utilisons des fonctionnalités comme l’auto-scaling group pour dimensionner au mieux notre infrastructure, ELB pour répartir la charge, ou les Security group. Nous avons aussi migré de Cloudflare vers Route 53, et dans l’optique de tout rassembler sur AWS, nous sommes passé sur ECR pour stocker nos images. Nous utilisons aussi SNS pour lancer des déploiements : on déclenche une Lambda via SNS. 

Comment vois-tu l’évolution de ton rôle, entre front-end et infrastructure ?

Actuellement je consacre plus d’un quart de mon temps à l’infrastructure. C’est un poste à part entière, il y a toujours quelque chose à améliorer ! L’avantage est que je peux utiliser le même langage qu’en développement frontend, le Javascript. Si je n’envisage pas de me dédier complètement au DevOps, j’apprécie néanmoins de faire plus d’infrastructure. Avoir une position hybride entre le frontend et l’infrastructure AWS me permet de faire le lien avec les développeurs, de concilier les besoins du frontend et les contraintes d’infrastructure.

Quel est le retour de l’équipe sur cette nouvelle infrastructure ?

C’est un vrai gain, tout est stable et automatisé aujourd’hui. Nos développeurs n’ont plus besoin de chercher pourquoi un serveur est tombé. Si une instance tombe ce n’est plus à cause d’un problème d’infrastructure, ou de limite de mémoire sur les conteneurs : c’est dû à un bug de code. Migrer sur le Cloud et laisser une partie du travail à AWS nous a fait gagner beaucoup de temps, et le fait d’avoir des logs détaillés pour chaque service est un réel avantage. J’ai été surpris par l’importance du nombre de services disponibles sur AWS. Cela ouvre de nombreuses possibilités, des fonctionnalités auxquelles je n’aurais pas pensé, et que j’ai découvert en lisant la documentation. Je travaille par exemple actuellement sur un système de versionning des déploiements, pour pouvoir faire des roll backs plus facilement.