Harbor est un projet de registre natif du cloud open source qui stocke, signe et analyse le contenu. Harbour a été créé par une équipe d’ingénieurs de VMware China. Le projet a été contribué au CNCF pour une adoption et une contribution plus larges. Récemment, le projet a annoncé sa version 2.0. Swapnil Bhartiya, le fondateur de TFiR.io , s’est entretenu avec Michael Michael, mainteneur de Harbor et directeur de la gestion des produits de VMware, pour parler de Harbor, de la communauté et de la dernière version.
Voici une transcription légèrement modifiée de l’interview :
Swapnil Bhartiya : Supposons que vous et moi soyons coincés dans un ascenseur et que je vous demande soudain : « Qu’est-ce que Harbour ? » Alors s’il vous plaît, expliquez ce que c’est. Michael Michael : J’espère que vous n’êtes pas coincé dans l’ascenseur pendant longtemps ; mais Harbour est essentiellement un registre natif du cloud open source. Considérez cela comme un référentiel où vous pouvez stocker et servir tous vos actifs cloud natifs, vos images de conteneur, vos graphiques Helm et tout ce dont vous avez besoin pour créer des applications cloud natives. Et puis des publications en plus de cela, de très bons moteurs de politique qui vous permettent de faire respecter la conformité, de s’assurer que les images que vous servez sont exemptes de vulnérabilités et de vous assurer que vous avez tous les garde-fous en place pour qu’un opérateur puisse gérer ce registre et le livrer à ses développeurs en libre-service.
Swapnil Bhartiya : Harbour est issu de VMware Chine. Je suis donc également curieux de savoir quel était le problème que l’équipe a vu à ce moment-là ? Parce qu’il y avait beaucoup de projets qui faisaient quelque chose de similaire, que vous avez vu unique que Harbour a été créé ? Michael Michael : Donc, essentiellement, le besoin était là, il n’y avait pas vraiment de bon moyen pour une entreprise d’avoir un registre hébergé qui possède toutes les capacités d’entreprise qu’elle recherchait, tout en étant capable d’avoir un contrôle total sur le registre. Comme beaucoup de fournisseurs de cloud ont leur propre implémentation de registre, il existe Docker Hub, ou vous pouvez acheter quelque chose à un prix très élevé. Mais si vous recherchez une solution open source qui vous offre des capacités enregistrées de bout en bout, comme vos développeurs peuvent pousser des images et extraire des images, puis vos opérateurs peuvent aller mettre une politique qui dit, Hé, je veux autoriser cela équipe de développement pour créer un projet, mais n’utilisant pas plus d’un téraoctet de stockage. Aucune de ces solutions n’avait cela, il y avait donc un besoin, une entreprise a besoin ici de développer un registre. Et en plus de cela, nous avons réalisé que ce n’était pas seulement nous qui avions le même besoin, il y avait beaucoup d’utilisateurs et d’entreprises dans l’écosystème natif du cloud.
Swapnil Bhartiya : Le projet est sorti depuis un certain temps et d’après ce que vous venez de me dire, je suis curieux de savoir quel type de communauté le produit a construit autour de lui-même et comment le projet a évolué ? Parce que nous parlerons aussi de la nouvelle version 2.0 mais avant cela, je veux parler du projet volontaire et de la communauté qui l’entoure. Michael Michael : Le projet a assez bien évolué au fil des années, nous avons augmenté nos contributeurs. Les statistiques de contribution que CNCF crée montrent que nous développons notre communauté. Nous avons maintenant des mainteneurs dans le projet de plusieurs organisations et il y a en fait trois organisations qui ont plus d’un mainteneur sur le projet. Donc, c’est en quelque sorte vous montrer qu’ils sont, l’écosystème a repris. Nous ajoutons de plus en plus de fonctionnalités dans Harbor, et nous rendons également Harbor enfichable. Donc, il y a des zones de Harbor où nous disons, Hé, voici l’expérience par défaut avec Harbor, mais si vous souhaitez étendre l’expérience en fonction des besoins de vos utilisateurs, allez-y et voici un moyen simple d’implémenter une interface et fais ça. Cela a vraiment augmenté la popularité de Harbour. Cela signifie deux choses,
Et plus important encore, si vous avez investi dans d’autres outils, vous pouvez brancher et jouer à Harbour dedans. Quand je parle d’autres outils, je veux dire, des choses comme les systèmes CI/CD, ces systèmes pilotent principalement le cycle de vie du développement. Ainsi, par exemple, vous passez du code source à l’image du conteneur à quelque chose qui est stocké dans un registre comme Harbor. Le moteur qui pilote le pipeline, ce workflow à bien des égards, est un moteur CI/CD. Alors, comment bien intégrer Harbour avec de tels systèmes ? Nous en avons fait une réalité maintenant et cela a rendu Harbour plus facile à mettre dans une organisation et à la faire adopter avec les normes existantes et les investissements existants.
Swapnil Bhartiya : Parlons maintenant du 2.0 récemment annoncé. Parlez de certaines des fonctionnalités principales, des fonctionnalités qui vous passionnent dans cette version. Michael Michael : Absolument, il y a trois ou quatre fonctionnalités qui m’excitent vraiment, vraiment. Le soutien à l’OCI est à venir. L’OCI est l’Open Container Initiative et elle crée essentiellement une manière standardisée de décrire à quoi ressemble une image. Et nous, dans Harbor 2.0, nous sommes en mesure d’annoncer que nous avons un OCI complet prenant en charge Harbor. Qu’est-ce que cela signifie pour les utilisateurs ? Dans les versions précédentes de Harbor, vous ne pouviez mettre dans Harbor que deux types d’artefacts ; une image de conteneur et une charte Helm. Il satisfait un grand nombre de cas d’utilisation pour les clients, mais ce n’est pas suffisant dans ce nouvel écosystème cloud natif, il y a des choses supplémentaires qu’en tant que développeur, opérateur, administrateur Kubernetes, vous voudrez peut-être pousser dans un référentiel comme Harbour et faites-leur également adopter une grande partie du moteur de politique fourni par Harbour.
Donnez-vous quelques exemples, des bundles uniques, l’application cloud native, un bundle. Vous pourriez avoir des fichiers OPA, vous pourriez avoir des fichiers de singularité et d’autres fichiers compatibles OCI. Alors maintenant, Harbor vous dit que, Hé, vous avez n’importe quel type de fichier là-bas ? S’il est conforme à l’OCI, vous pouvez le pousser vers Harbor, vous pouvez le retirer de Harbor. Et puis vous pouvez ajouter des choses comme des codeurs et des politiques de rétention et des politiques d’immuabilité et des politiques de réplication en plus de cela. La chose à ce sujet maintenant, juste en ajoutant quelques types d’artefacts pris en charge dans Harbor, ces types profitent immédiatement de tous les avantages de Harbor en termes de l’ensemble de notre moteur de politique et de la conformité qu’offrent les administrateurs de Harbor.
Swapnil Bhartiya : Que signifie la conformité OCI pour les utilisateurs ? Parce qu’en étant conforme, vous devez être plus strict sur ce que vous pouvez et ne pouvez pas faire. Alors pouvez-vous en parler ? Et aussi, comment cela affecte-t-il également les utilisateurs existants, devraient-ils avoir à s’inquiéter de quelque chose ou cela n’a pas vraiment d’importance ?
Michael Michael : Les utilisateurs existants ne devraient pas avoir à s’inquiéter à ce sujet, il existe une compatibilité descendante totale qui peut toujours pousser leurs images de conteneurs, qui sont conformes à l’OCI. Et si vous utilisiez auparavant une charte Helm, vous pouvez toujours la transférer dans Charts Museum, qui est un composant clé de Harbor, mais vous pouvez désormais également mettre une charte Helm en tant que fichier OCI. Donc pour les utilisateurs existants, pas beaucoup de différence, compatibilité descendante, nous les supportons toujours. Les utilisateurs sont frères ici, on ne va pas les oublier. Mais ce que cela signifie maintenant, c’est qu’en fait, ce n’est pas plus strict, c’est beaucoup plus ouvert. Si vous développez des artefacts conformes à OCI et qu’ils suivent la manière standard de décrire une image et une manière standard d’exécuter réellement une image au moment de l’exécution ; maintenant, Kubernetes est également compatible OCI au moment de l’exécution. Vous bénéficiez alors des avantages des deux mondes. Vous obtenez Harbour comme référentiel où vous pouvez stocker vos images et vous obtenez également un moteur d’exécution compatible OCI qui pourrait potentiellement les exécuter. Le très grand avantage ici pour les utilisateurs.
Quelques autres fonctionnalités que Harbour 2.0 apporte sont super, super excitantes. Le premier est l’introduction de Trivy par Aqua Security, car les batteries incluaient un scanner intégré dans Harbour. Auparavant, nous utilisions Claire comme scanner intégré et avec la sortie de Harbor appelée 1.10 qui est sortie en décembre 2019, nous avons introduit ce que nous appelons un framework enfichable, pensez-y comme un moyen pour les fournisseurs de sécurité comme Aqua et Encore de venir et créer leur propre implémentation d’un scanner de sécurité pour effectuer une analyse statique sur les images déployées dans Harbor.
Nous avons donc toujours inclus Claire en tant que scanner intégré, puis nous avons ajouté des points d’extension supplémentaires. Maintenant, nous avons vraiment aimé Trivy à tel point que notre communauté et nos utilisateurs aiment Trivy c’est la capacité d’appliquer et d’étudier l’analyse sur plusieurs systèmes d’exploitation sur plusieurs gestionnaires d’applications, c’est très bien aligné avec la vision que vous avez du point de vue de la sécurité dans le port. Et maintenant, nous avons ajouté Trivy en tant que scanner intégré à Harbour, nous l’expédions maintenant. Une grande, grande réussite et bravo à l’équipe Aqua pour avoir livré Trivy en tant que projet open source.
Swapnil Bhartiya : C’est la question que j’allais poser, mais je vais encore une fois poser la même chose, qu’est-ce que cela signifie pour les utilisateurs qui utilisaient Claire ? Michael Michael : Si vous utilisez Claire auparavant et que vous souhaitez continuer à utiliser Claire, nous allons continuer à mettre à jour Claire, Claire est déjà incluse dans Harbor. Il n’y a aucun changement dans l’expérience. Cependant, si vous pensez que Trivy est un meilleur scanner pour vous, et en passant, vous pouvez les utiliser côte à côte afin de pouvoir comparer les résultats de numérisation de chaque scanner. Et si Trivy est une meilleure option pour vous, nous vous avons permis de faire ce choix. Maintenant, la façon dont Harbour fonctionne est que vous avez un concept de multilocation et nous isolons une grande partie des paramètres et de la politique dans l’organisation des images et par projet. Alors qu’est-ce que cela signifie? Vous pouvez en fait aller dans Harbour et vous pouvez définir un projet et vous pouvez dire pour ce projet que je veux que Claire soit le scanner intégré.
Et puis Claire analysera tous vos projets, tous les fichiers de ce projet. Et vous pouvez utiliser un deuxième projet et dire, eh bien, je veux maintenant que Trivy soit le scanner de ce projet. Et puis Trivy of you scannera vos images. Et si vous avez le même ensemble d’images, vous pouvez les comparer et voir quel scanner fonctionne le mieux en fonction de vos besoins en tant qu’organisation et en tant qu’utilisateur. C’est phénoménal, non ? Pour donner aux utilisateurs le choix et nous leur donnons toutes les données, mais en fin de compte, ils doivent décider quel est le meilleur scanner à utiliser en fonction de leurs scénarios, du type d’images d’application et de conteneurs qu’ils utilisent et du type de bibliothèques ils utilisent ces conteneurs.
Swapnil Bhartiya : Excellent. Avant de conclure, quel type de feuille de route vous avez pour Harbor, bien sûr, c’est un projet open source. Il n’y a donc rien de tel que la sortie de la version 2.0. Mais quand on regarde 2020, quels sont les grands défis que vous voulez relever ? Quels sont les problèmes que vous souhaitez résoudre et à quoi ressemble la feuille de route de base ? Michael Michael : Absolument, je pense que l’une des choses que nous avons essayé de faire en tant qu’équipe de maintenance pour Harbor est de créer en quelque sorte des thèmes autour de la version, c’est en quelque sorte mettre un plan en termes de ce que c’est que essayons-nous d’atteindre? Et puis identifiez les caractéristiques qui ont du sens dans ce thème. Et nous ne proposons pas cela à partir du vide, nous parlons aux utilisateurs, nous parlons à d’autres entreprises où nous avons organisé des événements KubeCon dans le passé où nous avons eu des présentations et des individus sont venus nous poser des séries de questions. Nous avons des utilisateurs existants qui nous font part de leurs commentaires. Lorsque nous rassemblons tout cela, l’une des choses que nous avons proposées comme prochaine chose pour notre sortie est ce que vous appelez la distribution d’images. Nous avons donc trois caractéristiques clés que nous essayons d’aborder dans ce domaine.
Le premier est comment Harbour peut-il agir comme un cache proxy ? Pour permettre aux organisations qui déploient des environnements Kubernetes à la périphérie et qui souhaitent une instance Harbor locale pour proxy ou des images miroir du vaisseau mère comme votre centre de données principal et où la mise en réseau est primordiale. Peut-être que certains nœuds Kubernetes ne sont même pas connectés au réseau et qu’ils veulent être un support pour extraire des images de Harbor, puis Harbour extrait les images du centre de données en amont. Fonctionnalité très, très importante. Continuer sur le chemin de la distribution d’images. Nous intégrons Harbour avec Dragonfly d’Alibaba et Project Kraken d’Uber pour faciliter les mécanismes de distribution peer to peer pour vos images de conteneurs. Alors, comment pouvons-nous distribuer efficacement des images à la périphérie dans plusieurs centres de données dans des succursales qui ne disposent pas d’un bon réseau ou d’un réseau dense entre eux ? Et comment Harbour peut-il s’assurer que les bonnes images arrivent au bon endroit ? De grosses, grosses fonctionnalités que nous essayons de travailler avec la communauté. Et évidemment, nous ne le faisons pas seuls, nous travaillons à la fois avec les communautés Kraken et Dragonfly pour y parvenir.
Et enfin, la prochaine fonctionnalité que nous avons est ce que vous appelez la collecte des ordures sans temps d’arrêt. Traditionnellement, nous effectuons la récupération des ordures et c’est en quelque sorte le processus où vous récupérez certains des fichiers et des couches d’images de conteneurs qui ne sont plus utilisées.
Pensez à une organisation qui pousse et extrait des milliers d’images chaque jour ; ils les re-étiquettent, ils créent de nouvelles versions. Parfois, vous vous retrouvez avec des couches qui ne sont plus utilisées, pour que ces couches soient récupérées dans le stockage et par le système, leur registre doit être verrouillé car personne ne peut y tirer ou y envoyer des images. Dans Harbour 2.0, nous avons en fait fait une avancée significative où nous suivons toutes les couches et les métadonnées des images dans notre base de données plutôt que de dépendre d’un autre outil ou produit pour le faire. Alors maintenant, cela ouvre une route pour qu’à l’avenir, nous puissions réellement faire un ramassage des ordures sans aucun temps d’arrêt où Harbour peut identifier toutes les couches qui ne sont plus utilisées, aller les récupérer. Et puis cela n’aura aucun impact négatif ou temps d’arrêt pour les utilisateurs qui poussent et tirent du contenu. Énorme,
Swapnil Bhartiya : Génial, merci Michael d’avoir expliqué les choses en détail et d’avoir parlé de Harbour. J’ai hâte de vous parler à nouveau. Merci. Michael Michael : Absolument. Merci beaucoup pour l’opportunité.
