network_mode: service:vpn এবং হারানো db হোস্টনেম

আপনি অ্যাপে network_mode: service:vpn যোগ করেন, স্ট্যাক রিস্টার্ট করেন, এবং অ্যাপটি মরে যায় কারণ db আর রিজলভ হয় না। compose ফাইলে কিছুই নাম বদলানো হয়নি, তাই স্পষ্ট সন্দেহভাজন হলো DNS এবং ডেটাবেস। আসল পরিবর্তনটি আরও ছোট ও অদ্ভুত: অ্যাপটি যে Compose নেটওয়ার্কে সেই নামটি আছে, তার সদস্য হওয়া বন্ধ করেছে। ডেটাবেস কোন নেমস্পেস থেকে উত্তর দেবে তা আপনি ঠিক না করা পর্যন্ত প্রতিটি হোস্টনেম সংশোধনই অনুমান।

কেন db হোস্টনেম রিজলভ হওয়া বন্ধ করল

network_mode ব্যবহার করা একটি সার্ভিসের Compose নেটওয়ার্কে নিজের কোনো ঠিকানা থাকে না; এটি নামযুক্ত সার্ভিসের নেমস্পেস ধার করে। সেই নেমস্পেস নিজের ইন্টারফেস, রুট, পোর্ট স্পেস এবং রিজলভার নিয়ে আসে, এবং এটি backend নেটওয়ার্কে অ্যাপের সংযুক্তি প্রতিস্থাপন করে। db নামটি কখনোই বিমূর্ত ছিল না: এটি সেই নেটওয়ার্কেই বাস করত এবং তার অন্তর্নির্মিত DNS দিয়ে রিজলভ হতো। সংযুক্তিটি সরিয়ে দিলে নামটির রিজলভ হওয়ার কোনো জায়গা থাকে না।

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

ফাইল সম্পাদনার আগে তিনটি প্রশ্ন

এগুলোর উত্তর ক্রমে দিন, কারণ প্রতিটি টপোলজি সংকীর্ণ করে। ডেটাবেস কীসে উত্তর দেবে: অন্য কনটেইনারগুলো যে হোস্টনেম ব্যবহার করে, নাকি কেবল loopback-এ অ্যাপ? অ্যাপকে কি হোস্টে একটি পোর্ট প্রকাশ করতে হবে, এবং কোন সার্ভিস সেটির মালিক হবে? ডেটাবেসটি কি হোস্ট বা অন্য মেশিন থেকে পৌঁছানো যাবে, নাকি কেবল টানেলের ভেতর থেকে?

যদি ডেটাবেসের নিজের নাম দরকার হয় এবং অ্যাপ কিছু প্রকাশ না করে, তবে তাদের আলাদা সংযুক্তিতে রাখুন। যদি অ্যাপকে পোর্ট প্রকাশ করতে হয় এবং সবকিছু টানেল দিয়ে যায়, তবে ডেটাবেসকে VPN নেমস্পেসে রাখুন এবং loopback ব্যবহার করুন। দুটো মিশিয়ে দিলে এমন স্ট্যাক তৈরি হয় যা পরিষ্কারভাবে শুরু হয় এবং সংযোগের সময় ব্যর্থ হয়।

ডেটাবেসকে যেখানে আছে সেখানেই রাখুন

ছোট পরিবর্তনটি নেমস্পেসের মালিককে সেই নেটওয়ার্কে যুক্ত করে যেখানে ইতিমধ্যে ডেটাবেস আছে। অ্যাপটি সেই সংযুক্তি উত্তরাধিকার সূত্রে পায় কারণ এটি vpn স্ট্যাক ভাগ করে, এবং db আগের মতোই রিজলভ হয়।

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

অ্যাপেও networks যোগ করবেন না। Compose একই সার্ভিসে network_mode এর পাশে সেই বৈশিষ্ট্যটি প্রত্যাখ্যান করে, এবং ত্রুটিটি জোড়ার দিকে নয়, ফাইলের দিকে নির্দেশ করে। যদি VPN ক্লায়েন্ট তার নেমস্পেসের ভেতরে backend গন্তব্য ফিল্টার করে, তবে তার সমর্থিত লোকাল-নেটওয়ার্ক নীতিও সমন্বয় করুন; ভাগ করা সংযুক্তি একটি পথ দেয় কিন্তু সেই ফিল্টারকে অগ্রাহ্য করে না।

ডেটাবেসকে নেমস্পেসে সরান

বড় পরিবর্তনটি ডেটাবেসকে একই নেমস্পেসে রাখে এবং অ্যাপকে আসল পোর্টসহ 127.0.0.1 এর দিকে নির্দেশ করে। দুটি প্রসেস কেবল ভিন্ন কনটেইনারে শুরু হয়েছে বলে একই ঠিকানা ও পোর্ট দুটোই বাইন্ড করতে পারে না, তাই যে ডেটাবেস wildcard ঠিকানাতেও শোনে সেটি যা কিছু তা করে তার সঙ্গে সংঘর্ষে পড়বে। সরানোর আগে লিসেনারটি যাচাই করুন।

প্রকাশিত পোর্টগুলো নেমস্পেসের মালিক সার্ভিসের। অ্যাপে ports যোগ করা network_mode এর পাশে প্রত্যাখ্যাত হয়, এবং আলাদা অ্যাপ ঠিকানা বানানো এমন একটি ইন্টারফেস বর্ণনা করে যা নেই।

প্রস্তুতি, ব্লকিং এবং রিজলভার

depends_on কনটেইনার শুরু হওয়ার ক্রম ঠিক করে; এটি টানেল চালু থাকার প্রমাণ নয়, এবং টানেল পড়ে গেলে এটি ট্রাফিক বন্ধ করে না। পৌঁছানোযোগ্যতা, টানেল প্রস্তুতি এবং ব্যর্থতা ব্লকিংকে তিনটি আলাদা প্রয়োজনীয়তা হিসেবে দেখুন। যে স্ট্যাক কেবল প্রথমটি পূরণ করে সেটি ভালো দিনে হাতে-পরীক্ষায় পাস করে এবং খারাপ দিনে ফাঁস করে। তিনটি উত্তর compose ফাইলের পাশে লিখে রাখুন, যেখানে পরের মানুষটি তাকাবে।

নেমস্পেস ভাগ করার মানে হলো অ্যাপটি VPN কনটেইনার রিজলভার উত্তরাধিকার সূত্রে পায়, যা সাহায্য করে যখন টানেল DNS সার্ভার ঠেলে দেয় এবং বিভ্রান্ত করে যখন দেয় না। হোস্টের রিজলভার প্রযোজ্য ধরে নেওয়ার বদলে নেমস্পেসে আসলে কী আছে তা যাচাই করুন। Compose সার্ভিস রেফারেন্স এক জায়গায় network_mode, ports এবং নির্ভরতার আচরণ নথিভুক্ত করে, যার মধ্যে কেন network_mode সার্ভিসের নিজের ঠিকানা নেই তা-ও রয়েছে।