doc-locale/fr-fr/administration/geo/replication/container_registry.md
{{< details >}}
{{< /details >}}
Vous pouvez configurer un registre de conteneurs sur votre site Geo secondaire qui réplique les images de conteneurs depuis celui du site Geo principal. Cette réplication d'images de conteneurs est utilisée uniquement à des fins de reprise après sinistre.
Ne poussez pas vers le registre de conteneurs sur le site Geo secondaire, car les données ne sont pas propagées vers le site principal.
Nous ne recommandons pas d'extraire des données du registre de conteneurs depuis le site secondaire, car elles peuvent être obsolètes. La demande de fonctionnalité ticket 365864 permettrait de résoudre ce problème. Vous êtes encouragé à voter pour ce ticket afin d'enregistrer votre intérêt.
[!warning] Important : La base de données de métadonnées du registre de conteneurs est distincte de la réplication des images de conteneurs. Bien que les images de conteneurs se répliquent des sites principaux vers les sites secondaires, la base de données de métadonnées ne le fait pas. Lors de l'utilisation de GitLab Geo avec la base de données de métadonnées du registre de conteneurs activée, vous devez configurer des instances PostgreSQL externes séparées pour le registre de conteneurs sur chaque site Geo (principal et secondaire). La base de données de métadonnées du registre de conteneurs ne peut pas utiliser la base de données PostgreSQL gérée par GitLab par défaut. La base de données de métadonnées de chaque site fonctionne de manière indépendante, sans réplication entre elles. Pour les instructions de configuration, consultez Utilisation d'une base de données externe.
Geo prend en charge les types de registres de conteneurs suivants :
Les formats d'images de conteneurs suivants sont pris en charge par Geo :
De plus, Geo prend également en charge les images de cache BuildKit.
Pour plus d'informations sur les pilotes de stockage de registre pris en charge, consultez les pilotes de stockage du registre Docker
Lisez les considérations relatives à l'équilibrage de charge lors du déploiement du registre, et comment configurer le pilote de stockage pour le registre de conteneurs intégré à GitLab.
Les registres suivants prennent en charge les artefacts OCI :
Pour plus d'informations, consultez la spécification de distribution OCI.
Vous pouvez activer une réplication indépendante du stockage afin qu'elle puisse être utilisée pour un stockage cloud ou local. Chaque fois qu'une nouvelle image est poussée vers le site principal, chaque site secondaire la récupère dans son propre dépôt de conteneurs.
Pour configurer la réplication du registre de conteneurs :
Assurez-vous que le registre de conteneurs est configuré et fonctionnel sur le site principal avant de suivre les étapes suivantes.
Pour pouvoir répliquer de nouvelles images de conteneurs, le registre de conteneurs doit envoyer des événements de notification au site principal à chaque push. Le jeton partagé entre le registre de conteneurs et les nœuds web du site principal est utilisé pour sécuriser les communications.
Connectez-vous en SSH à votre serveur GitLab principal et connectez-vous en tant que root (pour GitLab HA, vous n'avez besoin que d'un nœud Registry) :
sudo -i
Modifiez /etc/gitlab/gitlab.rb :
# Configure the registry to listen on the public/internal interface
# Replace with the appropriate interface (for example, '0.0.0.0' for all interfaces)
registry['registry_http_addr'] = '0.0.0.0:5000'
registry['notifications'] = [
{
'name' => 'geo_event',
'url' => 'https://<example.com>/api/v4/container_registry_event/events',
'timeout' => '500ms',
'threshold' => 5,
'backoff' => '1s',
'headers' => {
'Authorization' => ['<replace_with_a_secret_token>']
}
}
]
Remplacez <example.com> par l'external_url défini dans le fichier /etc/gitlab/gitlab.rb de votre site principal, et remplacez <replace_with_a_secret_token> par une chaîne alphanumérique sensible à la casse qui commence par une lettre. Vous pouvez en générer une avec /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo
[!note] Si vous utilisez un registre externe (pas celui intégré à GitLab), vous n'avez besoin de spécifier que le secret de notification (
registry['notification_secret']) dans le fichier/etc/gitlab/gitlab.rb.
Pour GitLab HA uniquement. Modifiez /etc/gitlab/gitlab.rb sur chaque nœud web :
registry['notification_secret'] = '<replace_with_a_secret_token_generated_above>'
Reconfigurez chaque nœud que vous venez de mettre à jour :
gitlab-ctl reconfigure
Assurez-vous que le registre de conteneurs est configuré et fonctionnel sur le site secondaire avant de suivre les étapes suivantes.
Les étapes suivantes doivent être effectuées sur chaque site secondaire sur lequel vous attendez de voir les images de conteneurs répliquées.
Étant donné que nous devons permettre au site secondaire de communiquer de manière sécurisée avec le registre de conteneurs du site principal, nous devons disposer d'une seule paire de clés pour tous les sites. Le site secondaire utilise cette clé pour générer un JWT à courte durée de vie avec accès en lecture seule permettant d'accéder au registre de conteneurs du site principal.
Pour chaque nœud d'application et Sidekiq sur le site secondaire :
Connectez-vous en SSH au nœud et connectez-vous en tant qu'utilisateur root :
sudo -i
Copiez /var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key depuis le site principal vers le nœud.
Modifiez /etc/gitlab/gitlab.rb et ajoutez :
gitlab_rails['geo_registry_replication_enabled'] = true
# Primary registry's hostname and port, it will be used by
# the secondary node to directly communicate to primary registry
gitlab_rails['geo_registry_replication_primary_api_url'] = 'https://primary.example.com:5050/'
Reconfigurez le nœud pour que la modification prenne effet :
gitlab-ctl reconfigure
Pour vérifier que la réplication du registre de conteneurs fonctionne, sur le site secondaire :
Vous pouvez surveiller le processus de synchronisation sur chaque site Geo depuis le tableau de bord Geo Nodes du site principal dans votre navigateur.
Cela peut être effectué avec une vérification à l'aide de la console Rails :
Geo::ContainerRepositoryRegistry.replication_enabled?
https://<example.com>/api/v4/container_registry_event/eventsgeo_events avec replicable_name: 'container_repository', model_record_id: <ID of the container repository>.Geo::EventWorkerPour vérifier que cela fonctionne correctement, poussez une image vers le registre sur le site principal, et exécutez la commande suivante sur la console Rails pour vérifier que la notification a été reçue et traitée sous forme d'événement :
Geo::Event.where(replicable_name: 'container_repository')
Vous pouvez vérifier cela davantage en consultant geo.log pour les entrées provenant de Geo::ContainerRepositorySyncService.
Les erreurs 401 Unauthorized indiquent que la notification du registre de conteneurs du site principal n'est pas acceptée par l'application Rails, l'empêchant d'informer GitLab qu'un push a été effectué.
Pour résoudre ce problème, assurez-vous que les en-têtes d'autorisation envoyés avec la notification du registre correspondent à ce qui est configuré sur le site principal, comme cela devrait être fait lors de l'étape Configurer le site principal.
token from untrusted issuer: "<token>" {#registry-error-token-from-untrusted-issuer-token}Lors de la réplication d'images de conteneurs dans Geo, vous pourriez voir l'erreur token from untrusted issuer: "<token>".
Ce problème survient lorsque la configuration du registre de conteneurs est incorrecte, entraînant l'échec de l'authentification JWT de Sidekiq.
Pour résoudre ce problème :
Pour faciliter le dépannage, vous pouvez déclencher manuellement le processus de réplication du registre de conteneurs :
Vous pouvez également déclencher manuellement une resynchronisation en exécutant les commandes suivantes sur la console Rails du site secondaire :
registry = Geo::ContainerRepositoryRegistry.first # Choose a Geo registry entry
registry.replicator.sync # Resync the container repository
pp registry.reload # Look at replication state fields
#<Geo::ContainerRepositoryRegistry:0x00007f54c2a36060
id: 1,
container_repository_id: 1,
state: "2",
retry_count: 0,
last_sync_failure: nil,
retry_at: nil,
last_synced_at: Thu, 28 Sep 2023 19:38:05.823680000 UTC +00:00,
created_at: Mon, 11 Sep 2023 15:38:06.262490000 UTC +00:00>
Le champ state représente l'état de synchronisation :
"0" : synchronisation en attente (signifie généralement qu'elle n'a jamais été synchronisée)"1" : synchronisation démarrée (un job de synchronisation est en cours d'exécution)"2" : synchronisé avec succès"3" : échec de la synchronisationSi la réplication du registre de conteneurs a été désactivée pendant une période, que ce soit via le feature flag geo_container_repository_replication ou une mauvaise configuration, les images poussées durant cette période pourraient ne pas se synchroniser automatiquement vers le site secondaire.
Les nouveaux dépôts de conteneurs créés pendant l'interruption sont automatiquement pris en charge par le worker de remplissage après la réactivation de la réplication. Cependant, les mises à jour des dépôts de conteneurs existants (par exemple, de nouveaux tags poussés vers un dépôt existant) ne sont pas automatiquement resynchronisées. L'interface d'administration Geo peut toujours indiquer 100 % de réplication car l'état de synchronisation est basé sur l'état de l'entrée du registre, et non sur la vérification du contenu.
Les dépôts de conteneurs mis à jour se resynchronisent éventuellement après que le cycle de revérification du site principal détecte une discordance de somme de contrôle. Pour plus d'informations sur l'intervalle de revérification, consultez la re-vérification du dépôt.
Pour forcer une resynchronisation immédiate au lieu d'attendre la revérification, consultez réessayer manuellement la réplication ou la vérification.