L'infrastructure as code peut être une solution complète !

Conteneurs, orchestration et informatique serverless ont révolutionné la façon de travailler. Mais comment assurer le provisionnement des ressources sans baisse d'efficacité opérationnelle ?

Selon la Cloud Native Computing Foundation, le nombre de développeurs cloud-native a augmenté de près de la moitié au cours des deux dernières années, pour atteindre 6,8 millions. Voici pourquoi.

Conteneurs, orchestration et informatique serverless ont révolutionné la façon de travailler. Avec l’accès facile au calcul, le stockage et la mise en réseau dans le cloud via le libre-service, les développeurs ne sont plus obligés de demander des ressources, ce qui se traduit par une livraison plus rapide des logiciels. Les développeurs dits très performants effectuent environ 10 déploiements par jour avec un délai d'exécution de moins d'une heure.

Toutefois, si les problèmes liés à la construction et au déploiement de ressources telles que les serveurs ont été résolus, un nouveau défi est apparu : le provisionnement des ressources sans baisse d’efficacité opérationnelle.

Le développement et le déploiement peuvent donner lieu à des pratiques et à des problèmes qui nuisent au provisionnement. Au fil du temps, les serveurs déployés peuvent s'écarter d'une configuration standard au rythme des optimisations ou des mises à jour. Cette dérive de la configuration rend difficile la gestion des mises à jour à grande échelle et donne lieu à des ‘systèmes snowflake’ qui doivent être gérés individuellement. Comme les serveurs dérivent, les services doivent également être gérés individuellement. Enfin, il y a la mise hors service, qui est non seulement longue et complexe, mais aussi coûteuse : si vous oubliez d'éteindre des serveurs ou des services, vous recevrez une facture malvenue de votre fournisseur de services cloud.

La solution ? L'infrastructure as code (IaC). Il s'agit d'appliquer des pratiques d'ingénierie logicielle telles que le versionnage et les tests de l'infrastructure cloud-native afin de la rendre cohérente pour un provisionnement simplifié.

Facile ? Pas vraiment. Selon le dernier rapport State of the Cloud de Flexera, la plupart des entreprises utilisent par défaut des systèmes hybrides et multiclouds, ce qui signifie que l'IaC doit être capable de couvrir chaque fournisseur et chaque service. Mais, selon Flexera, seuls 25% utilisent des outils pour gérer le multicloud. En d'autres termes, ils exploitent leur infrastructure et les éléments qui la composent comme une série d'îlots non connectés.

Une IaC à part entière peut résoudre ce problème en jetant les bases d'une infrastructure cohérente et prévisible, indispensable pour fournir des systèmes cloud-native à grande échelle et à la vitesse requise.

La théorie de l'idempotence

Au cœur de l'IaC, il y a le principe d'idempotence. Il s'agit d'une commande de déploiement qui définit l'environnement cible avec la même configuration, quel que soit le moment où elle est activée. L'idempotence est obtenue automatiquement, soit en configurant une cible existante, soit en abandonnant cette cible et en créant un nouvel environnement. Avec l’IaC, les modifications sont apportées au modèle de description de l'environnement et de configuration de la version ; ce modèle est exécuté par le pipeline CI/CD.

Comment cela fonctionne-t-il dans le monde réel pour les développeurs ?

Tout d'abord, il faut décrire votre infrastructure sous la forme d'un mode déclaratif. Celui-ci définit l'état de votre système, des ressources telles que les serveurs, et enregistre leurs propriétés et les outils permettant de les configurer, ce qui facilite leur provisionnement cohérent et permet un retour en arrière. Vous pouvez également utiliser un mode impératif qui définit des commandes spécifiques et l'ordre dans lequel elles sont exécutées afin d'obtenir l'état souhaité ; sachez que la plupart des outils IaC – Terraform, Pulumi, CloudFoundation et Puppet – choisissent le mode déclaratif.

Viennent ensuite les modèles. Ils sont utilisés pour capturer l'état exact d'une ressource ou d'un environnement individuel, un serveur, par exemple. Un outil déclaratif utilise le modèle pour traiter la logique et les appels API nécessaires pour configurer une machine en nuage, la zone, le système d'exploitation, le cluster, etc. Par exemple, un modèle peut spécifier un serveur Debian sur GWC avec stockage, calcul, réseau et sécurité. Les modèles, cependant, servent un deuxième objectif : ils vous permettent de déployer des ressources par le biais d'une interface graphique, supprimant ainsi la nécessité de travailler au niveau de la ligne de commande ou de l'API. Les modèles sont donc une étape importante dans l'abandon d'une approche du provisionnement basée sur le codage qui, utilisée au fil du temps, contribue inévitablement à la dérive de la configuration.

Suivez le flux de travail

Le troisième élément de l’IaC est le flux de travail. Une fois que vous avez créé votre ressource, vous devez savoir comment elle se comportera : il faut donc prévoir des tests d'exécution, des tests unitaires, des tests d'intégration et des tests de sécurité à différentes phases : construction, acceptation, répétition et livraison. Ces phases sont mises en œuvre dans le pipeline CI/CD et doivent être réalisées après la création des demandes de déchargement et avant le déploiement.

Les phases du flux de travail peuvent être personnalisées et les événements de chacune d'elles définis à l'aide de cookbooks et de runbooks. Les meilleures sources pour la création de flux de travail sont les références du secteur, les fournisseurs de cloud ou les spécialistes DevOps, les modèles de menaces de sécurité ou les pratiques et procédures de votre entreprise.

Il y a trois meilleures pratiques à observer ici. Premièrement, ne figez pas vos flux de travail. Utilisez plutôt une approche basée sur un cadre qui permet aux flux de travail d'évoluer en fonction des besoins. Deuxièmement, les workflows doivent être ouverts pour permettre aux outils de différents fournisseurs de s'y brancher. Troisièmement, vous devez tester les flux de travail pour vous assurer qu'ils provisionnent correctement les ressources telles que les serveurs et déploient les paquets comme prévu.

Le dernier élément de l'IaC est l'automatisation. Un moteur d'automatisation optimise le potentiel des flux de travail et des modèles en les mettant en œuvre conformément aux exigences et aux spécifications du modèle d'infrastructure. Il sert de moyen de gestion des changements et de déploiements, en garantissant que les paramètres corrects sont appliqués pour obtenir une cohérence. Il vous permet également d'intégrer votre pipeline et vos outils CI/CD

L'automatisation peut être appliquée localement ou globalement. Dans le premier cas, elle s'exécute à l'aide de scripts enveloppants ; dans le second, elle s'exécute sur l'ensemble de votre infrastructure à l'aide d'un outil d'orchestration tel que Jenkins. Tous les moteurs d'automatisation ne sont pas identiques. Ils présentent des caractéristiques et des capacités différentes et chacun d'entre eux a un attrait différent et des ramifications différentes pour le DevOps. Par exemple, certains peuvent être hébergés en ligne, d'autres installés sur site et d'autres encore disponibles dans les deux options. Autres points à prendre en compte : voir si votre moteur suppose que l'environnement de mise en œuvre est le même que celui qu'il utilise ; s’il a le niveau d'intégration avec des outils tiers ; s'il suppose que les plug-ins restent les mêmes après le déploiement d'un changement ; et s'il met en œuvre les plans de changement simultanément ou individuellement.

Conclusion

Le cloud native a fait son entrée dans le monde des technologies d'entreprise grâce à la flexibilité et à la puissance qu'il confère aux développeurs. Mais un provisionnement efficace doit suivre pour que le cloud native atteigne son potentiel opérationnel. L'application des pratiques de l'ingénierie logicielle à l'infrastructure cloud native et, par conséquent, l'exploitation de l'infrastructure en tant que code permettent de libérer ce potentiel.