AWS ALB کا استعمال کرتے ہوئے Django-Celery کنفیگریشن میں ریکرنٹ HTTP 502 خراب گیٹ وے کے مسائل کو ٹھیک کرنا

AWS ALB کے ساتھ Django-Celery میں مشترکہ چیلنجز

Celery کے ساتھ چلنے والی اور AWS پر میزبانی کرنے والی Django ایپلیکیشنز کے لیے ایک مضبوط فن تعمیر کو ترتیب دینا ہمیشہ سیدھا نہیں ہوتا ہے۔ AWS Application Load Balancer (ALB) جیسے لوڈ بیلنس کو مربوط کرتے وقت، مستقل HTTP 502 خراب گیٹ وے کی خرابی جیسے مسائل پیدا ہو سکتے ہیں۔ بغیر کسی رکاوٹ کے آپریشن کے لیے بنیادی وجہ کو سمجھنا بہت ضروری ہے۔

یہ مخصوص خرابی متعدد غلط کنفیگریشنز سے پیدا ہوسکتی ہے، بشمول SSL مسائل، صحت کی جانچ میں ناکامی، یا یہاں تک کہ فرنٹ اینڈ اور بیک اینڈ کے درمیان غلط مواصلت۔ فرنٹ اینڈ کے لیے Docker کنٹینرز اور Django/Celery ایپلیکیشن کے ساتھ، ان تہوں کو سنبھالنا پیچیدہ ہو سکتا ہے۔

ایک اور اہم علاقے میں SSL سرٹیفکیٹ شامل ہوتے ہیں، خاص طور پر جب خود دستخط شدہ سرٹیفکیٹ جانچ کے لیے استعمال کیے جاتے ہیں۔ اگرچہ وہ مقامی طور پر ٹھیک کام کر سکتے ہیں، انہیں AWS ماحول میں تعینات کرنے سے اکثر مطابقت یا حفاظتی مسائل کا تعارف ہوتا ہے جنہیں احتیاط سے حل کرنے کی ضرورت ہوتی ہے۔

اس مضمون میں، ہم اس طرح کے سیٹ اپ میں مستقل HTTP 502 غلطیوں کے پیچھے ممکنہ وجوہات کا جائزہ لیں گے۔ ہم صحت کی جانچ کی ناکامیوں کو دریافت کریں گے، Django اور AWS کے لاگز کی جانچ کریں گے، اور اس مسئلے کو مؤثر طریقے سے حل کرنے کے لیے ٹربل شوٹنگ کے اقدامات فراہم کریں گے۔

Django-Celery اور ALB انٹیگریشن اسکرپٹ کو سمجھنا

اوپر دی گئی مثال میں فراہم کردہ اسکرپٹس کو AWS ALB (ایپلی کیشن لوڈ بیلنسر) کے ساتھ Django-Celery سیٹ اپ میں ہونے والی HTTP 502 خراب گیٹ وے کی مسلسل خرابیوں کو دور کرنے کے لیے ڈیزائن کیا گیا ہے۔ پہلا اسکرپٹ ایک Nginx ریورس پراکسی کا استعمال کرتا ہے تاکہ فرنٹ اینڈ سے EC2 مثالوں پر چلنے والی Django ایپلیکیشن پر درخواستیں بھیج سکے۔ Nginx کنفیگریشن اس بات کو یقینی بناتی ہے کہ پورٹ 80 پر آنے والی تمام ٹریفک کو محفوظ کنکشن کے لیے پورٹ 443 پر بھیج دیا جائے، جبکہ proxy_pass API کی درخواستوں کو مناسب بیک اینڈ سرور پر بھیجتا ہے۔ یہ سیٹ اپ ALB اور Django ایپلیکیشن کے درمیان محفوظ اور موثر مواصلت کو قابل بناتا ہے، SSL کو ہینڈل کرنے اور مناسب طریقے سے روٹنگ کو ممکن بناتا ہے۔

دوسرا اسکرپٹ پر توجہ مرکوز کرتا ہے۔ گنی کارن—جانگو ایپ کو پیش کرنے کے لیے استعمال ہونے والا ایپلیکیشن سرور۔ Gunicorn کو تمام نیٹ ورک انٹرفیس اور پورٹ 8000 سے منسلک کرکے، یہ یقینی بناتا ہے کہ Django ایپ ALB سے آنے والی ٹریفک کے لیے قابل رسائی ہے۔ مزید برآں، جینگو کی کنفیگریشن سیٹنگز، جیسے 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 میں Django-Celery سیٹ اپ کی مجموعی وشوسنییتا کو بہتر بناتے ہیں۔

# 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())

Django-Celery ماحول میں SSL اور ALB ہیلتھ چیکس کو بہتر بنانا

سیٹ اپ میں اکثر نظر انداز کیا جانے والا ایک پہلو جیسا کہ بیان کیا گیا ہے وہ ہے AWS ALB میں SSL ختم کرنے کی ترتیب جب خود دستخط شدہ سرٹیفکیٹس کو ہینڈل کرتے ہیں۔ اگرچہ یہ سرٹیفکیٹ مقامی طور پر کام کر سکتے ہیں، لیکن جب ٹریفک ALB سے گزرنے کی کوشش کی جائے تو پیچیدگیاں پیدا ہو سکتی ہیں۔ ایسا اس لیے ہوتا ہے کیونکہ AWS ALB کو بیک اینڈ ہیلتھ چیکس کے لیے مناسب طریقے سے بھروسہ مند سرٹیفکیٹ درکار ہوتے ہیں، جو مستقل ہونے کا باعث بن سکتے ہیں۔ HTTP 502 غلطیاں. ان مسائل سے بچنے کے لیے پیداواری ماحول میں AWS سرٹیفکیٹ مینیجر یا ایک درست، عوامی طور پر قابل بھروسہ SSL سرٹیفکیٹ استعمال کرنا ضروری ہے۔

مزید برآں، ALB پر کنفیگر کیے گئے ہیلتھ چیکس کو بیک اینڈ سیٹ اپ کے ساتھ ہم آہنگ ہونا چاہیے۔ اگر جینگو پیچھے بھاگتا ہے۔ گنی کارن، اور صحت کی جانچ کے راستوں یا پروٹوکولز (HTTP بمقابلہ HTTPS) کے درمیان کوئی مماثلت نہیں ہے، ALB بیک اینڈ کو صحت مند تسلیم نہیں کرسکتا ہے، جس کی وجہ سے درخواستیں 502 کی خرابی کے ساتھ ناکام ہوجاتی ہیں۔ ہیلتھ چیک اینڈ پوائنٹ کی مناسب ترتیب، راستے اور پروٹوکول دونوں سے مماثل، اس بات کو یقینی بناتی ہے کہ ALB بیک اینڈ کے ساتھ بات چیت کر سکتا ہے۔ اس بات کو یقینی بنائیں کہ ہیلتھ چیک پاتھ موجود ہے اور 200 OK اسٹیٹس واپس کرتا ہے۔

غور کرنے کا ایک اور عنصر یہ ہے کہ Nginx سیٹ اپ میں کیسے شامل ہے۔ ریورس پراکسی کے طور پر کام کرتے ہوئے، اگر مناسب طریقے سے ترتیب نہ دی گئی ہو، تو یہ رکاوٹیں یا ہیڈرز کی غلط فارورڈنگ کو متعارف کرا سکتا ہے۔ ہموار آپریشن کو یقینی بنانے کے لیے، درست طریقے سے سیٹ کریں۔ proxy_pass ہدایات اور اس بات کو یقینی بنائیں کہ X-Forwarded-For ہیڈر کے ساتھ SSL ختم کرنے کو Nginx، Django اور ALB کے درمیان روٹنگ کے مسائل سے بچنے کے لیے مناسب طریقے سے ہینڈل کیا گیا ہے۔ درست ترتیب کنکشن کی غلطیوں کو کافی حد تک کم کر دے گی۔