বাস্তব সার্ভারের জন্য Docker Compose কমান্ড চিট শিট

আপনি বাস্তবে যে Compose কমান্ডগুলো বেশি ব্যবহার করবেন

Docker Compose-এ 40-এর বেশি subcommand রয়েছে। সার্ভারে দৈনন্দিন কাজে প্রায় এক ডজন কমান্ড ব্যবহার হয়। আপনি যে কাজটি করছেন তার ভিত্তিতে এই পৃষ্ঠায় সেগুলো সাজানো হয়েছে। প্রতিটি কমান্ডের জন্য একটি সরল কারণ দেওয়া হয়েছে। কোনো কমান্ডে লুকানো সমস্যা থাকলে বিস্তারিত ব্যাখ্যার নির্দেশনাও দেওয়া হয়েছে।

এখানে সবকিছু Compose V2 ব্যবহার করে: docker compose-এর মধ্যে একটি space থাকে, পুরোনো docker-compose script নয়। V2 হলো একটি Go plugin, যা Docker Engine-এর সঙ্গে install হয়। বর্তমান package-গুলোতে V1 আর নেই। তাই 2026 সালের July মাসে নতুন Ubuntu system-এ docker-compose: command not found দেখা স্বাভাবিক; এটি installation নষ্ট হওয়ার লক্ষণ নয়। docker compose version দিয়ে যাচাই করুন। কমান্ডটি কোনো output না দিলে docker-compose-plugin package install করুন।

নিচের প্রতিটি কমান্ড সেই directory থেকে চালাতে হবে যেখানে আপনার compose.yaml রয়েছে। কারণ Compose project name ওই directory থেকে নেয় এবং file-টি ওই directory-র relative path হিসেবে খুঁজে পায়। একই কমান্ড এক level উপরের directory থেকে চালালে Compose no configuration file provided: not found দিয়ে থেমে যায়। File format-টি নতুন হলে আগে VPS-এ প্রথম Compose file তৈরি করা পড়ুন। এরপর কমান্ডগুলোর জন্য এখানে ফিরে আসুন।

Lifecycle: আপনি যে চারটি command ব্যবহার করবেন এবং যেটি container সরিয়ে দেয়

docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose down

up -d network তৈরি করে, container তৈরি করে, সেগুলো চালু করে এবং ফিরে আসে। container তৈরি হওয়ার সঙ্গে সঙ্গেই এটি ফিরে আসে। তাই এর পরে curl probe চালানো deploy script প্রথমবার প্রায়ই ব্যর্থ হয়। up -d --wait healthcheck ঘোষণা করা প্রতিটি service healthy না হওয়া পর্যন্ত অপেক্ষা করে এবং কোনো service কখনো healthy না হলে non-zero exit করে। এই flag-এর কার্যকারিতা এর পেছনের check-এর মানের ওপর নির্ভর করে। তাই automation-এ এটি ব্যবহারের আগে Compose যে healthcheck-এর ওপর নির্ভর করতে পারে লিখুন।

stop container থামায়, কিন্তু সেগুলো রেখে দেয়। তাই start একই writable layer-সহ একই container আবার চালু করে। down container থামানোর পর সেগুলো এবং project network সরিয়ে দেয়। volume-এর বাইরে container-এর ভেতরে লেখা যেকোনো data container-এর সঙ্গে মুছে যায়। Compose সম্পর্কে এটিই সবচেয়ে ব্যয়বহুল ভুল বোঝাবুঝি। down এবং stop-এর সম্পূর্ণ পার্থক্য অংশে এই পার্থক্য কোথায় সমস্যা তৈরি করে তা ব্যাখ্যা করা হয়েছে।

restart reload নয়। এটি একই container-কে থামিয়ে আবার চালু করে এবং container-এর বর্তমান configuration-ই ব্যবহার করে। তাই পরিবর্তিত environment variable, নতুন image tag বা সম্পাদিত port mapping-এর কোনো প্রভাব পড়ে না। file পরিবর্তন প্রয়োগ করতে আবার up -d চালান। Compose প্রতিটি service-কে তার চলমান container-এর সঙ্গে তুলনা করে এবং শুধু configuration পরিবর্তিত হওয়া container-গুলো পুনরায় তৈরি করে।

পরিবর্তন প্রয়োগ করা: recreate, pull অথবা rebuild

docker compose up -d --force-recreate
docker compose pull && docker compose up -d
docker compose build --no-cache web
docker compose up -d --build web

কোনো পরিবর্তন না থাকলে up -d কিছুই করে না। এ কারণেই এটি বারবার চালানো নিরাপদ। --force-recreate এই তুলনা উপেক্ষা করে এবং configuration একই হলেও প্রতিটি container প্রতিস্থাপন করে। তাই container-এর ভেতরের অস্বাভাবিক state দ্রুত পরিষ্কার করার এটি সবচেয়ে সহজ উপায়।

একটি image update করতে দুটি command লাগে, কারণ এগুলো ভিন্ন কাজ করে। pull file-এ উল্লেখ করা প্রতিটি tag-এর বর্তমান image download করে। এরপর up -d বুঝতে পারে যে service-এর image ID চলমান container-এর image ID-এর সঙ্গে আর মেলে না, এবং container-টি পুনরায় তৈরি করে। pull ধাপ বাদ দিলে up -d গত মাসের latest-ই কোনো error ছাড়া চালিয়ে যায়। বিপরীত ঝুঁকি দেখা দেয় multi-service stack-এ। সেখানে একসঙ্গে প্রতিটি service-এর জন্য latest pull করলে দশ সেকেন্ড আগেও সচল থাকা একটি app নষ্ট হয়ে যেতে পারে। এই কারণেই self-hosted AFFiNE workspace তার চারটি image tag আলাদাভাবে pin করে।

যেসব service-এ image:-এর পরিবর্তে build: section নির্ধারিত থাকে, তাদের ক্ষেত্রে build প্রযোজ্য। up -d --build এক ধাপেই build এবং start করে। code পরিবর্তনের সময় এটিই স্বাভাবিক workflow। কোনো cached layer স্পষ্টভাবে পুরোনো হলে তবেই --no-cache ব্যবহার করুন, কারণ এটি প্রতিটি layer শুরু থেকে rebuild করে।

চলমান কী আছে তা দেখা

docker compose ps
docker compose ps -a
docker compose logs -f --tail=100
docker compose logs --since 15m --timestamps db
docker compose top
docker compose ls

ps শুধু চলমান container-এর তালিকা দেখায়। কোনো service শুরু হওয়ার সময় crash করলে -a যোগ না করা পর্যন্ত সেখানে সেটি দেখা যায় না। তাই ps-এ কোনো container অনুপস্থিত থাকলেও ps -a সেটিকে Exited (1) হিসেবে দেখালে সেটিই startup failure-এর স্বাভাবিক চিত্র। প্রথমে exit code পড়ুন। এরপর log পড়ুন।

logs -f একই সময়ে প্রতিটি service অনুসরণ করে এবং প্রতিটি লাইনের শুরুতে service-এর নাম যোগ করে। service-গুলো পরস্পরের সঙ্গে যোগাযোগ করলে এবং event-এর ক্রম গুরুত্বপূর্ণ হলে এই view-টিই ব্যবহার করুন। তালিকা সীমিত করতে কোনো service-এর নাম দিন। এক মাস ধরে চলা container-এর ক্ষেত্রে --tail=100 গুরুত্বপূর্ণ, কারণ default পুরো history দেখায় এবং terminal ভরে ফেলে। --since 15m সাধারণত আপনার প্রয়োজনীয় প্রশ্নের উত্তর দেয়: আপনি যে restart করেছেন, তার সময় কী ঘটেছিল।

top প্রতিটি container-এর ভেতরের process-এর তালিকা দেখায়। এতে “container চলছে” এবং “এর ভেতরের process চলছে”—এই দুটি বিষয় আলাদা করে বোঝা যায়। ls বর্তমান directory-এর বাইরে গিয়ে host-এর সব Compose project-এর status দেখায়। ফলে তিন মাস আগে শুরু করা stack খুঁজে পাওয়া যায়।

সার্ভিসের ভেতরে shell চালানো

docker compose exec web sh
docker compose exec -u root web sh
docker compose run --rm web env
docker compose run --rm --no-deps web sh

exec ইতিমধ্যে চালু থাকা container-এর ভেতরে একটি command চালায়। run একই service definition থেকে একটি নতুন container চালু করে। সার্ভিসটি exec করার মতো দীর্ঘ সময় চালু না থাকলে এটিই প্রয়োজন। run-এর সঙ্গে সবসময় --rm ব্যবহার করুন। এটি না থাকলে প্রতিটি invocation একটি stopped container রেখে যায়, যা জমে গেলে docker compose ps -a পড়া কঠিন হয়ে যায়।

bash-এর আগে sh ব্যবহার করে দেখুন। Alpine ভিত্তিক image-এ bash থাকে না, তাই ব্যর্থ হলে exec: "bash": executable file not found in $PATH দেখা যায়। run-এ --no-deps যোগ করলে সার্ভিসের dependency বাদ যায়। ফলে দ্রুত configuration check করার সময় পুরো database চালু হয় না।

প্রতিটি .env file, environment: block এবং shell variable একত্র করার পরে সার্ভিসটি বাস্তবে কোন environment পেয়েছে তা দেখার দ্রুততম উপায় হলো run --rm web env। কোনো value ভুল হলে সাধারণত merge order-ই কারণ। Compose কীভাবে env file এবং secret resolve করে কোন source-এর অগ্রাধিকার থাকে তা ব্যাখ্যা করে।

নেটওয়ার্ক, port এবং name resolution

docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networks

Compose প্রতিটি service-কে একটি project network-এ রাখে, এবং প্রতিটি service name সেই network-এ একটি DNS name হিসেবে কাজ করে। resolution সফল হলে getent hosts db-এর ভিতরে web চালালে container IP দেখা যায়। resolution ব্যর্থ হলে কিছুই দেখা যায় না। তাই দুই সেকেন্ডের মধ্যে বোঝা যায়, “এই container-গুলো কি একে অপরের সঙ্গে যোগাযোগ করতে পারে?” name resolve হলেও connection refused হলে db-এর ভিতরের process 0.0.0.0-এর বদলে 127.0.0.1-এ bind করা থাকে। তাই এটি অন্য container থেকে আসা কোনো packet গ্রহণ করে না। এই মডেলের বাকি অংশ Compose network এবং service DNS কীভাবে কাজ করে-এ ব্যাখ্যা করা হয়েছে।

port web 80 দেখায়, container-এর কোন port host address এবং port-এ publish করা হয়েছে। Mapping কোনো variable থেকে এলে অনুমান করার প্রয়োজন হয় না। কোনো port publish করলে Docker নিজে পরিচালিত একটি firewall rule-ও তৈরি করে। সেই rule আপনার rule-এর আগে কার্যকর হয়। তাই যে service-কে আপনি private মনে করেছিলেন, সেটি Internet-এর জন্য উন্মুক্ত হয়ে যেতে পারে। এই পরিস্থিতি published Docker port কেন ufw-এর নিয়ম এড়িয়ে যায়-এ ব্যাখ্যা করা হয়েছে। এই port-গুলো publish না করে project network-এ service-গুলোর সামনে authentication সমর্থনকারী একটি proxy রাখাই নিরাপদ পদ্ধতি। একটি single sign-on layer হিসেবে Authentik চালানো এই কাঠামো প্রদান করে।

Volumes এবং data

docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -v

config --volumes প্রকল্পে ঘোষিত named volume-গুলো প্রতি লাইনে একটি করে দেখায়। এই তালিকাই আপনাকে backup করতে হবে। Volume-এ অপূরণীয় data থাকলে সঠিক backup command তালিকার মতোই গুরুত্বপূর্ণ। তাই PhotoPrism এবং Immich-এর তুলনা প্রতিটি photo server-এর জন্য প্রয়োজনীয় dump এবং copy command স্পষ্টভাবে দেখায়। cp shell না খুলেই container-এর ভেতরে বা বাইরে file copy করে। এর জন্য container যে পাশে আছে, সেই পাশে service:path form ব্যবহার করতে হয়।

down -v container-এর সঙ্গে সংশ্লিষ্ট named volume-গুলোও সরিয়ে দেয়। Test stack সম্পূর্ণভাবে সরানোর জন্য এটি উপযুক্ত command। কিন্তু গুরুত্বপূর্ণ data থাকা stack-এর ক্ষেত্রে এটি ব্যবহার করা উচিত নয়, কারণ কোনো confirmation নেই এবং undo করার উপায়ও নেই। Bind mount এতে প্রভাবিত হয় না, কারণ সেগুলো host filesystem-এ থাকে। Blast radius-এর এই পার্থক্যই bind mount এবং named volume-এর মধ্যে সচেতনভাবে বেছে নেওয়ার একটি কারণ।

ডেটা না হারিয়ে ডিস্ক খালি করা

docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune

--remove-orphans এমন container মুছে দেয়, যেগুলো project-এর অন্তর্ভুক্ত হলেও ফাইলে আর দেখা যায় না। কোনো service-এর নাম পরিবর্তন করার পরে ঠিক এই পরিস্থিতি তৈরি হয়। এটি না করলে ওই container-গুলো চলতেই থাকে এবং docker compose ps-এ দেখা যায় না।

কিছু মুছে ফেলার আগে docker system df দেখায় ডিস্কের স্থান কোথায় ব্যবহৃত হয়েছে। এটি image, container, local volume এবং build cache আলাদা করে দেখায় এবং প্রতিটির জন্য reclaim করা সম্ভব এমন স্থানও জানায়। কোনো tag দ্বারা নির্দেশিত নয় এমন প্রতিটি image image prune -a মুছে দেয়। কোনো server-এ বড় image-এর একাধিক version pull করা থাকলে সাধারণত এতে সবচেয়ে বেশি স্থান খালি হয়। builder prune build cache পরিষ্কার করে। নিজের image build করা যেকোনো server-এ এই cache ধীরে ধীরে বড় হয়।

এগুলোর কোনোটিই named volume-এ প্রভাব ফেলে না। শুধু docker volume prune এবং docker compose down -v named volume মুছে দেয়।

কোনো সমস্যা তৈরির আগে ফাইল যাচাই করা

docker compose config --quiet
docker compose config --services
docker compose --dry-run up -d

config --quiet সফল হলে কিছু প্রিন্ট করে না; তাই এটি pre-deploy ধাপ বা git hook-এ ব্যবহার করা উপযুক্ত। সাধারণ config সম্পূর্ণভাবে merge ও interpolate করা ফাইল প্রিন্ট করে। এর মাধ্যমে কোনো variable-এর মান নির্ধারিত হয়েছে কি না এবং override file প্রত্যাশামতো layer হয়েছে কি না নিশ্চিত করা যায়। unset variable সেখানে empty value হিসেবে দেখা যায়, পাশাপাশি The "X" variable is not set. Defaulting to a blank string. warning থাকে।

--dry-run একটি global flag, subcommand flag নয়। তাই এটি up-এর আগে দিতে হয়। এটি Compose যে প্রতিটি action নিত, তা প্রিন্ট করে এবং কোনো পরিবর্তন করে না। গুরুত্বপূর্ণ কোনো stack-এ down চালানোর আগে এই ত্রিশ সেকেন্ড ব্যয় করা যথার্থ।

ফাইল, profile এবং project নিয়ে কাজ করা

docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose --profile debug up -d
docker compose -p staging up -d

একাধিক -f flag ক্রমানুসারে merge হয়, এবং পরের ফাইলগুলো key অনুযায়ী আগের ফাইলের মান override করে। একটি base file-এর সঙ্গে ছোট একটি production override রাখার এটি প্রচলিত পদ্ধতি। তবে list ও map-এর ক্ষেত্রে নিয়ম আলাদা। তাই অপ্রত্যাশিত ফলাফল তদন্ত করার আগে Compose একাধিক file কীভাবে merge করে পড়ুন।

--profile ওই profile-এ tagged service-গুলোকে untagged service-গুলোর সঙ্গে চালু করে। এতে সাধারণ up-এর বাইরে debug tooling রাখা যায়। -p project name নির্ধারণ করে। ফলে একই stack-এর দুটি copy আলাদা network এবং আলাদা volume name ব্যবহার করে পাশাপাশি চালানো যায়। reboot-এর পরে stack পুনরায় চালু করা কোনো command নিজে টাইপ করার বিষয় নয়। এর জন্য এমন একটি unit ব্যবহার করা হয়, যা আপনার হয়ে এটি চালায়। এই পদ্ধতি boot-এর সময় Compose stack চালু করা-তে বর্ণনা করা হয়েছে।

FAQ

হাইফেনযুক্ত docker-compose-এর পরিবর্তে কী এসেছে?

Compose V2, যা docker compose হিসেবে একটি space দিয়ে চালানো হয়। এটি Docker Engine-এর সঙ্গে bundled একটি plugin, এবং বর্তমান package-গুলোতে V1 Python tool আর installed থাকে না। space-যুক্ত form কোনো output না দিলে আপনার distribution-এর জন্য docker-compose-plugin package install করুন। alias যোগ করার বদলে পুরোনো script-গুলো space-যুক্ত form-এ update করুন, কারণ V2-তে V1-এ না থাকা flag রয়েছে।

docker compose restart কেন আমার configuration পরিবর্তন গ্রহণ করছে না?

restart বিদ্যমান container-টিকে যে configuration দিয়ে তৈরি করা হয়েছিল, তা ব্যবহার করে stop ও start করে; এটি কখনো compose.yaml নতুন করে পড়ে না। environment variable, port, volume বা image tag-এ যেকোনো পরিবর্তনের জন্য docker compose up -d প্রয়োজন। এটি প্রতিটি service-কে তার চলমান container-এর সঙ্গে তুলনা করে এবং যেগুলোর মধ্যে পার্থক্য আছে, সেগুলো recreate করে। file-এ কোনো পরিবর্তন না থাকলেও replacement করাতে চাইলে --force-recreate যোগ করুন।

কোনো service-কে কীভাবে নতুন image-এ update করব?

প্রথমে docker compose pull, তারপর docker compose up -d চালান। pull command-টি file-এ থাকা প্রতিটি tag-এর বর্তমান image fetch করে, এবং up -d যেসব service-এর image ID তাদের container-এর image ID-এর সঙ্গে মেলে না, সেগুলো recreate করে। একা up -d চালালে disk-এ আগে থেকেই থাকা image পুনরায় ব্যবহার করা হয়। এ কারণেই latest-এ pinned একটি stack কোনো error না দেখিয়ে কয়েক মাস পুরোনো build-এ চলতে পারে।

live server-এ কোন cleanup command-গুলো নিরাপদ?

docker system df, docker image prune -a এবং docker builder prune শুধু image ও cache remove করে। তাই চলমান service-গুলো কাজ চালিয়ে যায় এবং named volume-এ কোনো পরিবর্তন হয় না। ঝুঁকিপূর্ণ জোড়াটি হলো docker compose down -v এবং docker volume prune। এগুলো কোনো prompt ছাড়াই named volume delete করে। কী কী ঝুঁকিতে আছে তা জানার জন্য আগে docker compose config --volumes চালান।

পুরো stack start না করে কি একটি command চালাতে পারি?

হ্যাঁ। docker compose run --rm --no-deps web sh web service definition থেকে একটি মাত্র container start করে, তার dependency-গুলো skip করে এবং আপনি বের হলে container-টি remove করে। container ইতিমধ্যে চলমান থাকলে এর বদলে exec ব্যবহার করুন, কারণ exec চলমান process-এ যুক্ত হয় এবং service-টি বাস্তবে যে অবস্থায় আছে তা দেখায়।