نحوه‌ی عیب‌یابی اپها
در هنگام ساخت، بیلد و دیپلوی اپ خود، در صورتی که با خطایی مواجه شدید، دانستن موارد زیر ممکن است به عیب‌یابی و رفع خطا کمک کند.
وضعیت اپ را مشاهده کنید
پیش از هر چیز eventهای اپ خود را در لیست اپها مشاهده کنید. برای این کار بر روی دکمه‌ی وضیعت اپ در لیست اپ کلیک کنید و در توضیحات نمایش داده شده event مربوط به اپ خود را مشاهده کنید.
همچنین در صورت دسترسی به kubectl استفاده از دستورات get pods و describe pod در عیب‌یابی کمک کننده هستند.
خطاهای رایج در این قسمت شامل ImagePullBackoff و Readiness probe failed هستند.
در مورد اول باید نسبت به درست و موجود بودن (اتمام بیلد) داکر ایمیج اپ مطمئن شوید.
مورد دوم یعنی آدرس Readiness Probe (HTTP) اپ، دچار ایراد شده و اپ در وضعیت notready قرار گرفته است.
لاگهای Build و Runtime اپ خود را مرور کنید
لاگ پادهای در حال اجرا از صفحه‌ی اپ و تب Logs قابل مشاهده هستند. ابتدا این بخش را مشاهده کنید تا ببینید آیا exception یا خطایی رخ داده است یا خیر. همچنین از طریق دسترسی kubectl هم می‌توانید لاگ پادها را ببینید.
برای مشاهده‌ی لاگ بیلدها، در صورت استفاده از سیستم CI/CD گیتلب، به صفحه‌ی مربوط به همان pipeline مراجعه کنید. در صورتی‌که از سیستم بیلد داخل خود دارکوب استفاده می‌کنید از تب Builds در صفحه‌ی هر اپ می‌توانید لیست بیلدها و لاگ هر بیلد را ببینید. مشکلات رایجتر در failed شدن بیلدها شامل موارد زیر هستند:
- خطا در داکرفایل
برای اطمینان از اینکه داکرفایل شما به درستی اجرا می‌شود، می‌توانید آن را روی سیستم خود اجرا و دیباگ کنید.
همچنین با بررسی لاگ بیلد، خط مشکل‌دار و نوع خطا مشخص می‌شود.
در صورت مشکل در دریافت base image از داکرهاب (به دلیل تحریم) می‌توانید از hub.hamdocker.ir به شکل زیر استفاده کنید:
FROM hub.hamdocker.ir/IMAGE_NAME:IMAGE_TAG
- خطای ارتباطی(شبکه‌ای)
بعضا به دلیل مشکلات ارتباطی/شبکه‌ای داخلی یا خارجی ممکن است موقتا سرعت دریافت فایلها کم شود. این نوع خطاها ممکن است با retry بیلد بعد از چند دقیقه برطرف شوند.
در صورتی که اثری از آخرین کامیت گیت شما در لیست بیلدها نبود، ممکن است دلیلش قطعی موقت ارتباط دارکوب با گیتهاب (یا گیتلب سازمانی شما) بوده باشد. در این صورت دکمه «بیلد و دیپلوی آخرین کامیت» را بزنید.
- خطای کمبود منابع
بیلدرهای دارکوب، که مسئولیت ساخت داکر ایمیج از داکرفایل را دارند، محدودیتی روی منابع مصرفی و زمان اجرای بیلد دارند.
یکی از مشکلات رایج در بیلد اپلیکیشنهای nodeمبنا مشکل کمبود RAM هست که از طریق وجود خط
exit code: 137
در لاگ بیلد می‌توان آن را مشاهده کرد. در مستند
ساخت اپ React JS
به نحوه‌ی رفع آن اشاره شده است.
در صورت بروز خطاهای دیگر، ابتدا یک بار retry کنید. اگر مجددا مشکل تکرار شد (در صورتی‌که مطمئن هستید ایراد از سمت کد نیست) برای بررسی بیشتر از طریق پشتیبانی ما را در جریان بگذارید.
جزئیات برنامه و زبان مورد استفاده را بررسی کنید
ب روز خطا ممکن است مربوط به نوع استفاده از زبان برنامه‌نویسی یا داکرایمیج باشد و به همین دلیل مرور آن از جمله مراحل توصیه شده برای عیب‌یابی است. شما همچنین می‌توانید بخش اپها و دیگر اپ‌های رایج مستندات هم‌روش را مرور کنید، شاید به مشکل شما اشاره شده باشد. اطلاعات بیشتر هر داکرایمیج را معمولا می‌توانید از صفحه‌ی مربوط به همان ایمیج در داکرهاب بررسی کنید.
مصرف منابع مربوط به اپ خود را بررسی کنید
در تب مصرف منابع هر اپ (یا در صورت داشتن grafana)، می‌توانید مقدار مصرف منابع (RAM, CPU, Disk) اپ را مشاهده کنید. اگر بر اساس این نمودارها تشخیص دادید CPU، RAM و یا دیسک مورد نیاز اپ شما بیش از میزان تخصیص داده شده است (به سقف مقدارش رسیده یا نزدیک شده است) می‌توانید منابع اپ خود را افزایش دهید. مخصوصا برای Disk , RAM پیش‌بینی مصرف منبع نقش مهمی در عدم بروز مشکل در آینده دارد.
از راهکارها/نرم‌افزارهای جانبی برای مانیتورینگ و خطایابی استفاده کنید
برای خطایابی دقیقتر می‌توان از ابزارهایی مثل Sentry استفاده کرد. همچنین در صورت نیاز به جمع‌آوری و ذخیره‌سازی پیشرفته‌تر متریک و لاگ اپها، امکان استقرار استک Prometheus/Grafana و EFK یا موارد مشابه با درج تیکت پشتیبانی وجود دارد.
مشخصات و تنظیمات اپ خود را مجددا بررسی کنید
مشخصات اپ خود شامل پورت سرویس، آدرس دامنه، آدرس Readiness Probe (HTTP)، دستور اجرائی، محل mount شدن دیسک، custom config و متغیرهای محیطی را مجددا بررسی نمائید.
آدرس http اپ خطا می‌دهد
پس از ساخت اپ و در صورت فعال بودن ساخت گواهی SSL، حداکثر چند دقیقه طول می‌کشد که گواهی SSL ساخته و استفاده شود. در این مدت زیردامنه خطای ۴۰۴ می‌دهد. همچنین برای انتشار رکوردهای dns زیردامنه نیز باید حداکثر چند دقیقه صبر کنید.
مشاهده‌ی خطای Service Unavailable 503 به معنی عدم وجود اپ آماده (ready) است در این صورت باید آدرس Readiness Probe (HTTP) خود را بررسی کنید. برای اینکه zero downtime deployment داشته باشید، نیاز به ست کردن این آدرس هست و در غیر این صورت در زمان ساخت نسخه‌ی جدید، احتمالا مدت کوتاهی (تا آماده شدن نسخه/پاد جدید) سرویس از دسترس خارج می‌شود.
کد خود را Debug کنید
هر آنچه در standard output برنامه خود بنویسید (مثلا با دستور print در پایتون) از طریق لاگ زمان اجرا قابل مشاهده است. برای دیباگ در زمان اجرا می‌توانید از این امکان استفاده کنید. همچنین امکان اتصال به کانتینر و اجرای کد دلخواه درون آن از طریق kubectl exec وجود دارد.
موارد دیگر
- فایل سیستم ذخیره‌ی فایلها در کانتینرها ماندگار (persistent) نیست و در صورت ریست کانتینر (ذخیره تغییرات مجدد) داده‌هایی که در خود داکر ایمیج نیستند، پاک می‌شوند. برای ماندگاری داده‌ها باید از ویژگی دیسک در دارکوب استفاده شود. در این صورت داده‌های موجود در همان پوشه‌ی خاصی که دیسک روی آن mount شده بود، ماندگار خواهند شد.
- پادهای در حال اجرا، IP و hostname ثابت ندارند.
- مطمئن شوید که مقادیر متغیرهای محیطی مربوط به اتصال به دیتابیس و سرویسهای دیگر به درستی تنظیم شده‌اند و توسط اپ استفاده شده‌اند.
- ممکن است به دلیل نگهداری حجم زیادی از فایل در داخل کانتینر پاد شما evict شده باشد. دلیل این اتفاق این است که مقدار محدودی فضا برای ذخیره‌سازی به کانتینر شما در دارکوب اختصاص داده شده است و از آن باید برای debugging استفاده شود. در صورتی که قصد ذخیره‌سازی و ماندگاری داده‌های خود را دارید باید از دیسک استفاده کنید که در مورد 1 به آن اشاره شده است.
چطور مشکل اتصال به kubectl را حل کنیم؟
۱. ابتدا دسترسی kubectl سازمان خود را بررسی کنید.
۲. اگر در مرحله اول مشکلی در ارتباط مشاهده نکردید، برای اطمینان از صحت authenticate شدن یکبار cache مربوط به oidc-login را حذف کنید و مجدد تلاش کنید:
$ rm -rf .kube/cache/oidc-login/
موارد زیر می‌تواند به ریشه‌یابی و حل سریع‌تر مشکل به شما کمک کند:
توجه داشته باشید که مکانیزم authentication نیاز دارد که پورت ۸۰۰۰ سیستم شما توسط پردازه دیگری اِشغال نشده باشد.
ترجیحا از ورژن کلاینت kubectl 1.24 به بالا استفاده کنید. برای چک کردن ورژن کلاینت کافی است از دستور kubectl version استفاده کنید. اگر کماکان پس از انجام این مراحل مشکل برقرار بود، لطفاً خروجی دستور زیر را به تیکت پیوست کنید:
kubectl get po -v8
خطا در سمت اپلیکیشن را چطور برطرف کنیم؟
۱. مطمئن شوید که پورت درستی را به اپ خود اختصاص داده‌اید.
۲. سرویس خود را تنظیم کنید که بر روی 0.0.0.0 به درخواست‌ها پاسخ دهد.
۳. لاگ اپلیکیشن خود را بررسی کنید تا از عملکرد صحیح آن مطمئن شوید.
۴. در صورتی که به‌تازگی سرویس را آپدیت کرده‌اید احتمالا مشکلی وجود ندارد و پس از وقفه‌ای کوتاه، سرویس شما در دسترس قرار خواهد گرفت. می‌توانید با اضافه کردن Readiness Probe (HTTP) سرویس خود را بدون داون‌تایم آپدیت کنید.
۵. در صورتی که کماکان مشکل وجود دارد از طریق پشتیبانی با تیم فنی ما در ارتباط باشید.
۵۰۳ service unavailable به چه معنی است و چطور آن را رفع کنیم؟
این پیام به این معنی است که سرویس مورد نظر در دسترس نیست. اگر شما مدیر اپلکیشن هستید چند کار زیر را انجام دهید:
۱. مطمئن شوید اپلکیشن مربوطه روشن است و پادهای آن در وضعیت سالمی قرار دارند.
۲. اگر به‌تازگی اپ خود را روشن یا ریست کرده‌اید، احتمالا اپ شما در وضعیت استارتاپ قرار دارد و نمی‌تواند پاسخ‌گوی درخواست شما باشد؛ در این شرایط با کمی صبر سرویس شما در دسترس قرار خواهد گرفت.