০৩ অক্টো, ২০২৫·8 মিনিট
কেন Docker ক্লাউডে অ্যাপ নির্ভরযোগ্যভাবে চালাতে জরুরি
শিখুন কেন Docker আপনার অ্যাপকে ল্যাপটপ থেকে ক্লাউড পর্যন্ত একইভাবে চালাতে সাহায্য করে, ডেপ্লয় সহজ করে, পরিবহনযোগ্যতা বাড়ায় এবং পরিবেশ সম্পর্কিত ঝামেলা কমায়।
শিখুন কেন Docker আপনার অ্যাপকে ল্যাপটপ থেকে ক্লাউড পর্যন্ত একইভাবে চালাতে সাহায্য করে, ডেপ্লয় সহজ করে, পরিবহনযোগ্যতা বাড়ায় এবং পরিবেশ সম্পর্কিত ঝামেলা কমায়।
অধিকাংশ ক্লাউড ডেপ্লয়মেন্টের সমস্যা একটি পরিচিত অবাক করে দেওয়ার থেকে শুরু হয়: অ্যাপটি ল্যাপটপে কাজ করে, কিন্তু ক্লাউড সার্ভারে পৌঁছানোর পর ব্যর্থ হয়ে যায়। হতে পারে সার্ভারে Python বা Node-এর ভিন্ন সংস্করণ আছে, কোনো সিস্টেম লাইব্রেরি নেই, কনফিগ ফাইলে ছোট তফাৎ আছে, বা কোনো ব্যাকগ্রাউন্ড সার্ভিস চালু নেই। এই ছোট-বড় তফাৎ মিলিত হয়ে দলগুলোকে পরিবেশ ডিবাগ করতে বাধ্য করে, ফলে প্রোডাক্ট উন্নত করার বদলে পরিবেশে আটকে যায়।
Docker সাহায্য করে আপনার অ্যাপকে সেই রানটাইম ও ডিপেনডেন্সিসহ প্যাক করে দেওয়ার মাধ্যমে। "ভার্সন X ইনস্টল করো, তারপর লাইব্রেরি Y যোগ করো, তারপর এই কনফিগ সেট করো"—এর মতো ধাপে ধাপে নির্দেশের বদলে আপনি একটি কনটেইনার ইমেজ পাঠান যেটাতে এসব ইতিমধ্যেই অন্তর্ভুক্ত।
একটি সহজ মানসিক মডেল:
যখন আপনি ক্লাউডে একই ইমেজ চালান যেটা আপনি লোকালি টেস্ট করেছেন, তখন "কিন্তু সার্ভার আলাদা" সমস্যা উল্লেখযোগ্যভাবে কমে যায়।
Docker বিভিন্ন ভূমিকাকে বিভিন্ন কারণে সাহায্য করে:
Docker অত্যন্ত সহায়ক, কিন্তু এটা একমাত্র টুল নয় যা আপনার দরকার হবে। আপনাকে এখনও কনফিগারেশন, সিক্রেটস, ডেটা স্টোরেজ, নেটওয়ার্কিং, মনিটরিং এবং স্কেলিং ম্যানেজ করতে হবে। অনেক দলের জন্য Docker একটি বিল্ডিং ব্লকের মতো কাজ করে—লোকাল ওয়ার্কফলো জন্য Docker Compose ও প্রোডাকশনে অর্কেস্ট্রেশন প্ল্যাটফর্মের সাথে এটি মিলেমিশে কাজ করে।
Docker-কে ভাবুন আপনার অ্যাপের জন্য একটি শিপিং কনটেইনার হিসেবে: ডেলিভারি আরও পূর্বানুমানযোগ্য করে তোলে। বন্দরের পরে (ক্লাউড সেটআপ ও রানটাইম) কি হচ্ছে তা এখনও গুরুত্বপূর্ণ—কিন্তু প্রতিটি চালান একইভাবে প্যাক করা থাকলে কাজ অনেক সহজ হয়ে যায়।
Docker নতুন কিছু শব্দভান্ডার মনে করাতে পারে, কিন্তু মূল ধারণা সহজ: আপনার অ্যাপ এমনভাবে প্যাক করুন যাতে এটি যে কোনো জায়গায় একইভাবে চলে।
একটি ভার্চুয়াল মেশিন আপনার অ্যাপের পাশাপাশি একটি পূর্ণ গেস্ট অপারেটিং সিস্টেম বাণ্ডিল করে। সেটা নমনীয়, কিন্তু রান করার জন্য ভারী এবং শুরুতে ধীর।
একটি কনটেইনার আপনার অ্যাপ ও তার ডিপেনডেন্সি বাণ্ডিল করে, কিন্তু হোস্ট মেশিনের OS কার্নেল শেয়ার করে পুরো OS পাঠায় না। এ কারণে কনটেইনার সাধারণত হালকা, কয়েক সেকেন্ডে শুরু হয়, এবং একই সার্ভারে অনেকগুলো চালানো যায়।
ইমেজ: আপনার অ্যাপের একটি রিড-অনলি টেমপ্লেট। এটিকে এমন একটি প্যাকেজড আর্টিফ্যাক্ট হিসেবে ভাবুন যাতে আপনার কোড, রানটাইম, সিস্টেম লাইব্রেরি ও ডিফল্ট সেটিংস রয়েছে।
কনটেইনার: একটি ইমেজের চলমান ইনস্ট্যান্স। ইমেজ যদি ব্লুপ্রিন্ট হয়, কনটেইনার হলো আপনি এখন যে বাড়িতে বাস করছেন।
Dockerfile: ইমেজ বানানোর ধাপে ধাপে নির্দেশ (কোন ডিপেনডেন্সি ইনস্টল করতে হবে, কোন ফাইল কপি করতে হবে, কোন কমান্ড দিয়ে শুরু করতে হবে)।
রেজিস্ট্রি: ইমেজ সংরক্ষণ ও বিতরণের সার্ভিস। আপনি ইমেজগুলোকে রেজিস্ট্রিতে “push” করেন এবং সার্ভারগুলো পরে সেগুলো “pull” করে (পাবলিক বা প্রাইভেট রেজিস্ট্রি)।
একবার আপনার অ্যাপ একটি Dockerfile থেকে বানানো ইমেজ হিসেবে সংজ্ঞায়িত হলে, আপনি একটি স্ট্যান্ডার্ড ডেলিভারি ইউনিট পান। সেই স্ট্যান্ডার্ডাইজেশন রিলিজগুলো পুনরাবৃত্তিমূলক করে তোলে: আপনি যেই ইমেজ টেস্ট করেছিলেন, সেটাই ডেপ্লয় করেন।
এটি হ্যান্ডঅফও সহজ করে দেয়। "আমার মেশিনে কাজ করে" বলার বদলে আপনি একটি নির্দিষ্ট ইমেজ ভার্সন রেজিস্ট্রিতে দেখিয়ে বলতে পারেন: এই কনটেইনার চালান, এই পরিবেশ ভ্যারিয়েবলগুলোর সাথে, এই পোর্টে। এটা ডেভ ও প্রোড পরিবেশের কনসিস্টেন্সির ভিত্তি।
Docker ক্লাউড ডেপ্লয়মেন্টে সবচেয়ে বড় সুবিধা হলো কনসিস্টেন্সি। ল্যাপটপ, CI রানার বা ক্লাউড VM-এ যা ইনস্টল আছে তার ওপর নির্ভর করার বদলে আপনি একবার Dockerfile-এ পরিবেশ সংজ্ঞায়িত করেন এবং বিভিন্ন ধাপে তা পুনর্ব্যবহার করেন।
প্র্যাকটিসে কনসিস্টেন্সি এমনভাবে প্রকাশিত হয়:
এই কনসিস্টেন্সি দ্রুত লাভ দেয়। প্রোডে যে বাগটি আসে, সেটি একই ইমেজ ট্যাগ চালিয়ে লোকালি পুনরুত্পাদন করা যায়। এমন একটি ডেপ্লয় যা কোনো লাইব্রেরি অনুপস্থিতির কারণে ব্যর্থ হয়—এমনটা অসাধারণ কারণ যদি লাইব্রেরি অনুপস্থিত থাকতো, তা আপনার টেস্ট কনটেইনারেও অর থাকবে।
দলগুলো প্রায়ই সেটআপ ডকস বা স্ক্রিপ্ট দিয়ে স্ট্যান্ডার্ডাইজ করার চেষ্টা করে। সমস্যা হলো ড্রিফট: মেশিনগুলো সময়ের সাথে পরিবর্তিত হয় প্যাচ ও প্যাকেজ আপডেট আসার ফলে, এবং ধীরে ধীরে পার্থক্য জমে।
Docker-এ পরিবেশকে একটি আর্টিফ্যাক্ট হিসেবে দেখা হয়। যদি পরিবর্তন করতে হয়, আপনি একটি নতুন ইমেজ পুনর্নির্মাণ করেন এবং সেটা ডেপ্লয় করেন—পরিবর্তনগুলো স্পষ্ট ও রিভিউযোগ্য। যদি আপডেটে সমস্যা হয়, রোলব্যাক প্রায়ই পূর্বের ভাল ট্যাগ পুনরায় ডেপ্লয় করাই সহজ।
Docker-এর আরেকটা বড় জয় হলো পোর্টেবিলিটি। একটি কনটেইনার ইমেজ আপনার অ্যাপকে একটি পোর্টেবল আর্টিফ্যাক্টে পরিণত করে: একবার বানান, তারপর যেখানে-ই সঙ্গত কনটেইনার রানটাইম আছে সেখানে চালান।
Docker ইমেজ আপনার অ্যাপ কোড এবং রানটাইম ডিপেনডেন্সিসহ বানায় (উদাহরণ: Node.js, Python প্যাকেজ, সিস্টেম লাইব্রেরি)। এর মানে একটি ইমেজ যা আপনি ল্যাপটপে চালিয়েছেন তা এই জায়গাগুলোতেও চালানো যাবে:
এটি অ্যাপ রানটাইম স্তরে ভেন্ডর লক-ইন কমায়। আপনি এখনও ক্লাউড-নেটিভ সার্ভিস (ডাটাবেস, কিউ, স্টোরেজ) ব্যবহার করতে পারেন, কিন্তু আপনার কোর অ্যাপকে হোস্ট বদলাতে আবার বিল্ড করতে হয় না।
পোর্টেবিলিটি তখনই ভাল কাজ করে যখন ইমেজগুলো রেজিস্ট্রিতে সংরক্ষণ ও ভার্সন করা হয়—পাবলিক বা প্রাইভেট। একটি সাধারণ ওয়ার্কফ্লো:
myapp:1.4.2)।রেজিস্ট্রিগুলো ডেপ্লয়মেন্ট পুনরুত্পাদন ও অডিট করাও সহজ করে: যদি প্রোডাকশন 1.4.2 চালায়, পরে আপনি একই আর্টিফ্যাক্ট pull করে একই বিট পেতে পারেন।
হোস্ট মাইগ্রেশন: যদি আপনি এক ভিপি প্রোভাইডার থেকে অন্যটিতে যান, পুরো স্ট্যাক পুনরায় ইনস্টল করতে হবে না। নতুন সার্ভারকে রেজিস্ট্রির দিকে পয়েন্ট করুন, ইমেজ pull করুন এবং একই কনফিগে কনটেইনার শুরু করুন।
স্কেল আউট: বেশি ক্যাপাসিটি দরকার? একই ইমেজ থেকে সার্ভারে অতিরিক্ত কনটেইনার চালু করুন। প্রতিটি ইনস্ট্যান্স একই হওয়ায় স্কেল করা একটি পুনরাবৃত্তিমূলক অপারেশন হয়ে যায়, ম্যানুয়াল সেটআপ নয়।
ভালো Docker ইমেজ শুধু "কিছু চলায়" এমন নয়। এটি একটি প্যাকেজড, ভার্সনকৃত আর্টিফ্যাক্ট যা আপনি পরে পুনর্নির্মাণ করলেও বিশ্বাসযোগ্য থাকবে। এটিই ক্লাউড ডেপ্লয়মেন্টকে পূর্বানুমানযোগ্য করে তোলে।
একটি Dockerfile ধাপে ধাপে কিভাবে আপনার অ্যাপ ইমেজ তৈরি হবে বর্ণনা করে—একটি রেসিপির মতো স্পষ্ট পরিমাপ ও নির্দেশ সহ। প্রতিটি লাইন একটি লেয়ার তৈরি করে, এবং একসাথে এগুলো নির্ধারণ করে:
এই ফাইলটি পরিষ্কার ও ইচ্ছাকৃত রাখলে ইমেজ ডিবাগ, রিভিউ ও রক্ষণাবেক্ষণ সহজ হয়।
ছোট ইমেজ দ্রুত pull হয়, দ্রুত শুরু হয় এবং কম জিনিস ভেঙে পড়ার সম্ভাবনা থাকে।
alpine বা slim ভ্যারিয়েন্ট) যদি আপনার অ্যাপের সাথে উপযুক্ত হয়।অনেক অ্যাপ কম্পাইলার ও বিল্ড টুল চায়, কিন্তু রানটাইমে তা দরকার হয় না। মাল্টি-স্টেজ বিল্ড আপনাকে এক স্টেজে বিল্ড করে এবং দ্বিতীয়, মিনিমাল স্টেজে প্রোড ইমেজ প্রস্তুত করতে দেয়।
# build stage
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# runtime stage
FROM nginx:1.27-alpine
COPY --from=build /app/dist /usr/share/nginx/html
ফলাফল একটি ছোট প্রোডাকশন ইমেজ যা প্যাচ করার মতো ডিপেনডেন্সি কম রাখে।
ট্যাগগুলোই নির্ধারণ করে আপনি ঠিক কী ডেপ্লয় করেছেন।
latest নির্ভর করবেন না; এটি অস্পষ্ট।1.4.2) রিলিজের জন্য ব্যবহার করুন।1.4.2-<sha> বা কেবল <sha>) যাতে আপনি সবসময় ইমেজকে কোডের সঙ্গে ট্রেস করতে পারেন।এটি রোলব্যাক ও ক্লিয়ার অডিটকে সমর্থন করে যখন ক্লাউডে কিছু বদলায়।
একটি "বাস্তব" ক্লাউড অ্যাপ সাধারণত একক প্রসেস নয়। এটি একটি ছোট সিস্টেম: একটি ওয়েব ফ্রন্টএন্ড, একটি API, হয়তো একটি ব্যাকগ্রাউন্ড ওয়ার্কার, এবং একটি ডাটাবেস বা ক্যাশ। Docker একক ও মাল্টি-সার্ভিস উভয় সেটআপকে সমর্থন করে—আপনাকে শুধু বুঝতে হবে কিভাবে কনটেইনারগুলো একে অপরের সাথে কথা বলে, কনফিগ কোথায় থাকে, এবং কিভাবে ডেটা রিস্টার্ট টিকে থাকে।
একক-কনটেইনার অ্যাপ হতে পারে একটি স্ট্যাটিক সাইট বা একটিমাত্র API যা অন্যকিছুর ওপর নির্ভর করে না। আপনি একটি পোর্ট (যেমন 8080) এক্সপোজ করে চালাবেন।
বহু-সার্ভিস অ্যাপ বেশি সাধারণ: web api-র উপর নির্ভর করে, api db-র উপর নির্ভর করে, এবং একটি worker জব কনসিউম করে। IP ঠিকানা হার্ডকোড না করে, কনটেইনারগুলো সাধারণত সার্ভিস নাম দিয়ে একটি শেয়ার্ড নেটওয়ার্কে একে অপরকে খুঁজে পায় (উদাহরণ: db:5432)।
Docker Compose লোকাল ডেভ ও স্টেজিংয়ের জন্য একটি ব্যবহারিক পছন্দ কারণ এটি একটি কমান্ডে পুরো স্ট্যাক চালায়। এ 또한 আপনার অ্যাপের "আকৃতি" (সার্ভিস, পোর্ট, ডিপেনডেন্সি) একটি ফাইলে দলভুক্তভাবে ডকুমেন্ট করে।
একটি সাধারণ প্রগ্রেশন:
ইমেজগুলো পুনরায় ব্যবহারযোগ্য ও শেয়ার করার জন্য নিরাপদ হওয়া উচিত। ইমেজের বাইরে রাখুন:
এগুলো পরিবেশ ভ্যারিয়েবল, .env ফাইল (সতর্কতা: কমিট করবেন না) বা আপনার ক্লাউডের সিক্রেটস ম্যানেজারের মাধ্যমে ইনজেক্ট করুন।
কনটেইনার ডিস্পোজেবল; আপনার ডেটা হওয়া উচিত নয়। যাদের রিস্টার্ট টিকে থাকা জরুরি তাদের জন্য ভলিউম ব্যবহার করুন:
ক্লাউড ডেপ্লয়মেন্টে সমতুল্যটি ম্যানেজড স্টোরেজ (managed DBs, network disks, object storage)। মূল ধারণা অপরিবর্তিত: কনটেইনার অ্যাপ চালায়; পারসিস্টেন্ট স্টোরেজ স্টেট ধরে রাখে।
একটি সুস্থ Docker ডেপ্লয়মেন্ট ওয়ার্কফ্লো ইচ্ছাকৃতভাবে সহজ: একবার ইমেজ বানান, তারপর সেই একটিই সব জায়গায় চালান। ফাইল সার্ভারে কপির মতো কাজ বা ইনস্টলার পুনরায় চালানোর বদলে, ডেপ্লয়মেন্টকে একটি পুনরাবৃত্তিমূলক রুটিনে পরিণত করুন: ইমেজ pull করুন, কনটেইনার চালান।
বেশিরভাগ দল এই পাইপলাইন অনুসরণ করে:
myapp:1.8.3)।এই শেষ ধাপটিই Docker-কে “নিরস” (boring) মনে করায়—ভালোভাবে:
# build locally or in CI
docker build -t registry.example.com/myapp:1.8.3 .
docker push registry.example.com/myapp:1.8.3
# on the server / cloud runner
docker pull registry.example.com/myapp:1.8.3
docker run -d --name myapp -p 80:8080 registry.example.com/myapp:1.8.3
ডকারাইজড অ্যাপ চালানোর দুইটি সাধারণ উপায়:
রিলিজের সময় আউটেজ কমাতে, প্রোডাকশনে সাধারণত তিনটি বিল্ডিং ব্লক যোগ করা হয়:
রেজিস্ট্রি কেবল স্টোরেজ নয়—এটা কিভাবে আপনি পরিবেশগুলোর কনসিস্টেন্সি রাখেন। একটি প্রচলিত অনুশীলন হল একই ইমেজ প্রোমোট করা dev → staging → prod (প্রায়শই re-tag করে), পুনরায় বিল্ড না করে। এর ফলে প্রোডাকশন একই আর্টিফ্যাক্ট চালায় যেটা আপনি আগেই টেস্ট করেছেন, যা "স্টেজিং-এ কাজ করেছিল" এর ধোঁয়াশা কমায়।
CI/CD (Continuous Integration ও Continuous Delivery) হচ্ছে সফটওয়্যার শিপ করার এসেম্বলি লাইন। Docker এটাকে আরও পূর্বানুমানযোগ্য করে তোলে কারণ প্রতিটি ধাপ একটি জ্ঞানীয় পরিবেশে চলে।
একটি Docker-বন্ধু পাইপলাইন সাধারণত তিনটি ধাপ থাকে:
myapp:1.8.3)।এই ফ্লো নন-টেক স্টেকহোল্ডারদের কাছে বোঝানোও সহজ: “আমরা একটা সিল করা বক্স বানাই, বক্সটাকে টেস্ট করি, তারপর একই বক্স প্রতিটি পরিবেশে পাঠাই।”
টেস্টগুলো প্রায়ই লোকালেই পাস করে কিন্তু প্রোডে ব্যর্থ হয় কারণ রানটাইম মেলেনি, সিস্টেম লাইব্রেরি অনুপস্থিত বা ভিন্ন env ভ্যারিয়েবল। কনটেইনারে টেস্ট চালালে এসব ফাঁক কমে। আপনার CI রানারকে একটি যত্নশীল মেশিনের প্রয়োজন নেই—শুধু Docker লাগলেই হয়।
Docker “promote, don’t rebuild” সমর্থন করে। প্রতি পরিবেশে আপনি একে করুন:
myapp:1.8.3 তৈরি ও টেস্ট করুন।পরিবেশগুলোর মধ্যে কেবল কনফিগ পরিবর্তন হয় (URL বা ক্রেডেনশিয়ালস), অ্যাপ আর্টিফ্যাক্ট নয়। এতে রিলিজ-ডে অনিশ্চয়তা কমে এবং রোলব্যাক সহজ হয়: পূর্বের ট্যাগ পুনরায় ডেপ্লয় করুন।
যদি আপনি দ্রুত চলছে থাকেন এবং Docker-এর সুবিধা পেতে চান কিন্তু কয়েকদিন স্ক্যাফল্ডিং এ কাটাতে চান না, Koder.ai আপনাকে চ্যাট-চালিত ওয়ার্কফ্লো থেকে প্রোডাকশন-আকৃতির অ্যাপ জেনারেট করতে এবং তারপর এটিকে পরিষ্কারভাবে কনটেইনারাইজ করতে সাহায্য করতে পারে।
উদাহরণস্বরূপ, দলগুলো প্রায়ই Koder.ai ব্যবহার করে:
docker-compose.yml যোগ করতে (তাতে dev ও prod আচরণ সঙ্গত থাকে),মূল সুবিধা হলো Docker ডেপ্লয়মেন্টের প্রিমিটিভিন থাকলেও Koder.ai আইডিয়া থেকে কনটেইনার-রেডি কোডবেসে যেতে গতি বাড়ায়।
Docker একটি সার্ভিসকে একটি মেশিনে প্যাকেজ ও চালানো সহজ করে। কিন্তু যদি আপনার একাধিক সার্ভিস, প্রতিটির একাধিক কপি, এবং একাধিক সার্ভার থাকে, তাহলে আপনি এমন একটি সিস্টেম চান যা সবকিছু সমন্বয় করে। এটিই অর্কেস্ট্রেশন: সফটওয়্যার যা সিদ্ধান্ত নেয় কোথায় কনটেইনার চলবে, এগুলোকে সুস্থ রাখবে, এবং ডিমান্ড বদলালে ক্যাপাসিটি সামঞ্জস্য করবে।
মাত্র কয়েকটি কনটেইনার থাকলে আপনি ম্যানুয়ালি চালু ও রিস্টার্ট করে জ্বলন্ত মিডজওয়াল ঠিক রাখতে পারেন। বড় স্কেলে তা দ্রুত ভেঙে পড়ে:
Kubernetes (সাধারণত “K8s”) সবচেয়ে প্রচলিত অর্কেস্ট্রেটর। একটি সহজ মানসিক মডেল:
Kubernetes কনটেইনার বানায় না; এটি কেবল চালায়। আপনি ইমেজ বানান, রেজিস্ট্রিতে push করেন, তারপর Kubernetes সেই ইমেজ নোডে pull করে পডগুলো চালায়। আপনার ইমেজ সর্বত্র ব্যবহৃত একটি পোর্টেবল, ভার্সনকৃত আর্টিফ্যাক্ট থাকে।
যদি আপনার একটি সার্ভার এবং কয়েকটি সার্ভিস থাকে, Compose অনেক সময় যথেষ্ট। অর্কেস্ট্রেশন তখনই উপকারী যখন আপনি উচ্চ প্রাপ্যতা, ঘন ডিপ্লয়মেন্ট, অটো-স্কেলিং, বা একাধিক সার্ভারে ক্ষমতা ও রেজিলিয়েন্স চান।
কনটেইনার স্বয়ংক্রিয়ভাবে অ্যাপকে নিরাপদ করে না—তবে তারা স্ট্যান্ডার্ডাইজ ও অটোমেট করা নিরাপত্তি কাজগুলো যোগ করার পরিমাণকে সহজ করে। সুবিধা হলো Docker আপনাকে স্পষ্ট, পুনরাবৃত্তি যোগ্য পয়েন্ট দেয় যেখানে অডিট ও সিকিউরিটি কন্ট্রোল যোগ করা যায়।
একটি কন্টেইনার ইমেজ আপনার অ্যাপ ও তার ডিপেনডেন্সির একটি বাণ্ডেল, তাই ভলনারেবিলিটিগুলো সাধারণত বেস ইমেজ বা সিস্টেম প্যাকেজ থেকে আসে। ইমেজ স্ক্যানিং ডেপ্লয়ের আগে পরিচিত CVE-গুলোর জন্য চেক করে।
পাইপলাইনে স্ক্যানিং একটি গেইট করুন: যদি ক্রিটিক্যাল ভলনারেবিলিটি পাওয়া যায়, বিল্ড ফেল করান এবং একটি প্যাচ করা বেস ইমেজ দিয়ে পুনরায় বিল্ড করুন। স্ক্যান ফলাফলগুলো আর্টিফ্যাক্ট হিসেবে রাখুন যাতে আপনি কি শিপ করেছেন তা কমপ্লায়েন্স রিভিউতে দেখাতে পারেন।
সম্ভব হলে non-root ইউজার হিসেবে চালান। অনেক অ্যাটাক রুট অ্যাক্সেস ব্যবহার করে কনটেইনারের বাইরে যাওয়ার চেষ্টা করে বা ফাইলসিস্টেম টেম্পার করে।
পাঠযোগ্য ফাইলসিস্টেম ও নির্দিষ্ট লিখনযোগ্য পাথ মাউন্ট (লগ বা আপলোডস) ব্যবহার করার কথা ভাবুন। এতে অনধিকার প্রবেশ ঘটলে একজন আক্রমণকারী কি পরিবর্তন করতে পারবে তা সীমাবদ্ধ হয়।
API কী, পাসওয়ার্ড, বা ব্যক্তিগত সার্টিফিকেট Docker ইমেজে কপি করবেন না এবং Git-এ কমিট করবেন না। ইমেজ ক্যাশ হয়, শেয়ার হয় এবং রেজিস্ট্রিতে push হয়—সিক্রেটস ব্যাপকভাবে লিক হতে পারে।
পার্কোর হিসেবে, রানটাইমে আপনার প্ল্যাটফর্মের সিক্রেট স্টোর (উদাহরণ Kubernetes Secrets বা ক্লাউড প্রোভাইডারের সিক্রেট ম্যানেজার) দিয়ে সিক্রেট ইনজেক্ট করুন এবং কেবল সেই সার্ভিসকে অ্যাক্সেস অধিকার দিন যা প্রয়োজন।
পরম্পরাগত সার্ভারের মতো কনটেইনার নিজে চলতে চলতে প্যাচ হয় না। সাধারণ পদ্ধতি হলো: আপডেটেড ডিপেনডেন্সিসহ ইমেজ পুনর্নির্মাণ করে পুনরায় ডেপ্লয় করা।
একটি ক্যালেন্ডার সেট করুন (সাপ্তাহিক বা মাসিক) এমনভাবে যে আপনি ইমেজগুলো পুনর্নির্মাণ করবেন এমনকি যখন আপনার অ্যাপ কোড বদলায়নি, এবং উচ্চ-গুরুত্বপূর্ণ CVE-র ক্ষেত্রে তৎক্ষণাৎ পুনর্নির্মাণ করুন। এই অভ্যাস ডেপ্লয়মেন্টগুলোকে অডিটযোগ্য ও কম ঝুঁকিপূর্ণ রাখে।
যেমনটুকু দলগুলো “Docker ব্যবহার করে” বললেও কিছু অভ্যাস থাকলে তবুও অনির্ভরযোগ্য ক্লাউড ডেপ্লয়মেন্ট শিপ হতে পারে। এখানে সবচেয়ে বেশি সমস্যার সৃষ্টি করা ভুলগুলো এবং প্রতিরোধের ব্যবহারিক উপায়গুলো আছে।
একটি সাধারণ অ্যান্টি-প্যাটার্ন হল “সার্ভারে SSH করে কিছু পরিবর্তন করা,” বা চালু কনটেইনারে exec করে কনফিগ হট-ফিক্স করা। একবার কাজ করে, পরে ভেঙে পড়ে কারণ কেউ সঠিক একই স্টেট পুনরায় তৈরি করতে পারে না।
বদলে কনটেইনারগুলোকে গবাদি বদলে (cattle) মতো আচরণ করুন: ডিসপোজেবল ও রিপ্লেসেবল। প্রতিটি পরিবর্তনই ইমেজ বিল্ড ও ডেপ্লয় পাইপলাইনের মাধ্যমে করুন। ডিবাগ করতে গেলে একটি অস্থায়ী পরিবেশে করুন এবং তারপর ফিক্সটি Dockerfile, কনফিগ বা ইনফ্রাস্ট্রাকচারে কোড করুন।
বড় ইমেজ CI/CD ধীর করে, স্টোরেজ খরচ বাড়ায়, এবং সিকিউরিটি সারফেস বাড়ায়।
এই সমস্যা এড়াতে Dockerfile কড়াকড়ি করুন:
.dockerignore যোগ করুন যাতে node_modules, বিল্ড আর্টিফ্যাক্ট বা লোকাল সিক্রেটস অনিচ্ছাকৃতভাবে পাঠানো না হয়।লক্ষ্য একটি পুনরাবৃত্তিমূলক ও দ্রুত বিল্ড—এমনকি ক্লিন মেশিনেও।
কনটেইনারগুলো অ্যাপের আচরণ বুঝতে বাধা দেয় না। লগ, মেট্রিক্স, ও ট্রেসিং ছাড়া আপনি কেবল ব্যবহারকারীর অভিযোগে জানবেন যে কোথাও সমস্যা আছে।
ন্যূনতমভাবে, নিশ্চিত করুন আপনার অ্যাপ stdout/stderr-এ লগ করে (লোকাল ফাইলে না), বেসিক হেলথ এন্ডপয়েন্ট আছে, এবং কয়েকটি কীগুলো মেট্রিক (এরর রেট, ল্যাটেন্সি, কিউ গভীরতা) নির্গত করে। তারপর সেগুলোকে আপনার ক্লাউড মনিটরিং সিস্টেমের সাথে সংযুক্ত করুন।
স্ট্যাটলেস কনটেইনার সহজে রিপ্লেস করা যায়; স্টেটফুল ডেটা নয়। দলগুলো প্রায়ই পরে আবিষ্কার করে যে কনটেইনারে ডাটাবেস চালানো "ভালো হয়ে" ছিল যতক্ষণ না রিস্টার্টে ডেটা মুছে যায়।
শুরুতেই সিদ্ধান্ত নিন স্টেট কোথায় থাকবে:
Docker অ্যাপ প্যাকেজিংয়ে অসাধারণ—কিন্তু নির্ভরযোগ্যতা আসে যখন আপনি সচেতনভাবে কনটেইনারগুলো কিভাবে বানানো, পর্যবেক্ষণ ও পার্সিস্টেন্ট ডেটার সাথে সংযুক্ত করা হবে তা ডিজাইন করেন।
Docker-এ নতুন হলে, দ্রুত মূল্য পাওয়ার সবচেয়ে সহজ উপায় হলো একটি বাস্তব সার্ভিসকে শেষ পর্যন্ত কনটেইনারাইজ করা: বিল্ড করা, লোকালি চালানো, রেজিস্ট্রিতে push করা, এবং ডেপ্লয় করা। নিম্ন чекলিস্টটুকু ব্যবহার করে স্কোপ ছোট রাখুন এবং ফলাফল ব্যবহারযোগ্য রাখুন।
প্রথমে একটি স্ট্যাটলেস সার্ভিস বাছুন (একটি API, একটি worker, বা একটি সাধারণ ওয়েব অ্যাপ)। নির্ধারণ করুন কী দিয়ে শুরু হবে: কোন পোর্টে লিসেন করে, প্রয়োজনীয় পরিবেশ ভ্যারিয়েবলগুলো, এবং কোনো বাহ্যিক ডিপেনডেন্সি (যেমন একটি ডাটাবেস যা আপনি আলাদাভাবে চালাতে পারবেন)।
লক্ষ্য স্পষ্ট রাখুন: “আমি একই ইমেজ থেকে লোকালি ও ক্লাউডে একইভাবে চালাতে পারি।”
যে Dockerfile টা সবচেয়ে ছোটে আপনার অ্যাপ নির্ভরযোগ্যভাবে বানায় সেটি লিখুন। পছন্দ করবেন:
তারপর লোকাল ডেভের জন্য docker-compose.yml যোগ করুন যা env ভ্যারিয়েবল ও ডিপেনডেন্সি (ডাটাবেস ইত্যাদি) ওয়্যারিং করে—আপনার ল্যাপটপে Docker ছাড়া অন্য কিছু ইনস্টল না করিয়েই চালানো যাবে।
পরবর্তীতে দরকার হলে লোকালি সেটআপ বাড়াতে পারেন—শুরুতে সাদাসিধে রাখুন।
ইমেজ কোথায় থাকবে (Docker Hub, GHCR, ECR, GCR ইত্যাদি) নির্ধারণ করুন। তারপর এমন ট্যাগাভিধি নিন যে ডেপ্লয়মেন্ট পূর্বানুমানযোগ্য হয়:
:dev লোকাল টেস্টিং (ঐচ্ছিক):git-sha (অপরিবর্তনীয়, ডেপ্লয়মেন্টের জন্য শ্রেষ্ঠ):v1.2.3 রিলিজের জন্যপ্রোডাকশনে :latest নির্ভর করবেন না।
CI সেটআপ করুন যাতে প্রধান ব্রাঞ্চে প্রতিটি মর্জে ইমেজ বিল্ড করে এবং রেজিস্ট্রিতে push করে। আপনার পাইপলাইন উচিত:
এটা কাজ করলে, আপনি প্রকাশিত ইমেজটিকে ক্লাউড ডেপ্লয় ধাপে যুক্ত করে আরও итераট করতে প্রস্তুত থাকবেন।
Docker “আমার মেশিনে কাজ করে” সমস্যা কমায় কারণ এটি আপনার অ্যাপটিকে তার রানটাইম ও ডিপেনডেন্সিসহ একটি ইমেজে প্যাকেজ করে। একই ইমেজ লোকালি, CI-তে এবং ক্লাউডে চালালে OS প্যাকেজ, ভাষার সংস্করণ ও ইনস্টল করা লাইব্রেরিগুলোর ভিন্নতা আচমকা আচরণ পরিবর্তন করে না।
সাধারণত আপনি একবার একটি ইমেজ বানান (যেমন myapp:1.8.3) এবং বিভিন্ন পরিবেশে তা থেকে অনেকগুলি কনটেইনার চালান।
একটি VM একটি সম্পূর্ণ গেস্ট অপারেটিং সিস্টেম নিয়ে আসে, তাই তা ভারী এবং সাধারণত ধীরে শুরু হয়। একটি কনটেইনার হোস্টের কার্নেল শেয়ার করে এবং শুধুমাত্র অ্যাপ ও তার লাইব্রেরিগুলো নিয়ে যায়, ফলে তা সাধারণত:
রেজিস্ট্রি হল যেখানে ইমেজগুলো সংরক্ষিত ও ভার্সন করা থাকে, যাতে অন্য মেশিনগুলো সেগুলো থেকে pull করতে পারে।
সাধারণ ওয়ার্কফ্লো:
docker build -t myapp:1.8.3 .docker push <registry>/myapp:1.8.3এর ফলে রোলব্যাক সহজ হয়: আগের ট্যাগটি পুনরায় ডেপ্লয় করুন।
প্রোডাকশনে এমন ট্যাগ ব্যবহার করুন যা অপরিবর্তনীয় ও ট্রেসযোগ্য।
প্রায়োগিক নিয়ম:
:1.8.3:<git-sha>:latest এড়িয়ে চলুন (এটি অস্পষ্ট)এটা ক্লিন রোলব্যাক ও অডিটকে সহায়তা করে।
ইমেজের বাইরে রেখে পরিবেশ-নির্ভর কনফিগারেশন রাখুন। Dockerfile-এ API কী, পাসওয়ার্ড বা ব্যক্তিগত সার্টিফিকেট কপি করবেন না।
বিকল্প:
.env ফাইল Git-এ কমিট করবেন নাএতে ইমেজগুলো পুনরায় ব্যবহারযোগ্য থাকে এবং লিক হওয়া কমে।
কনটেইনার ক্ষণস্থায়ী; তাই তাদের ফাইলসিস্টেম রিস্টার্ট বা রিপ্লেস হলে বদলে যেতে পারে।
ব্যবহার করুন:
নীতিগতভাবে: অ্যাপগুলো কনটেইনারে চালান, স্টেট পলি-বিল্ট স্টোরেজে রাখুন।
Compose লোকাল ডেভ ও এক একহোস্ট ব্যবহারের জন্য চমৎকার:
db:5432)যখন আপনি মাল্টি-সার্ভার, উচ্চ প্রাপ্যতা ও অটো-স্কেলিং চান, তখন সাধারণত একটি অর্কেস্ট্রেটর (কখনো কবারনেটিস) যোগ করা হয়।
একটি বাস্তবসম্মত পাইপলাইন: build → test → publish → deploy
“প্রোমোট, পুনরায় বিল্ড নয়” নীতি অনুসরণ করুন (dev → staging → prod) যাতে আর্টিফ্যাক্ট অপরিবর্তিত থাকে।
সাধারণ কারণগুলো:
-p 80:8080).ডিবাগ করতে, একই প্রোড ট্যাগ লোকালি চালান এবং প্রথমে কনফিগ তুলনা করুন।