AWS ALB ব্যবহার করে জ্যাঙ্গো-সেলেরি কনফিগারেশনে পুনরাবৃত্ত HTTP 502 খারাপ গেটওয়ে সমস্যার সমাধান করা

AWS ALB এর সাথে জ্যাঙ্গো-সেলারিতে সাধারণ চ্যালেঞ্জ

সেলেরির সাথে চলমান এবং AWS-এ হোস্ট করা জ্যাঙ্গো অ্যাপ্লিকেশনগুলির জন্য একটি শক্তিশালী আর্কিটেকচার সেট আপ করা সবসময় সহজ নয়। AWS অ্যাপ্লিকেশন লোড ব্যালেন্সার (ALB) এর মতো লোড ব্যালেন্সারকে সংহত করার সময়, স্থায়ী HTTP 502 খারাপ গেটওয়ে ত্রুটির মতো সমস্যা দেখা দিতে পারে। একটি নির্বিঘ্ন অপারেশনের জন্য মূল কারণ বোঝা অত্যন্ত গুরুত্বপূর্ণ।

এই নির্দিষ্ট ত্রুটিটি SSL সমস্যা, স্বাস্থ্য পরীক্ষা ব্যর্থতা বা এমনকি ফ্রন্টএন্ড এবং ব্যাকএন্ডের মধ্যে ভুল যোগাযোগ সহ একাধিক ভুল কনফিগারেশন থেকে উদ্ভূত হতে পারে। ফ্রন্টএন্ডের জন্য ডকার কন্টেইনার এবং জ্যাঙ্গো/সেলেরি প্রয়োগের জায়গায়, এই স্তরগুলি পরিচালনা করা জটিল হতে পারে।

আরেকটি গুরুত্বপূর্ণ ক্ষেত্রে SSL সার্টিফিকেট জড়িত, বিশেষ করে যখন স্ব-স্বাক্ষরিত শংসাপত্র পরীক্ষার জন্য ব্যবহার করা হয়। যদিও তারা স্থানীয়ভাবে ভাল কাজ করতে পারে, তবে AWS পরিবেশে তাদের স্থাপন করা প্রায়শই সামঞ্জস্য বা সুরক্ষা সমস্যাগুলির সাথে পরিচয় করিয়ে দেয় যা সাবধানে সমাধান করা প্রয়োজন।

এই নিবন্ধে, আমরা এই ধরনের সেটআপে স্থায়ী HTTP 502 ত্রুটির পিছনে সম্ভাব্য কারণগুলি অনুসন্ধান করব। আমরা স্বাস্থ্য পরীক্ষার ব্যর্থতাগুলি অন্বেষণ করব, Django এবং AWS থেকে লগগুলি পরীক্ষা করব এবং এই সমস্যাটিকে কার্যকরভাবে সমাধান করার জন্য সমস্যা সমাধানের পদক্ষেপগুলি প্রদান করব৷

জ্যাঙ্গো-সেলারি এবং ALB ইন্টিগ্রেশন স্ক্রিপ্ট বোঝা

উপরের উদাহরণে প্রদত্ত স্ক্রিপ্টগুলি AWS ALB (অ্যাপ্লিকেশন লোড ব্যালেন্সার) এর সাথে জ্যাঙ্গো-সেলেরি সেটআপে ঘটতে থাকা স্থায়ী HTTP 502 খারাপ গেটওয়ে ত্রুটিগুলি সমাধান করার জন্য ডিজাইন করা হয়েছে। প্রথম স্ক্রিপ্টটি EC2 দৃষ্টান্তে চলমান জ্যাঙ্গো অ্যাপ্লিকেশনে ফ্রন্টএন্ড থেকে অনুরোধ ফরোয়ার্ড করার জন্য একটি Nginx বিপরীত প্রক্সি ব্যবহার করে। Nginx কনফিগারেশন নিশ্চিত করে যে পোর্ট 80-এ সমস্ত আগত ট্র্যাফিক নিরাপদ সংযোগের জন্য 443 পোর্টে পুনঃনির্দেশিত হয়, যখন প্রক্সি_পাস উপযুক্ত ব্যাকএন্ড সার্ভারে API অনুরোধ ফরওয়ার্ড করে। এই সেটআপটি ALB এবং জ্যাঙ্গো অ্যাপ্লিকেশনের মধ্যে নিরাপদ এবং দক্ষ যোগাযোগ সক্ষম করে, SSL পরিচালনা করে এবং সঠিকভাবে রাউটিং করে।

দ্বিতীয় স্ক্রিপ্ট উপর ফোকাস গুনিকর্ন— জ্যাঙ্গো অ্যাপ পরিবেশন করতে ব্যবহৃত অ্যাপ্লিকেশন সার্ভার। Gunicorn-কে সমস্ত নেটওয়ার্ক ইন্টারফেস এবং পোর্ট 8000-এ আবদ্ধ করে, এটি নিশ্চিত করে যে Django অ্যাপটি ALB থেকে আগত ট্রাফিকের জন্য অ্যাক্সেসযোগ্য। উপরন্তু, Django এর কনফিগারেশন সেটিংস, যেমন SECURE_PROXY_SSL_HEADER এবং ALLOWED_HOSTS, অ্যাপ্লিকেশনকে জানানোর জন্য অপরিহার্য যে এটি একটি লোড ব্যালেন্সারের পিছনে রয়েছে এবং SSL সমাপ্তি ALB দ্বারা বাহ্যিকভাবে পরিচালনা করা হয়। এই সেটিংসগুলি নিশ্চিত করে যে অ্যাপ্লিকেশনটি ফরোয়ার্ড করা HTTPS অনুরোধগুলিকে সঠিকভাবে প্রক্রিয়া করে এবং অমিলযুক্ত প্রোটোকলের কারণে অসাবধানতাবশত নিরাপত্তা সমস্যাগুলি ট্রিগার করে না।

ট্রাবলশুটিং স্ক্রিপ্টে যেমন কমান্ড ব্যবহার করা হয় CSRF_TRUSTED_ORIGINS এবং CORS_ALLOW_HEADERS একটি উল্লেখযোগ্য ভূমিকা পালন করে। এই সেটিংস নিশ্চিত করে যে ফ্রন্টএন্ড (যেমন একটি Vue.js ডেভেলপমেন্ট সার্ভার) ALB এর মাধ্যমে Django ব্যাকএন্ডের সাথে নিরাপদে যোগাযোগ করতে পারে। ক্রস-অরিজিন রিসোর্স শেয়ারিং (CORS) সমস্যাগুলি মোকাবেলা করার সময় এটি বিশেষভাবে কার্যকর, যা প্রায়শই বহু-ধারক, বহু-অরিজিন পরিবেশে উদ্ভূত হয়। জন্য SSL শংসাপত্র অন্তর্ভুক্তি স্ব-স্বাক্ষরিত শংসাপত্র নিশ্চিত করে যে এমনকি পরীক্ষার পরিবেশও সুরক্ষিত থাকে এবং API ইন্টারঅ্যাকশনের সময় যথাযথ SSL প্রোটোকল মেনে চলে।

শেষ স্ক্রিপ্ট একটি নমুনা অন্তর্ভুক্ত ইউনিট পরীক্ষা স্বাস্থ্য চেক এন্ডপয়েন্ট প্রত্যাশিত HTTP 200 প্রতিক্রিয়া প্রদান করে তা যাচাই করতে, ALB স্বাস্থ্য পরীক্ষাগুলি ব্যাকএন্ড পরিষেবার স্থিতি যাচাই করতে পারে তা নিশ্চিত করে। স্বাস্থ্য পরীক্ষা এবং SSL শংসাপত্রের বৈধতার জন্য পরীক্ষা লিখে, আমরা সেটআপের সামগ্রিক অখণ্ডতা নিশ্চিত করি। এই ইউনিট পরীক্ষাগুলি 502 ত্রুটি হিসাবে প্রকাশের আগে অ্যাপ্লিকেশন স্তরে যে কোনও সম্ভাব্য ব্যর্থতা সনাক্ত করতে সাহায্য করে, ডাউনটাইম হ্রাস করে এবং AWS-এ জ্যাঙ্গো-সেলেরি সেটআপের সামগ্রিক নির্ভরযোগ্যতা উন্নত করে।

# Nginx configuration file for reverse proxy setup
server {
    listen 80;
    server_name _;
    location /api/ {
        proxy_pass http://127.0.0.1:8000;  # Backend Django instance
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    location / {
        return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
    }
}
server {
    listen 443 ssl;
    server_name _;
    ssl_certificate /path/to/cert.crt;
    ssl_certificate_key /path/to/cert.key;
    location /api/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# Command to run Gunicorn server with SSL handling at ALB
gunicorn --workers 3 --bind 0.0.0.0:8000 myproject.wsgi:application

# Ensure ALLOWED_HOSTS and settings are configured correctly in Django
ALLOWED_HOSTS = ['*']  # Allow all for testing; narrow down for production
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
USE_X_FORWARDED_HOST = True
USE_X_FORWARDED_PORT = True

# Gunicorn logs configuration (to troubleshoot)
loglevel = 'debug'
accesslog = '/var/log/gunicorn/access.log'
errorlog = '/var/log/gunicorn/error.log'

# Step 1: Verify health check configuration on AWS ALB
# Ensure health check target is correct
# Choose HTTPS or HTTP based on backend setup

# Django settings adjustments
CSRF_TRUSTED_ORIGINS = ['https://<alb-dns>', 'https://localhost']
CORS_ALLOW_ALL_ORIGINS = True
CORS_ALLOW_CREDENTIALS = True

# Step 2: Debugging logs from Django
# Add middleware for detailed logging
MIDDLEWARE += ['django.middleware.common.BrokenLinkEmailsMiddleware']

# test_health_check.py for testing ALB health check
from django.test import Client, TestCase
class HealthCheckTest(TestCase):
    def setUp(self):
        self.client = Client()

    def test_health_check(self):
        response = self.client.get('/api/health/')
        self.assertEqual(response.status_code, 200)
        self.assertIn('status', response.json())

# Test certificate expiry
def test_certificate_validity(self):
    cert_info = ssl.get_server_certificate(('localhost', 443))
    self.assertTrue(cert_info.expiry > timezone.now())

জ্যাঙ্গো-সেলারি পরিবেশে SSL এবং ALB স্বাস্থ্য পরীক্ষা উন্নত করা

স্ব-স্বাক্ষরিত শংসাপত্রগুলি পরিচালনা করার সময় AWS ALB-তে SSL সমাপ্তির কনফিগারেশন বর্ণনার মতো সেটআপগুলিতে প্রায়শই উপেক্ষিত একটি দিক। যদিও এই শংসাপত্রগুলি স্থানীয়ভাবে কাজ করতে পারে, ALB এর মাধ্যমে ট্রাফিক পাস করার চেষ্টা করার সময় জটিলতা দেখা দিতে পারে। এটি ঘটে কারণ AWS ALB ব্যাকএন্ড স্বাস্থ্য পরীক্ষার জন্য সঠিকভাবে বিশ্বস্ত শংসাপত্রের প্রয়োজন, যা স্থায়ী হতে পারে HTTP 502 ত্রুটি. এই সমস্যাগুলি এড়াতে উৎপাদন পরিবেশে AWS সার্টিফিকেট ম্যানেজার বা একটি বৈধ, সর্বজনীনভাবে বিশ্বস্ত SSL শংসাপত্র ব্যবহার করা অপরিহার্য।

অতিরিক্তভাবে, ALB-তে কনফিগার করা স্বাস্থ্য পরীক্ষাগুলি অবশ্যই ব্যাকএন্ড সেটআপের সাথে সারিবদ্ধ হতে হবে। জ্যাঙ্গো যদি পিছনে দৌড়ায় গুনিকর্ন, এবং স্বাস্থ্য পরীক্ষা পাথ বা প্রোটোকলের (HTTP বনাম HTTPS) মধ্যে একটি অমিল রয়েছে, ALB ব্যাকএন্ডটিকে স্বাস্থ্যকর হিসাবে চিনতে পারে না, যার ফলে অনুরোধগুলি 502 ত্রুটির সাথে ব্যর্থ হয়৷ হেলথ চেক এন্ডপয়েন্টের সঠিক কনফিগারেশন, পাথ এবং প্রোটোকল উভয়ের সাথে মিলে যাওয়া, নিশ্চিত করে যে ALB ব্যাকএন্ডের সাথে যোগাযোগ করতে পারে। নিশ্চিত করুন যে স্বাস্থ্য পরীক্ষার পথটি বিদ্যমান এবং একটি 200 ঠিক আছে স্ট্যাটাস প্রদান করে।

বিবেচনা করার আরেকটি কারণ হল কিভাবে Nginx সেটআপে জড়িত। একটি বিপরীত প্রক্সি হিসাবে কাজ করার সময়, সঠিকভাবে কনফিগার না করা হলে, এটি হেডারগুলির বাধা বা ভুল ফরওয়ার্ডিং প্রবর্তন করতে পারে। মসৃণ অপারেশন নিশ্চিত করতে, সঠিকভাবে সেট করুন প্রক্সি_পাস নির্দেশাবলী এবং নিশ্চিত করুন যে SSL সমাপ্তি, X-Forwarded-For হেডার সহ, Nginx, Django এবং ALB-এর মধ্যে রাউটিং সমস্যা এড়াতে যথাযথভাবে পরিচালনা করা হয়েছে। সঠিক কনফিগারেশন সংযোগ ত্রুটিগুলিকে ব্যাপকভাবে হ্রাস করবে।