সরাসরি প্রধান সামগ্রীতে চলে যান

Multiple Docker Containers network-based communication setup Bangla

🧭 Docker Multi-Container Networking Guideline (Reusable)

🧩 ১. মৌলিক ধারণা

প্রত্যেকটি Docker Compose প্রজেক্ট run করলে সেটি নিজে থেকেই একটা আলাদা network তৈরি করে — যেমন myapp_default, postgres_default ইত্যাদি।

⚠️ আলাদা compose প্রজেক্টের container গুলো একে অপরকে ping করতে পারে না, যতক্ষণ না তাদেরকে একই network-এ manually connect করানো হয়।


⚙️ ২. যদি দুইটা আলাদা Compose Project থাকে

ধরা যাক তোমার আছে:

  • একটি postgres container → postgres_default network-এ
  • একটি Spring Boot app → practice-spring-boot-jdk21_default network-এ

এখন app container থেকে postgres container এ connect করতে হলে তোমাকে app container কে postgres_default network-এ attach করতে হবে।

🔧 ধাপসমূহ:

➤ ১️⃣ Available network list দেখো:
docker network ls
➤ ২️⃣ Postgres container এর network নাম খুঁজে বের করো:
docker inspect postgres | grep "NetworkMode"

ধরো, output এসেছে → postgres_default

➤ ৩️⃣ App container কে ওই network-এ connect করো:
docker network connect postgres_default blogger-app
➤ ৪️⃣ যাচাই করো যে connect হয়েছে কিনা:
docker inspect blogger-app --format '{{json .NetworkSettings.Networks}}' | jq

এখানে "postgres_default" নাম দেখা গেলে ঠিক আছে ✅

➤ ৫️⃣ Connection test করো:
docker exec -it blogger-app bash
ping postgres

যদি reply আসে, তাহলে DB connection সফল।


🧱 ৩. Future-friendly Compose File Setup

তুমি চাওলে সরাসরি docker-compose.yml ফাইলেই external network define করে রাখতে পারো যাতে manual attach করতে না হয়।

🧾 Example:

services:
  app:
    build: .
    container_name: blogger-app
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/mydb
      SPRING_DATASOURCE_USERNAME: postgres
      SPRING_DATASOURCE_PASSWORD: postgres
    networks:
      - postgres-network  # external network name

networks:
  postgres-network:
    external: true
    name: postgres_default

⚙️ external: true মানে — এই compose নতুন network তৈরি করবে না, বরং আগে থেকে থাকা postgres_default network ব্যবহার করবে।


💡 ৪. সাধারণ টিপস

| বিষয় | নির্দেশনা | | ------------------- | ---------------------------------------------------------- | | Network check | docker network inspect <network-name> | | Container attach | docker network connect <network> <container> | | Container detach | docker network disconnect <network> <container> | | Ping test | docker exec -it <container> ping <target-container-name> | | Compose auto-attach | Compose ফাইলেই networks: সেকশন যোগ করো | | Same network rule | Container name দিয়েই DB host হিসেবে connect করা যায় |


✅ ৫. Summary (Quick Copy-Paste Cheatsheet)

# Find postgres container network
docker inspect postgres | grep NetworkMode

# Connect app container to same network
docker network connect postgres_default blogger-app

# Verify networks attached
docker inspect blogger-app --format '{{json .NetworkSettings.Networks}}' | jq

# Test connectivity
docker exec -it blogger-app bash
ping postgres

মন্তব্যসমূহ

এই ব্লগটি থেকে জনপ্রিয় পোস্টগুলি

সিজ্জিন (Sijjin) vs ইল্লিয়িন (Illiyin) পার্থক্য Difference

Sijjin (سِجِّين) এবং Illiyin (عِلِّيِّين) —এ দুটি শব্দ কুরআনে এসেছে এবং দুটোই মানুষের আমলনামা সংরক্ষণ সম্পর্কিত স্থানকে নির্দেশ করে। ১. সিজ্জিন (Sijjin) সিজ্জিন হলো পাপীদের (কাফের, মুনাফিক ও দুরাচারীদের) আমলনামা সংরক্ষণের স্থান। এটি সাত তলদেশের নীচে এক কারাগার বা অন্ধকার জগতে অবস্থিত বলে উল্লেখ রয়েছে। সূরা আল-মুতাফফিফীন (৮৩:৭-৯) তে বলা হয়েছে: "كَلَّا إِنَّ كِتَابَ الْفُجَّارِ لَفِي سِجِّينٍ ۝ وَمَا أَدْرَاكَ مَا سِجِّينٌ ۝ كِتَابٌ مَرْقُومٌ" অর্থ: "না, পাপীদের আমলনামা সিজ্জিনে সংরক্ষিত। তুমি কি জানো, সিজ্জিন কী? এটি এক লিখিত দলিল।" সিজ্জিনকে একটি কারাগার, সংকীর্ণ স্থান, বা নিচের স্তরে অবস্থিত এক অন্ধকার দুনিয়া হিসেবে ব্যাখ্যা করা হয়। ২. ইল্লিয়িন (Illiyin) ইল্লিয়িন হলো সৎকর্মশীলদের (মুমিন ও নেককারদের) আমলনামা সংরক্ষণের স্থান । এটি সপ্তম আসমানের ওপরে সংরক্ষিত এক সম্মানিত স্থান। সূরা আল-মুতাফফিফীন (৮৩:১৮-২১) তে বলা হয়েছে: "كَلَّا إِنَّ كِتَابَ الْأَبْرَارِ لَفِي عِلِّيِّينَ ۝ وَمَا أَدْرَاكَ مَا عِلِّيُّونَ ۝ كِتَابٌ مَرْقُومٌ ۝ يَش...

জাভা ফিডব্যাক এবং স্ট্রাকচার্ড কনকারেন্সি: বিবর্তনের গল্প

Introduction এই ভিডিওর নির্দিষ্ট অংশে জাভা ল্যাঙ্গুয়েজ আর্কিটেক্ট ব্রায়ান গোয়েটজ (Brian Goetz) আলোচনা করেছেন কীভাবে জাভার নতুন ফিচারগুলো তৈরি হয় এবং এতে সাধারণ ডেভেলপারদের মতামতের গুরুত্ব কতটুকু। বিশেষ করে Structured Concurrency -এর মতো জটিল ফিচারগুলো কেন বারবার 'Preview' অবস্থায় থাকে এবং কীভাবে কমিউনিটির ফিডব্যাক সেই ফিচারগুলোকে আরও নিখুঁত করতে সাহায্য করে, তা এখানে সহজভাবে বোঝানো হয়েছে। ১. ভালো ফিডব্যাক আসলে কী? ভিডিও রেফারেন্স: [ 34:53 ] ব্রায়ান গোয়েটজ বলছেন যে, জাভা টিম যখন কোনো নতুন ফিচারের খসড়া (Draft) বা প্রস্তাব (JEP) প্রকাশ করে, তখন তারা এমন কিছু জানতে চায় যা তারা নিজেরা আগে ভাবেনি। বিস্তারিত: একজন ডেভেলপার হিসেবে আমরা যখন কোনো নতুন ফিচার দেখি, আমাদের প্রথম প্রতিক্রিয়া হয় সেটার Syntax বা লেখার ধরন নিয়ে। কিন্তু ব্রায়ানের মতে, "এই লেখাটা কেন এমন হলো?" বা "এটা কোটলিন বা স্কালা-র মতো কেন নয়?"—এই ধরনের ফিডব্যাক খুব একটা কাজে আসে না। আসল দামী ফিডব্যাক হলো সেইটা, যা নতুন কোনো বাস্তব সমস্যা (Edge Case) তুলে ধরে। আমার চিন্তা: আপনি যদি কেবল দ...

Microservice Error Handling

একদম ঠিক বলেছেন ভাই 💯 — তুমি এখন microservice design-এর আসল beauty ধরেছো 👏 ✅ হ্যাঁ — যদি প্রতিটা service independent হয় (loosely coupled architecture), তাহলে একটা service fail করলে আরেকটা fail করবে না (at least directly না)। তবে, এখানে একটু গভীর বিষয় আছে — “independent” মানে কি logical independence, নাকি runtime independence?” এইটা বোঝা খুব জরুরি। চলো ধাপে ধাপে পরিষ্কারভাবে দেখি 👇 ⚙️ ১️⃣ Microservice Independence মানে কী? একটা system এ একাধিক service থাকে, যেমন: 🧾 Order Service 💳 Payment Service 🚚 Delivery Service ✉️ Notification Service 🔹 Logical Independence: প্রতিটা service এর নিজের data, business logic, আর deploy pipeline আলাদা। 📌 উদাহরণ: Payment service down থাকলেও Order service order create করতে পারবে (pending state এ রাখবে)। Delivery service নিজের data manage করবে, Payment এর DB access করবে না। 👉 মানে “tight coupling” নেই — service গুলা নিজের domain handle করে। 🔹 Runtime Independence: প্রতিটা service run হয় আলাদা instance/container এ। তাদের মধ্যে ...