Docker Compose stop বনাম down: কোনটি ব্যবহার করবেন?

সংক্ষিপ্ত উত্তর

docker compose stop কনটেইনারগুলো বন্ধ করে ডিস্কে রেখে দেয়। docker compose down কনটেইনারগুলো বন্ধ করার পর সেগুলো এবং প্রকল্পের জন্য Compose তৈরি করা নেটওয়ার্ক মুছে দেয়। কোনো কমান্ডই named volume-এ প্রভাব ফেলে না। আপনি -v যোগ করলেই কেবল আপনার database মুছে যাবে, যেমন docker compose down -v-এ, যা Compose ফাইলের volumes অংশে ঘোষিত named volume মুছে দেয়।

একটি অনুচ্ছেদে এটাই সম্পূর্ণ পার্থক্য। এই গাইডের বাকি অংশে একটি Postgres volume ব্যবহার করে তা দেখানো হয়েছে: down চালানোর পর volume কীভাবে টিকে থাকে এবং down -v চালালে কীভাবে মুছে যায়। এছাড়া --force-recreate কখন প্রয়োজন হয়, সেই দুটি ক্ষেত্রও ব্যাখ্যা করা হয়েছে।

docker compose stop: কনটেইনার চালু থাকে

stop প্রতিটি কনটেইনারের প্রধান প্রক্রিয়ায় SIGTERM পাঠায়, অপেক্ষা করে, তারপর প্রক্রিয়াটি চালু থাকলে SIGKILL পাঠায়। ডিফল্ট অপেক্ষার সময় 10 সেকেন্ড এবং -t এটি পরিবর্তন করে। কিছুই মুছে ফেলা হয় না। কনটেইনারটি তার ID, writable layer, IP reservation এবং লগ ধরে রাখে।

docker compose stop
docker compose ps -a

docker compose ps একা ব্যবহার করলে শুধু চলমান কনটেইনার দেখায়। তাই stop-এর পরে এটি একটি খালি টেবিল দেখায় এবং মনে হয় কনটেইনারগুলো মুছে গেছে। ps -a বন্ধ থাকা কনটেইনারও অন্তর্ভুক্ত করে। সেখানেই প্রতিটি service-এর পাশে Exited (0) দেখতে পাবেন। docker compose start দিয়ে সেগুলো আবার চালু করুন। এটি ঠিক একই কনটেইনার পুনরায় ব্যবহার করে।

কনটেইনারগুলো এখনও বিদ্যমান থাকায় volume-এর বাইরে কনটেইনারের ভেতরে লেখা সবকিছু সেখানেই থাকে। এর মধ্যে docker compose exec দিয়ে হাতে ইনস্টল করা package এবং কনটেইনারের ভেতরে সম্পাদনা করা config file-ও রয়েছে। Debugging-এর সময় stop পছন্দ করার এটি একটি বাস্তব কারণ: একই অবস্থায় পুনরায় চালু করতে পারবেন।

docker compose down: কনটেইনার এবং নেটওয়ার্ক সরানো হয়

down কনটেইনারগুলো বন্ধ করে। এরপর এটি সেগুলো সরিয়ে ফেলে এবং প্রকল্পের জন্য Compose তৈরি করা ডিফল্ট নেটওয়ার্কও সরিয়ে দেয়। Docker-এর ডকুমেন্টেশনে বলা হয়েছে, এটি up তৈরি করা কনটেইনার, নেটওয়ার্ক, ভলিউম এবং ইমেজ বন্ধ ও সরিয়ে দেয়। তবে ভলিউম এবং ইমেজের অংশগুলো কেবল তখনই কার্যকর হয়, যখন আপনি -v এবং --rmi ব্যবহার করে সেগুলোর জন্য অনুরোধ করেন।

docker compose down
docker compose ps -a
docker network ls

down চালানোর পর, ps -a প্রকল্পের জন্য কিছুই প্রিন্ট করে না এবং <project>_default নেটওয়ার্কটি আর থাকে না। আপনি name: সেট না করলে বা -p পাস না করলে প্রকল্পের নাম ডিরেক্টরির নাম থেকে নেওয়া হয়। কনটেইনারের writable layer-এর মধ্যে করা প্রতিটি পরিবর্তন এখন আর পুনরুদ্ধার করা যাবে না। তাই down-কে এমন একটি কমান্ড হিসেবে বিবেচনা করুন, যা কনটেইনারটি ফেলে দেয় এবং ভলিউমে রাখা ডেটা সংরক্ষণ করে।

ভুল ডিরেক্টরিতে এটি চালালে no configuration file provided: not found দেখায়। আপনি কোন প্রকল্প বোঝাচ্ছেন তা Compose জানে না, তাই এটি কমান্ডটি প্রত্যাখ্যান করে। প্রকল্প ফোল্ডারে না থাকলে docker compose -f /srv/myapp/compose.yaml down ব্যবহার করুন।

docker compose down কি আমার volumes মুছে ফেলে?

না। শীর্ষ-স্তরের volumes key-এর অধীনে ঘোষিত named volume, down-এর পরেও এবং যে container-এর সঙ্গে এটি সংযুক্ত ছিল, সেই container মুছে যাওয়ার পরেও টিকে থাকে। এই command নিয়ে এটিই সবচেয়ে প্রচলিত আশঙ্কা। Compose v2-এর সব সংস্করণে উত্তরটি একই।

পরীক্ষা করার জন্য একটি stack তৈরি করুন। একটি খালি directory-তে voltest নামে compose.yaml ফাইলে এটি রাখুন।

services:
  db:
    image: postgres:16.4
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

এটি চালু করুন এবং পরে শনাক্ত করতে পারবেন এমন একটি row লিখুন।

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "create table marker (note text);"
docker compose exec -T db psql -U postgres -c "insert into marker values ('survived');"

এখন container মুছে ফেলুন এবং volume পরীক্ষা করুন।

docker compose down
docker volume ls

আউটপুটে এখনও voltest_pgdata তালিকাভুক্ত থাকে। container মুছে গেছে, কিন্তু data মুছে যায়নি। stack আবার চালু করুন এবং row-টি পড়ুন।

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "select * from marker;"

আপনি survived-যুক্ত একটি row পাবেন। নতুন container-টি ভিন্ন ID-সহ একটি ভিন্ন container, তবে এটি একই volume-এর সঙ্গে সংযুক্ত। আরও বিস্তারিত জানতে Compose-এর মৌলিক বিষয়ের নির্দেশিকা দেখুন। সেখানে named volume এবং bind mount-এর তুলনা, এবং host-এ প্রতিটি volume আসলে কোথায় থাকে, তা ব্যাখ্যা করা হয়েছে।

-v ঠিক কী ধ্বংস করে

-v (দীর্ঘ রূপ --volumes) Compose ফাইলের volumes বিভাগে ঘোষিত নামযুক্ত volume এবং container-গুলোর সঙ্গে সংযুক্ত anonymous volume সরিয়ে দেয়। একই stack-এর ক্ষেত্রে এটি চালান।

docker compose down -v
docker volume ls

voltest_pgdata আর তালিকাভুক্ত নেই। আবার stack চালু করলে Postgres entrypoint একটি খালি data directory পায়, তাই এটি একটি নতুন cluster initialises করে। Container log-এ এটি স্পষ্টভাবে লেখা থাকে।

The files belonging to this database system will be owned by user "postgres".
PostgreSQL init process complete; ready for start up.

কয়েক মাস ধরে চলা stack-এ এই block দেখা গেলে volume সরানো হয়েছে। আপনার marker table আর নেই, এবং ফিরে পাওয়ার একমাত্র উপায় হলো backup।

-v কখনও কিছু storage সরায় না। Bind mount হলো একটি host path, তাই Docker শুধু সেটি unmount করে এবং আপনার file যেখানে ছিল সেখানেই থাকে। external: true হিসেবে চিহ্নিত volume ঘোষণা করে যে এটি এই project-এর বাইরের কোনো কিছুর অন্তর্ভুক্ত, তাই Compose কখনও এটি সরায় না। down -v চালানোর আগে Compose file থেকে মুছে ফেলা named volume আর ঘোষিত থাকে না। তাই Compose সেটি সরানোর কথা জানে না এবং docker volume prune পর্যন্ত orphan হিসেবে পড়ে থাকে।

Refactor করার সময় শেষের ঘটনাটি অনেককে বিভ্রান্ত করে। File থেকে কোনো service এবং তার volume সরিয়ে down -v চালালে volume টিকে থাকে, কারণ file-এ আর সেটির উল্লেখ নেই। File সম্পাদনা করার আগে down -v চালান, পরে নয়।

যখন সত্যিই --force-recreate প্রয়োজন

docker compose up -d প্রতিবার সবকিছু নতুন করে তৈরি করে না। Compose প্রতিটি service-এর resolved configuration-এর একটি hash container-এ label হিসেবে সংরক্ষণ করে। Hash এবং image ID দুটিই মিলে গেলে container-টি অপরিবর্তিত থাকে, এবং আপনি Container voltest-db-1 Running-এর পরিবর্তে Recreated পান। প্রায় সবসময় এটাই প্রত্যাশিত আচরণ, কারণ এতে up -d বারবার নিরাপদে চালানো যায়।

এ কারণেই কিছু পরিবর্তনের পরও কোনো ফল দেখা যায় না। Compose definition যে ফাইলগুলোর দিকে নির্দেশ করে, সেই ফাইলগুলোর বিষয়বস্তু নয়; resolved service definition-এর hash তৈরি করে। Container-এ mount করা কোনো config file startup-এর সময় একবার পড়া হলে, সেটি সম্পাদনা করলেও recreate হবে না, কারণ mount path পরিবর্তিত হয়নি। Service-টি চালু হওয়ার সময় পড়া মানগুলো নিয়েই চলতে থাকে।

docker compose up -d --force-recreate

এটি প্রতিটি container বন্ধ করে সরিয়ে ফেলে এবং একই definition থেকে নতুন container তৈরি করে। Mounted config file সম্পাদনা করার পর এটি ব্যবহার করুন। কোনো container এমন অবস্থায় চলে গেলে, যার কারণ আপনি ব্যাখ্যা করতে পারছেন না, তখনও এটি ব্যবহার করুন। Volumes অপরিবর্তিত থাকে, তাই force recreate করলেও database টিকে থাকে। একই tag-এ আরও নতুন image ব্যবহার করতে হলে pull-ও করতে হবে।

docker compose pull
docker compose up -d

pull নতুন image ID সংগ্রহ করে, এরপর up -d চলমান container-এর image ID আলাদা দেখতে পায় এবং নিজে থেকেই container recreate করে। pull ছাড়া --force-recreate যোগ করলে একই পুরোনো image থেকে নতুন container তৈরি হবে। তাই “আমি force recreate করেছি, তবুও এটি পুরোনো version” — এই অভিযোগটি এত সাধারণ।

docker compose restart এর কোনোটিই করে না। এটি বিদ্যমান container-গুলো restart করে এবং Compose file আবার পড়ে না। তাই পরিবর্তিত environment variable বা port mapping কার্যকর হবে না। File সম্পাদনা করলে up -d ব্যবহার করুন।

যে মানসিক মডেলটি মনে রাখতে হবে

Container প্রতিস্থাপনযোগ্য। একটি container হলো একটি process এবং তার ওপরের পাতলা writable layer। Compose ফাইল থেকে প্রায় এক সেকেন্ডে একই ধরনের container তৈরি করতে পারে। Volume প্রতিস্থাপনযোগ্য নয়, কারণ এতে state-এর একমাত্র কপি থাকে, যা আপনার repository-র কোনো file পুনরায় তৈরি করতে পারে না।

প্রতিটি Compose verb এই বিভাজনের সঙ্গে সামঞ্জস্যপূর্ণ। stop এবং start container-টি রেখে দেয়। down এবং up container-টি প্রতিস্থাপন করে এবং volume রেখে দেয়। down -v হলো একমাত্র নিয়মিত command যা state সরিয়ে দেয়। তাই এতে একটি explicit flag প্রয়োজন। কোনো বাস্তব পরিবেশে এটি type করার আগে নিশ্চিত করুন যে আপনার একটি backup আছে এবং আপনি সেটি অন্তত একবার restore করেছেন।

একই যুক্তি secret-এর ক্ষেত্রেও প্রযোজ্য। POSTGRES_PASSWORD-এর মাধ্যমে সেট করা password database প্রথমবার initialise করার সময়ই পড়ে। তাই environment file-এ এটি পরিবর্তন করে up -d চালালে আপনি password authentication failed for user "postgres" পাবেন। Container নতুন, কিন্তু volume পুরনো। পুরনো volume-এ এখনও পুরনো password আছে। একই variable দুবার set করা হলে কোন layer প্রাধান্য পায়, তা Compose কীভাবে env file এবং secret resolve করে ব্যাখ্যা করে।

ব্যর্থতার ধরন এবং যে বার্তাগুলো দেখবেন

no configuration file provided: not found নির্দেশ করে যে Compose এমন একটি ডিরেক্টরিতে চলছে, যেখানে compose.yaml বা docker-compose.yml কোনোটিই নেই। সম্পূর্ণ path-সহ -f পাস করুন।

down-এ network voltest_default has active endpoints নির্দেশ করে যে এই project-এর বাইরের একটি container project network-এর সঙ্গে সংযুক্ত আছে। সাধারণত এটি docker run --network দিয়ে হাতে শুরু করা হয়। সেই container সরিয়ে দিন। তারপর আবার down চালান।

কোনো service-এর নাম পরিবর্তন বা সেটি মুছে ফেলার পরে Found orphan containers ([voltest-old-1]) for this project দেখা যায়। পুরোনো container-এ এখনও project label রয়েছে। docker compose down --remove-orphans সেগুলো সরিয়ে দেয়। সচল stack-এ এটি চালানো নিরাপদ।

হাতে চালানো docker volume rm-এ Error response from daemon: remove voltest_pgdata: volume is in use নির্দেশ করে যে কোনো container এখনও volume-টি উল্লেখ করছে। বন্ধ থাকা container-ও এর অন্তর্ভুক্ত। প্রথমে docker compose down চালান। তারপর volume-টি সরান। অথবা সরাসরি down -v ব্যবহার করুন। বড় project-এ একটি multi service Compose stack দেখায়, একটি project-এ কতগুলো volume জমা হতে পারে।

FAQ

docker compose down কি আমার database মুছে দেয়?

না, যদি database named volume বা bind mount-এ থাকে। down containers এবং project network সরিয়ে দেয়, কিন্তু volume disk-এ থেকেই যায় এবং তার data অক্ষত থাকে। পরের docker compose up -d একই volume-এ একটি নতুন container সংযুক্ত করে, তাই data পাওয়া যায়। শুধু docker compose down -v named volumes সরায়, এবং শুধু Compose file-এর volumes section-এ ঘোষিত volumes সরায়।

যে container-টি পরে আবার চালু করতে চাই, তার ক্ষেত্রে stop এবং down-এর মধ্যে পার্থক্য কী?

stop container রেখে দেয়। তাই docker compose start একই writable layer-সহ একই container-এ ফিরিয়ে আনে। আপনি container-এর ভিতরে হাতে ইনস্টল বা সম্পাদনা করা যেকোনো কিছু তখনও থাকে। down container মুছে দেয়। তাই পরের up -d image থেকে একটি নতুন container তৈরি করে এবং হাতে করা পরিবর্তনগুলো হারিয়ে যায়। Debugging করার সময় stop ব্যবহার করুন।

একটি Compose project যা কিছু তৈরি করেছে, সব কীভাবে সরাব?

docker compose down -v --rmi all --remove-orphans containers, project network, file-এ ঘোষিত named volumes, services যে images ব্যবহার করেছে, এবং project name দিয়ে এখনও labelled থাকা যেকোনো container সরিয়ে দেয়। এটি bind mounts বা external: true চিহ্নিত volumes-এ কোনো পরিবর্তন করে না। চালানোর আগে কী হারাবেন তা docker volume ls দিয়ে পরীক্ষা করুন।

Mounted config file-এ করা পরিবর্তনটি আমার container কেন উপেক্ষা করছে?

একটি container পুনরায় তৈরি করা হবে কি না, তা Compose resolved service definition-এর hash তুলনা করে নির্ধারণ করে। এই hash mounted file-এর contents অন্তর্ভুক্ত করে না। Path পরিবর্তিত হয়নি, তাই Compose container-টি চালু রাখে এবং startup-এর সময় পড়া values ব্যবহার করে। File-টি আবার পড়বে এমন একটি নতুন container তৈরি করতে docker compose up -d --force-recreate চালান।

পরিবর্তন করার পর আমার নতুন POSTGRES_PASSWORD কেন কাজ করছে না?

Postgres image কেবল খালি data directory initialise করার সময় POSTGRES_PASSWORD পড়ে। আপনার volume-এ ইতিমধ্যে initialised cluster রয়েছে। তাই variable-টি উপেক্ষিত হয় এবং পুরনো password কার্যকর থাকে। আপনি password authentication failed for user "postgres" দেখতে পাবেন। চলমান database-এর ভিতরে ALTER USER দিয়ে password পরিবর্তন করুন, অথবা data হারানোর বিষয়টি মেনে নিয়ে docker compose down -v দিয়ে নতুন করে শুরু করুন।