ينطلق فحص صحة الـ ALB من واجهاته الخاصة (المحمية بـ sg-0a71c3e5f9b2d4068) نحو
المنفذ 8080 للـ instances. المجموعة app-souklmarsa-v2، المنسوخة من النموذج القديم
لحقبة nginx، لا تسمح لهذه المجموعة إلا على المنفذ 80. لذلك تُرمى الحِزم المتجهة نحو 8080
بصمت: ومن هنا Target.Timeout (وليس خطأ HTTP)، والـ 504 الذي يقدّمه الـ ALB.
التطبيق بخير: يجيب curl localhost:8080/health بـ 200 على الـ instance. والخطأ 404 على
/health كان سيعطي Target.ResponseCodeMismatch، وليس انتهاء مهلة. والـ network ACL هي الافتراضية
(كل شيء مسموح). ويرى الـ Auto Scaling الـ instances في حالة «Healthy» لأنه يستخدم نوع
الفحص EC2، الذي لا ينظر إلا إلى حالة الآلة.
تمّ حلّ الحادث
التحليل والإصلاح
الإصلاح: السماح لمجموعة الـ ALB على منفذ التطبيق:
aws ec2 authorize-security-group-ingress --group-id sg-0d58e2a9c4f1b7360 --protocol tcp --port 8080 --source-group sg-0a71c3e5f9b2d4068.
ثم التحقق: يجب أن ينتقل aws elbv2 describe-target-health … إلى healthy (3 فحوص ناجحة،
نحو 45 s) ويجب أن يجيب curl -I https://www.souklmarsa.ma بـ 200. ويمكن بعد ذلك إزالة القاعدة 80،
التي صارت غير مفيدة.
حتى لا يتكرر ذلك:
- وصف الـ security groups بـ infrastructure as code واشتقاق منفذ القاعدة من منفذ الـ target group (متغيّر واحد، لا نسختان)؛
- الإشارة دائمًا إلى الـ security group الخاص بالـ ALB كمصدر، وليس أبدًا 0.0.0.0/0؛
- التحقق باستخدام VPC Reachability Analyzer (ALB ← instance:8080) قبل تغيير مجموعة في الإنتاج، وتحويل instance واحدة أولًا؛
- إنذار CloudWatch على
UnHealthyHostCount > 0للـ target group، وتحويل نوع فحص الـ Auto Scaling إلىELBحتى يرى ما يراه الـ load balancer.