docker pull கண்டெய்னரின் ப்ராக்ஸி அமைப்பைப் புறக்கணிப்பது ஏன்?
கண்டெய்னரின் ப்ராக்ஸி மாறிகள் டீமனை இயக்கும் என்று எதிர்பார்க்காமல் இமேஜ்களை உண்மையில் பதிவிறக்கும் Docker பகுதியை அமைக்கவும்.
docker pull தோல்வியடைந்தால் Docker டீமன் அல்லது Docker Desktop-ஐ அமைக்கவும். செயலி கண்டெய்னர் தனது ப்ராக்ஸி மாறிகளைப் படிப்பதற்கு முன்பே இமேஜ் பதிவிறக்கப்படுகிறது.
நேரடியாக நிறுவிய Docker Engine
இந்தப் பகுதியை ஏற்கெனவே உள்ள டீமன் ப்ராக்ஸி அமைப்புடன் இணைத்து, ஆவண முனையத்தை மாற்றி, தொடர்பற்ற அமைப்புகளை வைத்திருங்கள். பொது ப்ராக்ஸி அனுமதிக்கப்படும் பொது இமேஜ் சோதனைகளுக்கு HTTP ப்ராக்ஸி பட்டியல் தேர்வுகளைத் தருகிறது:
{
"proxies": {
"http-proxy": "http://203.0.113.10:8080",
"https-proxy": "http://203.0.113.10:8080",
"no-proxy": "localhost,127.0.0.1,registry.example.internal"
}
}டீமனின் ஹைபன் கொண்ட விசைகள் Docker கிளையன்டின் ~/.docker/config.json-இல் உள்ள camelCase விசைகளிலிருந்து வேறுபடும். கிளையன்ட் ப்ராக்ஸி பகுதி புதிய கண்டெய்னர்களுக்கும் build-களுக்கும் சுற்றுச்சூழல் மாறிகள் தருகிறது; டீமன் பதிவிறக்கங்களையோ ஏற்கெனவே உள்ள கண்டெய்னர் சூழலையோ அமைப்பதில்லை.
நிறுவலுக்கு ஆவணப்படுத்தியபடி டீமனை மறுதொடக்கம் செய்து, நடப்புப் பணிகளின் தாக்கத்தைத் திட்டமிடுங்கள். டீமனுக்கு தொடக்கச் சூழலிலும் ப்ராக்ஸி மாறிகள் தரலாம்; பின்னர் டெர்மினலில் export செய்தால் இயங்கும் சேவை புதுப்படாது.
Docker Desktop
Desktop-இன் சொந்த ப்ராக்ஸி அமைப்பைப் பயன்படுத்துங்கள். Docker ஆவணப்படி Desktop daemon.json-இல் உள்ள ப்ராக்ஸி பதிவுகளைப் புறக்கணிக்கிறது; எனவே நேரடி Engine எடுத்துக்காட்டை மீண்டும் மீண்டும் மாற்றினாலும் இந்தத் தயாரிப்பின் பாதை அமையாது.
உண்மையான பகுதியைப் புதுப்பித்தபின் இமேஜை மீண்டும் பெறுங்கள். registry அணுகல், அங்கீகாரம், வழிமாற்றம் அல்லது லேயர் பதிவிறக்கத்தில் எது தோல்வியடைந்தது என்று பாருங்கள். ஏற்கெனவே உள்ள கண்டெய்னரில் வெற்றிகரமான HTTP கோரிக்கை அந்தச் செயலியின் பாதையை மட்டுமே சோதிக்கிறது. பகிரும் திரைப்பிடிப்புகளிலும் commit கோப்புகளிலும் ப்ராக்ஸி நுழைவுச் சான்றுகளை வைக்க வேண்டாம்; டீமன் அமைப்பும் கண்டெய்னர் சூழலும் ரகசியக் கிடங்குகள் அல்ல.