De l’Infrastructure as code à l’Everything as code

L’Everything as code est-il l’avenir de l’Infrastructure as code ? Tout porte à le croire. Avant de se pencher sur le phénomène de l’Everything as code (XaC), revenons sur l’Infrastructure as code (IaC).

L’Infrastructure as Code se définit par la capacité à décrire un état désiré d’une infrastructure ou d’une plateforme dans un document. C’est l’outillage qui permet de faire la transformation d’un document vers la création, la suppression ou la mise à jour des ressources pour que l’état désiré soit restitué sur l’infrastructure.

L’Infrastructure as Code offre plusieurs possibilités :

  • Tracker les changements qui se déroulent sur l’infrastructure à travers des guides. Ils rassemblent les commit Git réalisés, le changelog associé et listent, via l’application du Terraform plan, les changements déclenchés par la mise en œuvre des modifications. Grâce au mécanisme de GitOps, avec le git et le pull/merge request, la revue de code commune est simplifiée. En effet, les autres collaborateurs ont accès aux dernières productions, corrigent les potentielles erreurs et vérifient le fonctionnement de la plateforme.
  • S’outiller de modules templatisés et réutilisables. Par le fonctionnement en brique, les modules permettent de recréer plus rapidement une plateforme. Il est également possible d’utiliser des templates de plateformes complètes. Très intéressant dans les grands projets, le système par template simplifie l’instanciation des infrastructures dans une nouvelle région et/ou la synchronisation des différents environnements.
  • Exploiter les outils d’intégration continue pour faire des tests de validation du code (sur des aspects de sémantique par exemple) ou s’assurer que tout fonctionne selon le plan lors de la mise en production.

Les trajectoires de l’Infrastructure as code apportent une réponse sur l’Everything as code dans les années à venir.

L’Infrastructure as code s’étend au sein de Claranet

L’Infrastructure as code gérée localement par une équipe offre une bonne maîtrise. Toutefois, comment s’assurer que les usages et les bonnes pratiques passent à l’échelle ? La question devient plus épineuse lorsque des équipes transverses ou expertes sont conviées.

Harmoniser les pratiques via un framework

La première démarche consiste à créer un framework commun à toutes les équipes concernées. Claranet œuvre à la création dudit framework afin de garantir le même niveau de travail et de service.

Le choix de l’outil

Avant de procéder à l’élaboration du framework, le choix de l’outil a façonné notre approche en imposant certaines fonctionnalités et aussi, il faut bien le reconnaître, un certain nombre de limites.

Aux prémices, il n’existait que deux options :

  • Décrire l’infrastructure avec du code JSON, un format de données issu du monde Javascript dont les propriétés le rendent difficilement lisible et donc à maintenir dans le temps
  • Employer un Domain Specific Language appliqué à l’infrastructure : Terraform

En dépit de sa jeunesse et des reproches sur son manque de généricité, Terraform et son langage HCL se sont rapidement imposés auprès des équipes et plus généralement sur le marché.
L’outil disposait et dispose toujours d’une base grandissante de provider (chaque provider étend les capacités en permettant d’exposer les API d’un fournisseur pilotable à l’aide de Terraform) et permet d’avoir un seul et unique flux de travail quelle que soit l’infrastructure ciblée.

Certains promoteurs du produit ont pensé que Terraform serait la réponse ultime pour rendre agnostique un document d’infrastructure. Soyons clair, il n’en ait rien. Le document devant être réécrit intégralement (module compris) pour fonctionner sur un autre Cloud Service Provider.

À l’origine du framework, le wrapper

Conscientes de cette nécessité, les équipes de Claranet ont construit il y a quelques années, un wrapper pour Terraform. Celui-ci s’inspire du concept de Ruby on Rails qui prône la convention over configuration. En d’autres termes, l’environnement de travail, à travers sa structure, doit rester identique, quel que soit le projet, afin d’offrir la même expérience aux diverses équipes.

Claranet se donne pour mission d’encourager les bonnes pratiques et de construire une approche commune dans la gestion des états. Spécifiques à Terraform, leur sécurisation est primordiale pour garantir un fonctionnement cohérent.

Contribuer au provider Terraform

Disposant d’une base de provider Terraform vaste et opensource, la marche à franchir pour étendre ses capacités ou développer de nouveaux providers étaient naturellement accessibles à notre population DevOps rompue au langage Golang.

De nouveaux « providers » développés par Claranet ont par conséquent vu le jour permettant de gérer d’autres service comme le déploiement de Bastion, la création d’utilisateurs dans certains systèmes ou bien encore d’ajouter la gestion des contrôles pour une meilleure maitrise sur les changements.

Demain, les Active Directory et la gestion des utilisateurs dans les Active Directory pourraient être gérés depuis l’Everything as code. Les collaborateurs pourraient alors créer un Active Directory traçable dont les paramètres pourraient être reconstruit depuis une feuille blanche. Nous disposerions ainsi d’une arme redoutable pour lutter contre les rançongiciels. Une partie de la gestion de l’AD pouvant être considérée comme immutable…

Monitorer

En parallèle de l’investissement sur les providers, Claranet s’est penché sur le Monitoring as code en créant des templates en open source. Les providers et templates sont disponibles sur le GitHub de Claranet, ils incluent les seuils de monitoring les plus intelligents et génériques possible.

Changer d’échelle

L’Everything as code intègre également les escalades grâce, par exemple, à des outils comme PagerDuty paramétré à l’aide du même processus. La distribution des équipes, les plannings d’astreinte ainsi que l’intégration avec les sources d’alertes sont également décrites pour permettre le passage à l’échelle de nos opérations.

Les solutions Claranet

Face à l’engouement pour Terraform, Claranet a développé plusieurs solutions.

Le module AKS

A titre d’exemple, le Terraform AKS module permet d’instancier le service Kubernetes managé par Azure avec l’ensemble des composants permettant d’en garantir son exploitation. Le module Terraform AKS complète le service par tout un écosystème : Velero pour les backups du cluster, gestion de certificats, respects des conventions Claranet, gestion des logs ou stockage. Le module est pertinent pour deux raisons :

  • 1. Il encourage le respect des standards et des bonnes pratiques ;
  • 2. Il apporte de la flexibilité : il est possible de surcharger une majorité des paramètres dans le module lorsque l’on souhaite le décliner tout en respectant des pratiques spécifiques à certains clients.

Les plateformes Claranet
Afin de réduire le temps de mise à disposition des plateformes pour les développeurs, Claranet a construit plusieurs plateformes sur étagère.

Claranet Digital Experience
Cette solution à base d’IaaS et de PaaS tourne sur les infrastructures de Claranet, d’AWS et d’Azure. Digital Experience permet de propulser des CMS ou des e-commerce à travers la plateforme industrialisée (en termes de monitoring, de backup, de création de ressources d’infrastructure ou de pipeline). La plateforme est rapidement mise à disposition.

Antares
Le pendant de Claranet Digital Experience se nomme Antares. Utile pour faire ses premiers pas dans le monde de la conteneurisation, Antares peut constituer l’étape préliminaire à Kubernetes. Antares s’intéresse aux aspects de type stateless front-end web.

CaaS
Cette plateforme concerne les microservices et se concentre sur le déploiement intergiciel.

Les plateformes Claranet et l’everything as code
Quel est le lien entre les trois plateformes Claranet et l’Everything as code ? L’automatisation de ces solutions promptement mises à disposition pour les clients finaux s’appuie sur les concepts de l’Infrastructure as code et le développement d’automatisation avec le config management. Terraform et GitOps accélèrent le déploiement.

Focus sur les landing zones
L’Infrastructure as code est utilisée aussi bien pour les plateformes de Claranet que pour la mise en place de landing zones.
Une landing zone englobe l’écosystème qui accueille les applications de manière sécurisée et efficace. Notons également la zone de share services où les équipes déploient le bastion et les consoles anti-virus. Le concept embarque plusieurs éléments :

  • Identity access management ;
  • Networking ;
  • Accès VPN ;
  • Interconnexion avec les autres infrastructures.

Viennent ensuite s’attacher sur le Hub, les différents Spoke qui vont supporter les charges de travail. On y intègre les différentes règles de filtrage et la délégation de droits permettant de confier aux équipes éligibles la capacité d’administrer le périmètre en question. Puisque les templates héritent de règle de conformité, le renforcement de la sécurité s’en trouve plus facilement harmonisée.

La landing zone pour un déploiement rapide

Le groupe Legrand avait pour objectif de concevoir et d’implémenter sa landing zone. Les équipes ont fait appel à Claranet pour templatiser la landing zone et la déployer dans différents continents, selon une approche Virtual Data Center. Le template a permis de définir l’ensemble des caractéristiques du VDC pour ensuite pouvoir le dupliquer sur chaque continent où le client est présent.

Policies, compliance et everything as code

Les bonnes pratiques, les règles et leur suivi

Claranet intègre les enjeux de sécurité dans l’Everything as code. Les politiques prioritaires concernent le respect d’un certain nombre de bonnes pratiques et la conformité. Cette dernière s’étend à plusieurs procédures : les règles de nommage ou le respect des politiques.

Les divers CCoE
Pour répondre aux enjeux, Claranet a mis en place un Cloud Center of Excellence (CCoE) qui érige les règles et les bonnes pratiques. Les clients grands comptes possèdent également leur propre CCoE avec leurs règles de sécurité et de conformité. Claranet a donc pour mission d’agréger les deux pour valider la prise en compte de la sécurité dès la phase de construction.

Focus sur Azure Policy
Azure Policy permet de créer un filet de sécurité qui réagit de deux façons : en mode deny, l’appel d’API en contradiction avec les politiques est rejeté ou l’audit qui lance une alerte capturée par les équipes de Claranet. Le concept étant bien entendu décliné par CSP.

L’everything as code dans l’avenir

Le futur de l’Everything as code engendre beaucoup de débats. Face à des outils qui présentent un manque, la réponse la plus sérieuse consiste à s’appuyer sur un vrai langage de programmation. Dans un premier temps, passons en revue les solutions existantes.

Les faiblesses de Terraform

Nous l’évoquions précédemment, même si Terraform offre de nombreux atouts, il vient également avec son lot de limitation. Une partie a été gommée au fil des évolutions, d’autres persistent et persisteront de part la nature même de son design.

Le cycle de vie
Exigeant, le cycle de vie de Terraform garde bien occupé. Difficile à valoriser, il engendre une dette technique puisqu’il faut assumer les montées de version ou constater l’obsolescence des providers.

Les modules trop élaborés
Malgré une volonté d’efficacité, certaines agglutinations autour de la ressource Terraform apportent trop peu de valeur ajoutée. Le point de vigilance à garder en tête concerne la valeur ajoutée de chaque module supplémentaire.

Le ROI parfois manquant
L’Infrastructure as code à tout prix n’est pas toujours une sinécure. Il faut être vigilant aux environnements ou plateformes uniques qui subissent peu de changement, comme dans le cas de Proof of Concept ou Proof of Value qui n’auraient pas vocation à être pérenniser au-delà de la preuve et garderait ce caractère éphémère.

Le temps nécessaire
Il est parfois difficile de justifier le temps de développement d’une Infrastructure as code ou d’un template. Lorsque la Virtual Machine est créée rapidement, elle n’intègre pas la conformité, la politique de sécurité ou une capacité à suivre les évolutions dans le temps.

La dépendance cyclique
Lorsque le développement dépend de deux actions conjointes, il y a un problème. La notion de create&destroy s’entremêle dans certains cas.

Même si la solution présente des failles, elle reste un bon compromis entre fonctionnalité, maturité et expérience sur les sujets Infrastructure as code.

Celles vers qui se tourner
Des solutions comme Pulumi ou plus récemment AWS CDK (une alternative à Terraform qui se rapproche du développement applicatif) sont très intéressantes. Il est stratégique de s’intéresser de près à ces nouveaux venus dans le monde l’Infrastructure as Code.

Si l’on souhaite se tourner vers du développement purement applicatif pour piloter les aspects de l’Infrastructure as code, des Cloud Functions et affiner leur intégration, il faudra toutefois s’armer de patience puisque la courbe d’apprentissage sera plus importante. Tous les collaborateurs doivent être formés sur des langages poussés, aussi bien ceux qui rédigent le code que ceux qui le reprennent. Cette évolution n’est pas à exclure dans l’immédiat, il est plus pertinent de la confier à des équipes matures.

Que faut-il retenir ?

L’everything as code induit des changements profonds
Notamment pour les équipes peu matures. Avant tout, c’est un activateur d’automatisation autour du configuration management ou de l’Infrastructure as code.

Il offre l’opportunité d’avoir un meilleur code

L’Everything as code est idéal pour utiliser un code de meilleure qualité et des environnements plus fiables. Ils sont aussi mis à disposition plus rapidement à travers des processus de type GitOps/code review. De ce fait, il assure une meilleure collaboration avec les clients de Claranet à travers les activités de CMSP.

Il réduit le time-to-market

L’Everything as code diminue la mise à disposition des plateformes puisqu’elles sont standards et réutilisables à l’envie.

Conclusion
Porteur de changement, mais exigeant au niveau des équipes, l’Everything as code se positionne en suite logique de l’Infrastructure as code. Parfois faibles sur certains aspects, les outils disponibles forment une première base intéressante et suffisante pour se lancer. N’oublions pas d’intégrer les notions de compliance et policy dans chaque projet.

Pour finir, l’Everything as code intègre les notions de security by design.