J'utilise un modèle google (fichier binaire: environ 3 Go) dans mon fichier docker, puis j'utilise Jenkins pour le construire et le déployer sur le serveur de production. Le reste du code est extrait du repo bitbucket.Traitement de gros fichiers binaires (3 Go) dans docker et Jenkins
Un exemple de ligne du fichier docker dans lequel je télécharge et décompresse le fichier. Cela n'arrive qu'une fois car cette commande sera mise en cache. Tout fonctionne correctement lorsque je compile et exécute le docker sur ma machine locale. Cependant, quand je fais la version de patch pour pousser ces changements au serveur de production par Jenkins, mon processus de construction échoue à la fin. Les phases d'installation, de construction et de test fonctionnent correctement. Cependant, la phase de post-construction échoue. (Le processus de construction pousse les modifications à la repo, et selon les journaux, toutes les commandes dans le fichier docker fonctionne aussi bien.) Quelque chose se passe après cela et je reçois l'erreur suivante lorsque j'ai regardé les journaux.
18:49:27 654f45ecb7e3: Layer already exists
18:49:27 2c40c66f7667: Layer already exists
18:49:27 97108d083e01: Pushed
18:49:31 35a4b123c0a3: Pushed
18:50:10 1e730b4fb0a6: Pushed
18:53:46 error parsing HTTP 413 response body: invalid character '<'
looking for beginning of value: "<html>\r\n<head><title>413 Request
`Entity Too Large</title></head>\r\n<body
bgcolor=\"white\">\r\n<center>`<h1>413 Request
Entity Too Large</h1></center>\r\n<hr>
center>nginx/1.10.1</center>\r\n</body>\r\n</html>\r\n"
Est-ce que ce fichier est trop volumineux? Avant l'ajout de ce fichier, tout avec docker et Jenkins fonctionnait bien aussi.
Je me demande s'il y a des limites dans docker/Jenkins dans la gestion d'un gros fichier comme celui-ci? ou je casse quelque chose comme je l'aborde.
Mise à jour: L'augmentation de client_max_body_size a permis de résoudre cette erreur spécifique. Cependant, je reçois une autre erreur à ssh -o StrictHostKeyChecking=no [email protected] "cd /root/ourapi &&docker-compose pull api &&docker-compose -p somefolder up -d"
La traction de docker-composer échoue ici avec un eof inattendu. Il essaie de télécharger l'image (1,6 Go) mais l'annule après presque se rapprocher de cette taille, puis l'essaie de nouveau, ce qui se termine par une erreur d'erreur.
Ce qui m'amène à la vieille question si les gros fichiers doivent être traités différemment dans cette situation?
Mise à jour 2: Le problème a été résolu. Je devais augmenter le client_max_body_size à 4 Go et aussi augmenter le paramètre de délai pour extraire le référentiel de notre propre serveur de référentiel. Ajuster ces deux paramètres a conduit à résoudre le problème.
Si votre serveur en utilisant nginx jenkins ou tout autre serveur proxy, essayez ce https://stackoverflow.com/questions/35922145/jenkins-artifactory-plugin-give-unexpected -character-when-essay-to-upload-large – Gangaraju
L'augmentation de client_max_body_size a résolu cette erreur spécifique mais maintenant je reçois une erreur avec le docker compose, ce qui m'amène encore à la question si les gros fichiers doivent être gérés différemment. – utengr
Envisager d'écrire une réponse - les questions sans réponse semblent être ouvertes. –