Platform Lead - Kubernetes & Infrastructure Data/IA
Architecte de plateformes cloud-native pour la recherche
Alexis Guyot
E-mail:
guyot.alexis91@gmail.com
E-mail:
guyot.alexis91@gmail.com
Je m’appelle Alexis Guyot, je conçois et pilote des plateformes cloud-native complexes dédiées aux environnements de recherche, de la data science et de l’intelligence artificielle, en plaçant l’automatisation et l’expérience utilisateur au cœur de chaque architecture.
Ingénieur systèmes de formation, j’interviens à l’intersection de l’architecture technique, de l’industrialisation des infrastructures et de la stratégie IT opérationnelle.
Ma démarche est guidée par une conviction simple : créer des systèmes robustes, lisibles et automatisés pour que leurs utilisateurs puissent se concentrer sur l’essentiel, sans être freiné par la complexité sous-jacente.
Au sein du Groupe GENES, j’ai été responsable de l’évolution technique de la plateforme Onyxia, une infrastructure Kubernetes multi-tenant en production supportant les entités scientifiques (ENSAE, ENSAI, CREST, CEPE).
Cette plateforme mutualise des ressources (GPU, stockage objet, services open source) et permet aux utilisateurs de provisionner des environnements self-service dans un cadre sécurisé, automatisé et observé.
Mon expertise couvre notamment :
- l’orchestration Kubernetes en production
- la mutualisation de GPU
- l’industrialisation via GitOps
- l’identité et l’accès (IAM)
- l’intégration de services IA on-prem
- l’automatisation et la standardisation des workflows
L’automatisation est au cœur de ma manière de travailler. Je conçois des plateformes pensées pour durer, évoluer et rester maîtrisables dans le temps. Créer l’infrastructure pour rendre la complexité aussi lisible qu’un YAML résume assez bien ma façon d’aborder les systèmes.
Au-delà de la technique, j’attache une grande importance à la collaboration entre équipes, à la clarification des processus et à l’accompagnement des usages, car une infrastructure n’a de valeur que si elle est adoptée et maîtrisée.
Je poursuis actuellement la certification PMP pour structurer et enrichir mes compétences en pilotage de projets complexes selon les standards internationaux, en complément de mon expertise technique.
- IAM / OIDC (Keycloak)
- Gestion des accès
- SSL/TLS
- Shibboleth
- Prometheus
- Grafana
- ELK
- Supervision & alerting
- Kubernetes
- Onyxia
- Helm
- GitOps (ArgoCD)
- Kubespray
- Docker
- AWS
- MinIO (S3)
- Longhorn
- Nextcloud
- Terraform
- Ansible
- Drone
- Scripting (Python/Shell)
CV sur le Cloud
Site web hébergé chez AWS sans serveur (https://alexisguyot.click)
J'ai entrepris ce projet peu après avoir obtenu ma certification AWS Cloud Practitioner. Pour la conception du frontend, j'ai opté pour l'utilisation d'un modèle HTML/CSS que j'héberge sur un stockage AWS S3.
Le chargement du site Web déclenche une fonction AWS Lambda qui augmente de un le nombre de visiteurs dans une table DynamoDB et renvoie le nouveau nombre de visiteurs au site Web. Pour empêcher tout accès non autorisé à la fonction, une URL de fonction Lambda CORS a été configurée pour n'accepter que les requêtes du domaine : "https://alexisguyot.click".
Chaque modification apportée déclenche un processus d'intégration continue et de déploiement continu (CI/CD) via AWS CodePipeline et GitHub.
AWS Route 53 prend en charge la gestion du nom de domaine, la distribution est globalement distribuée grâce à AWS CloudFront qui va mettre en cache le site sur des serveurs Edge dans le monde entier.
AWS Certificate Manager gère les certificats SSL/TLS pour une communication sécurisée. De plus, des permissions OAC ont été configurées sur S3, garantissant que tout le trafic passe obligatoirement par CloudFront, renforçant ainsi la sécurité.
Speedlight
Application Web de calcul
Cette application web permet de calculer le temps estimé pour parcourir une distance donnée en utilisant divers moyens de transport créés par l'humanité, tout en le comparant à la vitesse de la lumière.
L'interface utilisateur repose sur une simple page HTML/CSS hébergée sur AWS Amplify. Les utilisateurs entrent simplement la distance en kilomètres qu'ils souhaitent calculer.
En coulisses, pour la partie back-end : le navigateur communique avec une API backend publique, construite à l'aide de Lambda et d'API Gateway. Cette API effectue les calculs, fournissant ensuite les résultats à l'utilisateur.
La fonction Lambda est rédigé en python et utilise boto3 pour intéragir avec d'autres ressources AWS. Celle-ci va également enregistrer chaques calculs effectués par les utilisateurs dans une base de donnée DynamoDB.
Pour des raisons de coût, l'application réside désormais sur AWS S3 plutôt que via AWS Amplify.
Application Web
Application Web sans serveur
Ce projet a été conçu dans le but d'affiner mes compétences et d'explorer de nouvelles perspectives.
Le frontend de l'application web est pré-construit, c'est une interface utilisateur HTML qui permet d'ajouter des points GPS sur une carte, tandis que le backend communique avec un service web RESTful pour enregistrer ces coordonnées dans une base de données DynamoDB.
AWS Amplify assure le déploiement continu et l'hébergement des ressources web statiques, incluant HTML, CSS, JavaScript et images.
Le JavaScript exécuté dans le navigateur envoie et reçoit des données d'une API backend publique conçue en utilisant Lambda et API Gateway.
L'application web prend également en charge la fonctionnalité d'inscription et d'authentification des utilisateurs, via Amazon Cognito, sécurisant ainsi notre API backend.
Enfin, DynamoDB offre une couche de persistance où les données peuvent être stockées par la fonction Lambda de l'API.
Terraform Speedlight
Déploiement d'infrastructure via terraform
Pour approfondir mes compétences en Infrastructure as Code
(IaC), j'ai entrepris de rendre mon projet "Speedlight" entièrement
déployable via Terraform. Cette démarche vise à permettre à quiconque de
déployer puis détruire automatiquement cette application sur AWS en quelques secondes. Le projet Speedlight a été divisé en trois parties
distinctes incluant également la création d'un script python qui modifie la valeur d'un fichier html récupéré via un output terraform.
Partie 1 - AWS Lambda + DynamoDB
Cette partie s'est déroulée sans difficultés majeures. Les
blocs Terraform ont été structurés de la manière suivante : création de la
fonction Lambda, importation du code Python au format zip et définition du
rôle IAM pour la Lambda.
Partie 2 - Importation des fichiers HTML/CSS sur S3
Cette partie a été plus complexe, les étapes comprenaient :
- La création d'un compartiment S3, la modification des
contrôles d'accès (ACL) pour rendre le compartiment S3 public,
- La définition du
compartiment en tant que site web statique,
- La configuration de la redirection
vers le fichier index.html,
- L'importation des stratégies du compartiment S3 via
un fichier JSON, et enfin, l'importation des fichiers front-end (HTML, CSS,
etc.) dans le compartiment.
Le principal défi rencontré ici a été la gestion de
l'importation des fichiers dans le compartiment S3, réglé via l'utilisation d'une
boucle "for_each", qui n'est pas directement prise en charge dans la
documentation Hashicorp.
De plus, Terraform ne vérifie pas automatiquement le contenu
des fichiers pour détecter s'ils ont été modifiés pour les réimportés. Pour
résoudre ce problème, j'ai inclus l'option "etag = filemd5" dans la
boucle, ce qui a permis de garantir que les fichiers seraient réimportés en cas
de modification.
Cependant, il subsiste un problème lié au format des
fichiers importés dans S3 via Terraform, car les métadonnées telles que
"Content-Type: text/html" ne sont pas automatiquement définies lors de l'importation. Cela entraîne
le téléchargement des fichiers au lieu de les afficher lors de l'accès au site
web.
Une solution consisterait à spécifier le "content_type" pour
chaque fichier lors de l'importation, ce qui implique une complication et
refonte total du block d’import via la boucle "for_each".
Il serait plus judicieux de créer le compartiment S3 via
Terraform, mais d'importer les fichiers manuellement ou autres méthodes, car de
cette façon S3 sait reconnaître automatiquement le "content_type" des
fichiers.
Partie 3 - AWS API Gateway
Cette partie devrait être mise en place comme suit :
- Création d'une API Gateway REST,
- Création de méthodes "OPTION, POST" avec une intégration de type "Lambda Function"en liant notre fonction Lambda précédemment
créée
- Ajout de la gestion des
autorisations CORS
- Déploiement de l'API et génération d'une sortie contenant
le lien de l'API à insérer dans notre fichier index.html
La configuration des méthodes "OPTIONS, POST" ont posées des
problèmes, notamment l'absence de certaines configurations qui normalement, n'ont pas besoin d'être spécifiées lors ce que l’ont crée la
ressource manuellement.
Cela a affecté les étapes telles que "Method
Request", "Integration Request", "Method Response" et surtout "Integration Response" où le besoin d'ajouter d'un modèle de mappage (application/json : "{"statusCode":200}") que j'ai eu du mal à trouver. Mais après de nombreuses heures d'essais, ces
configurations sont maintenant correctement gérées via Terraform.
Points à améliorer sur le code fonctionnel :
Revoir la gestion des métadonnées (content_type) lors de l'importation
des fichiers dans S3 via Terraform pour éviter le téléchargement manuel des fichiers sur S3.