docker pull VPN-i kaudu: daemonil on oma võrk

Sülearvuti on ettevõtte VPN-is, curl jõuab sisemise registry juurde ja ometi sureb docker pull EOF-iga. See kombinatsioon ei ole vastuolu. Käsk, mille te kirjutasite, jookseb teie shellis, kuid ülekanne jookseb selles daemonis, mille Docker CLI valis, ja see daemon võib olla hoopis teises hostis. Töötama peab just tema võrgutee ja kehtivad just tema proxy-seaded.

Alustage mootori, mitte marsruudi tuvastamisest

Käivitage docker context show ja docker version. Versiooni väljund trükib kliendi jaotise ja serveri jaotise ning serveri plokk ütleb, kes vastas: kohalik natiivne mootor, Docker Desktopi virtuaalmasin või daemon kaugmasinas. docker context inspect näitab valitud konteksti lõpp-punkti, kui soovite kindel olla, ja ükski neist käskudest ei muuda midagi.

Keskkonnamuutuja nagu DOCKER_HOST võib CLI vaikselt suunata teisele mootorile, kui te eeldate, mis on tavaline seletus sülearvutile, mis näib olevat VPN-is, samal ajal kui tõmbamine liigub mujale.

Daemonil on oma võrguidentiteet

Kaugmootoril on vaja oma kinnitatud teed privaatse registry juurde. Sülearvuti VPN-kliendi ühendamine annab sellele sülearvutile marsruudi; see ei anna laboris või pilve alamsuunas asuvale daemonile sama privaatset aadressi. Kui mootor on Docker Desktop, toimub tõmbamine selle virtuaalmasinas, millel on oma võrgu- ja proxy-konfiguratsioon, mis on teie shelli keskkonnast eraldi.

Seepärast on edukas curl hostis tõend hosti kohta ja mitte midagi enamat.

Tehke kindlaks, milline registry-vahetus lõppes

Kujutise tõmbamine on järjestus: autentimine, manifesti hankimine ja seejärel blob-ülekanded, mis suunatakse sageli objektihoidlasse või CDN-i lõpp-punkti. Edukas docker login tõestab ainult esimest sammu ja token võib olla täiesti kehtiv, samal ajal kui ümbersuunatud blob-host on daemoni võrgust kättesaamatu. Enne millegi muutmist kirjutage üles täpne aeg, kujutise viide ja esimene kasulik sündmus daemoni või kliendi logist.

EOF iseenesest ei nimeta põhjust. See võib olla katkenud ühendus, voo maha visanud proxy, aegumine või MTU probleem, ning nende vahel ilma ajatempliga sündmuseta oletamine on viis, kuidas inimesed hakkavad tervet mootorit ümber ehitama. Käsitlege kliendi väljundis olevat baidi nihet andmena, sest ülekanne, mis peatub iga kord samal suurusel, on hoopis teine loom kui see, mis ei alga kunagi. Kirjutage üles mõlemad tulemused ja võrrelge neid katsete vahel.

Seadistage komponent, mis edastab

Natiivse Linuxi mootori puhul kuulub proxy teenusekeskkonda, mitte teie shelli. Drop-in fail asukohas /etc/systemd/system/docker.service.d/ kirjetega HTTP_PROXY, HTTPS_PROXY ja NO_PROXY, millele järgnevad systemctl daemon-reload ja taaskäivitus, on dokumenteeritud lahendus. Docker Desktop pakub samu väärtusi oma seadete kaudu ja shelli profiili muutmine ei puuduta kumbagi.

Kui registry peab olema kättesaadav otse VPN-i kaudu, vajab daemon resolverit, marsruuti ja teadlikku proxy-väljajätmist, mitte ainult väljajätmist. NO_PROXY sobitamine on komponendipõhine stringivõrdlus ja erand ilma aluseks oleva marsruudita tekitab tõrke, mis näeb välja nagu proxy probleem.

Kui ettevõtte TLS-inspektsioon asub kinnitatud teel, installige selle kontrollitud juur mootori või Desktopi töövoo kaudu. Registry lisamine insecure-registries loendisse on teistsugune muudatus, mis lülitab valideerimise välja, ja see ei ole usaldushoidla konfiguratsioon.

Korrake ühte kontrollitud tõmbamist ja kontrollige, mis muutus

Muutke ühte piiri, taaskäivitage komponent, millele see kuulub, ja korrake sama tõmbamist samast kontekstist. Kontrollige saadud kujutise viidet ja digesti, mitte vea puudumist, sest vahemällu salvestatud kiht võib panna teise katse läbima palju väiksemat osa teest kui esimene. Hoidke piletis ülekanded, mis tegelikult toimusid, sest need on ainus ülestähendus sellest, mida korduskatse tõesti testis.

Build-sammudel ja jooksvatel konteineritel on oma võrgukontekstid, seega käsitlege neid eraldi küsimustena, kui tõmbamine ise töötab.