Docker Compose stop বনাম down: কোনটি কী মুছে দেয়

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

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

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

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

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

docker compose stop
docker compose ps -a

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

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

docker compose down: container ও network সরানো হয়

down container-গুলো বন্ধ করে, তারপর সেগুলো সরিয়ে দেয়। একই সঙ্গে project-এর জন্য Compose তৈরি করা default network-ও সরানো হয়। Docker documentation-এ এটিকে container বন্ধ করা এবং up তৈরি করা container, network, volume ও image সরানো হিসেবে বর্ণনা করা হয়েছে। তবে volume ও image সরানোর কাজ কেবল -v এবং --rmi দিয়ে অনুরোধ করলে হয়।

docker compose down
docker compose ps -a
docker network ls

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

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

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

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

পরীক্ষা করার জন্য একটি stack তৈরি করুন। খালি voltest directory-তে 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-এর পার্থক্য এবং প্রতিটি volume host-এ আসলে কোথায় থাকে তা ব্যাখ্যা করা হয়েছে।

down -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 initialize করে। 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।

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

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

কখন --force-recreate ব্যবহার করা প্রয়োজন

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

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

docker compose up -d --force-recreate

এটি প্রতিটি container বন্ধ করে সরিয়ে দেয় এবং একই definition থেকে নতুন container তৈরি করে। Mount করা config file সম্পাদনা করার পর এবং কোনো container এমন অবস্থায় চলে গেলে যার কারণ ব্যাখ্যা করতে পারছেন না, তখন এটি ব্যবহার করুন। Volume-এ কোনো পরিবর্তন হয় না, তাই 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 প্রায় এক সেকেন্ডে file থেকে একই রকম container তৈরি করতে পারে। Volume প্রতিস্থাপনযোগ্য নয়। কারণ এতে state-এর একমাত্র copy থাকে, যা repository-এর কোনো file দিয়ে পুনরায় তৈরি করা যায় না।

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

একই যুক্তি secret-এর ক্ষেত্রেও প্রযোজ্য। POSTGRES_PASSWORD-এর মাধ্যমে সেট করা password database প্রথমবার initialize হওয়ার সময়ই শুধু পড়ে। তাই 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 এমন একটি directory-তে চলছে যেখানে compose.yaml এবং docker-compose.yml কোনোটিই নেই। সম্পূর্ণ path দিয়ে -f দিন।

down-এ network voltest_default has active endpoints দেখালে এর অর্থ হলো এই project-এর বাইরের কোনো container project network-এ যুক্ত আছে। সাধারণত এটি docker run --network দিয়ে হাতে চালু করা container। ওই container সরিয়ে ফেলুন, তারপর আবার down চালান।

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

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

FAQ

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

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

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

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

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

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

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

Compose resolved service definition-এর hash তুলনা করে সিদ্ধান্ত নেয় container পুনরায় তৈরি করতে হবে কি না। এই hash-এ mounted file-এর contents অন্তর্ভুক্ত থাকে না। path পরিবর্তিত হয়নি, তাই Compose container-টি চালু রাখে এবং startup-এর সময় পড়া value ব্যবহার করে। 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 ব্যবহার করুন।