Skip to main content

نحوه‌ی عیب‌یابی اپها

در هنگام ساخت، بیلد و دیپلوی اپ خود، در صورتی که با خطایی مواجه شدید، دانستن موارد زیر ممکن است به عیب‌یابی و رفع خطا کمک کند.

وضعیت اپ را مشاهده کنید#

پیش از هر چیز eventهای اپ خود را در لیست اپ‌ها مشاهده کنید. برای این کار بر روی دکمه‌ی وضیعت اپ در لیست اپ کلیک کنید و در توضیحات نمایش داده شده event مربوط به اپ خود را مشاهده کنید.

state

همچنین در صورت دسترسی به kubectl استفاده از دستورات get pods و describe pod در عیب‌یابی کمک کننده هستند. خطاهای رایج در این قسمت شامل ImagePullBackoff و Readiness probe failed هستند. در مورد اول باید نسبت به درست و موجود بودن (اتمام بیلد) داکر ایمیج اپ مطمئن شوید. مورد دوم یعنی آدرس health check اپ، دچار ایراد شده و اپ در وضعیت 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 یا موارد مشابه با درج تیکت پشتیبانی وجود دارد.

مشخصات و تنظیمات اپ خود را مجددا بررسی کنید#

مشخصات اپ خود شامل پورت سرویس، آدرس هاست، آدرس healthcheck، دستور اجرائی، محل mount شدن دیسک، custom config و متغیرهای محیطی را مجددا بررسی نمائید.

آدرس http اپ خطا می‌دهد#

پس از ساخت اپ و در صورت فعال بودن ساخت گواهی SSL، حداکثر چند دقیقه طول می‌کشد که گواهی SSL ساخته و استفاده شود. در این مدت زیردامنه خطای ۴۰۴ می‌دهد. همچنین برای انتشار ریکوردهای dns زیردامنه نیز باید حداکثر چند دقیقه صبر کنید.

مشاهده‌ی خطای Service Unavailable 503 به معنی عدم وجود اپ آماده (ready) است در این صورت باید آدرس healthcheck خود را بررسی کنید. برای اینکه zero downtime deployment داشته باشید، نیاز به ست کردن این آدرس هست و در غیر این‌ صورت در زمان ساخت نسخه‌ی جدید،‌ احتمالا مدت کوتاهی (تا آماده شدن نسخه‌/پاد جدید) سرویس از دسترس خارج می‌شود.

کد خود را Debug کنید#

هر آنچه در standard output برنامه خود بنویسید (مثلا با دستور print در پایتون) از طریق لاگ زمان اجرا قابل مشاهده است. برای دیباگ در زمان اجرا می‌توانید از این امکان استفاده کنید. همچنین امکان اتصال به کانتینر و اجرای کد دلخواه درون آن از طریق kubectl exec وجود دارد.

موارد دیگر#

  1. فایل سیستم ذخیره‌ی فایلها در کانتینرها ماندگار (persistent) نیست و در صورت ریست کانتینر (ذخیره و دیپلوی مجدد) داده‌هایی که در خود داکر ایمیج نیستند،‌ پاک می‌شوند. برای ماندگاری داده‌ها باید از ویژگی دیسک در دارکوب استفاده شود. در این صورت داده‌های موجود در همان پوشه‌ی خاصی که دیسک روی آن mount شده بود، ماندگار خواهند شد.
  2. پادهای در حال اجرا، IP و hostname ثابت ندارند.
  3. مطمئن شوید که مقادیر متغیرهای محیطی مربوط به اتصال به دیتابیس و سرویسهای دیگر به درستی تنظیم شده‌اند و توسط اپ استفاده شده‌اند.