Harbor 2.16 - mieux contrôler ses images Docker avec un registre privé

Harbor 2.16 est disponible depuis le 9 novembre 2026. Cette nouvelle version du registre d’images auto-hébergé améliore notamment la prise en charge d’ARM64, la gestion des rôles et les réglages du cache. Une actualité utile pour les équipes qui construisent et déploient leurs applications avec Docker. Notes de version officielles.

Un déploiement dépend du code, mais aussi de l’image que le serveur doit récupérer. Si celle-ci disparaît, devient inaccessible ou peut être remplacée par un compte trop largement autorisé, la chaîne de livraison se fragilise. Un registre privé permet de reprendre la maîtrise de cette étape, à condition de l’intégrer à l’exploitation de l’infrastructure.

Un registre Docker privé, pour quoi faire ?

Une image de conteneur rassemble l’application et les éléments nécessaires à son exécution. Le registre est le service qui la conserve et la met à disposition : le pipeline y publie une version avec docker push, puis les serveurs la récupèrent avec docker pull.

Harbor assure ce rôle sur une infrastructure choisie par l’entreprise. Les images sont organisées par projet, avec des accès publics ou privés. Les outils Docker habituels restent utilisables. Publication et récupération des images dans Harbor.

Pour un éditeur SaaS ou une équipe qui exploite plusieurs applications, l’intérêt est concret : savoir où résident les images, qui peut les publier et comment les retrouver lors d’une restauration. Cela prolonge la logique d’une chaîne CI/CD intégrée à un cloud privé.

Ce que Harbor 2.16 apporte aux équipes d’exploitation

La version 2.16 réunit plusieurs évolutions qui facilitent l’administration du registre :

• AMD64 et ARM64 : la prise en charge complète de ces deux architectures élargit les possibilités d’hébergement de Harbor. Les images applicatives doivent toujours, de leur côté, être construites pour les architectures visées.
• Rôles personnalisés dans l’interface : les administrateurs disposent d’une interface pour gérer les rôles propres aux projets.
• Cache plus finement configurable : l’interface expose davantage de réglages, avec une API de filtrage des dépôts.
• Suivi des changements d’accès : de nouveaux événements d’audit enregistrent la création, la modification et la suppression de membres.
• Évolution du socle technique : Valkey remplace Redis comme moteur de cache.

Ces changements sont détaillés dans le journal officiel de Harbor 2.16. Ils touchent aussi bien les droits que les dépendances du service : une mise à niveau mérite donc une recette des publications, des récupérations et des automatisations existantes.

Harbor peut travailler aux côtés de Gitea

Gitea dispose déjà d’un registre de conteneurs intégré. Il peut recevoir les images construites par les workflows et les distribuer aux serveurs de production. Documentation du registre Gitea.

Harbor peut prendre en charge cette partie sans remplacer la forge. Gitea conserve les dépôts et les workflows ; les tâches de construction publient leurs images dans Harbor ; Docker Compose ou les autres outils de déploiement les récupèrent à cette nouvelle adresse.

La séparation devient intéressante lorsqu’il faut centraliser les images de plusieurs équipes, gérer un registre commun à plusieurs forges ou organiser leur distribution entre sites. Pour une petite plateforme dont le registre intégré couvre les besoins, conserver l’existant peut rester le choix le plus simple.

Le changement demande d’adapter les chemins des images, les secrets des pipelines et les droits des machines de production. Notre article sur Gitea et l’exploitation d’une forge auto-hébergée aborde l’autre partie de cette chaîne : le code, les accès et les automatisations.

Des accès distincts pour construire et déployer

Un serveur qui récupère une image n’a généralement pas besoin de pouvoir en publier une nouvelle. Harbor propose des comptes d’automatisation, avec des permissions adaptées aux projets et aux opérations attendues. Comptes d’automatisation Harbor.

Nous recommandons de traduire cette séparation dans les usages : un accès de publication pour le pipeline de livraison, un accès de lecture pour la production, et une gestion documentée de leur rotation. Lorsqu’un secret doit être révoqué, l’équipe sait alors quels services seront concernés.

Cette organisation réduit les conséquences possibles d’un accès compromis. Elle facilite aussi les investigations : les actions techniques ne dépendent plus toutes du même compte partagé.

Le cache réduit la dépendance aux registres externes

Harbor peut récupérer des images depuis un registre distant et en conserver une copie locale. Les serveurs utilisent alors l’adresse du projet de cache Harbor. Une image déjà présente peut continuer à être distribuée lorsque le registre distant est injoignable. Fonctionnement officiel du cache.

Cela évite de télécharger plusieurs fois les mêmes couches et rapproche les images des machines qui les utilisent. En revanche, une image jamais récupérée ne sera pas disponible pendant une coupure. La documentation précise également qu’une image supprimée du registre d’origine n’est plus servie lorsque cette suppression est constatée.

Les images nécessaires à une reprise doivent donc être conservées explicitement. Le cache est un outil de distribution ; une politique de sauvegarde et de restauration répond à un autre besoin.

Exploiter le registre comme une dépendance de production

Une indisponibilité du registre n’arrête pas nécessairement les conteneurs déjà en fonctionnement. Elle peut en revanche bloquer un nouveau déploiement, un changement de serveur ou une reprise après incident.

Avant de le placer au centre des livraisons, nous recommandons de vérifier quatre points :

1. La capacité de stockage et son évolution, avec des règles de conservation qui préservent les versions utiles au retour arrière.
2. La supervision, notamment l’espace disponible, les erreurs de publication et les échecs de récupération.
3. La sauvegarde cohérente du service, en couvrant les images, la base de données et les éléments de configuration nécessaires à sa restauration.
4. Un test de reprise réel, jusqu’au téléchargement d’une image et au redéploiement d’une application sur un environnement isolé.

Harbor 2.16 renforce une brique utile pour maîtriser ses livraisons logicielles. Sa valeur se mesure dans l’ensemble de la chaîne : des droits adaptés, des images disponibles et une équipe capable de remettre le service en route.

Chez Forget About IT, nous intégrons ces dépendances à l’infogérance des infrastructures Linux : maintenance, supervision et préparation de la reprise, selon le périmètre confié. Vous souhaitez fiabiliser vos déploiements Docker ? Échangeons sur votre infrastructure.