Libelektra: Jenkins : le docker pull échoue avec un EOF inattendu

Créé le 3 déc. 2019  ·  13Commentaires  ·  Source: ElektraInitiative/libelektra

Pour continuer la discussion à partir de #160 séparément :

Je l'ai recréé manuellement

@Maltraité comment l'avez-vous fait, uniquement sur un nœud ou avez-vous poussé l'image vers le hub ? Pensez-vous que le problème est isolé à jenkinsNode3 et qu'il n'y a pas de problème sur le hub ?

Commentaire le plus utile

L'augmentation du délai d'attente n'a pas aidé. J'ai remarqué que (seulement) jenkinsNode3VM exécutait le docker debian 18.x, j'ai donc mis à niveau vers la version amont du docker 19.x (qui était déjà utilisée par tous les autres nœuds).

jenkinsNode3VM était désormais capable de pousser et d'extraire des images sans problème. J'espère que ça restera comme ça.

Tous les 13 commentaires

D'accord, merci d'avoir corrigé ! Ensuite, cela n'a pas de sens pour moi d'effacer le registre Docker.

Je vais essayer de reconstruire et voir si tout fonctionne maintenant.

J'ai déjà vu cette erreur lorsque j'ai essayé pour la première fois d'ajouter un nouvel agent. A l'époque c'était l'agent hetzner-jenkins1. L'erreur a disparu après quelques tentatives, je ne savais pas pourquoi.

J'ai cloné libelektra et exécuté ce qui suit sur le jenkinsNode3 :
docker build libelektra/scripts/docker/debian/stretch/.

Habituellement, les agents réutilisent l'image locale, une fois qu'elle est extraite, mais je ne sais pas pourquoi l'extraction du hub génère une erreur occasionnelle.

Les images sont reconstruites tous les mois à ma connaissance (de sorte que le logiciel à l'intérieur des images est maintenu quelque peu à jour). Cela s'est également produit pour décembre maintenant, il est donc possible que l'image la plus récente n'ait pas déjà été mise en cache localement.

J'espère que cela (reconstruction mensuelle de toutes les images) se produira toujours, car

@ingwinlu, savez-vous toujours ce que le travail de construction mensuel a fait et pourquoi il n'avait pas de fichier Jenkins ?

J'ai recréé l'ancien serveur Jenkins. Je peux maintenant recréer le travail mensuel.

Je peux maintenant recréer le travail mensuel.

Fait.
Je ne connais pas les étapes exactes, mais je les examinerai dans la soirée.

J'ai recréé l'ancien serveur Jenkins. Je peux maintenant recréer le travail mensuel.

Bon travail, il pourrait être utile de conserver l'ancien serveur Jenkins pendant un certain temps. Arrêtez simplement le conteneur après utilisation et ne le démarrez pas au démarrage.

Maintenant, le push échoue également avec device or resource busy (j'ai déjà vu ça): https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3319/2/pipeline

Sur jenkinsNode3VM :

docker push hub.libelektra.org/build-elektra-website-backend:PR-3319_2
[...]
860ee8d82838: Retrying in 1 second
6bbb813c7d87: Retrying in 1 second
error creating overlay mount to /var/lib/docker/overlay2/8535169ca4de05e069978de34233d82158d1831fb4d980772411f59de2d370a5/merged: device or resource busy
script returned exit code 1

Peut-être qu'augmenter le délai d'attente dans le nginx de a7 aide : https://github.com/moby/moby/issues/22188#issuecomment -328011573

J'ai augmenté le délai d'attente, voyons.

L'augmentation du délai d'attente n'a pas aidé. J'ai remarqué que (seulement) jenkinsNode3VM exécutait le docker debian 18.x, j'ai donc mis à niveau vers la version amont du docker 19.x (qui était déjà utilisée par tous les autres nœuds).

jenkinsNode3VM était désormais capable de pousser et d'extraire des images sans problème. J'espère que ça restera comme ça.

Apparemment, cela a été corrigé.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

sanssecours picture sanssecours  ·  3Commentaires

mpranj picture mpranj  ·  3Commentaires

markus2330 picture markus2330  ·  4Commentaires

mpranj picture mpranj  ·  3Commentaires

e1528532 picture e1528532  ·  4Commentaires