Loading...Le monde d’aujourd’hui évolue plus rapidement que jamais ! Dans pratiquement tous les contextes d’entreprise, la rapidité est un facteur clé – dans certains cas, il est même le plus important.
Toutes les start-ups veulent être les premières à commercialiser leurs produits, toutes les entreprises veulent avoir une longueur d’avance sur leurs concurrents.
Et cela repose principalement sur les épaules des développeurs, c’est-à-dire nos épaules.
Heureusement, les services AWS sont là pour nous faciliter la vie et nous offrir un développement plus efficace et un déploiement plus rapide.
Le monde aujourd’hui évolue rapidement, cela devrait également être le cas de vos conteneurs ! À l’occasion d’un événement PentaBAR que j’avais organisé à l’agence Pentalog de Iasi, j’ai expliqué comment développer un conteneur Docker avec son propre pipeline de CI/CD TypeScript (avec le nouveau CDK) et les services AWS.
Nous devons être plus productifs, efficaces, et nous ne pouvons pas nous permettre d’attendre des semaines ou des mois pour que quelqu’un, quelque part, mette en place un serveur pour notre nouveau POC.
Alors, comment y parvenir ?
Deux mots : Abstraction et Automatisation dans les services AWS
Cela n’a rien de nouveau dans le domaine du développement logiciel, mais comment peut-on l’appliquer à l’univers des infrastructures ?
C’est justement là que « l’infrastructure as code » entre en jeu.
L’idée principale de « l’infrastructure as code » est que les systèmes et appareils utilisés pour exécuter un logiciel sont traités comme s’ils étaient eux-mêmes des logiciels.
Cela offre les avantages suivants :
-
Automatisation (l’avantage est ici évident)
-
Répétabilité (le même code produit la même infrastructure)
-
Gestion des versions (tout se trouve dans notre dépôt git et a le même flux que le produit logiciel principal)
Examinons d’un peu plus près l’historique de « l’infrastructure as code » dans les services AWS :
IAC V1 : CloudFormation JSON
Au milieu des années 2010, AWS lance CloudFormation, un service qui :
« …fournit un langage commun pour décrire et provisionner toutes les ressources d’infrastructure dans votre environnement cloud. Il vous permet d’utiliser un simple fichier texte pour modéliser et provisionner, de manière automatisée et sécurisée, toutes les ressources nécessaires pour vos applications à travers toutes les régions et tous les comptes. Cela vous donne une source de vérité unique pour vos ressources AWS et tierces. »
En réalité, CloudFormation se compose de deux parties :
-
Les modèles qui décrivent votre infrastructure
-
Les services AWS qui utilisent ces modèles afin de provisionner l’infrastructure pour vous (gérant ainsi l’état, contrairement à d’autres outils comme terraform, où vous avez la responsabilité de gérer l’état d’une manière ou d’une autre)
Bien que révolutionnaire à l’époque, tout le monde détestait l’un de ces aspects : les modèles étaient au format JSON !
Nous nous souvenons tous du débat JSON vs XML : nous sommes passés à JSON car il est plus facile à lire par des humains que XML, il est plus facile à analyser et il économise de la bande passante ! (Point très important pour les applis mobiles !)
Mais on se rend rapidement compte qu’il n’est finalement pas si facile à lire par des humains lorsqu’il faut gérer des milliers de lignes de modèles JSON.
Exemple d’un modèle de CloudFormation pour une instance EC2 et un groupe de sécurité au format JSON.
IAC V1.1 : CloudFormation YAML
À mesure que la popularité du service s’est accrue, la difficulté à gérer JSON est devenue de plus en plus forte.
En 2016, AWS a lancé l’éditeur YAML pour CloudFormation, qui permet :
-
D’ajouter des commentaires à votre code
-
D’utiliser des fonctions intrinsèques courtes (de { “Fn::Base64” : valueToEncode } à !Base64 valueToEncode)
Bien qu’imparfait, cet outil représentait une amélioration bienvenue. Le même modèle qui ajoute une instance ec2 et un groupe de sécurité ressemble désormais à cela :
Modèle d’application sans serveur IAC V1.2
À peine quelques mois plus tard, toujours en 2016, AWS décide d’éditer SAM, conçu pour vous aider à déployer plus facilement des applications sans serveur.
Cela était certes possible avec CloudFormation seul, mais SAM simplifiait énormément le processus.
Par exemple, créer une fonction lambda est passé de cela :
À cela :
Une amélioration majeure pour les développeurs sans serveur, non ?
Notons que SAM apporte bien d’autres avantages aux développeurs : débogage local, meilleures pratiques intégrées, etc.
Le plus intéressant reste la manière dont il y parvient, et la réponse est étonnante : les
« transforms »
Les « transforms » sont, pour résumer, des pré-processeurs qui se basent sur votre modèle YAML pour les étendre.
Cerise sur le gâteau : vous pouvez créer vos propres transforms !
Mais je ne vais pas entrer dans les détails, car je m’apprête à aborder la partie la plus intéressante !
IAC V2 Cloud Development Kit (CDK)
Prenez l’idée des « pré-processeurs » et ajoutez-y un véritable langage de programmation – vous obtenez le CDK.
Ajouter une fonction lambda ressemble désormais à cela :
Alors certes, il ne dépasse pas la limite habituelle de 120 caractères pour l’analyse du code en tant que ligne unique, mais il reste impressionnant.
C’est là que la vraie abstraction entre en jeu : vous pouvez écrire votre infrastructure en tant que modules de niveau plus élevé et les utiliser comme vous le feriez avec n’importe quelle bibliothèque.
Cet article était l’occasion d’aborder un aspect plus technique et de mieux saisir l’intérêt des services AWS pour répondre aux besoins DevOps.
Néanmoins, j’aimerais rappeler que le succès d’une implémentation DevOps au sein de votre équipe reposera à part égale sur ses compétences techniques et son aptitude à appliquer les pratiques Agiles. Dans cet article justement, nous expliquions pourquoi l’agilité était une condition sine qua non aux pratiques DevOps.
Pour un déploiement DevOps sans fausse note, je vous invite à découvrir les 5 erreurs les plus communes lors de la mise en place d’une approche DevOps afin de compléter votre lecture.
