Comme n’importe quel site web, MacGeneration ne serait rien sans des serveurs. C’est valable aussi pour notre application mobile, qui a bien besoin de récupérer tous nos contenus quelque part. Pour prolonger le 25e anniversaire de MacGeneration, je vous propose de lever en partie le voile sur l’infrastructure qui héberge tous nos sites et services.
Une infrastructure à mi-chemin entre deux mondes
Pour commencer, il faut peut-être évoquer notre situation actuelle, qui est assez particulière. MacGeneration a connu de nombreuses infrastructures au cours de son existence. Au début de l’aventure, au tournant des années 2000, c’était le système D avec des Mac bricolés en guise de serveurs. Notre hébergement s’est ensuite vite professionnalisé pour répondre à la croissance continue du lectorat. Cela fait maintenant dix ans que nous sommes hébergés par OVH, devenu OVHcloud, l’un des leaders européens de l’hébergement et un acteur français qui nous permet d’utiliser des serveurs situés dans le nord de la France. Si nous n’avons pas changé d’hébergeur depuis, les techniques comme nos besoins ont changé en une décennie et nous nous trouvons actuellement au cœur d’une transition.
Vous l’avez peut-être noté si vous utilisez nos sites web, leur interface a un petit peu changé l’été dernier. Sans bousculer la maquette, MacGeneration, iGeneration et WatchGeneration ont basculé sur une toute nouvelle base technique courant 2024 et c’est le signe le plus visible de cette transition qui devrait encore durer quelques mois. Sous le capot, nous sommes en train d’abandonner Drupal, un gestionnaire de contenu (CMS) concurrent historique de WordPress que nous utilisons depuis la toute fin des années 2000. Nous avons décidé il y a quelques années de créer notre propre CMS parfaitement adapté à nos besoins, au lieu d’essayer d’adapter un outil clé en main, comme nous l’avions fait jusque-là.
Pour cette nouvelle fondation, nos développeurs ont créé un ensemble d’applications que l’on nomme API dans le jargon. Vous ne les voyez pas, mais vous les utilisez au quotidien : ce sont ces API qui stockent le contenu dans une base de données, que ce soit des articles ou des commentaires, et ce sont aussi des API qui distribuent ce contenu quand vous ouvrez une page de nos sites. Cette approche modulaire, avec des dizaines de briques qui communiquent entre elles, est bien différente du monolithe qu’est Drupal 7, le CMS que nous continuons d’utiliser pendant la transition.
En effet, nos moyens limités ne nous permettent pas de basculer entièrement du jour au lendemain sur notre nouveau CMS et il n’est pas question de fermer les sites pendant une longue durée pour réaliser cette opération. Dans ce contexte, nous avons mis en place deux infrastructures serveur qui tournent en parallèle. L’ancienne destinée à héberger Drupal reste active pour gérer les contenus. La nouvelle avec toutes les API maison prend peu à peu le relai, remplaçant progressivement des fonctionnalités assurées jusque-là par le CMS historique. De nombreuses briques dépendent encore de Drupal, à la fois en interne (pour tous les outils de création et de publication d’articles) et en externe. Par exemple, notre app mobile historique repose largement sur Drupal et nous devrons la remplacer par une toute nouvelle version afin de mener à bien la transition.
Tout cela pour vous prévenir que notre infrastructure serveur est un petit peu complexe en ce moment, ce qui est l’occasion parfaite d’évoquer quelques évolutions menées dans les centres de données qui hébergent MacGeneration.
Du matériel aux conteneurs, une infrastructure de plus en plus virtuelle
Ces évolutions dépendent en réalité largement de la technologie à notre disposition. Quand MacGeneration voit le jour en 1999, héberger un site web, même purement statique comme il l’était à l’époque, n’est pas une mince affaire. Des serveurs (pas très puissants) à la bande passante (les données qui transitent depuis les serveurs vers les ordinateurs des visiteurs), tout coûte cher. Au fil du temps, le réseau internet gagne en importance et se démocratise, ce qui passe aussi par du matériel plus abordable et plus puissant. Le prix de la bande passante chute également, à tel point qu’on ne nous la facture plus du tout et qu’elle n’est même pas mesurée. Ce n’est pas le cas pour tous les hébergeurs, ni pour toutes les régions du monde, mais vous pouvez héberger un site en Europe sans payer un centime de plus même si vous recevez d’un coup un trafic énorme, ce qui est rassurant pour les entreprises comme nous.
Pendant très longtemps, notre infrastructure a été basée sur des serveurs dédiés, du matériel que nous avons d’abord possédé puis loué auprès de l’hébergeur, mais qui était entièrement géré par nos soins. Cette option n’a pas disparu, OVHcloud a toujours une large gamme de serveurs dédiés pour les clients qui le souhaitent. Cela a encore quelques intérêts, notamment financiers si l’on a des besoins importants. À capacité égale, un hébergement dédié peut être moins cher qu’un serveur virtuel s’il demande beaucoup de puissance CPU (ou GPU à l’ère de l’intelligence artificielle) ou énormément de stockage. Elle a aussi des inconvénients, qui nous ont poussés au fil des années vers la virtualisation.
Avec un serveur dédié, vous dépendez d’un équipement particulier qui peut, comme tout matériel, connaître des défaillances au fil du temps. Si vous le louez, votre hébergeur devra alors effectuer les réparations et même si l’opération est rapide, on parle probablement de quelques heures où le serveur sera au mieux ralenti, souvent inaccessible. Si la panne concerne le stockage, ce qui est courant, il faut en plus prévoir le temps de restaurer les données et gérer d’éventuelles pertes depuis la dernière sauvegarde. C’est pourquoi notre ancienne infrastructure reposait sur des serveurs redondants pour chaque élément : nous avions deux serveurs de base de données qui répliquaient les informations en temps réel, plusieurs serveurs web qui hébergeaient les sites et même plusieurs load balancers, des serveurs qui accueillent au départ les visiteurs et les dirigent ensuite au bon endroit.
Ce genre d’infrastructure est assez lourd à mettre en œuvre et à gérer au quotidien, tandis que les éventuels avantages financiers sont effacés par la nécessité d’avoir de la redondance matérielle. C’est pourquoi nous avons choisi de basculer sur une nouvelle configuration à la fin des années 2010, profitant de l’offre « Public Cloud » de l’hébergeur français. Pour faire (très) simple, l’entreprise installe de nombreux serveurs dans ses centres de données et les propose à la découpe, avec des machines virtuelles qui n’exploitent qu’une partie de ce matériel — on parle en général d’instances. Selon les besoins, vous pouvez opter pour une petite instance avec peu de cœurs CPU, peu de RAM et peu de stockage ou au contraire une très grosse instance. Contrairement à un hébergement « mutualisé » que l’on trouve en entrée de gamme, ces ressources sont garanties, c’est-à-dire que si vous payez pour deux cœurs CPU, vous aurez accès à 100 % de ces deux cœurs aussi longtemps que vous le souhaitez, sans être bridé par un voisin plus gourmand.
Notre première infrastructure « virtuelle » a été un calque de l’ancienne, avec des instances au lieu de serveurs dédiés. Nous avions comme toujours un load balancer en entrée, deux ou trois instances web pour répartir la charge entre tous les visiteurs, et un gros serveur de base de données, le tout communicant via un réseau interne privé. Inutile de créer de la redondance, c’est OVHcloud qui s’en charge en mettant en place plus de matériel que nécessaire. Quand un des serveurs du Public Cloud tombe en panne, un autre prend le relai en toute transparence et nous ne nous en rendons même pas compte. Si les problèmes peuvent toujours arriver, notamment à l’échelle d’un centre de données entier, cette virtualisation nous a permis d’éviter les pannes matérielles les plus courantes. En six ans avec cette offre, nous n’avons jamais perdu une instance à cause d’un disque dur déficient ou d’une alimentation défaillante.
Ce choix a apporté de nombreux avantages que l’on n’avait pas envisagés au départ. Puisque les instances sont virtuelles, on peut facilement et surtout très rapidement en créer de nouvelles selon les besoins. Alors qu’un serveur dédié est en général loué pour un mois entier1, une instance Public Cloud est facturée à l’heure. C’est très utile pour tester rapidement une idée et nous l’avons fait à plusieurs reprises au fil des années, avec des instances lancées pendant quelques jours seulement puis supprimées. Autre atout, puisque tout est virtuel, nous pouvons ajuster la puissance d’une instance si nos besoins changent… ou alors en créer une nouvelle si c’est plus facile, puisque c’est une opération simple et rapide.
La transition en cours vers notre CMS maison nous a amené à revoir en profondeur cette architecture « traditionnelle » et ajouter une couche de virtualisation supplémentaire. Les API qui composent notre gestionnaire de contenu maison tournent en effet dans des conteneurs, des sortes de machines virtuelles allégées, grâce à Docker, un outil très connu et utilisé en masse dans le monde des serveurs. Chaque brique repose sur une « stack » (pile) composée de plusieurs conteneurs différents en fonction des besoins. Ces conteneurs échangent entre eux au sein d’une pile et aussi avec les autres conteneurs, tout est géré par Docker et lié au même réseau privé « vRack » à notre disposition dans cette offre. Nous utilisions déjà cette technologie du temps des serveurs dédiés, elle reste toujours d’actualité avec nos instances virtuelles.
Avec cette approche, nous n’avons plus besoin d’autant de serveurs différents, mais chaque instance doit être nettement plus grosse. Pour résumer, la nouvelle infrastructure se compose de trois instances Public Cloud. La première est dédiée aux API et à toute la gestion des données (on parle souvent de « back-end »). La deuxième fait office de serveur web pour fournir ces données à nos sites et sur nos apps (le « front-end »). La troisième se charge d’héberger tous les outils annexes, de Plausible que nous utilisons désormais pour des statistiques plus respectueuses de votre vie privée à Portainer qui nous sert à gérer les conteneurs Docker.
Cette couche d’abstraction supplémentaire répond à une tendance générale dans le monde de l’hébergement et elle nous simplifie la vie, en nous permettant encore plus facilement d’ajuster les ressources pour répondre à la demande. C’est aussi une bonne manière de moins dépendre d’un hébergeur, puisque nos conteneurs Docker peuvent tourner n’importe où.
Une gestion entièrement en interne
MacGeneration n’est plus le site amateur alimenté par des contributeurs sur leur temps libre, c’est une entreprise qui paye un salaire à ses journalistes et développeurs. Malgré tout, nous restons une petite structure indépendante avec des moyens limités, un fort sens de la débrouille et un goût prononcé pour la polyvalence. Je ne suis pas journaliste de formation, j’ai commencé à écrire pour le site presque par accident pendant mes études et je n’ai jamais quitté l’entreprise depuis. Je travaille principalement comme rédacteur, mais aussi comme administrateur réseau. Je gère les serveurs au quotidien avec mon collègue Cédric, embauché comme développeur web pour travailler sur Drupal, et cela fait près de dix ans que nous faisons tout en interne.
Avant cela, nous avions des contrats d’infogérance, comme on dit dans le milieu, c’est-à-dire qu’un tiers ou l’hébergeur lui-même se chargeait de gérer les serveurs et toute la configuration de l’infrastructure. MacGeneration se contentait de fournir un cahier des charges et nous avions accès aux serveurs uniquement pour gérer nos fichiers et applications. La première infrastructure créée chez OVHcloud a été imaginée et mise en place par Maxime Valette, que vous connaissez peut-être grâce au site Vie de merde qu’il a fondé à la fin des années 2000. Cédric a pris le relai par la suite et je l’ai rejoint vers 2017 pour mettre au point une toute nouvelle infrastructure, la première conçue et déployée en interne et celle qui tourne encore pour héberger Drupal.
Confier l’administration réseau à deux employés est une bonne affaire pour MacGeneration, qui ne pourrait de toute manière pas se permettre d’avoir un employé à temps plein juste pour cette tâche. Ce n’est pas qu’une histoire de gros sous néanmoins : en gérant nous-mêmes nos serveurs, nous avons une liberté et une réactivité bien supérieures à ce qu’un contrat d’infogérance nous apporterait. Nous pouvons décider sur un coup de tête d’expérimenter avec une idée, quitte à tout annuler si elle n’aboutit pas, sans avoir à solliciter un tiers et devoir définir un cahier des charges bien précis. Grâce à cette gestion interne, nous avons expérimenté beaucoup plus et énormément appris : c’est l’avantage pour Cédric et moi-même.
Nous apprenons d’ailleurs encore tous les jours, dès que l’on commence à bricoler avec ces serveurs. Cette souplesse nous a aussi joué des tours, c’est vrai. Ne le répétez pas à notre patron, mais il nous arrive de perdre du temps sur un problème qu’un professionnel saurait peut-être corriger d’un claquement de doigt, ou alors de suivre une voie qui mène à une impasse. En contrepartie, nous maîtrisons toute la chaîne technique et nous gérons autant le stockage que la distribution du contenu que vous pouvez lire tous les jours sur nos sites et dans nos apps. Garder un tel contrôle d’un bout à l’autre, c’est assez rare dans notre industrie et une fierté.
-
L’offre s’est élargie depuis et OVHcloud, comme ses concurrents, propose désormais des serveurs dédiés payés à l’heure et gérés comme des instances virtuelles. ↩︎
