0
সার্ভারে প্রবেশ — VPS ও AWS উভয়
প্রোভাইডার প্যানেল থেকে IP ও লগইন পদ্ধতি বুঝে প্রথম SSH। AWS হলে `.pem` যে ফোল্ডারে আছে সেখানে `cd`, `chmod 400`, তারপর `ssh -i`। ডোমেন কিনে DNS এ ভিপিএস IP পয়েন্ট করা (Namecheap, GoDaddy)।
প্রয়োজনীয় এই সেকশনের গুরুত্ব
না করলে সাধারণত সার্ভারে অ্যাপ চালু, প্রবেশ বা কানেকশন পুরোপুরি হয় না — বা গুরুতর ত্রুটি থেকে যায়। করলে স্ট্যাক কাজ করে।
কেন দরকার ও কেন এভাবে
গাইডের বাকি অংশ SSH দিয়ে সার্ভারে ঢুকে কমান্ড চালানো ধরে নেয়। নতুনরা প্রায়ই “কোথায় লগইন?” এ আটকে — প্রোভাইডার ভিন্ন হলে ধাপ ভিন্ন (ইমেইলে রুট পাসওয়ার্ড vs শুধু SSH কী, AWS তে সিকিউরিটি গ্রুপে ২২ খোলা)।
উদাহরণ: DigitalOcean ড্রপলেট তৈরি করলে ইমেইলে IP ও রুট পাসওয়ার্ড; AWS EC2 তে কী পেয়ার বেছে নিয়ে ইন্সট্যান্স স্টার্ট, তারপর “Connect” থেকে SSH কমান্ড কপি।
0.1 জেনেরিক VPS (DigitalOcean, Hetzner, Linode, Vultr…)কেন এই ধাপ
একই আইডিয়া: কন্ট্রোল প্যানেলে ইন্সট্যান্স → পাবলিক IPv4 → SSH পোর্ট ২২ খোলা।
প্রোভাইডার অ্যাকাউন্টে লগইন করে “Droplet / Server / Instance” তৈরি করুন (Ubuntu LTS বেছে নিন)। তালিকায় পাবলিক IPv4 নোট করুন। কিছু প্রোভাইডার প্রথম লগইনের রুট পাসওয়ার্ড ইমেইল করে; কেউ কেউ শুধু SSH কী। নিজের মেশিনে টার্মিনাল খুলে `ssh root@আপনার_IP` বা প্রোভাইডারের দেওয়া কমান্ড চালান। ভুল IP বা ফায়ারওয়ালে ২২ বন্ধ থাকলে “Connection timed out” দেখতে পারেন। কপি 1 # typical first login (password auth, if provider emailed root password)
2 ssh root@YOUR_SERVER_IP
3
4 # if you already added a deploy user + key on the server
5 ssh deploy@YOUR_SERVER_IP
0.2 AWS EC2কেন এই ধাপ
AWS তে সিকিউরিটি গ্রুপ, কী পেয়ার ও ইউজারনেম (ubuntu, ec2-user ইত্যাদি) আলাদা নিয়ম।
কনসোলে EC2 → Instances → Launch। AMI তে Ubuntu নিলে ডিফল্ট ইউজার সাধারণত ubuntu; Amazon Linux এ ec2-user।
লঞ্চের সময় বা পরে কী পেয়ার (.pem) ডাউনলোড করুন — AWS আবার দেখাবে না। ফাইল যে ফোল্ডারে আছে সেখানে টার্মিনাল খুলুন (বা `cd` দিয়ে সেই ডিরেক্টরিতে যান), তারপর `chmod 400` ও `ssh -i` চালান।
ইন্সট্যান্সের Security Group ইনবাউন্ডে TCP ২২ আপনার IP (বা অস্থায়ীভাবে 0.0.0.0/0 — কম সুপারিশ) খুলুন, নাহলে SSH যাবে না।
হোস্ট হিসেবে কনসোলে দেখানো পাবলিক IPv4 অথবা AWS এর public DNS (`ec2-….compute.amazonaws.com` ধরনের) ব্যবহার করুন — নিজের ইন্সট্যান্সের মান বসাবেন। “Connect” ট্যাবে প্রায়ই উদাহরণ কমান্ড থাকে।
কপি 1 cd ~/Downloads
2 # cd "C:\Users\You\Downloads"
3
4 chmod 400 "./YOUR_KEY.pem"
5
6 # Ubuntu AMI — ubuntu@ (Amazon Linux — ec2-user@)
7 ssh -i "./YOUR_KEY.pem" ubuntu@YOUR_PUBLIC_DNS_OR_IP
8
9 # ssh -i "./YOUR_KEY.pem" ubuntu@ec2-00-00-00-00.us-east-1.compute.amazonaws.com
10 # ssh -i "./YOUR_KEY.pem" ubuntu@203.0.113.10
স্পেস থাকা ফোল্ডারে থাকলে কীর পাথ কোটে রাখুন। `-i` এর পরে যে ফাইল দিচ্ছেন সেটাই প্রাইভেট কী — কখনো GitHub, চ্যাট বা স্ক্রিনশটে শেয়ার করবেন না।
ইন্সট্যান্স সিলেক্ট → Connect → EC2 Instance Connect দিয়ে ব্রাউজারে সেশন খুলতে পারেন (কী ছাড়াই), অথবা SSH ক্লায়েন্ট ট্যাবে কমান্ড কপি করুন।
1
প্রাথমিক সার্ভার সেটআপ ও সিকিউরিটি উভয়
সোয়াপ, আপডেট, ডিপ্লয় ইউজার, SSH কী, ফায়ারওয়াল ও Fail2ban — সব আকারের অ্যাপের জন্য। ২FA ও CrowdSec ছোট/মাঝারি সেটআপে ঐচ্ছিক।
সুপারিশিত এই সেকশনের গুরুত্ব
না করলেও অনেক সময় মৌলিক কাজ চলতে পারে (যেমন রুট দিয়ে SSH, IP:পোর্টে অ্যাপ); করলে নিরাপত্তা, স্থায়িত্ব ও দলের কাজের ধরন ভালো হয়।
কেন দরকার ও কেন এভাবে
ধরুন আপনি একটি ছোট ভিপিএসে প্রথমবার সার্ভার চালু করছেন। ইন্টারনেটে প্রতিটি সার্ভিস (SSH সহ) বট ও ব্রুটফোর্সের সামনে খোলা থাকে। তাই আগে সোয়াপ ও আপডেট দিয়ে স্টেবিল বেস, তারপর নন-রুট ডিপ্লয় ইউজার ও কী-বেস SSH দিয়ে লগইন সুরক্ষিত করাই স্ট্যান্ডার্ড।
উদাহরণ: রুটে Node চালালে একটা RCE বাগ পুরো সার্ভার কম্প্রোমাইজ করতে পারে; ডিপ্লয় ইউজার + UFW দিয়ে ব্লাস্ট রেডিয়াস ছোট হয়।
1.1 সোয়াপ মেমোরিকেন এই ধাপ
RAM কম থাকলে লিনাক্স OOM কিলার অ্যাপ বন্ধ করে দেয়; সোয়াপ অস্থায়ী মেমোরি বাড়িয়ে ছোট স্পাইক সহনীয় করে।
সোয়াপ = ডিস্কের একটু জায়গা র্যামের মতো ব্যবহার করা (ধীর, কিন্তু OOM এড়ায়)। উদাহরণ: ১ GB RAM ড্রপলেটে `npm run build` + API একসাথে চললে RAM ফুল হয়ে লিনাক্স প্রসেস কিল করতে পারে; ২ GB সোয়াপ থাকলে অনেক সময় বেঁচে যায়।
ঐচ্ছিক কিন্তু: ৪ GB+ RAM আর হালকা ট্রাফিকে অনেকে সোয়াপ ছাড়াই চালায় — তবে স্পাইকে OOM ঝুঁকি থাকতে পারে।
কপি 1 sudo fallocate -l 2G /swapfile
2 sudo chmod 600 /swapfile
3 sudo mkswap /swapfile
4 sudo swapon /swapfile
5 echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
1.2 সিস্টেম আপডেটকেন এই ধাপ
পুরনো কার্নেল/লাইব্রেরিতে নোন্নতম সিকিউরিটি প্যাচ থাকে না; আপডেট দিয়ে SSH ও সিস্টেম লাইব্রেরি নিরাপদ রাখা হয়।
কপি 1 sudo apt update && sudo apt -y upgrade
2 sudo apt -y install curl git ufw fail2ban unattended-upgrades
1.3 ডিপ্লয় ইউজার ও SSH কীকেন এই ধাপ
রুট দিয়ে ডেপ্লয় মানে একটা বাগেই পুরো সার্ভার ঝুঁকি; আলাদা ইউজার ও SSH কী পাসওয়ার্ড ব্রুটফোর্স কমায়।
ডিপ্লয় ইউজার = অ্যাপ ও ডেপ্লয় স্ক্রিপ্ট চালানোর আলাদা লিনাক্স অ্যাকাউন্ট (রুট নয়)। SSH কী জোড়া = ল্যাপটপে গোপন কী + সার্ভারে পাবলিক কী `authorized_keys` এ। উদাহরণ: একই `ssh-keygen` এর `.pub` GitHub এ ও সার্ভারের `deploy` ইউজারে লাগানো যায়।
হ্যাঁ, টেকনিক্যালি চলতে পারে — কিন্তু একটা নোড বাগ বা লিক হলে পুরো সার্ভার কম্প্রোমাইজের ঝুঁকি। প্রোডে নন-রুট + কী-অনলি SSH স্ট্যান্ডার্ড।
কপি 1 sudo adduser deploy
2 sudo usermod -aG sudo deploy
3 sudo rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy
কপি 1 # on your laptop
2 ssh-keygen -t ed25519 -C "deploy@yourdomain"
কপি 1 # append public key on server
2 sudo mkdir -p /home/deploy/.ssh
3 echo "YOUR_PUBLIC_KEY" | sudo tee -a /home/deploy/.ssh/authorized_keys
4 sudo chown -R deploy:deploy /home/deploy/.ssh
5 sudo chmod 700 /home/deploy/.ssh
6 sudo chmod 600 /home/deploy/.ssh/authorized_keys
/etc/ssh/sshd_config কপি 1 # recommended flags (merge carefully)
2 PermitRootLogin no
3 PasswordAuthentication no
4 KbdInteractiveAuthentication no
5 ChallengeResponseAuthentication no
6 AllowUsers deploy
1.4 SSH টু-ফ্যাক্টর (PAM) (ঐচ্ছিক)কেন এই ধাপ
কী লিক হলেও দ্বিতীয় ফ্যাক্টর ছাড়া লগইন কঠিন; উচ্চ-রিস্ক বা কমপ্লায়েন্সে সুপারিশ।
কপি 1 # 1) install tools
2 sudo apt -y install libpam-google-authenticator qrencode
3
4 # 2) as deploy user
5 google-authenticator -t -d -f -r 3 -R 30 -W
6
7 # 3) edit PAM for sshd
8 echo "auth required pam_google_authenticator.so" | sudo tee -a /etc/pam.d/sshd
9
10 # 4) sshd_config — enable challenge-response + require MFA after pubkey
11 sudo nano /etc/ssh/sshd_config
12 # set: ChallengeResponseAuthentication yes
13 # append: AuthenticationMethods publickey,keyboard-interactive
14
15 # 5) keep sudo session safe (optional)
16 echo "auth required pam_google_authenticator.so" | sudo tee -a /etc/pam.d/sudo
17
18 # 6) reload
19 sudo systemctl reload ssh
20
21 # 7) TEST in a second session before closing the first
22
23 # 8) emergency: recovery console / IPMI if locked out
24
25 # 9) backup secret codes offline
26
27 # 10) rotate codes periodically
1.5 ফায়ারওয়াল (UFW)কেন এই ধাপ
শুধু ২২/৮০/৪৪৩ খোলা রাখলে অপ্রয়োজনীয় পোর্ট বন্ধ থাকে; বট স্ক্যান করে যা পায় তা আক্রমণ করতে পারে না।
কপি 1 sudo ufw default deny incoming
2 sudo ufw default allow outgoing
3 sudo ufw allow OpenSSH
4 sudo ufw allow 80/tcp
5 sudo ufw allow 443/tcp
6 sudo ufw enable
7 sudo ufw status verbose
1.6 Fail2Banকেন এই ধাপ
বারবার ভুল পাসওয়ার্ড/SSH চেষ্টা আইপি ব্যান করে ব্রুটফোর্স ধীর করে; ফায়ারওয়াল একা প্যাটার্ন বুঝতে পারে না।
Fail2ban = লগ দেখে বারবার ব্যর্থ লগইন করা IP অস্থায়ী ব্যান। উদাহরণ: কেউ সেকেন্ডে ২০ বার ভুল পাসওয়ার্ড দিলে ১ ঘণ্টার জন্য ব্লক। SSH শুধু কী দিয়ে হলে ব্রুটফোর্স কম তবু লগ নজরদারি সুবিধা থাকে।
কী-অনলি SSH আর UFW ঠিক থাকলে অনেক ছোট সেটআপে Fail2ban ছাড়াও চলে — তবে পাসওয়ার্ড SSH খোলা থাকলে সুপারিশ।
/etc/fail2ban/jail.local কপি 1 [DEFAULT]
2 bantime = 1h
3 findtime = 10m
4 maxretry = 5
5
6 [sshd]
7 enabled = true
8 port = ssh
9 logpath = %(sshd_log)s
10 backend = systemd
কপি 1 sudo systemctl enable --now fail2ban
2 sudo fail2ban-client status sshd
1.7 CrowdSec (ঐচ্ছিক)কেন এই ধাপ
কমিউনিটি সিগন্যাল শেয়ার করে নতুন আক্রমণ প্যাটার্ন দ্রুত ব্লক করা যায়; Fail2Ban-এর বাইরে আরেক স্তর।
কপি 1 curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
2 sudo apt install crowdsec
3 sudo cscli hub update
4 sudo cscli collections install crowdsecurity/linux crowdsecurity/sshd
5 sudo systemctl enable --now crowdsec
2
ডাটাবেজ সেটআপ উভয়
MongoDB, PostgreSQL+PgBouncer, Redis — ম্যানুয়াল বা ডকার পথে।
প্রয়োজনীয় এই সেকশনের গুরুত্ব
না করলে সাধারণত সার্ভারে অ্যাপ চালু, প্রবেশ বা কানেকশন পুরোপুরি হয় না — বা গুরুতর ত্রুটি থেকে যায়। করলে স্ট্যাক কাজ করে।
কেন দরকার ও কেন এভাবে
অ্যাপের ডাটা যেখানে জমা হয় সেটাই সবচেয়ে মূল্যবান অংশ। ভুল ডিবি সেটআপ মানে স্লো কোয়েরি, ডাটা লস, বা লিক। ম্যানুয়াল পথে আপনি হোস্টে সরাসরি কন্ট্রোল; ডকার পথে একই ভার্সন ডেভ ও প্রোডে চালানো সহজ।
উদাহরণ: ইউজার ডাটা Mongo তে থাকলে বাইন্ড 127.0.0.1 + অথ বন্ধ করে শুধু অ্যাপকে ভিতরে অ্যাক্সেস দিন — বাইরে থেকে ডাটাবেজ পোর্ট খোলা রাখবেন না।
2A MongoDB (ম্যানুয়াল)কেন এই ধাপ
ডকুমেন্ট-স্টোর ডাটার জন্য Mongo সাধারণ; হোস্টে ইনস্টল করলে পারফরম্যান্স টিউন ও লগ সরাসরি হাতের নাগালে।
কপি 1 wget -qO - https://www.mongodb.org/static/pgp/server-7.0.asc | sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-7.0.gpg
2 echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
3 sudo apt update && sudo apt -y install mongodb-org
/etc/mongod.conf কপি 1 storage:
2 dbPath: /var/lib/mongodb
3 systemLog:
4 destination: file
5 path: /var/log/mongodb/mongod.log
6 net:
7 port: 27017
8 bindIp: 127.0.0.1
9 security:
10 authorization: enabled
কপি 1 sudo systemctl enable --now mongod
কপি 1 mongosh <<'EOF'
2 use admin
3 db.createUser({ user: "admin", pwd: "STRONG_PASSWORD", roles: ["root"] })
4 use appdb
5 db.createUser({ user: "app", pwd: "STRONG_PASSWORD", roles: ["readWrite"] })
6 EOF
2C PostgreSQL + PgBouncer (ম্যানুয়াল) (ঐচ্ছিক)কেন এই ধাপ
অনেক ছোট কানেকশন খুলে রাখা Postgresের জন্য ব্যয়বহুল; PgBouncer পুল করে ট্রানজ্যাকশন মোডে চাপ কমায়।
কপি 1 sudo apt -y install postgresql postgresql-contrib pgbouncer
/etc/pgbouncer/pgbouncer.ini কপি 1 [databases]
2 app = host=127.0.0.1 port=5432 dbname=app
3
4 [pgbouncer]
5 listen_addr = 127.0.0.1
6 listen_port = 6432
7 auth_type = scram-sha-256
8 auth_file = /etc/pgbouncer/userlist.txt
9 pool_mode = transaction
10 max_client_conn = 200
11 default_pool_size = 20
/etc/pgbouncer/userlist.txt কপি 1 "appuser" "SCRAM_HASH_FROM_postgres"
2E Redis (ম্যানুয়াল)কেন এই ধাপ
সেশন, রেট লিমিট, ক্যাশ, কিউ — দ্রুত ইন-মেমোরি স্টোর দরকার হলে Redis; লোকালহোস্ট বাইন্ড ও পাসওয়ার্ড বাধ্যতামূলক।
কপি 1 sudo apt -y install redis-server
/etc/redis/redis.conf কপি 1 bind 127.0.0.1
2 protected-mode yes
3 requirepass STRONG_REDIS_PASSWORD
4 maxmemory 256mb
5 maxmemory-policy allkeys-lru
3
অ্যাপ্লিকেশন ডেপ্লয়মেন্ট উভয়
Node.js + PM2 বা tmux (ম্যানুয়াল পথে বিকল্প) অথবা ডকার ইমেজ ও কম্পোজ — যেটা পছন্দ সেটা বেছে নিন।
প্রয়োজনীয় এই সেকশনের গুরুত্ব
না করলে সাধারণত সার্ভারে অ্যাপ চালু, প্রবেশ বা কানেকশন পুরোপুরি হয় না — বা গুরুতর ত্রুটি থেকে যায়। করলে স্ট্যাক কাজ করে।
কেন দরকার ও কেন এভাবে
এখানে আসল কাজ: আপনার Node বিল্ডকে প্রোডাকশনে চালু করা এবং ক্র্যাশ হলে আবার উঠানো। PM2 দিয়ে ক্লাস্টার/রিস্টার্ট সহজ; tmux দিয়ে প্রসেস ম্যানেজার ছাড়াই সেশন ডিট্যাচ করে চালানো যায়; ডকার দিয়ে ইমেজে প্যাক করে একই কমান্ডে রোল আউট।
উদাহরণ: ট্রাফিক বাড়লে PM2-তে instances: "max" দিয়ে CPU কোর ব্যবহার করতে পারেন; ডকারে একই অ্যাপের নতুন ট্যাগ পুল করে zero-downtime ধরনের আপডেট সাজানো যায়।
3A Node.js + PM2 (ম্যানুয়াল)কেন এই ধাপ
NVM দিয়ে নোড ভার্সন পিন, PM2 দিয়ে প্রসেস রিস্টার্ট/ক্লাস্টার — সরাসরি সার্ভারে দ্রুত ইটারেশনের জন্য।
এই উপসেকশন এড়িয়ে যান — ডকার ইমেজ ও কম্পোজ দিয়ে ডেপ্লয় করুন।
কপি 1 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
2 source ~/.nvm/nvm.sh
3 nvm install --lts
4 node -v
কপি 1 ssh-keygen -t ed25519 -C "deploy-key" -f ~/.ssh/deploy_ed25519 -N ""
2 cat ~/.ssh/deploy_ed25519.pub
3 # add read-only deploy key in Git provider
কপি 1 sudo mkdir -p /var/www && sudo chown deploy:deploy /var/www
2 cd /var/www
3 git clone git@github.com:org/backend.git
4 git clone git@github.com:org/frontend.git
5 git clone git@github.com:org/dashboard.git
/var/www/backend/ecosystem.config.js কপি 1 module.exports = {
2 apps: [{
3 name: "api",
4 cwd: "/var/www/backend",
5 script: "dist/main.js",
6 instances: "max",
7 exec_mode: "cluster",
8 env: { NODE_ENV: "production" }
9 }]
10 };
/var/www/frontend/ecosystem.config.js কপি 1 module.exports = {
2 apps: [{
3 name: "web",
4 cwd: "/var/www/frontend",
5 script: "node_modules/next/dist/bin/next",
6 args: "start -p 3000",
7 env: { NODE_ENV: "production" }
8 }]
9 };
/var/www/dashboard/ecosystem.config.js কপি 1 module.exports = {
2 apps: [{
3 name: "dash",
4 cwd: "/var/www/dashboard",
5 script: "dist/server.js",
6 env: { NODE_ENV: "production" }
7 }]
8 };
কপি 1 npm i -g pm2
2 cd /var/www/backend && npm ci && npm run build
3 cd /var/www/frontend && npm ci && npm run build
4 cd /var/www/dashboard && npm ci && npm run build
5 pm2 start /var/www/backend/ecosystem.config.js
6 pm2 start /var/www/frontend/ecosystem.config.js
7 pm2 start /var/www/dashboard/ecosystem.config.js
8 pm2 save
9 pm2 startup systemd -u deploy --hp /home/deploy
3C tmux — PM2 ছাড়াই প্রসেস চালু রাখাকেন এই ধাপ
PM2 ছাড়াই SSH সেশন ডিট্যাচ করে নোড/স্ক্রিপ্ট চালু রাখা যায়; ছোট সার্ভার বা পছন্দে বৈধ বিকল্প।
এই উপসেকশন এড়িয়ে যান — ডকারে কন্টেইনারের restart পলিসি দিয়ে প্রসেস ম্যানেজ করুন।
PM2: ক্র্যাশে রিস্টার্ট, ক্লাস্টার, লগ রোটেশন, বুট স্টার্টআপ — প্রোড Node-এর জন্য সুবিধাজনক। tmux: হালকা, শুধু টার্মিনাল সেশন ডিট্যাচ; রিস্টার্ট/মেট্রিক্স নিজে দেখতে হবে। দুটোই একসাথে লাগবে না — একটি বেছে নিন।
ইনস্টল: `sudo apt install -y tmux`। নতুন সেশন: `tmux new -s app`। ভেতরে অ্যাপ চালান (`node dist/main.js` বা `npm run start`)। কীবোর্ড থেকে ডিট্যাচ: Ctrl+b তারপর d। আবার ঢুকুন: `tmux attach -t app`। সেশন তালিকা: `tmux ls`।
কপি 1 sudo apt update && sudo apt install -y tmux
2 tmux new -s api
3 # inside tmux: cd /var/www/backend && node dist/main.js
4 # detach: Ctrl+b then d
5 tmux attach -t api
6 tmux ls
সার্ভার রিবুট হলে tmux সেশন মুছে যায় — তখন systemd ইউনিট বা @reboot ক্রন দিয়ে আবার চালু করার পরিকল্পনা রাখুন, অথবা PM2 ব্যবহার করুন।
4
এনভায়রনমেন্ট ভেরিয়েবল উভয়
ম্যানুয়ালে .env ফাইল; ডকারে কম্পোজ env_file বা সিক্রেট। ফাইল প্যাটার্ন দেখানো হয়েছে; সঠিক ভেরিয়েবল মান ছাড়া অ্যাপ ডাটাবেজ বা রেডিসে যোগ দিতে পারবে না।
প্রয়োজনীয় এই সেকশনের গুরুত্ব
না করলে সাধারণত সার্ভারে অ্যাপ চালু, প্রবেশ বা কানেকশন পুরোপুরি হয় না — বা গুরুতর ত্রুটি থেকে যায়। করলে স্ট্যাক কাজ করে।
কেন দরকার ও কেন এভাবে
সিক্রেট (API কী, DB পাসওয়ার্ড) কোডে হার্ডকোড করা মানে একবার লিক হলে সব পরিবেশ কম্প্রোমাইজ। .env বা কম্পোজ সিক্রেট দিয়ে কনফিগ আলাদা রাখা হয়।
উদাহরণ: ম্যানুয়ালে DATABASE_URL=127.0.0.1:5432 ঠিক আছে; ডকারে একই ভেরিয়েবল postgres:5432 (সার্ভিস নাম) হতে পারে — কপি-পেস্ট করলে কানেকশন ফেল করবে, তাই পথ অনুযায়ী আলাদা ফাইল রাখুন।
4A ম্যানুয়াল .envকেন এই ধাপ
অ্যাপ ডিরেক্টরিতে .env রেখে পোর্ট ও DB URI হোস্ট লোকালহোস্টে সেট করুন — PM2/Node সরাসরি পড়ে।
‘.env’ = কনফিগ, খালি রাখা যায় না
ফাইল নাম `.env` হোক বা অন্য — ভেরিয়েবলের মান সঠিক হতে হবে। উদাহরণ: `DATABASE_URL` এ ভুল হোস্ট দিলে `ECONNREFUSED` বা ORM এর “Can't reach database server”। ডকারে হোস্ট `postgres` (সার্ভিস নাম), ম্যানুয়ালে `127.0.0.1`।
/var/www/backend/.env কপি 1 NODE_ENV=production
2 PORT=4000
3 DATABASE_URL=mongodb://app:password@127.0.0.1:27017/appdb
4 REDIS_URL=redis://:password@127.0.0.1:6379
4C পার্থক্য ও সতর্কতাকেন এই ধাপ
দুই পথের কনফিগ এক রকম দেখালেও নেটওয়ার্ক নাম আলাদা — এখানে ভুল বুঝলে প্রোডে কানেকশন ফেল।
ডকারে সার্ভিস হোস্টনেম কন্টেইনার নাম হয় (যেমন postgres)। ম্যানুয়ালে 127.0.0.1। একই DATABASE_URL দুই পথে কাজ নাও করতে পারে।
6
Nginx — রিভার্স প্রক্সি উভয়
ইনস্টল, শেয়ার্ড proxy_params, API/ফ্রন্ট/ড্যাশবোর্ড সাইট, সাইট সক্রিয়করণ।
সুপারিশিত এই সেকশনের গুরুত্ব
না করলেও অনেক সময় মৌলিক কাজ চলতে পারে (যেমন রুট দিয়ে SSH, IP:পোর্টে অ্যাপ); করলে নিরাপত্তা, স্থায়িত্ব ও দলের কাজের ধরন ভালো হয়।
কেন দরকার ও কেন এভাবে
ব্রাউজার শুধু ৮০/৪৪৩ দেখে; আপনার Node অ্যাপ আলাদা পোর্টে চলে। Nginx রিভার্স প্রক্সি দিয়ে ডোমেইন → লোকাল পোর্ট ব্রিজ করেন, SSL এক জায়গায় টার্মিনেট করতে পারেন।
উদাহরণ: api.example.com → 127.0.0.1:4000, ওয়েব example.com → 3000 — এক সার্ভারে একাধিক অ্যাপ একই আইপিতে।
6.1 Nginx ইনস্টলকেন এই ধাপ
রিভার্স প্রক্সি ও স্ট্যাটিক ফাইল সার্ভ করার জন্য Nginx স্ট্যান্ডার্ড; সিস্টেম সার্ভিস হিসেবে সহজে রিলোড।
কপি 1 sudo apt -y install nginx
2 sudo systemctl enable --now nginx
6.2 proxy_params শেয়ার্ড ফাইলকেন এই ধাপ
হেডার ও আপগ্রেড ম্যাপ এক জায়গায় রাখলে তিনটি সাইট ব্লকে কপি-পেস্ট কমে, ভুলও কমে।
না — সংগঠনের জন্য। একই `proxy_set_header` লাইনগুলো প্রতিটি `server { }` ব্লকের ভিতরে সরাসরি লিখলেও Nginx চলবে। শেয়ার্ড ফাইল থাকলে তিনটা সাইটে এক জায়গায় এডিট, কপি-পেস্ট ভুল কমে।
/etc/nginx/proxy_params কপি 1 proxy_http_version 1.1;
2 proxy_set_header Host $host;
3 proxy_set_header X-Real-IP $remote_addr;
4 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
5 proxy_set_header X-Forwarded-Proto $scheme;
6 proxy_set_header Upgrade $http_upgrade;
7 proxy_set_header Connection $connection_upgrade;
$connection_upgrade — map block আলাদা ফাইলে রাখুন
proxy_params-এ `Connection $connection_upgrade` ব্যবহার হয়েছে। এই variable-টি nginx-এর `http {}` context-এ `map` directive ছাড়া কাজ করে না। map block একাধিক site config-এ রাখলে nginx duplicate variable error দেয় — তাই `/etc/nginx/conf.d/upgrade-map.conf`-এ একবার রাখুন।
/etc/nginx/conf.d/upgrade-map.conf কপি 1 map $http_upgrade $connection_upgrade {
2 default upgrade;
3 '' close;
4 }
কপি 1 sudo nginx -t && sudo systemctl reload nginx
6.3 Backend API সাইটকেন এই ধাপ
API আলাদা হোস্টনেমে রাখলে কুকি, রেট লিমিট ও সার্ট আলাদা নিয়ন্ত্রণ করা সহজ।
WebSocket upgrade-এর জন্য `map` directive section 6.2-এ `/etc/nginx/conf.d/upgrade-map.conf`-এ রাখা হয়েছে। সেটি আগে তৈরি করে নিন।
/etc/nginx/sites-available/api.yourdomain.com কপি 1 server {
2 listen 80;
3 server_name api.yourdomain.com;
4
5 location / {
6 include proxy_params;
7 proxy_pass http://127.0.0.1:4000;
8 }
9 }
6.4 ফ্রন্টএন্ড সাইটকেন এই ধাপ
ইউজার-ফেসিং অ্যাপ সাধারণত মেইন ডোমেইনে; এখানে Next/SPA আপস্ট্রিম পাস করা হয়।
/etc/nginx/sites-available/yourdomain.com কপি 1 server {
2 listen 80;
3 server_name yourdomain.com www.yourdomain.com;
4
5 location / {
6 include proxy_params;
7 proxy_pass http://127.0.0.1:3000;
8 }
9 }
6.5 ড্যাশবোর্ড সাইটকেন এই ধাপ
অ্যাডমিন/অ্যানালিটিক্স আলাদা সাবডোমেইনে রাখলে অ্যাক্সেস নিয়ন্ত্রণ ও ক্যাশ রুল আলাদা করা যায়।
/etc/nginx/sites-available/dashboard.yourdomain.com কপি 1 server {
2 listen 80;
3 server_name dashboard.yourdomain.com;
4
5 location / {
6 include proxy_params;
7 proxy_pass http://127.0.0.1:4100;
8 }
9 }
6.6 সাইট সক্রিয়করণকেন এই ধাপ
sites-available থেকে sites-enabled সিমলিংক দিয়ে সাইট চালু; nginx -t দিয়ে সিনট্যাক্স চেক করুন।
কপি 1 sudo ln -s /etc/nginx/sites-available/api.yourdomain.com /etc/nginx/sites-enabled/
2 sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
3 sudo ln -s /etc/nginx/sites-available/dashboard.yourdomain.com /etc/nginx/sites-enabled/
4 sudo nginx -t && sudo systemctl reload nginx
6.7 SSL সার্টিফিকেট — Certbot (Required)কেন এই ধাপ
প্রোডাকশন অ্যাপে HTTPS বাধ্যতামূলক; Certbot বিনামূল্যে Let's Encrypt সার্ট দেয় এবং Nginx কনফিগ স্বয়ংক্রিয় আপডেট করে।
DNS ও Nginx আগে সেটআপ থাকতে হবে
Certbot চালানোর আগে ডোমেইনের DNS A record আপনার সার্ভার IP-তে পয়েন্ট করা এবং Nginx-এ সেই `server_name` কনফিগ করা থাকতে হবে। DNS propagate না হলে ACME challenge fail করবে।
কপি 1 sudo apt -y install certbot python3-certbot-nginx
2
3 # প্রতিটি ডোমেইনের জন্য আলাদা চালান
4 sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
5 sudo certbot --nginx -d api.yourdomain.com
6 sudo certbot --nginx -d dashboard.yourdomain.com
Let's Encrypt ACME challenge দিয়ে ডোমেইন যাচাই করে `.pem` সার্ট ডাউনলোড করে, Nginx site config-এ `ssl_certificate` লাইন যোগ করে, এবং port 80 → 443 redirect সেটআপ করে।
6.8 HTTPS রিডাইরেক্ট ও SSL ব্লক (Certbot পরে)কেন এই ধাপ
Certbot চালানোর পরে Nginx site config কেমন দেখায় তা বুঝলে TLS সমস্যা নিজেই ডিবাগ করতে পারবেন।
Certbot সফলভাবে চললে site config প্রায় এরকম আপডেট হয় (Certbot নিজেই লেখে — শুধু যাচাই করুন):
/etc/nginx/sites-available/yourdomain.com (after certbot) কপি 1 server {
2 listen 80;
3 server_name yourdomain.com www.yourdomain.com;
4 return 301 https://$host$request_uri;
5 }
6
7 server {
8 listen 443 ssl;
9 server_name yourdomain.com www.yourdomain.com;
10
11 ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
12 ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
13 include /etc/letsencrypt/options-ssl-nginx.conf;
14 ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
15
16 location / {
17 include proxy_params;
18 proxy_pass http://127.0.0.1:3000;
19 }
20 }
কপি 1 # কনফিগ টেস্ট করুন ও Nginx রিলোড
2 sudo nginx -t && sudo systemctl reload nginx
6.9 সার্ট অটো-রিনিউয়াল যাচাইকেন এই ধাপ
Let's Encrypt সার্ট ৯০ দিনে expire করে; systemd timer স্বয়ংক্রিয় রিনিউ করে — install-এর পরেই টাইমার active আছে কিনা যাচাই করুন।
কপি 1 # dry-run: সার্ট expire না হলেও রিনিউ প্রক্রিয়া সিমুলেট করে
2 sudo certbot renew --dry-run
3
4 # systemd timer চালু আছে কিনা দেখুন
5 sudo systemctl list-timers | grep certbot
6 sudo systemctl status certbot.timer
Timer না থাকলে — cron fallback
কিছু সিস্টেমে certbot timer স্বয়ংক্রিয় তৈরি হয় না। তখন cron যোগ করুন: `0 3 * * * certbot renew --quiet`। সার্ট expire হলে ব্রাউজারে 'Not Secure' warning আসে এবং অ্যাপ ব্লক হয়।
7
অ্যাডভান্স সিকিউরিটি — WAF ও SSL উভয়
মাঝারি/বড় ট্রাফিক বা কমপ্লায়েন্সের জন্য। ছোট অ্যাপে নিচের সাবসেকশনগুলো সাধারণত ঐচ্ছিক।
ঐচ্ছিক এই সেকশনের গুরুত্ব
নির্দিষ্ট দরকারে লাগে বা অ্যাডভান্স সেটআপ। না করলে মূল স্ট্যাক অনেক সময় চলতে পারে; করলে সেই বিষয়ে লাভ বা সুবিধা।
কেন দরকার ও কেন এভাবে
বেসিক ফায়ারওয়াল IP ফিল্টার করে; WAF/রেটলিমিট অ্যাপ লেয়ারের আক্রমণ (SQLi, স্ক্রিপ্টিং) কমায়। SSL হার্ডেনিং ব্রাউজারকে পুরনো সাইফার ব্যবহার করতে বাধা দেয়।
উদাহরণ: হঠাৎ ট্রাফিক স্পাইকে limit_req জোন দিয়ে API রুট সুরক্ষিত করতে পারেন; ছোট সাইটে শুধু Certbot+Nginx যথেষ্ট হলে WAF পরে যোগ করুন।
7.1 ModSecurity WAF (ঐচ্ছিক)কেন এই ধাপ
অ্যাপ কোডের বাইরে কমন ওয়েব আক্রমণ ফিল্টার করতে WAF; ট্রাফিক বেশি হলে বেশি দরকার।
কপি 1 sudo apt -y install libnginx-mod-http-modsecurity
2 sudo mkdir -p /etc/nginx/modsec
3 sudo wget -qO /etc/nginx/modsec/modsecurity.conf https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
OWASP CRS ছাড়া ModSecurity প্রায় কিছুই block করে না
ModSecurity শুধু ইঞ্জিন — আক্রমণ block করতে OWASP Core Rule Set (CRS) rules লাগে। নিচে CRS install ও nginx.conf-এ include করা দেখানো হয়েছে।
OWASP CRS ইনস্টল কপি 1 sudo apt -y install git
2 sudo git clone https://github.com/coreruleset/coreruleset /etc/nginx/modsec/owasp-crs
3 sudo cp /etc/nginx/modsec/owasp-crs/crs-setup.conf.example /etc/nginx/modsec/owasp-crs/crs-setup.conf
/etc/nginx/modsec/main.conf কপি 1 Include /etc/nginx/modsec/modsecurity.conf
2 Include /etc/nginx/modsec/owasp-crs/crs-setup.conf
3 Include /etc/nginx/modsec/owasp-crs/rules/*.conf
4 SecRuleEngine On
/etc/nginx/nginx.conf — http { } block এর ভেতরে যোগ করুন কপি 1 modsecurity on;
2 modsecurity_rules_file /etc/nginx/modsec/main.conf;
কপি 1 sudo nginx -t && sudo systemctl reload nginx
7.2 DDoS সুরক্ষা (Nginx) (ঐচ্ছিক)কেন এই ধাপ
সস্তা বট ট্রাফিক বা রিপিটেড রিকোয়েস্ট এজে কেটে অ্যাপ সার্ভার সুরক্ষিত রাখে।
/etc/nginx/conf.d/ddos-protection.conf কপি 1 limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
2 limit_conn_zone $binary_remote_addr zone=addr:10m;
3
4 server {
5 limit_req zone=perip burst=20 nodelay;
6 limit_conn addr 20;
7 }
7.3 SSL হার্ডেনিং (ঐচ্ছিক)কেন এই ধাপ
Let's Encrypt সার্ট পেলেও দুর্বল সাইফার বা HSTS ছাড়া ব্রাউজার স্কোর ও সিকিউরিটি কমে।
কপি 1 sudo apt -y install certbot python3-certbot-nginx
2 sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
/etc/nginx/snippets/ssl-hardening.conf কপি 1 ssl_protocols TLSv1.2 TLSv1.3;
2 ssl_prefer_server_ciphers off;
3 add_header Strict-Transport-Security "max-age=63072000" always;
সার্ট ইস্যুর পরে SSL ল্যাবস বা মজিলা অবজারভেটরি দিয়ে গ্রেড পরীক্ষা করুন।
8
Cloudflare Tunnel উভয়
Dashboard থেকে connector ইনস্টল করে hostname → localhost:PORT ম্যাপ করুন। Nginx ও SSL সার্ট ছাড়াই সাইট চলে।
ঐচ্ছিক এই সেকশনের গুরুত্ব
নির্দিষ্ট দরকারে লাগে বা অ্যাডভান্স সেটআপ। না করলে মূল স্ট্যাক অনেক সময় চলতে পারে; করলে সেই বিষয়ে লাভ বা সুবিধা।
কেন দরকার ও কেন এভাবে
Cloudflare Tunnel মানে আপনার সার্ভার থেকে Cloudflare-এর দিকে একটা আউটবাউন্ড সংযোগ — ইনবাউন্ড পোর্ট (80/443) খুলতে হয় না। Cloudflare নিজেই SSL টার্মিনেট করে এবং hostname অনুযায়ী ট্রাফিক রুট করে।
উদাহরণ: api.yourdomain.com → localhost:4000, yourdomain.com → localhost:3000 — Nginx ছাড়াই, সার্টিফিকেট ছাড়াই।
8.0 Nginx বনাম Cloudflare Tunnel — কোনটা বেছে নেবেন?কেন এই ধাপ
দুটি পথ একেবারে আলাদা আর্কিটেকচার — একটি বেছে নিন, দুটো একসাথে সাধারণত দরকার নেই।
বিষয় Nginx + Certbot Cloudflare Tunnel SSL সার্টিফিকেট নিজে manage (Certbot) Cloudflare handle করে — লাগে না Port 80/443 সার্ভারে খুলতে হবে বন্ধ রাখা যায় — outbound only Nginx লাগে লাগে না সেটআপ জটিলতা বেশি (Nginx config, certbot) কম (dashboard click করুন) Cloudflare dependency নেই (সরাসরি VPS IP) Cloudflare ছাড়া site চলবে না কখন বেছে নেবেন Cloudflare ছাড়া চালাতে চাইলে বা custom Nginx config দরকার হলে সহজ সেটআপ, SSL ঝামেলা এড়াতে, বা inbound port বন্ধ রাখতে চাইলে
সাধারণত না। Cloudflare Tunnel ব্যবহার করলে Nginx ও Certbot দরকার নেই — Tunnel নিজেই hostname → localhost:PORT routing করে। শুধু তখনই দুটো লাগে যদি একই সার্ভারে কিছু সার্ভিস Tunnel-এ আর কিছু সরাসরি IP-তে চালাতে চান।
8.1 ধাপ ১ — Cloudflare-এ Domain যোগ করুন ও Nameserver পরিবর্তনকেন এই ধাপ
Tunnel ব্যবহারের আগে domain টি Cloudflare-এর নিয়ন্ত্রণে আনতে হবে — nameserver পরিবর্তন করেই এটা হয়।
cloudflare.com-এ লগইন করুন। Home page-এ বা বাম sidebar-এ **Websites** (বা Domains/Overview) থেকে **Add a site** বা **Add a domain** বাটনে ক্লিক করুন। **Connect your domain** অপশন বেছে নিন। Domain name টাইপ করুন (যেমন `yourdomain.com`) → **Continue**। Plan বেছে নিন — **Free** plan-এ সব দরকারি feature আছে → **Continue**। Cloudflare আপনার domain-এর বিদ্যমান DNS record scan করবে। **Quick scan** রেজাল্ট review করুন — সব ঠিক থাকলে **Continue**। Cloudflare দুটো nameserver দেবে (যেমন `alice.ns.cloudflare.com` ও `bob.ns.cloudflare.com`)। এগুলো copy করুন। Domain কেনার জায়গায় (Namecheap, GoDaddy, Dynadot যেটাই হোক) লগইন করুন → Domain management → **Custom nameservers** বা **Nameservers** সেকশনে যান → Cloudflare-এর দেওয়া দুটো nameserver বসান → Save। Cloudflare-এ ফিরে আসুন এবং **Done, check nameservers** বাটনে ক্লিক করুন। Propagation সাধারণত ৫ মিনিট থেকে ২৪ ঘণ্টা লাগে। Active হলে ইমেইল পাবেন। Nameserver propagation চলাকালে site ভাঙতে পারে
Nameserver পরিবর্তনের পর পুরানো ও নতুন DNS একসাথে active থাকে — এই সময়ে কিছু ব্যবহারকারীর কাছে site ভিন্ন দেখাতে পারে বা না খুলতে পারে। Propagation শেষ হওয়ার পর ঠিক হবে।
8.2 ধাপ ২ — Zero Trust Tunnel তৈরি ও Connector ইনস্টলকেন এই ধাপ
Tunnel তৈরি করলে Cloudflare একটি unique token সহ install command দেয় — সেটি সার্ভারে চালালেই connector চালু হয়।
Cloudflare Dashboard-এর বাম sidebar থেকে **Zero Trust** → **Networks** → **Tunnels** → **Create a tunnel** ক্লিক করুন। Connector type: **Cloudflared** বেছে নিন → **Next**। Tunnel-এর একটি নাম দিন (যেমন `production`) → **Save tunnel**। **Install and run a connector** ধাপে OS হিসেবে **Debian** বা **Linux** বেছে নিন। Cloudflare একটি command দেবে যার মধ্যে unique token আছে। সার্ভারে SSH করুন এবং Cloudflare-এর দেওয়া সেই command টি হুবহু চালান। Command দেখতে নিচের মতো হবে (token আপনার নিজের হবে)। Command চালানোর পরে Cloudflare dashboard-এ connector **Connected** দেখাবে → **Next** চাপুন। Cloudflare-এর দেওয়া command (উদাহরণ — token আপনার নিজের হবে) কপি 1 curl -L --output cloudflared.deb \
2 https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb \
3 && sudo dpkg -i cloudflared.deb \
4 && sudo cloudflared service install eyJhIjoiYWJjZGVm...YOUR_TOKEN_HERE
Token কারো সাথে শেয়ার করবেন না
Cloudflare-এর দেওয়া command-এ যে token আছে সেটি আপনার tunnel-এর secret — এটি GitHub, chat বা screenshot-এ শেয়ার করলে যে কেউ আপনার tunnel-এ প্রবেশ করতে পারবে।
8.3 ধাপ ৩ — Public Hostname যোগ করুনকেন এই ধাপ
Hostname mapping-এ domain → localhost:PORT বলে দিলে Cloudflare সেই domain-এ আসা ট্রাফিক সার্ভারের সঠিক port-এ পাঠায়।
Connector connected হওয়ার পর **Public Hostname** ট্যাবে প্রতিটি সার্ভিসের জন্য একটি করে entry যোগ করুন:
Subdomain Domain Type URL কোন সার্ভিস (খালি) yourdomain.com HTTP localhost:3000 Frontend (Next.js/React) www yourdomain.com HTTP localhost:3000 Frontend (www redirect) api yourdomain.com HTTP localhost:4000 Backend API dashboard yourdomain.com HTTP localhost:4100 Admin dashboard
URL হলো `localhost:PORT` — সার্ভারের ভেতরে HTTPS নেই। Type যদি HTTPS দেন তাহলে Cloudflare সার্ভারের সাথে TLS handshake করতে গিয়ে fail করবে এবং ব্যবহারকারী 502 error পাবে।
⏭️ সেটআপ শেষ — Nginx ও Certbot লাগবে না
এখন yourdomain.com HTTPS-এ চলবে, api.yourdomain.com-ও। Nginx ইনস্টল করতে হবে না, SSL সার্টিফিকেটও লাগবে না — সব Cloudflare handle করছে। UFW-এ 80 ও 443 বন্ধ রাখতে পারেন।
8.4 UFW আপডেট — 80/443 বন্ধ করুন (ঐচ্ছিক)কেন এই ধাপ
Tunnel ব্যবহারে ইনবাউন্ড HTTP/HTTPS-এর দরকার নেই — বন্ধ করলে attack surface আরও কমে।
কপি 1 sudo ufw delete allow 80/tcp
2 sudo ufw delete allow 443/tcp
3 sudo ufw status verbose
4 # এখন শুধু 22 (SSH) খোলা থাকবে
8.5 Cloudflare Dashboard সেটিংস (ঐচ্ছিক)কেন এই ধাপ
ভুল SSL মোড বা aggressive caching SPA/Next.js ভেঙে দেয়; নিচের টেবিল নিরাপদ default দেখায়।
সেটিং সুপারিশকৃত মান কেন SSL মোড Flexible Origin localhost HTTP — Full দিলে 526 error Always HTTPS চালু HTTP → HTTPS redirect Cloudflare করবে Rocket Loader বন্ধ SPA/Next.js-এ JS execution ভেঙে দিতে পারে Bot Fight Mode চালু (প্রয়োজনে) Basic bot protection বিনামূল্যে Cache Rules HTML no-cache, static long-cache Dynamic page cache করলে stale data দেখাবে WAF Managed rulesets Cloudflare-এর built-in WAF চালু রাখুন
Tunnel ব্যবহারে origin localhost HTTP — তাই SSL মোড Flexible রাখুন। Full (strict) দিলে Cloudflare origin-এ valid SSL cert খুঁজবে কিন্তু পাবে না — 526 error আসবে।
9
Prometheus + Grafana মনিটরিং উভয়
প্রোডাকশন পর্যবেক্ষণ — ছোট প্রোজেক্টে ঐচ্ছিক; মাঝারি/বড় দলের জন্য সুপারিশ।
ঐচ্ছিক এই সেকশনের গুরুত্ব
নির্দিষ্ট দরকারে লাগে বা অ্যাডভান্স সেটআপ। না করলে মূল স্ট্যাক অনেক সময় চলতে পারে; করলে সেই বিষয়ে লাভ বা সুবিধা।
কেন দরকার ও কেন এভাবে
মেট্রিক্স দিয়ে বুঝবেন CPU/RAM/ডিস্ক কখন শেষ হচ্ছে, কোন সার্ভিস ডাউন। Grafana দিয়ে চার্ট; Uptime Kuma দিয়ে বাইরে থেকে HTTP চেক।
উদাহরণ: Node মেমরি লিক হলে Grafana গ্রাফে ধীরে ধীরে RAM বাড়া দেখা যায়; আপটাইম টুল আলার্ট দেয় "৫০২ শুরু হয়েছে"।
9.1 Prometheus ইনস্টল (ঐচ্ছিক)কেন এই ধাপ
মেট্রিক্স টাইম সিরিজে জমা করে অ্যানোমালি ধরতে; node exporter সহ সার্ভার হেলথ দেখা যায়।
কপি 1 cd /tmp
2 VER=$(curl -s https://api.github.com/repos/prometheus/prometheus/releases/latest | grep tag_name | cut -d '"' -f4)
3 VERFILE=$(echo "$VER" | sed 's/^v//')
4 wget "https://github.com/prometheus/prometheus/releases/download/${VER}/prometheus-${VERFILE}.linux-amd64.tar.gz"
5 tar xvf prometheus-*.linux-amd64.tar.gz
6 sudo mv prometheus-*.linux-amd64 /opt/prometheus
/opt/prometheus/prometheus.yml কপি 1 global:
2 scrape_interval: 15s
3
4 scrape_configs:
5 - job_name: node
6 static_configs:
7 - targets: ["127.0.0.1:9100"]
9.2 Grafana ইনস্টল (ঐচ্ছিক)কেন এই ধাপ
শুধু সংখ্যা নয় চার্ট দরকার হলে Grafana; টিমকে একই ড্যাশবোর্ড শেয়ার করা সহজ।
কপি 1 # GPG কী — apt-key deprecated (Ubuntu 22.04+), keyring পদ্ধতি ব্যবহার করুন
2 sudo mkdir -p /etc/apt/keyrings
3 wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
4 echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
5 sudo apt update && sudo apt -y install grafana
6 sudo systemctl enable --now grafana-server
9.3 ড্যাশবোর্ড আইডি (ঐচ্ছিক)কেন এই ধাপ
প্রস্তুত ড্যাশবোর্ড আইডি দিয়ে দ্রুত Node/DB/Docker ভিউ আমদানি — নিজে সব প্যানেল বানানোর সময় বাঁচে।
আইডি বিবরণ 1860 Node Exporter Full 3662 Prometheus 2.0 7362 MongoDB 9628 PostgreSQL 11835 Redis 12708 Docker
9.4 Uptime Kuma (ঐচ্ছিক)কেন এই ধাপ
বাইরে থেকে HTTP পিং করে ডাউনটাইম নোটিফিকেশন; মেট্রিক্সের পাশাপাশি ইউজার-ফেসিং চেক।
কপি 1 docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1
10
স্টেজিং ও Git ওয়ার্কফ্লো উভয়
ব্রাঞ্চিং ও ডেপ্লয় ফ্লো সবার জন্য; পৃথক স্টেজিং সার্ভার ঐচ্ছিক (ছোট টিমে প্রায়ই মেইন+ট্যাগই যথেষ্ট)।
সুপারিশিত এই সেকশনের গুরুত্ব
না করলেও অনেক সময় মৌলিক কাজ চলতে পারে (যেমন রুট দিয়ে SSH, IP:পোর্টে অ্যাপ); করলে নিরাপত্তা, স্থায়িত্ব ও দলের কাজের ধরন ভালো হয়।
কেন দরকার ও কেন এভাবে
ব্রাঞ্চ মডেল দিয়ে কোড কোথায় মার্জ হবে স্পষ্ট হয় — প্রোড শুধু main থেকে। স্টেজিং সার্ভার দিয়ে ক্লায়েন্ট UAT বা ইন্টিগ্রেশন টেস্ট আলাদা রাখা যায়।
উদাহরণ: feature/login → PR → staging এ মার্জ → QA OK হলে main → প্রোড ডেপ্লয়; হটফিক্স ব্রাঞ্চ দিয়ে জরুরি প্যাচ আলাদা ট্র্যাক করুন।
10.1 Git ব্রাঞ্চিংকেন এই ধাপ
কোন ব্রাঞ্চে কী ধরনের কোড থাকবে স্পষ্ট করলে রিলিজ ও হটফিক্স ট্র্যাক করা সহজ।
ব্রাঞ্চ উদ্দেশ্য main প্রোডাকশন staging প্রি-প্রোড ইন্টিগ্রেশন develop ডেভ ইন্টিগ্রেশন feature/* ফিচার কাজ hotfix/* জরুরি প্যাচ
10.2 স্টেজিং (ম্যানুয়াল) (ঐচ্ছিক)কেন এই ধাপ
প্রোডের আগে আলাদা .env ও পোর্টে চালিয়ে রিগ্রেশন ধরা; PM2 এ আলাদা env দিয়ে চালানো যায়।
কপি 1 sudo mkdir -p /var/www/staging && sudo chown deploy:deploy /var/www/staging
2 cd /var/www/staging
3 git clone -b staging git@github.com:org/backend.git
4 cp /var/www/staging/backend/.env.example /var/www/staging/backend/.env.staging
5 # edit DATABASE_URL, secrets for staging
6 cd /var/www/staging/backend && npm ci && npm run build
7 pm2 start ecosystem.config.js --env staging
10.4 ডেপ্লয় ফ্লোকেন এই ধাপ
ফিচার থেকে প্রোড পর্যন্ত ধাপ লিখে রাখলে টিম একই রিদমে রিলিজ করে; UAT বাদ দিলে ঝুঁকি বাড়ে।
ফিচার ব্রাঞ্চে কাজ ও PR স্টেজিংয়ে মার্জ ও স্বয়ংক্রিয়/ম্যানুয়াল টেস্ট স্টেকহোল্ডার UAT মেইনে মার্জ (প্রোড) বিল্ড আর্টিফ্যাক্ট/ইমেজ তৈরি ব্যাকআপ নিশ্চিত রোলিং ডেপ্লয় পোস্ট-ডেপ্লয় স্বাস্থ্য পরীক্ষা
11
CI/CD পাইপলাইন উভয়
ম্যানুয়াল/ডকার ডেপ্লয় স্ক্রিপ্ট — সবার জন্য। GitHub Actions ও ব্লু-গ্রিন ঐচ্ছিক (ছোট রিলিজে ম্যানুয়াল স্ক্রিপ্টই চলে)।
সুপারিশিত এই সেকশনের গুরুত্ব
না করলেও অনেক সময় মৌলিক কাজ চলতে পারে (যেমন রুট দিয়ে SSH, IP:পোর্টে অ্যাপ); করলে নিরাপত্তা, স্থায়িত্ব ও দলের কাজের ধরন ভালো হয়।
কেন দরকার ও কেন এভাবে
ম্যানুয়াল ডেপ্লয় মানে একই কমান্ড সিরিজ বারবার — স্ক্রিপ্টে রাখলে ভুল কমে, অন্য কেউ রিলিজ করতে পারে। CI (GitHub Actions) দিয়ে মেইনে পুশ হলেই স্বয়ংক্রিয় SSH ডেপ্লয়।
উদাহরণ: /opt/scripts/deploy.sh এ git pull + build + pm2 reload একসাথে; ডকারে compose pull করে শুধু api সার্ভিস রিফ্রেশ করলে ডাউনটাইম কমে।
11.1 ডেপ্লয় স্ক্রিপ্ট (ম্যানুয়াল)কেন এই ধাপ
একই সিকোয়েন্স (পুল, বিল্ড, রিলোড) স্ক্রিপ্টে বন্ধ করলে ম্যানুয়াল টাইপো কমে, অন্য কেউ রিলিজ করতে পারে।
/opt/scripts/deploy.sh কপি 1 #!/usr/bin/env bash
2 set -euo pipefail
3
4 # non-interactive SSH-এ ~/.bashrc source হয় না — nvm manually load করতে হবে
5 export NVM_DIR="$HOME/.nvm"
6 [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
7
8 APP_DIR="/var/www/backend"
9 git -C "$APP_DIR" fetch --all --prune
10 git -C "$APP_DIR" checkout main
11 git -C "$APP_DIR" pull --ff-only
12 cd "$APP_DIR" && npm ci && npm run build
13 pm2 reload ecosystem.config.js --only api
কপি 1 sudo chmod +x /opt/scripts/deploy.sh
11.3 GitHub Actions (ঐচ্ছিক)কেন এই ধাপ
মেইনে মার্জ হলেই একই স্ক্রিপ্ট চালানো — ম্যানুয়াল ভুলে ভুল সার্ভারে SSH কম।
.github/workflows/deploy.yml কপি 1 name: Deploy
2 on:
3 push:
4 branches: [main]
5
6 jobs:
7 deploy:
8 runs-on: ubuntu-latest
9 steps:
10 - uses: actions/checkout@v4
11 - name: SSH deploy
12 uses: appleboy/ssh-action@v1.0.3
13 with:
14 host: ${{ secrets.PROD_HOST }}
15 username: deploy
16 key: ${{ secrets.SSH_PRIVATE_KEY }}
17 script: |
18 /opt/scripts/deploy.sh
11.4 ব্লু-গ্রিন ডেপ্লয় (ঐচ্ছিক)কেন এই ধাপ
নতুন বিল্ড আলাদা ডিরে হেলথ চেক করে ট্রাফিক ফ্লিপ — বিগ ব্যাং রিলিজের ঝুঁকি কমে।
/opt/scripts/blue-green.sh কপি 1 #!/usr/bin/env bash
2 set -euo pipefail
3 ACTIVE=$(readlink -f /var/www/active)
4 if [[ "$ACTIVE" == "/var/www/blue" ]]; then
5 TARGET="/var/www/green"
6 else
7 TARGET="/var/www/blue"
8 fi
9 git clone --depth 1 git@github.com:org/backend.git "$TARGET"
10 # build, healthcheck, flip nginx upstream symlink
11 ln -sfn "$TARGET" /var/www/active
12 sudo nginx -s reload
12
রোলব্যাক স্ট্র্যাটেজি উভয়
ম্যানুয়াল গিট রিভার্ট ও ডকার ট্যাগ সোয়াপ।
সুপারিশিত এই সেকশনের গুরুত্ব
না করলেও অনেক সময় মৌলিক কাজ চলতে পারে (যেমন রুট দিয়ে SSH, IP:পোর্টে অ্যাপ); করলে নিরাপত্তা, স্থায়িত্ব ও দলের কাজের ধরন ভালো হয়।
কেন দরকার ও কেন এভাবে
খারাপ রিলিজ হবেই — গুরুত্বপূর্ণ হলো কত দ্রুত পেছনে ফিরতে পারবেন। গিট কমিট পিন বা ডকার পুরনো ট্যাগে ফিরলে ব্যবহারকারী দ্রুত স্থিতি পায়।
উদাহরণ: নতুন বিল্ড ৫০২ দিলে rollback.sh LAST_GOOD_SHA দিয়ে আগের কমিটে ফিরে PM2 রিলোড; ডকারে আগের ইমেজ ট্যাগ এক্সপোর্ট করে compose up।
12.1 রোলব্যাক (ম্যানুয়াল)কেন এই ধাপ
খারাপ কমিট দ্রুত ছেড়ে আগের SHA-তে ফিরে বিল্ড+রিলোড — MTTR কমায়।
/opt/scripts/rollback.sh কপি 1 #!/usr/bin/env bash
2 set -euo pipefail
3 APP_DIR="/var/www/backend"
4 LAST_GOOD="${1:-}"
5 if [[ -z "$LAST_GOOD" ]]; then
6 echo "usage: rollback.sh <commit_sha>"
7 exit 1
8 fi
9 git -C "$APP_DIR" checkout "$LAST_GOOD"
10 cd "$APP_DIR" && npm ci && npm run build
11 pm2 reload ecosystem.config.js --only api
13
ব্যাকআপ স্ট্র্যাটেজি উভয়
MongoDB, PostgreSQL, ক্রন শিডিউল।
সুপারিশিত এই সেকশনের গুরুত্ব
না করলেও অনেক সময় মৌলিক কাজ চলতে পারে (যেমন রুট দিয়ে SSH, IP:পোর্টে অ্যাপ); করলে নিরাপত্তা, স্থায়িত্ব ও দলের কাজের ধরন ভালো হয়।
কেন দরকার ও কেন এভাবে
রansomware, ভুল মাইগ্রেশন, বা ডিস্ক ফেল করলে ব্যাকআপ ছাড়া পুনরুদ্ধার অসম্ভব। অটোমেটেড ডাম্প + অফসাইট কপি মানে ঘুমোতে পারবেন।
উদাহরণ: প্রতিদিন রাত ২টায় mongodump আর্কাইভ, সপ্তাহে একবার S3-তে sync — রিটেনশন রাখুন যেন ডিস্ক না ভরে।
13.1 MongoDB ব্যাকআপকেন এই ধাপ
আর্কাইভড ডাম্প অফসাইটে না গেলে এক ডিস্ক ফেলে সব হারায়; ম্যানুয়াল ও ডকার উভয় রুট।
/opt/scripts/backup-mongo.sh (manual) কপি 1 #!/usr/bin/env bash
2 mongodump --uri="$MONGO_URI" --archive=/backups/mongo-$(date +%F).gz --gzip
docker exec one-liner কপি 1 docker exec stack-mongo-1 mongodump --archive=/tmp/dump.gz --gzip
2 docker cp stack-mongo-1:/tmp/dump.gz ./mongo-$(date +%F).gz
13.2 PostgreSQL ব্যাকআপকেন এই ধাপ
pg_dump লজিক্যাল ব্যাকআপ — ভার্শন মিশম্যাচে ভলিউম কপির চেয়ে নিরাপদ অনেক সময়।
কপি 1 pg_dump -h 127.0.0.1 -U appuser app | gzip > /backups/pg-$(date +%F).sql.gz
কপি 1 docker exec stack-postgres-1 pg_dump -U appuser app | gzip > pg-$(date +%F).sql.gz
13.3 ক্রন শিডিউলকেন এই ধাপ
ম্যানুয়াল রিমাইন্ডারে ব্যাকআপ ভুলে যায়; ক্রনে স্থির সময়ে চালালে অফসাইট সিঙ্কও একসাথে বাঁধা যায়।
crontab -e কপি 1 0 2 * * * /opt/scripts/backup-mongo.sh
2 15 2 * * * /opt/scripts/backup-pg.sh
3 30 3 * * * /opt/scripts/offsite-sync.sh
13.4 অফসাইট সিঙ্ক — S3 / Object Storageকেন এই ধাপ
লোকাল ডাম্প ডিস্ক ফেলে গেলে কাজে আসে না — S3 বা compatible storage-এ sync করলে সত্যিকারের disaster recovery সম্ভব।
দুটি জনপ্রিয় পদ্ধতি: AWS CLI (S3 সরাসরি) বা rclone (S3, Backblaze B2, Cloudflare R2, Google Cloud Storage — যেকোনো provider)।
পদ্ধতি ১ — AWS CLI কপি 1 # AWS CLI ইনস্টল
2 sudo apt -y install awscli
3
4 # credentials একবার সেটআপ করুন
5 aws configure
6 # AWS Access Key ID: YOUR_ACCESS_KEY
7 # AWS Secret Access Key: YOUR_SECRET_KEY
8 # Default region name: ap-southeast-1
9 # Default output format: json
/opt/scripts/offsite-sync.sh (AWS CLI) কপি 1 #!/usr/bin/env bash
2 set -euo pipefail
3 BUCKET="your-bucket-name"
4 HOST=$(hostname)
5 aws s3 sync /backups "s3://$BUCKET/backups/$HOST/" --storage-class STANDARD_IA
6 # S3 Lifecycle Rule দিয়ে ৩০ দিনের পুরনো ব্যাকআপ স্বয়ংক্রিয় মুছুন
পদ্ধতি ২ — rclone (যেকোনো provider) কপি 1 # rclone ইনস্টল
2 curl https://rclone.org/install.sh | sudo bash
3
4 # interactive config (provider বেছে credentials দিন)
5 rclone config
/opt/scripts/offsite-sync.sh (rclone) কপি 1 #!/usr/bin/env bash
2 set -euo pipefail
3 # "remote" = rclone config-এ দেওয়া নাম
4 rclone sync /backups remote:your-bucket/backups/$(hostname)/
AWS credentials `~/.aws/credentials` বা environment variable-এ রাখুন — script-এ hardcode করবেন না। IAM user-এ শুধু S3 bucket-এ PutObject/GetObject/ListBucket permission দিন।
14
ডিজাস্টার রিকভারি উভয়
রিস্টোর কমান্ড — প্রয়োজনে। সম্পূর্ণ DR চেকলিস্ট বড়/মিশন-ক্রিটিকাল সিস্টেমের জন্য; ছোট অ্যাপে ঐচ্ছিক।
ঐচ্ছিক এই সেকশনের গুরুত্ব
নির্দিষ্ট দরকারে লাগে বা অ্যাডভান্স সেটআপ। না করলে মূল স্ট্যাক অনেক সময় চলতে পারে; করলে সেই বিষয়ে লাভ বা সুবিধা।
কেন দরকার ও কেন এভাবে
DR মানে “পুরো অঞ্চল ডাউন” পরিস্থিতিতেও সিস্টেম ফেরানোর পরিকল্পনা। ছোট অ্যাপে অন্তত রিস্টোর কমান্ড জেনে রাখুন; বড় দলে ধাপে ধাপ চেকলিস্ট।
উদাহরণ: প্রোভাইডার ফায়ারে ডাটাসেন্টার হারালে নতুন ভিপিএসে ডাম্প রিস্টোর + DNS TTL কমিয়ে ট্রাফিক সরানো।
14.1 MongoDB রিস্টোরকেন এই ধাপ
ডাম্প থেকে পুনরুদ্ধার জানা থাকলে ইন্সিডেন্টে সময় বাঁচে; ডকার কপি পাথও একই।
কপি 1 mongorestore --uri="$MONGO_URI" --archive=/backups/mongo-YYYY-MM-DD.gz --gzip
কপি 1 docker cp ./mongo-YYYY-MM-DD.gz stack-mongo-1:/tmp/dump.gz
2 docker exec stack-mongo-1 mongorestore --archive=/tmp/dump.gz --gzip
14.2 ফুল রিকভারি চেকলিস্ট (ঐচ্ছিক)কেন এই ধাপ
পুরো অঞ্চল/প্রোভাইডার ফেলে গেলে ধাপ মিস করলে সেবা আধা-উঠা থেকে যায়; টেবিল হল রানবুক স্কেলেটন।
ধাপ ম্যানুয়াল ডকার 1 নতুন ভিপিএস প্রভিজন নতুন ভিপিএস প্রভিজন 2 SSH কী ও ইউজার SSH কী ও ইউজার 3 UFW/Fail2ban UFW/Fail2ban 4 Nginx ইনস্টল ডকার ইনস্টল 5 ডাটাবেজ ইনস্টল কম্পোজ স্ট্যাক 6 রিস্টোর ডাম্প রিস্টোর ভলিউম/ডাম্প 7 গিট ক্লোন ও বিল্ড ইমেজ পুল 8 .env পুনরুদ্ধার .env ও সিক্রেট 9 PM2 স্টার্ট আপ স্ট্যাক 10 Nginx সাইট রিভার্স প্রক্সি 11 SSL সার্ট SSL সার্ট/টানেল 12 DNS আপডেট DNS আপডেট 13 স্মোক টেস্ট স্মোক টেস্ট 14 মনিটরিং পুনরায় সংযোগ মনিটরিং পুনরায় সংযোগ 15 ইন্সিডেন্ট নোট ইন্সিডেন্ট নোট 16 পোস্টমর্টেম —
15
সিকিউরিটি চেকলিস্ট উভয়
সার্ভার, ডাটাবেজ, অ্যাপ, অপারেশন ও ট্রাবলশুটিং।
সুপারিশিত এই সেকশনের গুরুত্ব
না করলেও অনেক সময় মৌলিক কাজ চলতে পারে (যেমন রুট দিয়ে SSH, IP:পোর্টে অ্যাপ); করলে নিরাপত্তা, স্থায়িত্ব ও দলের কাজের ধরন ভালো হয়।
কেন দরকার ও কেন এভাবে
চেকলিস্ট দিয়ে রিলিজের আগে/পরে “ভুলবো না তো?” দ্রুত যাচাই করেন — নিরাপত্তা শুধু টুল নয়, অভ্যাস। অপারেশন কমান্ড দিয়ে দৈনন্দিন স্বাস্থ্য দেখা।
উদাহরণ: নতুন সার্ভার হাতে পেলে UFW+SSH কী+ব্যাকআপ স্ক্রিপ্ট টিক দিন; ৫০২ হলে প্রথমে আপস্ট্রিম লগ, তারপর ডিস্ক।
15.1 সার্ভার সিকিউরিটিকেন এই ধাপ
সার্ফেস অ্যাটাক কমাতে SSH, ফায়ারওয়াল, প্যাচিং — অ্যাপ সিকিউর হলেও বক্স খোলা থাকলে লিক হয়।
আইটেম স্ট্যাটাস রুট লগইন বন্ধ □ কী-অনলি SSH □ UFW সক্রিয় □ অটো আপডেট □
15.2 ডাটাবেজ সিকিউরিটিকেন এই ধাপ
পাবলিক বাইন্ড বা দুর্বল রোল মানে এক লিকে পুরো ডাটা; লোকাল বাইন্ড+রোল মিনিমাইজেশন।
আইটেম স্ট্যাটাস শুধু লোকালহোস্ট বাইন্ড □ শক্তিশালী পাসওয়ার্ড/রোল □ নিয়মিত ব্যাকআপ □
15.3 অ্যাপ্লিকেশন সিকিউরিটিকেন এই ধাপ
হেডার ও রেট লিমিট ব্রাউজার/বট আক্রমণ কমায়; ডিপেন্ডেন্সি প্যাচ সাপ্লাই চেইন সুরক্ষা।
আইটেম স্ট্যাটাস হেডার (HSTS, CSP) □ রেট লিমিট □ ডিপেন্ডেন্সি আপডেট □
15.4 দৈনন্দিন কমান্ডকেন এই ধাপ
দ্রুত স্বাস্থ্য চেক (প্রসেস, লগ, nginx) ইউজার রিপোর্টের আগে সমস্যা ধরে।
Manual কপি 1 pm2 status
2 pm2 logs api --lines 200
3 sudo nginx -t && sudo systemctl reload nginx
Docker কপি 1 docker compose ps
2 docker compose logs -f --tail=200 api
15.5 ট্রাবলশুটিংকেন এই ধাপ
লক্ষণ→পরীক্ষা ম্যাপ দিয়ে ডিবাগ অর্ডার ঠিক রাখা; ৫০২ এ আগে আপস্ট্রিম, পরে সার্ট/ডিস্ক।
লক্ষণ পরীক্ষা 502 আপস্ট্রিম/PM2/কন্টেইনার স্বাস্থ্য SSL ত্রুটি সার্ট মেয়াদ ও চেইন ডিস্ক পূর্ণ লগ ও ডাম্প পরিষ্কার
16
কমান্ড রেফারেন্স (PM2, tmux, ডকার, সিস্টেম) উভয়
নিচের ব্লকগুলো ক্লিক করে খুলুন — PM2, tmux, ডকার কম্পোজ, systemd, লগ ও Nginx দ্রুত কমান্ড।
ঐচ্ছিক এই সেকশনের গুরুত্ব
নির্দিষ্ট দরকারে লাগে বা অ্যাডভান্স সেটআপ। না করলে মূল স্ট্যাক অনেক সময় চলতে পারে; করলে সেই বিষয়ে লাভ বা সুবিধা।
কেন দরকার ও কেন এভাবে
মূল গাইডে কমান্ড ছড়িয়ে থাকে; এখানে এক জায়গায় “কী চাইলে কী চালাব”। প্রোডে সব একসাথে চালাবেন না — বুঝে কপি করুন।
উদাহরণ: “লগ দেখতে” PM2 এ pm2 logs, ডকারে compose logs, সিস্টেম সার্ভিসে journalctl।
16.1 PM2 ও প্রসেস ম্যানেজমেন্টকেন এই ধাপ
ম্যানুয়াল পথে Node অ্যাপ চালাতে PM2 স্ট্যান্ডার্ড — স্টার্ট, রিলোড, লগ, মেট্রিক্স।
গ্লোবাল ইনস্টল: sudo npm i -g pm2। প্রথমবার: cd অ্যাপ ডিরেক্টরি থেকে pm2 start …
▶ স্টার্ট / স্টপ / রিস্টার্ট / রিলোড কপি 1 pm2 start ecosystem.config.js
2 pm2 start npm --name api -- start
3 pm2 stop api
4 pm2 restart api
5 pm2 reload api # zero-downtime cluster reload (if app supports)
6 pm2 delete api
▶ তালিকা, মনিটর, স্ট্যাটাস কপি 1 pm2 list
2 pm2 status
3 pm2 monit
4 pm2 show api
5 pm2 describe api
▶ লগ (লাইভ, লাইন লিমিট, ফ্লাশ) কপি 1 pm2 logs
2 pm2 logs api
3 pm2 logs api --lines 200
4 pm2 flush # clear all log files
▶ স্টার্টআপে আবার চালু (boot) কপি 1 pm2 save
2 pm2 startup # prints a sudo command — run it once
3 pm2 unstartup systemd # remove autostart (distro-specific)
▶ আপডেট / ইনস্টল / ক্লাস্টার কপি 1 pm2 update # update in-memory PM2
2 npm i -g pm2@latest && pm2 update
3
4 # ecosystem example: instances : "max" or number for cluster mode
5 pm2 scale api 4
▶ লগ রোটেশন (pm2-logrotate) — প্রোডাকশনে জরুরি প্রোডাকশনে PM2 লগ ফাইল বাড়তে বাড়তে ডিস্ক ভরে যায় — pm2-logrotate মডিউল স্বয়ংক্রিয় কেটে রাখে।
কপি 1 pm2 install pm2-logrotate
2
3 # ১০ MB-এর বেশি হলে নতুন ফাইলে রোটেট
4 pm2 set pm2-logrotate:max_size 10M
5
6 # ৭টি পুরনো ফাইল রাখবে, বাকি মুছবে
7 pm2 set pm2-logrotate:retain 7
8
9 # gzip কম্প্রেস করে রাখা
10 pm2 set pm2-logrotate:compress true
11
12 # প্রতিদিন মাঝরাতে রোটেট
13 pm2 set pm2-logrotate:rotateInterval '0 0 * * *'
14
15 # বর্তমান সেটিংস দেখুন
16 pm2 get pm2-logrotate
▶ এনভ ও ডিবাগ কপি 1 pm2 env 0
2 pm2 restart api --update-env
3 NODE_ENV=production pm2 restart api --update-env
16.2 Docker ও Composeকেন এই ধাপ
ডকার পথে ইমেজ, কন্টেইনার, ভলিউম ও কম্পোজ এক লাইনে চালানোর রেফারেন্স।
▶ কম্পোজ (সাধারণ) কপি 1 docker compose ps
2 docker compose up -d
3 docker compose pull api
4 docker compose up -d --no-deps api
5 docker compose logs -f --tail=200 api
6 docker compose down
▶ ইমেজ ও কন্টেইনার কপি 1 docker images
2 docker ps -a
3 docker exec -it CONTAINER_NAME sh
4 docker stats --no-stream
16.3 systemd ও লগ (journalctl)কেন এই ধাপ
Nginx বা সিস্টেম সার্ভিস ডিবাগ ও রিবুট পর স্ট্যাটাস দেখতে।
▶ systemctl কপি 1 sudo systemctl status nginx
2 sudo systemctl reload nginx
3 sudo systemctl restart nginx
4 sudo systemctl is-active nginx
▶ journalctl কপি 1 journalctl -u nginx -f
2 journalctl -u nginx --since "1 hour ago"
3 journalctl -xe
16.4 Nginx, সার্ট, ডিস্ককেন এই ধাপ
সাইট কনফিগ টেস্ট, সার্ট রিনিউ, ডিস্ক ফুল হলে দ্রুত চেক।
▶ Nginx + Certbot কপি 1 sudo nginx -t
2 sudo systemctl reload nginx
3 sudo certbot renew --dry-run
4 sudo certbot renew
▶ ডিস্ক ও মেমোরি কপি 1 df -h
2 du -sh /var/log/* | sort -h | tail
3 free -h
16.5 tmux দ্রুত রেফারেন্সকেন এই ধাপ
ম্যানুয়াল পথে PM2 ছাড়া চালালে সেশন, ডিট্যাচ ও রিকভারি এক নজরে।
সেশন নাম দিয়ে চালান (`tmux new -s api`) যাতে রিবুটের পর `attach` সহজ হয়।
▶ সেশন ও উইন্ডো কপি 1 tmux new -s work
2 tmux ls
3 tmux attach -t work
4 tmux kill-session -t work
5
6 # prefix key default: Ctrl+b
7 # new window: Ctrl+b c
8 # next/prev window: Ctrl+b n / Ctrl+b p
▶ স্ক্রল ও কপি (কপি মোড) কপি 1 # enter copy mode: Ctrl+b [
2 # navigate with vi keys or arrows; q to quit copy mode
ক্র্যাশ বা রিবুটের পর প্রসেস আবার চালু হয় না — systemd সার্ভিস, ক্রন, বা হাতে `attach` করে স্ক্রিপ্ট চালানোর পরিকল্পনা রাখুন।