Gérer un parc de serveurs qui grossit, c’est un peu comme jongler avec de plus en plus de balles ! Chaque nouvelle machine ajoute une tâche : installer, configurer, mettre à jour, distribuer les bons paquets et vérifier sa conformité. Multipliez ça par des dizaines, voire des milliers de serveurs, et le jonglage devient vite ingérable à la main. Et ça, c’est exactement le problème que la stack PFK, Pulp – Foreman – Katello, a été conçue pour résoudre !

Dans un premier temps, Foreman orchestre le provisioning et la configuration de vos serveurs, du premier démarrage jusqu’au dernier correctif. Katello vient ensuite compléter le tableau : ce plugin gère la distribution des paquets et des abonnements. Et enfin, sous le capot, c’est Pulp qui fait tourner la machine, en synchronisant et stockant le contenu logiciel sans dupliquer inutilement les paquets.

Ensemble, Foreman, Katello et Pulp forment une stack open source complète pour piloter le cycle de vie de votre infrastructure. Découvrez comment dans cet article !

Foreman, le chef d’orchestre du cycle de vie des serveurs

Foreman est un projet open source qui automatise le cycle de vie complet des serveurs physiques et virtuels : provisioning, configuration, orchestration et supervision.

Concrètement, il vous permet de :

  • installer un système à distance à l’aide de PXE, DHCP et TFTP,
  • et le configurer automatiquement grâce à des intégrations avec Puppet, Ansible, Salt ou Chef.

Le projet est né en juillet 2009, sous l’impulsion d’Ohad Levy et Paul Kelly, dans la mouvance de la communauté Puppet. L’objectif de départ était simple : combler le manque d’outils capables de gérer le provisioning initial des machines, là où Puppet excellait déjà sur la configuration post-installation. Depuis, Foreman a beaucoup grandi. À ce jour, il est distribué sous licence GNU GPL v3 et sert même de base au produit commercial Red Hat Satellite.

Par ailleurs, Foreman propose une interface web, une CLI (Hammer) et une API REST. De quoi s’adapter à tous les styles de travail, que vous préfériez cliquer ou scripter.

Katello, le gestionnaire de contenu qui complète Foreman

Katello, lui, s’attaque à un autre problème : la distribution de contenu logiciel.

Il s’agit d’un plugin pour Foreman qui sert à :

  • gérer des abonnements et des droits d’accès aux dépôts,
  • versionner du contenu dans des Content Views,
  • promouvoir ces contenus à travers des environnements de cycle de vie (développement, test, production).

En clair, Katello décide quoi distribuer, à qui et à quel moment.

Ainsi, un correctif de sécurité passe par les mêmes étapes de validation partout, sans surprise.

Pulp, le moteur de contenu qui alimente Katello

Enfin, Pulp se concentre sur la couche la plus concrète : le stockage et la circulation des paquets eux-mêmes.

C’est un projet open source à part entière, que Katello utilise comme moteur de contenu. Concrètement, il vous permet de :

  • synchroniser localement tout ou partie d’un dépôt distant,
  • héberger vos propres paquets dans des dépôts versionnés,
  • gérer des contenus variés (RPM, DEB, images de conteneurs, collections Ansible, paquets Python) depuis une même plateforme,
  • revenir à une version antérieure d’un dépôt à tout moment.

Le projet est né chez Red Hat, où il a d’abord été développé pour gérer les paquets RPM, avant de s’ouvrir à d’autres formats au fil des versions. Pulp 3, sorti en décembre 2019, a marqué une refonte complète de son architecture pour gagner en fiabilité et en flexibilité. Distribué sous licence GNU GPL v2+, il fonctionne aussi bien comme composant de Katello que comme solution autonome : Microsoft s’en sert par exemple pour distribuer ses dépôts logiciels Linux à grande échelle.

Par ailleurs, Pulp propose lui aussi une API REST complète, ce qui permet à Katello (et à d’autres outils) de s’appuyer entièrement dessus sans réinventer la gestion de contenu.

Pourquoi utiliser la stack PFK ?

Foreman seul gère déjà très bien le provisioning et la configuration. Alors, pourquoi ajouter Katello ? Parce que sans lui, vous devez gérer vos dépôts, mises à jour et abonnements avec des outils séparés, souvent manuellement. Avec Katello, ces briques rejoignent la même console, la même API et le même modèle de permissions.

Et sans Pulp derrière Katello, cette synchronisation de contenu resterait une mécanique fragile. C’est lui qui garantit qu’un paquet n’est stocké qu’une seule fois, correctement versionné, et prêt à être distribué à tous les systèmes sans ressaisie manuelle.

Concrètement, un administrateur peut provisionner un serveur avec Foreman, puis l’abonner à un environnement de contenu géré par Katello. Pulp se charge alors en silence de synchroniser et stocker ce que Katello lui demande.

En bref : aucune rupture entre l’installation et la maintenance.

Les trois projets partagent par ailleurs la même communauté et publient leurs versions de façon coordonnée, ce qui limite les problèmes de compatibilité. Ils ne se concurrencent pas : ils se complètent.

Les avantages fonctionnels concrets du trio

Sur le terrain, cette association apporte plusieurs bénéfices tangibles :

Ainsi, une équipe ops peut standardiser ses pratiques sur l’ensemble du parc, du datacenter historique jusqu’aux instances cloud les plus récentes.

Prenons un cas concret : une DSI qui gère 500 serveurs RHEL répartis sur trois sites. Sans Katello ni Pulp, chaque site synchronise ses propres miroirs de paquets, avec le risque de dérives entre environnements.

Avec la stack complète, un seul Content View central définit la version validée d’un paquet. Pulp le stocke une seule fois, et les Smart Proxies de chaque site le distribuent localement.

Pour résumer : moins de bande passante consommée, et surtout, la certitude que la production tourne exactement sur ce qui a été testé en amont.

C’est ce genre de garantie qui rassure tant les équipes sécurité que les équipes infrastructure.

Stack PFK : l’allié des architectures en étoile

S’il y a un cas d’usage où la stack PFK est particulièrement pratique, c’est bien pour piloter des architectures décentralisées et complexes, avec des contraintes de sécurité fortes et/ou des limitations réseau entre les sites. C’est justement le rôle du Smart Proxy.

En arrière-plan, Foreman s’appuie sur un Smart Proxy. C’est un composant qui exécute les opérations déléguées par le serveur central :

Placer un Smart Proxy près d’un site distant réduit donc la latence et allège la charge du serveur principal. Voilà pourquoi les organisations multi-sites l’adoptent volontiers.

Katello, quant à lui, s’appuie sur deux briques essentielles pour fonctionner :

Le Smart Proxy vient ainsi compléter ce trio sur le terrain. Une fois le contenu synchronisé par Pulp, il relaie localement vers les hôtes de chaque site, sans repasser par le serveur central à chaque requête.

Depuis la version 4.0 de Katello, le projet utilise exclusivement Pulp 3. Là où l’ancienne architecture dépendait encore de MongoDB, elle repose maintenant sur PostgreSQL pour l’ensemble de ses composants. Fini la duplication inutile de paquets !

Résultat : un déploiement plus simple et des publications de contenu plus rapides.

Cette séparation des responsabilités est finalement la clé de voûte de l’ensemble. Foreman orchestre, Katello pilote contenus et abonnements, Pulp le stocke et le fait circuler… Et chaque brique reste remplaçable ou activable selon vos besoins réels, sur le moment.

Conclusion : un trio qui continue d’évoluer

Foreman, Katello et Pulp ne sont pas des projets figés. Ils avancent au rythme d’une communauté active, avec des cycles de publication réguliers.

Katello 4.17, par exemple, a récemment introduit les Rolling Content Views, qui pointent automatiquement vers la dernière version d’un dépôt sans passer par un cycle de publication manuel. Une évolution pensée pour les environnements qui ont besoin de mises à jour immédiates.

De son côté, Pulp continue d’élargir son socle de contenus pris en charge, plugin après plugin, sans jamais casser la compatibilité avec ce qui est déjà en production.

Ce dynamisme illustre bien l’esprit du trio : rester pragmatique, s’adapter aux usages réels des équipes ops et continuer à simplifier ce qui, sans eux, resterait un vrai casse-tête de gestion d’infrastructure.

La stack PFK est particulièrement efficace sur les distributions « Red Hat like » comme AlmaLinux ou Rocky Linux… Mais elle peut l’être moins ailleurs. Sur l’écosystème Ubuntu par exemple, Canonical propose sa propre solution de gestion de parc : Landscape. Autant dire qu’il n’existe pas d’outil universel : le bon choix dépend avant tout de votre socle technique.

C’est précisément là que l’expertise Capensis prend tout son sens. Au-delà de Foreman, Katello et Pulp, nous accompagnons les équipes IT sur l’ensemble de l’écosystème open source pour construire avec vous des solutions sur-mesure et pérennes, adaptées à votre infrastructure réelle plutôt qu’à un outil unique.

Envie d’en discuter ? Contactez notre équipe !