L’œuf et la poule : par où commencer dans le Platform Engineering ?

Lorsque l’on se lance dans le Platform Engineering, la question la plus fréquente reste : « Par où commencer ? »
Cette interrogation, simple en apparence, cache une complexité sous-jacente, car elle touche à la fois à des considérations techniques et organisationnelles. Nous vous partageons ici notre réflexion, issue de nos expériences, pour aborder ce premier jalon stratégique.

TL;DR

Notre approche repose sur une séparation des responsabilités entre infrastructure et plateforme, et un démarrage pragmatique avec des outils simples :

• Éléments nécessaires :
  • Un repository Git, externe à la plateforme, pour centraliser l’IaC.
  • Un sous-domaine DNS pour gérer les services de la plateforme.
  • Les secrets initiaux (AK/SK de l’infrastructure, secrets DNS).
• Éléments critiques à sécuriser :
  • Les inventaires Ansible et états Terraform.
  • Les clés SSH et secrets initiaux (racine de PKI, clés d’API root).

Cette méthodologie s’inscrit dans une démarche itérative, permettant à chaque équipe de monter en puissance tout en minimisant les risques initiaux.

Délimiter les responsabilités : Infrastructure vs. Plateforme

Dès les premières étapes, une distinction claire entre infrastructure et plateforme s’impose.
Pour mieux refléter les contextes de nos clients, nous avons adopté une approche où :

• L’équipe infrastructure : Déjà en place, elle gère les éléments fondamentaux comme les enregistrements DNS et les machines via de l’IaC (Infrastructure as Code), ainsi que la configuration de l’infrastructure jusqu’au niveau système.
• L’équipe plateforme : Partie de zéro, elle construit un écosystème dédié à l’exécution des capacités. Son autonomie est cruciale pour éviter les blocages dans les premières étapes.

Cette séparation des responsabilités facilite non seulement l’alignement des équipes sur leurs missions respectives, mais permet aussi de s’adapter aux réalités organisationnelles.

Un noyau minimaliste pour démarrer efficacement

Plutôt que de se perdre dans une ambition démesurée, nous avons opté pour un noyau minimaliste, capable de poser les bases sans se surcharger inutilement.

Le choix du couple Terraform et Ansible

Sous l'impulsion d'Aurélien Maury, nous avons adopté Terraform pour la création des ressources et Ansible pour leur configuration. Cette combinaison nous permet de gérer efficacement l’infrastructure avec des outils complémentaires :

• Terraform : Automatisation de la création des ressources IaaS.
• Ansible : Configuration précise des rôles et gestion fine des machines.

Ces choix impliquent la création et la gestion d’un couple Access Key / Secret Key auprès du fournisseur cloud, nécessaire au fonctionnement de Terraform et Ansible.

Un repository Git pour centraliser l’IaC

Pour organiser notre travail et assurer la traçabilité, nous avons centralisé nos scripts IaC dans un repository Git. Ce dernier joue un rôle pivot en :

1. Stockant les scripts nécessaires à l’initialisation de la plateforme.
2. Permettant la collaboration entre les équipes tout en structurant le contrôle des modifications.

Cette approche soulève néanmoins deux questions clés :

• Où stocker le state Terraform et les inventaires Ansible ?
  Nous avons choisi de laisser ces éléments sous la responsabilité de l’équipe infrastructure, garantissant ainsi leur stabilité.
• Qui est propriétaire des scripts IaC ?
  Initialement, l'équipe infrastructure conserve cette responsabilité pour des raisons pratiques, notamment :
  • L’impact direct de l’infrastructure sur les coûts, mieux maîtrisé par l’équipe infra.
  • La complexité d’étendre les droits trop tôt, ce qui pourrait engendrer des erreurs critiques.

Stockage du premier repository Git IaC

La question du stockage de ce premier repository Git se pose, et on revient rapidement à l'œuf et la poule : ce repo doit-il appartenir à la plateforme ?

Notre réponse est clairement non. Qu'il soit hébergé sur un service SaaS (GitLab, GitHub, Bitbucket – choisissez votre poison) ou sur une machine interne (mais régulièrement sauvegardée), ce nucleus doit être stocké en dehors de la plateforme pour permettre une reconstruction complète rapide. Ce choix garantit non seulement une indépendance vis-à-vis des premières capacités déployées, mais également une résilience en cas de défaillance.

Un DNS pour une accessibilité simplifiée

L’accessibilité est cruciale dans la gestion des capacités d’une plateforme. C’est pourquoi nous avons fait du DNS une priorité dès les premières étapes.
Pour répondre à ce besoin, nous avons opté pour une solution standard et open-source : Bind9.

• Avantages clés de Bind9 :
  • Open source et hautement configurable.
  • Pilotable en CLI et compatible avec des outils comme External-DNS.

Bind9 a été déployé sur une machine dédiée (via Ansible/Terraform), en incluant la création d’un secret (rfc2136_tsig_secret) pour faciliter l’intégration à venir.

Limite identifiée : L’absence d’automatisation complète pour nettoyer les enregistrements DNS nous a contraints, dans un premier temps, à autoriser des connexions SSH vers la machine Bind9, en collaboration avec l’équipe infrastructure.

Le cluster initial : le socle de la plateforme

Pour OXP, nous avons fait le choix de Kubernetes comme socle d’exécution.
Les scripts IaC déployés par l’équipe infrastructure permettent de :

1. Démarrer un cluster Kubernetes racine.
2. Transférer les clés d’accès (kubeconfig) à l’équipe plateforme.

Ce cluster racine est essentiel pour héberger les premières capacités et inclut des secrets critiques comme le rfc2136_tsig_secret pour la gestion DNS.

Dans le cadre d’OXP, nous avons choisi d’instancier un cluster Kapsule, hébergé au sein d’un compte Scaleway.

La passation entre équipes

Une fois le cluster initial opérationnel, l’équipe infrastructure délègue entièrement la suite des opérations à l’équipe plateforme. Cela inclut :

• Un inventaire des machines disponibles.
• Les configurations essentielles comme le kubeconfig root, ou la clé DNS tsig

Retour d’expérience : apprendre en marchant

Cette organisation nous a permis de structurer efficacement le démarrage de la plateforme tout en clarifiant les rôles et responsabilités. Cependant, certains points restent perfectibles, en particulier la gestion des droits et la collaboration sur les scripts IaC.

On peut imaginer la mise à disposition de ces scripts sous forme d'API (via Caddy ou un produit tel qu'Ansible AWX). Mais cette délégation d’utilisation est un projet en soi et ne fournit pas forcément de valeur ajoutée immédiate.