عیب‌یابی استک بدون پاک کردن داده

در پوشهٔ تمرین کار کنید. این فرمان‌ها وضعیت را می‌خوانند و داده حذف نمی‌کنند. گزارش برنامهٔ واقعی ممکن است مقدار خصوصی داشته باشد؛ پیش از اشتراک‌گذاری آن را بررسی و پاک‌سازی کنید.

sudo docker compose config --quiet
sudo docker compose ps -a
sudo docker compose logs --tail 50 web gateway metrics
sudo docker stats --no-stream
sudo docker compose port gateway 8080
df -h

نخستین خطا را بخوانید، نه فقط پیام پایانی شکست. لایه‌ها را جدا بررسی کنید:

• رد شدن تنظیمات: تورفتگی، مسیر فایل و متغیرهای خالی را پیش از اجرا بررسی کنید.
• توقف یا اجرای مجدد پی‌درپی: گزارش همان سرویس را بخوانید. مشکل مجوز، تنظیم ناقص، نسخهٔ ناسازگار پایگاه داده و کمبود حافظه راه‌حل یکسان ندارند.
• رد شدن اتصال: فرایند و پورت منتشرشده را بررسی کنید. تغییر نام، برنامهٔ متوقف را اجرا نمی‌کند.
• 404: نام درخواست و مسیر را بررسی کنید؛ ممکن است پاسخ خود برنامه باشد.
• 502 یا 504: پراکسی پاسخ معتبر از مقصد نگرفته است. نام سرویس، پورت، شبکه، آمادگی و گزارش را بررسی کنید.
• حلقهٔ ورود: نشانی پایهٔ برنامه، کوکی، HTTPS و تنظیم پراکسی مورد اعتماد را بررسی کنید. احراز هویت را برای پنهان کردن مشکل خاموش نکنید.
• پر شدن دیسک: خروجی df -h، df -i و sudo docker system df را مقایسه کنید. پیش از حذف، عامل رشد را پیدا کنید. پاک‌سازی کلی volume راه‌حل معمول نیست.

فقط برنامهٔ تمرینی را متوقف کنید

این آزمایش عمداً سرویس وب قابل‌حذف را متوقف می‌کند. آن را در پروژهٔ واقعی اجرا نکنید.

sudo docker compose stop web
curl --max-time 20 -i --resolve lab.test:18080:127.0.0.1 http://lab.test:18080/
sudo docker compose logs --tail 20 gateway
sudo docker compose start web
curl --fail --resolve lab.test:18080:127.0.0.1 http://lab.test:18080/

در زمان توقف، به‌جای HTML باید خطای گیت‌وی یا پایان مهلت بگیرید. پس از اجرا، چند ثانیه صبر و دوباره امتحان کنید؛ صفحه باید برگردد. Prometheus ممکن است در همین زمان برای گیت‌وی up=1 نشان دهد، چون متریک گیت‌وی قابل‌خواندن است حتی وقتی برنامه قطع است. به همین دلیل بررسی دسترس‌پذیری مکمل متریک است.

اگر کانتینر کشته شده، فیلد State.OOMKilled را با خروجی محدود docker inspect --format بخوانید و محدودیت حافظه را با مصرف مقایسه کنید. خروجی کامل inspect را منتشر نکنید؛ ممکن است راز داشته باشد.

نشانهٔ مشکل، خطای مرتبط، یک تغییر و نتیجه را ثبت کنید. این یادداشت از فهرست راه‌اندازی‌های مجدد مفیدتر است. مرحلهٔ بعد: پشتیبان و بازیابی.