VPN দিয়ে docker pull: ডেমনের নিজস্ব নেটওয়ার্ক আছে

আপনার ল্যাপটপ কর্পোরেট VPN-এ আছে, curl অভ্যন্তরীণ রেজিস্ট্রিতে পৌঁছায়, তবুও docker pull EOF দিয়ে ব্যর্থ হয়। এই সমন্বয় কোনো বিরোধ নয়। আপনি যে কমান্ডটি লিখেছেন সেটি আপনার শেলে চলে, কিন্তু স্থানান্তরটি চলে যে ডেমনটি Docker CLI বেছে নিয়েছে তার ভেতরে, আর সেই ডেমন সম্পূর্ণ ভিন্ন কোনো হোস্টে থাকতে পারে। কাজ করতে হবে তার নেটওয়ার্ক পথটিকেই, আর প্রযোজ্য হয় তার প্রক্সি সেটিংসই।

রুট নয়, ইঞ্জিন চিহ্নিত করে শুরু করুন

docker context show এবং docker version চালান। ভার্সন আউটপুট একটি ক্লায়েন্ট অংশ ও একটি সার্ভার অংশ ছাপে, আর সার্ভার ব্লকটি বলে দেয় কে উত্তর দিয়েছে: স্থানীয় নেটিভ ইঞ্জিন, Docker Desktop ভার্চুয়াল মেশিন, নাকি দূরবর্তী মেশিনে থাকা ডেমন। নিশ্চিত হতে চাইলে docker context inspect নির্বাচিত কনটেক্সটের এন্ডপয়েন্ট দেখাবে, এবং এই কমান্ডগুলোর কোনোটিই কিছু বদলায় না।

DOCKER_HOST-এর মতো এনভায়রনমেন্ট ভেরিয়েবল নীরবে CLI-কে আপনি যে ইঞ্জিন ধরে নিয়েছেন তার বদলে অন্য ইঞ্জিনের দিকে দেখাতে পারে, আর ল্যাপটপ VPN-এ থাকা সত্ত্বেও পুল অন্যত্র যাওয়ার এটাই সাধারণ ব্যাখ্যা।

ডেমনের নিজস্ব নেটওয়ার্ক পরিচয় আছে

দূরবর্তী ইঞ্জিনের প্রাইভেট রেজিস্ট্রিতে যাওয়ার জন্য নিজস্ব অনুমোদিত পথ দরকার। আপনার ল্যাপটপের VPN ক্লায়েন্ট সংযুক্ত করলে সেই ল্যাপটপ একটি রুট পায়; এতে ল্যাব বা ক্লাউড সাবনেটে বসে থাকা ডেমন একই প্রাইভেট ঠিকানা পায় না। ইঞ্জিন যদি Docker Desktop হয়, পুলটি ঘটে তার ভার্চুয়াল মেশিনের ভেতরে, যার নিজস্ব নেটওয়ার্কিং ও প্রক্সি কনফিগারেশন আছে এবং তা আপনার শেলের এনভায়রনমেন্ট থেকে আলাদা।

সেজন্যই হোস্টে সফল curl কেবল হোস্ট সম্পর্কে প্রমাণ, এর বেশি কিছু নয়।

কোন রেজিস্ট্রি বিনিময় শেষ হয়েছে তা খুঁজুন

ইমেজ পুল একটি ক্রম: প্রমাণীকরণ, ম্যানিফেস্ট সংগ্রহ, তারপর blob স্থানান্তর যা প্রায়ই অবজেক্ট স্টোরেজ বা CDN এন্ডপয়েন্টে রিডাইরেক্ট হয়। সফল docker login কেবল প্রথম ধাপ প্রমাণ করে, আর টোকেন পুরোপুরি বৈধ হতে পারে অথচ রিডাইরেক্ট হওয়া blob হোস্টটি ডেমনের নেটওয়ার্ক থেকে পৌঁছানোর বাইরে। কিছু বদলানোর আগে সঠিক সময়, ইমেজ রেফারেন্স এবং ডেমন বা ক্লায়েন্ট লগের প্রথম কাজের ইভেন্টটি লিখে রাখুন।

EOF একা কোনো কারণ বলে না। এটি কাটা সংযোগ, স্ট্রিম ফেলে দেওয়া প্রক্সি, টাইমআউট বা MTU সমস্যা হতে পারে, আর টাইমস্ট্যাম্পযুক্ত ইভেন্ট ছাড়া এগুলোর মধ্যে অনুমান করাই মানুষকে সুস্থ ইঞ্জিন পুনর্নির্মাণে ঠেলে দেয়। ক্লায়েন্ট আউটপুটের বাইট অফসেটকে তথ্য হিসেবে গণ্য করুন, কারণ প্রতিবার একই আকারে থেমে যাওয়া স্থানান্তর আর কখনো শুরু না হওয়া স্থানান্তর সম্পূর্ণ আলাদা জিনিস। দুই ফলাফলই লিখে রাখুন এবং বারবার চেষ্টার মধ্যে তুলনা করুন।

যে কম্পোনেন্ট স্থানান্তর করে সেটি কনফিগার করুন

নেটিভ Linux ইঞ্জিনের ক্ষেত্রে প্রক্সি থাকে সার্ভিস এনভায়রনমেন্টে, আপনার শেলে নয়। /etc/systemd/system/docker.service.d/-এর অধীনে HTTP_PROXY, HTTPS_PROXY ও NO_PROXY এন্ট্রিসহ একটি drop-in ফাইল, এরপর systemctl daemon-reload এবং রিস্টার্ট, এটাই নথিভুক্ত ব্যবস্থা। Docker Desktop নিজের সেটিংসের মাধ্যমে একই মান দেয়, আর শেল প্রোফাইল সম্পাদনা করলে এর কোনোটিই স্পর্শ হয় না।

রেজিস্ট্রিতে সরাসরি VPN দিয়ে পৌঁছাতে হলে ডেমনের প্রয়োজন resolver, একটি রুট এবং সচেতনভাবে করা প্রক্সি বর্জন, কেবল বর্জন নয়। NO_PROXY মিলকরণ প্রতিটি কম্পোনেন্টের জন্য স্ট্রিং তুলনা, আর অন্তর্নিহিত রুট ছাড়া ছাড় প্রদান এমন ব্যর্থতা তৈরি করে যা প্রক্সি সমস্যার মতো দেখায়।

এন্টারপ্রাইজ TLS পরিদর্শন অনুমোদিত পথে থাকলে এর যাচাইকৃত রুট সার্টিফিকেট ইঞ্জিন বা Desktop ওয়ার্কফ্লো দিয়ে ইনস্টল করুন। রেজিস্ট্রিকে insecure-registries-এ যোগ করা ভিন্ন পরিবর্তন যা বৈধতা যাচাই বন্ধ করে, এবং এটি ট্রাস্ট স্টোর কনফিগারেশন নয়।

একটি নিয়ন্ত্রিত পুল পুনরাবৃত্তি করুন এবং কী বদলেছে দেখুন

একটি সীমানা বদলান, সেটির মালিক কম্পোনেন্টটি রিস্টার্ট করুন, এবং একই কনটেক্সট থেকে একই পুল পুনরাবৃত্তি করুন। ত্রুটির অনুপস্থিতি নয়, ফলস্বরূপ ইমেজ রেফারেন্স ও digest যাচাই করুন, কারণ ক্যাশ করা স্তর দ্বিতীয় প্রচেষ্টাকে প্রথমটির চেয়ে অনেক কম পথ পরীক্ষা করাতে পারে। যে স্থানান্তরগুলো সত্যিই ঘটেছে সেগুলো টিকিটে রাখুন, কারণ পুনঃপ্রচেষ্টা আসলে কী পরীক্ষা করেছে তার এটিই একমাত্র রেকর্ড।

বিল্ড ধাপ ও চলমান কন্টেইনারের নিজস্ব নেটওয়ার্ক কনটেক্সট আছে, তাই পুলটি নিজেই কাজ শুরু করার পর সেগুলোকে আলাদা প্রশ্ন হিসেবে দেখুন।