2017-10-16 3 views
0

Nous avons une configuration de test artificielle sur AWS qui implique AWS ELB et une instance EC2 agissant comme un serveur artificiel. JFROG artificielDocker push Tomber avec "Impossible de lire le flux: EOF inattendu lu sur le socket 'status' 400 '

Nous sommes confrontés à l'erreur "EOF inattendue de lecture sur le socket" en poussant une image particulière ("platform-image") mais nous sommes en mesure de pousser la même image vers l'environnement de production que nous avons. entre ces deux environnements est que nous utilisons AWS ELB et registre de docker de type sous-domaine à l'environnement de test.Dans notre prod actuelle, nous ne disposons pas de registre de docker et ELB est de liaison de type port

2017-10-16 06: 48: 37,967 [http-nio-8081-exec-9] [ERREUR] (oaacrArtifactoryService: 282) - Échec de lecture du flux: EOF inattendue lue sur le socket org.jfrog. storage.binstore.common.ClientInputStreamException: Impossible de lire le flux: EOF inattendu lu sur le socket at org.jfrog.storage.binstore.common.ClientStream.read (ClientStream.java:36) ~ [binary-store-core-1.0 .2.jar: na] à org.apache.commons.io.IOUtils.copyLarge (IOUtils.java:1792) ~ [commons-io-2.4.jar: 2.4] à org.apache.commons.io.IOUtils .copyLarge (IOUtils.java:1769) ~ [commons-io-2.4.jar: 2.4] à org.apache.commons.io.IOUtils.copy (IOUtils.java:1744) ~ [commons-io-2.4.jar : 2.4]

2017-10-16 06: 48: 37,968 [http-nio-8081-exec-9] [WARN] (ojrdvrhDockerV2LocalRepoHandler: 170) - Erreur lors du chargement de blob 'platform-image/_uploads/e205ae95-2e43-48c2-942e-a5aea659575c' obtenu le statut '400 'et message:' Impossible de lire le flux: EOF inattendu lu sur le socket '

S'il vous plaît vérifier et laissez-nous savoir ce qui pourrait être le problème ici. Nous ne sommes pas confrontés à ce problème pour toutes les images. Mais et même image qui a des problèmes, nous sommes en mesure de pousser à prod instance.

Remarque: La même image a fonctionné initialement une fois mais lorsque nous essayons après quelques jours, cela ne fonctionne pas. Nous soupçonnons que cela pourrait être quelque chose avec notre configuration. S'il vous plaît laissez-nous savoir si vous avez besoin de plus de détails de notre part.

Nom de l'image: platform-image Taille: 15.2 GB.

Nos coordonnées du cluster: AWS classique ELB: 1 EC2 instance (i3.2xlarge): 1

config Nginx:

## server configuration 
server { 
    listen 443 ssl; 
    listen 80 ; 
    server_name ~(?<repo>.+)\.domain.com domain.com; 

    if ($http_x_forwarded_proto = '') { 
     set $http_x_forwarded_proto $scheme; 
    } 
    ## Application specific logs 
    access_log /var/log/nginx/docker-access.log; 
    error_log /var/log/nginx/docker-error.log; 
    rewrite ^/$ /artifactory/webapp/ redirect; 
    rewrite ^/artifactory/?(/webapp)?$ /artifactory/webapp/ redirect; 
    rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/$repo/$1/$2; 
    chunked_transfer_encoding on; 
    client_max_body_size 0; 
    location /artifactory/ { 
    proxy_read_timeout 3200; 
    proxy_pass_header Server; 
    proxy_cookie_path ~*^/.* /; 
    proxy_pass   http://localhost:8081/artifactory/; 
    proxy_set_header X-Artifactory-Override-Base-Url $http_x_forwarded_proto://$host:$server_port/artifactory; 
    proxy_set_header X-Forwarded-Port $server_port; 
    proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; 
    proxy_set_header Host    $http_host; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 
} 

Répondre

0

Après enquête, nous avons constaté cette question a été provoquée par la configuration ELB . La valeur du délai d'inactivité ELB a été définie sur 60 secondes par défaut et l'élément artificiel n'a pas pu renvoyer de réponse dans ce délai, ce qui a empêché la connexion de se terminer par ELB. L'augmentation de la valeur du délai d'inactivité a résolu le problème.

Erreur de journal artificiel n'était pas clair sur le délai d'attente et il est plus générique qui nous fait penser à plusieurs côtés.

Merci.