web-dev-qa-db-fra.com

Docker pull: timeout de prise de contact TLS

J'obtiens ceci de façon 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 très 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-networkingdocker
16
Willem

net/http: TLS handshake timeout signifie 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 pas de paramètres qui vous permettent de modifier le délai d'expiration de la connexion. Vous pouvez essayer de créer votre propre cache de registre ailleurs et en extraire des images.

17
Azamat Hackimov

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 d'attente entre en action 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 deuxième réussit pour moi.

4
JaM

Dans mon cas, mon serveur était derrière le nat et le proxy et réglé 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
4
Mansur Ali

J'ai eu un problème égal, en utilisant docker run hello-world 1ère fois, ce qui entraîne le téléchargement d'une image à l'aide de https://registry-1.docker.io/v2/, qui se terminent 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.

(soit dit en passant: j'ai eu un problème de "prise de contact TLS" égal avec composer et packagist. Cela était dû à un fichier cacert.pem manquant, qui n'était pas fourni par ubuntu par défaut. Peut-être que cela docker-problem va dans le même sens?)

4
The Bndr

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

nom du registre changera en conséquence

En outre, veuillez modifier votre taille MTU à 1300, c'est aussi une chose que j'ai faite pour résoudre l'erreur. Je pense que vous l'avez 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

3
rebelution

Vous pouvez obtenir le TLS handshake timeout erreur 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

0
wisbucky

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.

0
bandaangosta

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

Après ce changement, le département 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 s certains 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.

0
Fei