Docker pull: délai d'expiration de la négociation TLS

14

Je reçois ceci de manière cohérente (Ubuntu 16.04 LTS):

$ docker pull nginx
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: TLS handshake timeout

Cependant curl TLS fonctionne bien (à part l'erreur d'authentification):

$ curl https://registry-1.docker.io/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

Et même un petit programme golang (pour imiter docker) fonctionne très bien:

package main
import (
    "fmt"
    "io/ioutil"
    "net/http"
)
func main() {
    resp, err := http.Get("https://registry-1.docker.io/v2/")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    body, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }
    fmt.Println("Got: ", string(body))
}

Le pcap pour la demande de délai d'expiration du docker TLS:

reading from file docker-timeout.pcap, link-type LINUX_SLL (Linux cooked)
00:38:54.782452 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [S], seq 26945613, win 29200, options [mss 1460,sackOK,TS val 1609360 ecr 0,nop,wscale 7], length 0
00:38:54.878630 IP registry-1.docker.io.https > my-ubuntu.52036: Flags [S.], seq 2700732154, ack 26945614, win 26847, options [mss 1460,sackOK,TS val 947941366 ecr 1609360,nop,wscale 8], length 0
00:38:54.878691 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [.], ack 1, win 229, options [nop,nop,TS val 1609384 ecr 947941366], length 0
00:38:54.878892 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609384 ecr 947941366], length 155
00:38:55.175931 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609459 ecr 947941366], length 155
00:38:55.475954 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609534 ecr 947941366], length 155
00:38:56.076327 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609684 ecr 947941366], length 155
00:38:57.280103 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609985 ecr 947941366], length 155
00:38:59.684095 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1610586 ecr 947941366], length 155
00:39:04.492102 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611788 ecr 947941366], length 155
00:39:04.879468 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [F.], seq 156, ack 1, win 229, options [nop,nop,TS val 1611884 ecr 947941366], length 0
00:39:04.976015 IP registry-1.docker.io.https > my-ubuntu.52036: Flags [.], ack 1, win 105, options [nop,nop,TS val 947943890 ecr 1609384,nop,nop,sack 1 {156:157}], length 0
00:39:04.976073 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611909 ecr 947943890], length 155
00:39:05.275922 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611984 ecr 947943890], length 155
00:39:05.876104 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1612134 ecr 947943890], length 155

Qu'est-ce qui pourrait mal tourner?

linux-networking docker Willem
la source
1
J'ai échangé mon modem DSL et le problème avait disparu ... Je soupçonne que c'était un problème de MTU.
Willem

Réponses:

14

net/http: TLS handshake timeoutsignifie que votre connexion Internet est lente. La valeur par défaut du délai de connexion est trop petite pour votre environnement. Malheureusement, Docker n'a aucun paramètre vous permettant de modifier le délai d'expiration de la connexion. Vous pouvez essayer de créer votre propre cache de registre ailleurs et d'en extraire des images.

Azamat Hackimov
la source
1
Eh bien, speedtest.netet fast.commontre que ma vitesse Internet est de 90 Mbit / s. C'est lent? Je tire l' python:2.7-slimimage. Je peux tirer hello-worlddu hub mais pas du python. Cela me donne la même TLS handshake timeouterreur.
Nikhil Chilwant
3
Avant que les gens commencent à faire quelque chose de dramatique, je veux faire remarquer: avoir une faute de frappe dans le nom de l'image produit également la même erreur. Très descriptif.
Barafu Albino
1
Un délai d'attente de prise de contact TLS ne signifie généralement pas, la connexion Internet doit ralentir. Ce message apparaîtra également si la prise de contact TLS s'arrête pour différentes raisons. Par exemple, si un côté n'aime pas parler avec une version TLS spécifique ou à cause d'un problème de certificat.
Le Bndr
4

Dans mon cas, mon serveur était derrière le nat et le proxy et configuré pour détecter automatiquement le proxy ce que j'ai fait sur le terminal actuel, j'ai des paramètres de proxy d'exportation 

root@k8master:~/runner# export http_proxy="http://192.168.10.208:3128"
root@k8master:~/runner# docker pull gitlab/gitlab-runner:latest
latest: Pulling from gitlab/gitlab-runner
7b722c1070cd: Pull complete 
5fbf74db61f1: Pull complete 
ed41cb72e5c9: Pull complete 
7ea47a67709e: Pull complete 
ae336ceeca88: Pull complete 
f9f79780e6cf: Pull complete 
67e622273f37: Pull complete 
bc84c40af701: Pull complete 
69e36092e9de: Pull complete 
Digest: sha256:b1f5387942aaaf8c220f6613a1e96ba2cbcb6c58a5e47ca0df8ae3216720a15e
Status: Downloaded newer image for gitlab/gitlab-runner:latest
Mansur Ali
la source
3

J'ai eu un problème égal, en utilisant la docker run hello-world1ère fois, ce qui se traduit par le téléchargement d'une image en utilisant https://registry-1.docker.io/v2/, ce qui se termine par

docker: Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: net/http: TLS handshake timeout.

La recherche sur le Web pendant des heures et a découvert que cela se produit chez certains utilisateurs avec Ubuntu 18.04 et la version actuelle de Docker, derrière un proxy. Une solution de contournement consiste à supprimer toute la configuration du proxy https afin de ne laisser que la configuration du proxy http, pour forcer un téléchargement http (pas https).

Je ne sais pas quelle est la vraie raison.

(au fait: j'ai eu un problème de "prise de contact TLS" avec le compositeur et le packagist. C'était à cause d'un fichier cacert.pem manquant, qui n'était pas fourni par ubuntu par défaut. Peut-être que ce problème de docker va dans le même sens ?)

Le Bndr
la source
3

J'éprouve le même problème. Puis la réponse d'Azamat Hackimov m'a pointé dans la bonne direction. Ma machine est un peu lente, surtout au démarrage, lorsque je veux lancer le service. Par conséquent, le court délai expire et tue ma demande.

Voici ma solution:

docker pull $IMAGE || docker pull $IMAGE ||  docker pull $IMAGE || docker pull $IMAGE

Martelez simplement le serveur à la demande. Habituellement, le second réussit pour moi.

Confiture
la source
Pas une solution définitive mais une solution de contournement temporaire
Gonzalo Cao
2

Si vous utilisez un registre privé, vous devez placer le certificat que sous /etc/docker/certs.d/ registryName /ca.crt

le nom de registre changera en conséquence

De plus, veuillez modifier votre taille MTU à 1300, c'est aussi une chose que j'ai faite pour résoudre l'erreur. Un registre, je crois que vous l'avez peut-être déjà fait. Commande de changement de MTU

ip link set dev eth0 mtu 1300

La taille de la MTU est importante à vérifier pour éviter cette erreur si votre vitesse Internet est vraiment bonne

rébellion
la source
C'est une bonne astuce, mais ne pas avoir le certificat entraînerait une x509: certificate signed by unknown authorityerreur, non TLS handshake timeout.
wisbucky
0

Ce qui a fonctionné pour moi, c'était d'utiliser une interface réseau différente. Au lieu de me connecter via Ethernet (filaire), je suis passé au wifi. Problème résolu.

Au fait, j'étais sur une nouvelle installation de Raspbian Stretch.

bandaangosta
la source
0

Aucune des réponses ci-dessus ne peut résoudre mon problème, mais j'ai trouvé que https://github.com/helm/helm/issues/5220 fonctionne pour moi!

Après ce changement, l'appartement informatique de mon entreprise a trouvé une solution. J'ai utilisé la variable d'environnement https_proxy avec https: // url pour notre proxy. Cela fonctionne pour la plupart des outils que nous utilisons, mais pas pour Helm ou le kube plus récent. Ils semblent avoir quelques problèmes avec la prise de contact TLS. Nous sommes passés de https: // à une URL http: // (par exemple https_proxy = http: // myproxy ) et maintenant tout fonctionne bien.

Fei
la source
0

Vous pouvez obtenir l' TLS handshake timeouterreur si votre proxy de démon docker n'est pas configuré correctement.

# verify docker daemon proxy configuration
/etc/systemd/system/docker.service.d/proxy.conf

# flush changes
sudo systemctl daemon-reload

# restart docker service
sudo systemctl restart docker

Pour plus de détails, voir https://docs.docker.com/config/daemon/systemd/#httphttps-proxy

wisbucky
la source