অ্যাপ কীভাবে চলে

কোড শনাক্তকরণ ও বিল্ড প্রক্রিয়া#

প্রতিবার ডিপ্লয় শুরু হওয়ার সময় Meghly আপনার প্রজেক্টের ফাইলগুলো পরীক্ষা করে স্বয়ংক্রিয়ভাবে বুঝে নেয় এটি কোন ধরনের অ্যাপ্লিকেশন:

অ্যাপের ধরন ও ভার্সন অনুযায়ী Meghly নিজস্ব বিল্ড সিস্টেম ব্যবহার করে অ্যাপটি প্রস্তুত করে, তাই আলাদাভাবে কোনো Dockerfile লেখার প্রয়োজন হয় না। প্রতিটি ফ্রেমওয়ার্কের জন্য আলাদা গাইড রয়েছে: ASP.NET Core, Node.js, Python, PHP / Laravel, WordPress এবং স্ট্যাটিক সাইট।

এগুলোর বাইরে অন্য কোনো ভাষা (যেমন Go, Rust বা Java) ব্যবহার করতে চাইলে কিংবা কাস্টম বিল্ডের প্রয়োজন হলে নিজস্ব Dockerfile ব্যবহার করতে পারেন। তবে রিপোজিটরিতে শুধু Dockerfile থাকলেই তা স্বয়ংক্রিয়ভাবে চলবে না; অ্যাপ তৈরির সময় অ্যাপের ধরন (What is it?) হিসেবে Dockerfile নির্বাচন করে দিতে হবে। বিস্তারিত জানতে দেখুন নিজস্ব Dockerfile।

একটি বিল্ড সম্পন্ন হতে সর্বোচ্চ ১৫ মিনিট পর্যন্ত সময় লাগতে পারে। প্রতিটি বিল্ডের সম্পূর্ণ লগ সংশ্লিষ্ট ডিপ্লয়মেন্ট পেজে সংরক্ষিত থাকে।

পোর্ট কনফিগারেশন#

আপনার ওয়েব প্রসেসটি কোন পোর্টে চলবে, তা Meghly PORT এনভায়রনমেন্ট ভেরিয়েবলের মাধ্যমে জানিয়ে দেয় (সাধারণত 8080, অথবা Detect ধাপে যে পোর্টটি পাওয়া যায়)। আপনার অ্যাপ্লিকেশনকে অবশ্যই localhost-এর পরিবর্তে 0.0.0.0 অ্যাড্রেসে এবং নির্ধারিত পোর্টে রান করতে হবে।

const port = process.env.PORT || 8080;
app.listen(port, "0.0.0.0");

ASP.NET Core, Laravel কিংবা Django-র মতো জনপ্রিয় ফ্রেমওয়ার্কের ক্ষেত্রে Meghly নিজে থেকেই এই পোর্ট কনফিগারেশন সম্পন্ন করে, তাই আপনাকে সাধারণত কোডে বাড়তি কিছু করতে হয় না।

বাইরের ইন্টারনেট থেকে সব রিকোয়েস্ট Meghly-র নিরাপদ রাউটারের মাধ্যমে HTTPS প্রোটোকলে অ্যাপে পৌঁছায়। এছাড়া WebSocket সংযোগও (যেমন SignalR, socket.io বা Laravel Reverb) সরাসরি কাজ করে।

গেম সার্ভার, VoIP কিংবা IoT প্রজেক্টের জন্য সরাসরি আলাদা TCP/UDP পোর্টের প্রয়োজন হলে দেখুন রিয়েলটাইম ও পোর্ট।

প্রসেস পরিচিতি: web, worker ও cron#

একটি অ্যাপ্লিকেশনের অধীনে এক বা একাধিক প্রসেস থাকতে পারে এবং প্রতিটি প্রসেস আলাদা কন্টেইনারে স্বাধীনভাবে চলে:

অ্যাপের Processes পেজ থেকে নতুন প্রসেস যোগ করা, রেপ্লিকা (replica) সংখ্যা বাড়ানো বা কমানো এবং মেমোরি লিমিট পরিবর্তন করা যায়। কোনো কারণে একটি প্রসেস ক্র্যাশ করলে বা বন্ধ হয়ে গেলে সিস্টেম স্বয়ংক্রিয়ভাবে সেটিকে পুনরায় চালু করে।

Procfile-এর ব্যবহার#

Heroku, Render বা Railway-এর মতোই আপনার রিপোজিটরির রুট ফোল্ডারে Procfile থাকলে Meghly সেখান থেকে প্রসেসের নির্দেশনা পড়ে নেয়:

web: node server.js
worker: node jobs/worker.js
release: npx prisma migrate deploy

• web: — মূল ওয়েব প্রসেস চালানোর কমান্ড।
• release: — প্রতিটি ডিপ্লয়ের ঠিক আগে একবার রান করার কমান্ড (নিচে বিস্তারিত দেখুন)।
• অন্য যেকোনো নাম — আলাদা ব্যাকগ্রাউন্ড worker প্রসেস হিসেবে গণ্য হয়।

প্রতিটি কমান্ড sh -c-এর মাধ্যমে রান হয়, ফলে $PORT ভেরিয়েবল বা && অপারেটর স্বাভাবিক নিয়মেই কাজ করে। একটি অ্যাপে সর্বোচ্চ ১০টি প্রসেস চালানো যাবে।

ফাইল সংরক্ষণ ও স্টোরেজ#

নিরাপত্তার স্বার্থে প্রতিটি কন্টেইনারের মূল ফাইল সিস্টেম শুধু পড়ার যোগ্য (read-only) হিসেবে থাকে। তবে আপনার অ্যাপ নিচের দুটি স্থানে ফাইল রাইট বা সংরক্ষণ করতে পারবে:

• /tmp ফোল্ডারে — এটি অস্থায়ী স্টোরেজ; অ্যাপ রিস্টার্ট হলে এর ভেতরের ফাইল মুছে যায়।
• Volume-এ — অ্যাপের Files & backups পেজ থেকে স্থায়ী ভলিউম (যেমন /app/storage) যুক্ত করা যায়। ইউজারদের আপলোড করা ফাইল, ছবি বা সিকিউরিটি কি—যেগুলো রিস্টার্ট বা নতুন ডিপ্লয়ের পরেও অক্ষত থাকা জরুরি—সেগুলো এই ভলিউমে সংরক্ষণ করুন।

ডাউনটাইম ছাড়াই ডিপ্লয়মেন্ট#

1. নতুন ভার্সনের কন্টেইনারটি পুরনো ভার্সনের পাশাপাশি চালু হয়।
2. এরপর Meghly নতুন ভার্সনের হেলথ চেক (Health check) সম্পন্ন করে: GET / (অথবা আপনার নির্ধারিত Health check path) থেকে 2xx বা 3xx রেসপন্স এলে হেলথ চেক সফল বলে ধরে নেওয়া হয়।
3. হেলথ চেক সফল হলেই কেবল ভিজিটর ট্রাফিক নতুন ভার্সনে স্থানান্তরিত হয় এবং এরপর পুরনো কন্টেইনারটি বন্ধ করা হয়।

কোনো কারণে হেলথ চেক ব্যর্থ হলে ডিপ্লয়মেন্টটি স্থগিত হয়ে যায় এবং পুরনো ভার্সনটিই নিরবচ্ছিন্নভাবে চলতে থাকে। ডিপ্লয় ব্যর্থ হলে ডিপ্লয়মেন্ট পেজে অ্যাপের সর্বশেষ লগ দেখে সমস্যার কারণ জানা যায়।

রিলিজ ধাপ ও ডেটাবেস মাইগ্রেশন#

প্রতিটি ডিপ্লয়ে নতুন ভার্সনে ট্রাফিক পাঠানোর আগে আলাদা একটি কন্টেইনারে রিলিজ কমান্ড ও ডেটাবেস মাইগ্রেশন একবার রান হয়। মাইগ্রেশন ব্যর্থ হলে ডিপ্লয় প্রক্রিয়া সেখানেই থেমে যায় এবং পুরনো ভার্সনটি সচল থাকে।

• Laravel (php artisan migrate), Django, Prisma এবং Alembic-এর মাইগ্রেশন কমান্ড Meghly স্বয়ংক্রিয়ভাবে শনাক্ত করে।
• অন্য কোনো ফ্রেমওয়ার্ক বা টুল ব্যবহার করলে অ্যাপের General → Release command সেকশনে আপনার নিজস্ব কমান্ডটি লিখে দিন, অথবা Procfile-এ release: লাইনটি যুক্ত করুন।

রিলিজ ধাপটি ডেটাবেসের migration login ব্যবহার করে, যার টেবিল তৈরি বা স্কিমা পরিবর্তন করার অনুমতি রয়েছে। অন্যদিকে মূল চলমান অ্যাপটি পায় runtime login, যা কেবল ডেটা পড়া ও লেখার কাজ করতে পারে কিন্তু টেবিলের গঠন পরিবর্তন করতে পারে না। এজন্য অ্যাপ স্টার্টআপের সময় কোডের ভেতরে Database.Migrate() বা EnsureCreated() চালালে তা কাজ করবে না; এই কাজটি রিলিজ ধাপেই সম্পন্ন করতে হবে।

রোলব্যাক (পূর্বের ভার্সনে ফিরে যাওয়া)#

Deployments পেজ থেকে মাত্র এক ক্লিকেই আগের যেকোনো সফল ডিপ্লয়মেন্টে ফিরে যাওয়া যায়। রোলব্যাক করলে ওই সময়ের কন্টেইনার ইমেজ ও এনভায়রনমেন্ট ভেরিয়েবলগুলো হুবহু পুনরুদ্ধার হয়।

অ্যাপ থেকে ইমেইল পাঠানো#

স্প্যাম প্রতিরোধের জন্য কন্টেইনার থেকে সরাসরি পোর্ট 25 ব্যবহার করে বাইরে মেইল পাঠানো বন্ধ রাখা হয়েছে। অ্যাপ থেকে ইমেইল পাঠাতে হলে SMTP সাবমিশন পোর্ট (587) ব্যবহার করে আপনার নিজস্ব Meghly মেইলবক্স অথবা অন্য যেকোনো মেইল সার্ভিস যুক্ত করুন।

রিসোর্স ও সীমা#

আপনার নির্বাচিত প্ল্যানের মোট RAM, CPU এবং ডিস্ক স্পেস আপনার অ্যাকাউন্টের সব অ্যাপ মিলে ব্যবহার করে। কোনো প্রসেস তার নির্ধারিত মেমোরি সীমা অতিক্রম করলে সেটি বন্ধ হয়ে স্বয়ংক্রিয়ভাবে পুনরায় চালু হয়, আর ডিস্ক পূর্ণ হয়ে গেলে নতুন ফাইল লেখা বন্ধ হয়ে যায়। অ্যাপের Usage পেজে রিসোর্স ব্যবহারের হিসাব এবং Logs পেজে অ্যাপের রিয়েলটাইম লগ দেখতে পাবেন।