Radio France optimise ses pipelines CI/CD pour Kubernetes
Pour s’adapter aux nouveaux usages de ses auditeurs, le célèbre groupe radiophonique de service public a adopté le cloud. Le cloud a amené avec lui Kubernetes, puis la nécessité de faire évoluer sa chaîne d’outils CI/CD afin de parfaire les déploiements et de réduire les coûts.
Radio France n’est pas épargné par la montée en puissance du numérique. Le service public aux 15 millions d’auditeurs quotidiens devait s’adapter aux nouveaux usages, à une temporalité des médias désagrégée. Il développe depuis 2006 ses sites web, des contenus dédiés (podcasts, webdocs, etc.) depuis 2012, des applications, et l’écoute en streaming depuis 2014.
Parmi ses prérogatives, Radio France a le souhait d’innover. Cette innovation souvent audible (on se souvient de la diffusion des premiers reportages en son binaural) se joue également en arrière-plan. Illustration parfaite de ce phénomène, le groupe a adopté en production Kubernetes en 2017 pour sept de ses stations de radio.
Un cluster d’une quarantaine de nœuds propulse l’ensemble des sites web, des API, des applications et des podcasts de France Inter, France Bleu, France Culture, France Musique, Mouv’ et Fip (France Info dépend d’un partenariat avec France Télévisions). Sans oublier de mentionner la gestion du site web « corporate » et son application. En cumulé, les sites web accueillent plus de 100 millions de visiteurs uniques par mois.
L’orchestrateur lui-même réside sur le cloud d’AWS, infrastructure à la demande choisie par le groupe pour encaisser les pics d’audience et la montée en flèche de la consommation de podcasts (plus de 55 millions de téléchargements mensuels en 2018). Le cloud permet de stocker des pétaoctets de données de fichiers audio ainsi que les contenus des pages web. Logiquement, Radio France a opté pour une architecture de microservices, dont le grand intérêt est d’assurer l’isolation des composants logiciels. Cela évite qu’un site entier tombe à cause d’un module, et permet de le redémarrer plus rapidement. Radio France utilise, entre autres, les services EC2, Route 53 et Amazon S3. Sa pile technologique comprend PHP, React, Node.js, svelte, Golang, RabbitMQ ou encore PostgreSQL.
Or une telle structure, exige des développeurs une organisation particulière, notamment pour gérer les pipelines CI/CD et le déploiement de code au quotidien. Avant d’adopter Kubernetes, Radio France s’appuyait sur Jenkins et Gitlab. « Quand j’ai pris mon poste il y a deux ans et demi, nous utilisions déjà Gitlab pour le dépôt de code. Nous venions de passer sur Kubernetes en production peu de temps auparavant. Jenkins était le moteur CI/CD : il servait pour les tests unitaires, d’intégration, les builds des images applicatives et pour le déploiement », se rappelle Julien Vey, responsable excellence opérationnelle chez Radio France.
Comment GitLab CI a remplacé Jenkins chez Radio France
« Les développeurs avaient leur code d’un côté, leurs pipelines de l’autre. Ce n’était pas forcément optimal. »
Julien VeyResponsable excellence opérationnelle, Radio France
Cependant, synchroniser correctement Jenkins et GitLab ne semble pas une chose aisée. « Les développeurs avaient leur code d’un côté, leurs pipelines de l’autre. Ce n’était pas forcément optimal », indique le responsable.
Par ailleurs, une seule équipe se chargeait du développement des jobs CI/CD. « C’était très cadré. Quand une équipe démarrait un projet en PHP, par exemple, ses builds, ses tests, ses déploiements répondaient toujours à la même logique parce que nous ne voulions pas gérer avec Jenkins des centaines de spécificités », note Julien Vey. Au moment de lancer un nouveau projet, il fallait alors créer des tickets pour préparer les pipelines Jenkins.
« Avec GitLab, les développeurs ont la main sur leurs pipelines. Nous leur confions GitLab, GitLab CI ou encore des wrappers de code, mais ce sont eux qui décident de la manière de conduire leurs tests, leur builds ou le type de déploiement, suivant leurs contraintes ». Le responsable évoque notamment le changement de fonctionnalités sur les fleurons que sont Franceinter.fr ou Francebleu.fr, qui demande de communiquer avec les métiers avant la mise en production. À l’inverse, le service d’optimisation des images publiées sur le site peut être modifié sans consultation.
Cette approche doit également faciliter la collaboration entre les développeurs. Radio France dispose d’équipes dédiées au front-end de chaque site web et des applications, tandis que les personnes en charge du back-end desservent en général l’ensemble des services. Il y a par exemple un groupe chargé du streaming et un autre des podcasts. Certains d’entre eux gèrent jusqu’à 20 services différents.
En outre, les équipes de Radio France réalisent en moyenne une cinquantaine de MEP par jour. « Soit le microservice dépend d’un déploiement continu et les mises à jour entrent rapidement en production, soit il y a une phase de révision avant une publication le lendemain. On ne se prive pas de faire des mises en production, nous sommes vraiment en flux tendu : la merge request déclenche souvent le déploiement », précise Julien Vey.
L’adoption de Kubernetes a provoqué le choix de GitLab CI. « Ce passage s’est fait pas à pas. Nous avons commencé à migrer tous les tests unitaires, les jobs classiques, avec des runners GitLab [des agents pour démarrer les pipelines CI/CD sur les clusters Kubernetes, N.D.L.R.] sur des machines virtuelles au départ. Puis, nous avons progressivement migré ces runners vers Kubernetes, une étape relativement simple puisqu’ils reposent sur des processus Go peu complexes à exécuter », déclare-t-il.
« Nous ne serions pas allés vers GitLab.com ou GitHub, nous voulions gérer la solution chez nous. »
Julien VeyRadio France
En outre, les responsables DevOps de Radio France souhaitaient administrer l’outil en interne. « Nous ne serions pas allés vers GitLab.com ou GitHub, nous voulions gérer la solution chez nous. De plus, nous sommes très friands des projets open source. La communauté GitLab nous a permis de régler des problèmes avec les Runners Kubernetes quand nous avons commencé à les utiliser », indique Julien Vey.
Toutefois, l’intégration entre GitLab et Kubernetes n’est pas encore totalement mature. « Nous exécutons GitLab sur une machine virtuelle », ajoute-t-il. Seuls les agents runners sont lancés sur l’orchestrateur.
Des économies importantes
Cette approche facilite le démarrage de « pods CI » sur des nœuds Kubernetes déjà en route afin d’optimiser leur utilisation. « Cela nous permettait de densifier nos applications », remarque Julien Vey. Pour réaliser des économies, les équipes de Radio France ont décidé de placer leurs jobs CI sur des instances Spot. Spot offre toutes les fonctionnalités d’Amazon EC2 à bas coût, avec le risque assumé que l’instance soit terminée si une tâche colocalisée devient prioritaire.
Pour cela, Julien Vey et ses équipes s’appuient sur le projet open source Kops afin de gérer leurs clusters Kubernetes sur AWS. Ce composant permet notamment d’établir des groupes d’instances automatiquement rattachés à des capacités d’autoscaling dans EC2, et l’un d’eux cible des environnements Spot.
« Il nous suffit de définir la taille minimale et maximale de notre groupe d’instances, ainsi que le prix maximum que nous sommes prêts à payer pour une instance », écrit le responsable dans un article de blog posté sur Medium. Cela a permis de réduire les coûts annuels de la CI/CD de 70 %, selon notre interlocuteur.
« Cela va être plus difficile de placer des choses en cache, le coût de la bande passante est plus élevé, mais nous avons beaucoup moins d’échecs liés à des effets de bord. »
Julien VeyRadio France
« Nous avions un peu peur que les arrêts soient trop fréquents ainsi que des impacts possibles sur la CI/CD. Finalement, à l’usage, il y a une journée dans le mois où les instances Spot sont interrompues, mais elles s’exécutent près de deux semaines sans interruption », observe-t-il. En cas de problème, les équipes peuvent toujours basculer ces « pods CI » sur une machine virtuelle le temps que cela revienne à la normale. Mais avant d’en arriver à cette extrémité, Julien Vey mise sur l’agilité de Kubernetes. « Généralement, si un nœud consacré à la CI sur Kubernetes ne fonctionne pas correctement nous ne réfléchissons pas : nous le détruisons et nous en récréons un autre ».
Dans l’ensemble, Julien Vey salue les capacités de Kubernetes tout en mentionnant quelques inconvénients. « Cela va être plus difficile de placer des choses en cache, le coût de la bande passante est plus élevé, mais nous avons beaucoup moins d’échecs liés à des effets de bord. Nous passons très peu de temps à maintenir notre CI », assure-t-il.
Le Chaos Engineering pour mettre à l’épreuve Kubernetes
Kubernetes pose d’autres difficultés, insoupçonnées. « Kubernetes propose des points de contrôle (healthchecks) à tous les niveaux : des nœuds, des pods, des services, des Ingress, etc. En conséquence, quand quelque chose se déroule mal, parfois nous ne nous en rendons compte que trois semaines plus tard. L’orchestrateur gère très bien les petits problèmes avec des failovers, des restaurations, mais ils peuvent s’accumuler. Il nous est arrivé par le passé de ne pas trouver la source d’une difficulté parce que nous n’avions pas assez de rétentions sur les métriques ou les logs ».
Dans ce contexte, les Runners GitLab sont avantageux, selon le responsable. Ils s’intègrent aisément à la pile technologique de supervision de Radio France, composée du triptyque ELK (Elastic, Logstach, Kibana), Prometheus, Thanos, Alert Manager ou encore de Grafana. « Le Runner nous permet de collecter des métriques afin de savoir combien de jobs tournent à un instant T. Nous mesurons également l’empreinte mémoire de notre CI, qui, sur des pics journaliers, peut représenter 250 Go de RAM. L’effort pour obtenir ce type d’informations avec Jenkins est beaucoup plus important ».
« Le Chaos Engineering permettrait de repérer nos véritables goulets d’étranglement en simulant des incidents ».
Julien VeyRadio France
À l’avenir et en complément des processus déjà en place, les équipes de Radio France souhaiteraient s’essayer au Chaos Engineering. « Nous voulons évaluer cette technique pour mieux investiguer notre infrastructure. Kubernetes ne tombe pas suffisamment en panne pour comprendre les défauts de notre infrastructure. Le Chaos Engineering permettrait de repérer nos véritables goulets d’étranglement en simulant des incidents ». Dans la même veine, le responsable excellence opérationnelle cherche à adopter les meilleures pratiques SRE, notamment les « error budgets », la durée maximale pendant laquelle un système peut rester hors service sans conséquence sur les SLA.
Enfin, les équipes de Radio France ne réalisent pour l’instant que des déploiements progressifs (rolling updates, en VO). « Nous aimerions ajouter des méthodes plus évoluées comme du Canary ou du Blue/Green afin de donner aux équipes le choix du type de déploiement suivant les projets », conclut Julien Vey.
