DÉPLOYER

Registres privés

Tirez depuis Docker Hub, GHCR, GitLab ou un registre auto-hébergé avec des identifiants enregistrés.

Les images publiques ne demandent aucune configuration. Une entrée de registre sert à l’autre cas : les images derrière des identifiants — votre propre GitHub Container Registry, un registre GitLab, un dépôt Docker Hub payant, ou un registre que vous exploitez.

En ajouter un

Un registre, c’est un hôte, un identifiant et un mot de passe. L’hôte est ce que prend docker login — sans schéma, sans chemin :

TEXT

ghcr.io
registry.gitlab.com
registry.example.com:5000

Cette même chaîne est le préfixe qu’une référence d’image doit porter pour correspondre à cette entrée. ghcr.io/acme/api:v3 correspond à la ligne ghcr.io et est tirée avec ses identifiants ; acme/api:v3 non, et part vers Docker Hub anonymement.

DockBoard teste les identifiants à l’enregistrement et affiche le résultat. Un registre jamais testé avec succès apparaît explicitement en attente, plutôt que discrètement cassé jusqu’à votre prochain déploiement.

Le mot de passe est stocké chiffré et n’est jamais restitué en clair par aucun endpoint. Il n’est déchiffré que pour un docker login exécuté par DockBoard lui-même, ou transmis à un agent dans une charge de déploiement chiffrée.

Utilisez un jeton limité à la lecture des paquets, pas le mot de passe de votre compte. GitHub, GitLab et Docker Hub en délivrent tous un, et il se révoque sans toucher au reste de vos accès.

Personnel ou limité à un projet

Un registre appartient à la personne qui l’a ajouté, et se limite éventuellement à un projet :

Personnel — utilisable dans tous les projets de son propriétaire. Adapté au jeton de votre propre compte.
Limité au projet — utilisable seulement dans ce projet. Adapté au registre d’un client, ou à un identifiant qui appartient à l’équipe plutôt qu’à vous.

Même forme que pour les fournisseurs DNS, et pour la même raison : un identifiant doit porter exactement aussi loin que le travail auquel il sert.

Exploiter votre propre registre

DockBoard peut exécuter un conteneur de registre sur l’un de vos serveurs et en gérer le certificat. Ce certificat est auto-signé : les machines qui tirent depuis ce registre doivent lui faire confiance — DockBoard leur distribue donc l’autorité de certification.

Cette distribution ne coûte rien en exploitation : Docker relit le magasin de confiance à chaque pull, une nouvelle machine ne nécessite donc aucun redémarrage de démon. C’est pourquoi cette approche a été retenue plutôt que l’édition de la liste des registres non sécurisés du démon, qui, elle, en exige un.

Un serveur hébergeant un registre ne peut pas être supprimé tant que des applications y puisent. Supprimer discrètement les identifiants d’un registre en service se traduit par un échec de pull à chaque déploiement suivant, sans rien à l’écran pour l’expliquer. Déplacez ou supprimez d’abord ces applications.

Un cluster possède toujours son propre registre, provisionné automatiquement à sa création — chaque nœud y puise. Celui-là est géré pour vous et n’est pas le même objet qu’un registre ajouté ici.

S’en servir dans une application

Rien à sélectionner. Déployez une application depuis une image prête en donnant la référence complète — si son préfixe d’hôte correspond à un registre auquel vous avez accès, les identifiants sont utilisés automatiquement :

TEXT

ghcr.io/acme/api:v3.2.1

Un pull qui échoue à l’authentification le dit dans le log de déploiement. Les deux causes habituelles : le jeton a expiré, ou la référence d’image n’a pas de préfixe d’hôte et est discrètement cherchée sur Docker Hub.