Share:

Dans cet article, Kleopatra Chatziprimou, développeur de systèmes Cloud chez Cloudreach, partage quelques conseils sur la création d’infrastructures Cloud natives.

Une partie importante de mon travail en tant que développeur de systèmes Cloud chez Cloudreach consiste à me tenir au courant des dernières tendances en matière de conception de systèmes Cloud natifs. En novembre 2018, j’ai assisté à la conférence O’Reilly Velocity qui a réuni des conférenciers partageant les meilleures pratiques et les leçons apprises sur la création d’une infrastructure Cloud native ou Infrastructure-as-Code (IaC). L’événement m’a fait réfléchir à la façon dont IaC couvre bien plus que les racks de serveurs, le réseau et le stockage de la Conférence Velocity. C’est la combinaison de philosophies, de pratiques et d’outils culturels qui augmente la capacité d’une organisation à fournir de manière fiable des applications et des services à grande vitesse et à faible coût. Dans cet article, je discuterai des défis liés à la construction d’une infrastructure évolutive et fournirai une méthodologie de meilleures pratiques pour démarrer avec IaC, y compris les tests d’environnement continus, l’automatisation de l’infrastructure, la gestion de la configuration et plus encore. Allons-y !

Défis liés à la conception des infrastructures

Les systèmes distribués modernes sont intrinsèquement complexes, couvrant plusieurs technologies, groupes et parfois différentes organisations. Le plus poignant, c’est qu’ils peuvent échouer de manière inattendue. L’adoption de technologies d’infrastructure dynamiques telles que le Cloud, les conteneurs et le sans serveur facilite le provisionnement, la configuration, la mise à jour et la maintenance des systèmes et facilite ainsi l’amélioration continue de la qualité. IaC peut rendre les systèmes cohérents, fiables et faciles à gérer, mais une base de code peut facilement devenir compliquée, fragile et désordonnée, donc impossible à modifier ou à améliorer. La facilité de provisionnement d’une nouvelle infrastructure peut conduire à un portefeuille de systèmes en croissance constante, et il faut de plus en plus de temps pour éviter que tout ne s’effondre. La gestion des changements d’une manière qui améliore la cohérence et la fiabilité ne sort pas de la boîte avec IaC. Afin de modifier, d’étendre et d’améliorer régulièrement l’infrastructure, les équipes doivent avoir l’assurance que les modifications fonctionneront correctement et que l’impact des défaillances est faible et facile à corriger. Une infrastructure performante ne peut être fournie qu’en s’appuyant sur les principes fondamentaux et les pratiques clés de l’industrie.

Une méthodologie recommandée pour commencer avec IAC

  • Vitesse

Se déplacer à grande vitesse permet aux clients d’innover plus rapidement, de s’adapter à l’évolution des marchés et de croître plus efficacement. Pour ce faire, les équipes d’ingénierie doivent décider de leur approche de développement afin qu’une faible proportion de temps soit consacrée à la résolution des problèmes et que davantage soit investie dans la valeur ajoutée. Une approche de développement courante, principalement observée dans les startups, consiste à privilégier la vitesse à l’exactitude, ce qui entraîne souvent des échecs rapides à faible coût. Le côté opposé, avec l’exemple des grandes sociétés financières, privilégie l’exactitude à la vitesse à un coût élevé. Cependant, les longs délais et les processus complexes qui en résultent finissent par poser des obstacles à la qualité. Dans de tels scénarios, la liste des problèmes connus, ainsi que la pression du temps pour les nouvelles versions, ne cessent de croître.

  • Livraison rapide

Ayant traité les deux extrêmes décrits ci-dessus chez Cloudreach, je suis un défenseur de la construction de produits minimum viables (MVP), des mises en production fréquentes et de l’adoption d’un développement piloté par les tests avec des tests fréquents et des commentaires rapides des clients. Les ingénieurs peuvent progresser rapidement et assurer l’exactitude des systèmes dans des cycles de développement contrôlés. La fourniture de MVP n’est possible que lorsque les équipes client, de développement et d’exploitation ne sont plus « cloisonnées », mais fusionnées en une seule équipe où les ingénieurs travaillent tout au long du cycle de vie de l’application, du développement et des tests au déploiement en passant par les opérations, et développent une gamme de compétences qui ne se limite pas à une seule fonction.

  • Outils du Cloud natif

Une pile technologique et des outils du Cloud natif peuvent aider les équipes à exploiter et à faire évoluer les applications rapidement et de manière fiable. Ces outils aident également les ingénieurs à accomplir de manière indépendante des tâches (par exemple, le déploiement de code ou le provisionnement de l’infrastructure) qui auraient normalement nécessité l’aide d’équipes externes, ce qui augmente encore la vitesse d’une équipe. Vous trouverez ci-dessous la liste des catégories d’outils Cloud standard :

  • Développement d’applications : IDE, outil de construction, tests unitaires.
  • Empaquetage d’application : Docker, war, jar, PRM, .deb.
  • Plateformes d’exécution d’applications : PaaS, sans serveur, container orchestration.
  • Livraison des modifications : Jenkins, orchestration de pipeline, analyse de code statique.
  • Gestion opérationnelle : outils de suivi.
  • Infrastructure dynamique : API Cloud, virtualisation, conteneurs, sans serveur.
  • Pool de ressources : infrastructure physique (calcul, réseau, stockage)
  • Outils de gestion de pile : Terraform, Cloudformation, GCP Deployment Manager/Azure Resource Manager, Sceptre.
  • Outils de configuration du serveur : Ansible, Chef, Puppet, Saltstack.
  • Création d’image serveur : Packer.

Chez Cloudreach, nous utilisons la pile complète pour développer des produits de bout en bout couvrant des applications indépendantes de l’infrastructure, pour mettre en œuvre un déploiement automatisé de l’infrastructure, dans les tests et la validation, et dans les pipelines de conception pour empaqueter et déployer les modifications dans tous les environnements. Nous gérons également la configuration dans les systèmes où l’infrastructure est reconstruite, étendue et réduite dynamiquement. J’aime utiliser Sceptre, un outil développé en interne chez Cloudreach, pour permettre aux clients de provisionner, modifier et détruire les modèles Cloudformation de manière reproductible, permettant aux développeurs d’optimiser leur temps et de se concentrer sur la création de meilleurs environnements. Il ajoute également des fonctionnalités extensibles basées sur les fonctionnalités offertes par CloudFormation brut, ce qui ajoute à la richesse de l’écosystème AWS.

  • Gestion de la configuration

La configuration autour de l’infrastructure et des applications est importante pour développer une base de code maintenable et facilement reproductible dans tous les environnements. La meilleure pratique consiste à ajouter une configuration dans un format standardisé et facilement maintenable composé de composants déployables indépendamment avec une cohésion fonctionnelle élevée avec les attributs suivants :

  • Externalisé : visible, auditable et gérable avec des outils standard.
  • Composable : peut être divisé entre les équipes, les modifications peuvent être publiées indépendamment à différentes instances, la configuration est testable à différents niveaux précis.
  • Sans surveillance : prend en charge l’utilisation automatisée, par exemple CI/CD.
  • S’intègre :se marie parfaitement avec les autres outils décrits ci-dessus

Pour ce faire, les ingénieurs doivent allouer du temps pour aborder de manière critique la configuration, identifier l’espace variable et le séparer du code. D’après mon expérience, si la configuration manque les attributs ci-dessus, elle devient un monolithe. Une base de code monolithique est rapide à développer mais aussi fragile, sujette aux erreurs et difficile à tester. Cela finira par ralentir la livraison car elle ne peut pas être prolongée ou partagée entre les équipes.

  • Tests continus

L’infrastructure de test doit inclure des tests automatisés des piles. Il existe deux approches principales pour les tests ;

  • Test d’instance éphémère : exécutez des tests, puis détruisez toute l’infrastructure éphémère créée pour les exécuter. Cette méthode est rentable mais lente, car l’ensemble de la solution doit être créé à partir de zéro à chaque fois.
  • Test d’instance persistant : exécutez les tests et laissez-les. Cette méthode est rapide à appliquer aux changements aux environnements existants, mais elle implique des coûts d’exploitation plus élevés de l’infrastructure déployée en permanence.

La validation de la syntaxe et le linting sont des conditions préalables à des tests efficaces. Ce sont les seules actions qui peuvent être effectuées pour se préparer à des tests qui ne nécessitent pas le déploiement d’une nouvelle infrastructure. Contrairement au développement logiciel traditionnel, où la moquerie peut être utilisée pour découpler les composants de test, la moquerie des API Cloud est moins utile lors des tests d’infrastructure. L’infrastructure de test peut être créée dans le code de test (makefile, make targets), dans les scripts de build (par exemple terraform) et dans des outils comme test-kitchen (c’est-à-dire l’outil chef qui orchestre l’environnement).

  • Sélection de l’environnement

Plusieurs environnements peuvent être utilisés pour gérer la complexité des tests (par exemple, intermédiaire, assurance qualité). Cependant, plusieurs environnements de test peuvent également entraîner des incohérences en raison de la variabilité entre eux. Pour éviter ce problème, il est recommandé aux ingénieurs de minimiser la surface configurable de l’infrastructure. Un nombre élevé de paramètres configurables enlève généralement de la puissance des tests, car les déploiements ne peuvent pas fonctionner dans tous les environnements en même temps.

Les modifications doivent être promues à l’aide d’un pipeline, en promouvant le code d’un environnement à l’autre. Contrôles de code source avec des branches et des balises pour décider quelle version du code s’applique à quel environnement est nécessaire. Comme ligne directrice pour les utilisations de différents environnements, les éléments suivants sont recommandés : Environnement sandbox pour les ingénieurs individuels, Environnement de test pour le rôle d’escouade de produits, Environnement client pour l’escouade de produits (processus de bris de verre applicables), Environnement de service de livraison pour l’équipe d’opérations de livraison et Environnement de service opérationnel pour l’escouade d’opérations pertinente.

  • Automatisation

L’un des ingrédients fondamentaux de l’adoption de l’automatisation de l’infrastructure est la notion de changements immuables emballés sous la forme d’images de serveur. Les images « cuites » ou les images « dorées » sont testées une fois, puis utilisées plusieurs fois. En conséquence, la cuisson est recommandée pour les solutions lourdes qui n’impliquent pas souvent de changements. D’autre part, des images « frites » sont ajoutées au moment de la création de l’instance. Par conséquent, ils sont plus appropriés sur les cas d’utilisation plus légers.

Deux approches de développement sont disponibles pour les images « cuites » :

  • Push (par exemple Ansible) : le langage d’automatisation peut effectuer des installations, obtenir un accès privilégié aux serveurs et n’a pas besoin d’un logiciel de gestion de configuration pour s’exécuter.
  • Pull (par exemple, Chef & Puppet) : un logiciel de gestion de la configuration est utilisé et extrait les configurations d’un emplacement central pour configurer l’instance plutôt que d’obtenir un accès privilégié aux serveurs.

Je préfère la méthode Pull car il est plus simple de gérer la configuration à partir d’un seul emplacement central tout en évitant l’utilisation de privilèges élevés des serveurs, ce qui augmente la sécurité et réduit les risques.

En combinant les pratiques discutées chez Velocity et notre expérience chez Cloudreach, les praticiens DevOps sont invités à prendre en compte les modèles et les anti-modèles ci-dessous lors de la création de solutions Cloud natives :

Modèles :

  • Chaque pile d’infrastructure doit se trouver sur un pipeline de livraison.

  • Chaque application a son propre pipeline avec sa propre pile.

  • Utiliser des piles d’infrastructure partagée pour les ressources partagées au sein de l’équipe (par exemple, pipeline VPC partagé). De cette manière, les ingénieurs peuvent s’appuyer sur le code extensible et éviter les efforts de duplication.

  • La pile du fournisseur ne doit pas connaître ses consommateurs, doit être minimale, divisée en piles plus petites pour éviter les monolithes rigides et non testables.

  • Les piles « shared-nothing » approchent, les équipes ne partagent rien et utilisent des infrastructures distinctes telles que des sous-réseaux et des clusters kubernetes.

  • Éviter les accouplements serrés

Antimodèles :

  • N’exécutez les outils de gestion de la configuration que lorsque vous avez des modifications spécifiques à apporter. De cette façon, les changements s’accumuleront au fil du temps et conduiront à des incohérences.