سوالات متداول
با مطالعه سوالات و پاسخ‌های موجود در این صفحه، بخشی از سوالات شما در جهت مشکلات پیش آمده طی استفاده از خدمات هم‌روش پاسخ داده می‌شود.
بعد از دیپلوی موفق، در اتصال به سرویس خود با timeout مواجه می‌شوم. مشکل از چیست؟
مطمئن شوید که سرویس شما به جای 127.0.0.1 روی 0.0.0.0 درحال دریافت request باشد. اگر سرویس قرار است ترافیک خارج از host را نیز دریافت کند، باید روی 0.0.0.0 در حال listen کردن باشد زیرا در این صورت، علاوه‌بر127.0.0.1، ترافیک مربوط به دیگر network adapter های موجود در host را نیز دریافت خواهد کرد. همچنین مطمئن شوید که پورتی که برنامه/پردازه‌ی کانتینری شده روی آن اجرا می‌شود، به درستی ست شده باشد.
چگونه مشکل pull کردن image های رسمی Docker Hub را حل کنم؟
اگر image مورد نظر عضوی از مجموعه image های رسمی Docker Hub (با پیش‌وند library) است، ممکن است لازم باشد این پیش‌وند را به دستور خود اضافه کنید. در حالت عادی و در غیاب این پیش‌وند، Docker Hub آن را به request اضافه می‌کند. با توجه به محدودیت اخیر Docker Hub روی حد نرخ درخواست برای manifest ها، مکانیسمی در زیرساخت هم‌روش برای مدیریت این امر پیاده‌سازی شده که ممکن است به خاطر آن، استفاده از پیش‌وند library ضروری باشد. به عنوان مثال، ممکن است 'docker pull python' با موفقیت انجام نشده و نیاز به استفاده از 'docker pull library/python' باشد.
چگونه می‌توانم به سرویس‌هایم در داخل کلاستر هم‌روش متصل شوم؟
اگر سرویس های مبدا و مقصد هر دو در یک کلاستر هم‌روش هستند،
می‌توانید با آدرس SVC_NAME.NS.svc به مقصد متصل شوید که در آن NS نام namespace و SVC_NAME نام service مقصد است.
اگر سرویس مقصد را با دارکوب دیپلوی کرده‌اید، SVC_NAME همان نام اپ است.
اگر به کلاست ر دسترسی دارید، می‌توانید با دستور kubectl get svc -n NS مقدار آن را پیدا کنید. در غیر این صورت، تیکت ثبت کنید.
برای اپها/پادهای دیسک‌دار به مشکل permissions برخورد می‌کنم و برنامه دسترسی به پوشه‌ی مربوطه ندارد. مشکل از چیست؟
در صورتی که کانتینرِ اپ/پاد شما با userای غیر از root اجرا شود
(که در بسیاری از ایمیجهای رایج به دلایل امنیتی مشاهده می‌شود) دسترسی (خواندن/نوشتن)
در پوشه‌ای که دیسک به آن الصاق شده است را ندارد.
برای بررسی وجود این مسئله می‌توانید به مستندات خود ایمیج مراجعه کنید
یا داخل کانتینر (پس از exec) دستور id را بزنید. برای رفع این مشکل می‌توان به چند طریق عمل کرد.
راه اول استفاده از ایمیجی دیگر، که با یوزر root اجرا می‌شود (مثلا alpine)، به عنوان initcontainer است. در این حالت initcontainerای که دسترسی به دیسک هم دارد، در دستور اجرایی‌اش عملیات chown بر روی پوشه‌ی دیسک را انجام می‌دهد. برای این کار باید user_id و group_idای که پردازه کانتینر اصلی با آن اجرا می‌شود را پیدا کنیم و در دستور زیر وارد کنیم:
chown -R UID:GID /DISK_MOUNT_POINT
راه دیگر استفاده از مفهوم fsGroup در قسمت securityContext مانیفست پاد هست. برای اطلاعات بیشتر به صفحه‌ی توضیحات secrurity context کوبرنتیز مراجعه کنید.
راه دیگر این است که ایمیج اپ/پاد را موقتا به ایمیجی دیگر (مثلا alpine) تغییر دهیم و از طریق تنظیم دستور اجرایی (یا با exec کردن در کانتینرش) دسترسی پوشه‌ی دیسک را (مشابه حالت initcontainerای) اصلاح کنیم و سپس با ویرایش مجدد، آدرس ایمیج را به ایمیج اصلی بازگردانیم.
چرا نباید از تگ latest برای انتخاب ایمیجهای داکر استفاده کنیم؟
تگ latest در گذر زمان و با افزایش نسخه، همواره به یک نسخه خاص و ثابت از ایمیج اشاره نمی‌کند. در صورت وجود تغییرات backward incompatible در نسخه‌ی جدید و دریافت و اجرای مجدد ایمیج latest (به هر دلیلی) مشکلاتی در اجرای برنامه به وجود خواهد آمد. همچنین استفاده از تگ latest عملیات rollback و مشاهده‌ی تاریخچه‌ی تغییرات را سخت می‌کند. توصیه می‌شود که برای انتخاب تگ ایمیج یا از تگ دقیق (مثلا 1.2.3 یا digest) استفاده کنیم و یا در صورت پشتیبانی (عملی!) برنامه از Semantic Versioning از قسمت Major.Minor (مثلا 1.2) به عنوان تگ استفاده کنیم. تا قسمت سوم (قسمت patch)، که بعضا patch های امنیتی در آنها اعمال می‌شوند و حتما با نسخه‌ی minor سازگار هستند، به شکل خودبه‌خود (در صورت دریافت و اجرای مجدد ایمیج) اعمال شوند.
چرا بیلدهای من ناموفق می‌شوند؟
ناموفق شدن بیلد دلایل مختلفی می‌تواند داشته باشد. برخی از این دلایل عبارتند از:
- مشکلات شبکه و مولفه‌های زیرساختی. در این موارد با retry بیلد ممکن است مشکل برطرف شود.
- رسیدن به محدودیت زمان بیلد ماهانه. هر سازمان دارکوب در طول یک ماه می‌تواند حداکثر ۱۰۰ ساعت بیلد رایگان داشته باشد. در صورتی که خطای x را مشاهده کنید، یعنی به این محدودیت رسیده‌اید.
- طولانی شدن زمان بیلد. در صورتی که زمان بیلد از دو ساعت فراتر رود، بیلد شما توسط دارکوب kill خواهد شد.
- مصرف حافظه بالا.
همچنین محدودیت حافظه‌ی بیلد در دارکوب ۲ گیگابایت است و در صورتی که پردازه‌ی بیلد به این محدودیت برخورد کند، ممکن است kill شود. در بیلدهای nodejs، می‌توانید با ست کردن متغیر
NODE_OPTIONSاین محدودیت رم را در اپ خود مشخص کنید. توضیحات تکمیلی در این مورد در صفحه‌ی ساخت اپ ری‌اکت داده شده است.
چرا دیتای ذخیره‌شده در اپ پاک شده‌اند؟
فایل سیستم ذخیره‌ی فایلها در کانتینرها ماندگار (persistent) نیست و در صورت ریست کانتینر، داده‌هایی که در خود داکر ایمیج نیستند، پاک می‌شوند. برای ماندگاری داده‌ها باید از ویژگی دیسک در دارکوب استفاده شود. در این صورت داده‌های موجود در همان پوشه‌ی خاصی که دیسک روی آن mount شده بود، ماندگار خواهند شد. این ویژگی مخصوصا در استفاده از اپهای دیتابیسی اهمیت بیشتری پیدا می‌کند.
آیا دیتای غیر ماندگار (ephemeral) در اپ محدودیت حجم دارد؟
بله. در دارکوب مقدار محدودی دیتا به شکل ephemeral می‌توان نگه‌داشت و برای حجم زیاد بهتر است از دیسک استفاده کنید که در سوال قبلی به آن پاسخ داده شده است. برای debugging از این حجم استفاده کنید.
چرا پیام «مقدار دیسک به حداکثر رسیده است» را مشاهده می‌کنم؟
این مورد در شرایطی رخ می‌دهد که دیسک سرور مربوطه ظرفیت افزایش ندارد. در این شرایط و در صورت نیاز به افزایش ظرفیت دیسک می‌بایست عملیات انتقال دیسک به سروری دیگر انجام شود. این عملیات نیازمند downtime برای اپلیکیشن مربوط به آن است. مدت زمان مورد نیاز برای فرآیند انتقال به ازای هر GB دیسک ۱ الی ۲ دقیقه تخمین زده می‌شود. در صورت نیاز به افزایش ظرفیت دیسک، حجم افزایشی مورد نظر خود را از طریق تیکت به پشتیبانی فنی اعلام کنید.
چرا حساب کاربری من تعلیق شده است؟
در صورتی که از بستر دارکوب برای انجام فیشینگ استفاده نمایید یا ابزارهای امنیتی علیه سرویسه ای دیگران اجرا نمایید حساب شما تعلیق خواهد شد.
برای این که سالم بودن اپ من به شکل دوره‌ای و اتوماتیک بررسی شود چه کاری باید انجام دهم؟
در کوبرنتیز امکانی وجود دارد که می‌توانید یک
endpoint
پروتکل
http
را مشخص کنید تا به شکل منظم به آن درخواست دهد و در صورتی که
status code
مناسب دریافت نکند، آن اپ را ناسالم و وضعیت آن را
Not Ready
می‌کند. این
endpoint
را
Readiness Probe (HTTP)
می‌نامیم. به این شکل وقتی اپ شما در شرایط ناسالم قرار گرفت متوجه آن خواهید شد.
علاوه بر این وقتی دیپلوی جدید می‌کنید (مثلا به پروژه‌ی خود در هم‌گیت پوش می‌کنید و نسخه‌ی جدید از اپ دیپلوی می‌شود).
تا زمانی که این
Readiness Probe (Health Check)
موفقیت‌آمیز نباشد، ترافیک کاربران را به آن نمی‌فرستد و نسخه‌ی قبلی را هم پایین نمی‌آورد.
این کار باعث می‌شود احتمال داشتن
down time
موقع آپدیت اپ کمتر شود.
در صفحه‌ی «اطلاعات عمومی» اپ می‌توانید در بخش
"Readiness Probe (HTTP)"
این
endpoint
را تعیین کنید. اگر نیاز دارید که با یک دستور سالم بودن اپ را بررسی کنید از
custom config
استفاده کنید.
گاهی لازم می‌شود یک اپ دیسک‌دار به نود دیگر منتقل شود. دلیل این موضوع چیست؟
در زیرساخت هم‌روش برای اپهای دیسک‌دار از دیسک لوکال استفاده می‌شود. به این معنی که وقتی پاد دیسک‌دار روی نود قرار می‌گیرد، دیسک آن روی همان نود ساخته می‌شود. ممکن است دیسک هر یک از این نودها پر شود و دیگر نتوان دیسک بیشتری به پادهای روی آن داد. در این زمان لازم می‌شود که برای افزایش دیسک، پاد و دیتای دیسک آن به نود دیگری که ظرفیت دارد منتقل شود.
گاهی لازم می‌شود به سرویس‌های خارج از هم‌روش یک آیپی ثابت اعلام کنیم. برای زیرساخت هم‌روش این آیپی چه مقداری است؟
برای اعلام آیپی ثابت برای درگاه بانک، سرویس SMS، یا هرگونه سرویس دیگری که نیاز به وایت‌لیست کردن آیپی ثابت دارد، می‌توانید از آیپی خروجی کلاستر استفاده کنید. این آیپی برای هریک از کلاسترهای هم‌روش متفاوت است. بعد از ساخت اپ در صفحه‌ی «اطلاعات عمومی» اپ کنار نام کلاستر روی "i" کلیک کنید تا این آیپی برای شما نمایش داده شود.
برای اتصال دو اپ به یکدیگر چه کار باید کرد؟
وقتی برای اپ پورتی تعیین می‌شود، به شکل داخلی یک رکورد DNS برای آن ساخته می‌شود که با استفاده از آن می‌توان به آن اپ دسترسی پیدا کرد. به این رکورد «آدرس داخلی» می‌گوییم. این آدرس را می‌توان در صفحه‌ی اطلاعات اپ دید.
برای مثال فرض کنید یک اپ بک‌اند دارید که باید به دیتابیس وصل شود. در اپ بک‌اند با یک متغیر محیطی آدرس دیتابیس را بگیرید و در قسمت "Environment Variables" در تنظیمات دارکوب مقدار این متغیر را برابر آدرس داخلی دیتابیس قرار دهید.
آیا امکان دسترسی از طریق SSH به اپها وجود دارد؟
نمی‌توان از طریق
SSH
به اپها دسترسی پیدا کرد. به جای آن می‌توانید از
kubectl exec
استفاده کنید که در
این مستند
نحوه‌ی کار با آن آمده است یا از تب «ترمینال» در اپ استفاده کنید.
برای ساخت کانتینر از روی برخی ایمیج‌ها نیاز به دسترسی privileged هست. مثل --cap-add در داکر. این کار را چگونه می‌توان در دارکوب انجام داد؟
اجرای کانتینر با دسترسیِ privileged در کلاسترهای عمومی دارکوب ممکن نیست.
آیا در پلتفرم ابری دارکوب می‌توان میل سرور ساخت؟
برای ایجاد میل سرور نیاز است تعدادی پورت مشخص به بیرون اکسپوز شوند. در پلتفرم ابری از آیپی مشترک استفاده می‌شود و نمی‌توان این پورت‌های ثابت را به یک اپ اختصاص داد. در نتیجه نمی‌توان چنین سرویسی ساخت. می‌توانید از سرویس‌های موجود دیگر مانند Yandex استفاده کنید.
چگونه در درخواست‌های HTTP می‌توان آیپی واقعی کاربران را به دست آورد؟
می‌توانید مقدار هدر
X-Real-Ip
را استفاده کنید.
چطور timezone کانتینر را تغییر دهیم؟
برای تغییر timezone کافی است دو خط زیر را داخل داکرفایل خود اضافه کنید.
ENV TZ="Your Timezone"
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
می‌توانید لیست timezoneها را در ویکی پدیا ببینید.
چگونه می‌توان در دارکوب کران جاب (cron job) اجرا کرد؟
یک راه برای اجرای کران جاب این است که cron را نصب کنید و جاب‌های خود را به آن دهید. نصب cron و تنظیمات جاب‌ها باید در داکرفایل انجام و ایمیج آن ساخته شود. این لینک یک نمونه آموزش برای این کار است. در پلتفرم ابری دارکوب برای اجرای این جاب‌ها باید یک اپ جدا از نوع منبع گیت یا داکر ایمیج بسازید.
از این روش بهتر این است که متناسب با زبان و فریم‌ورکی که استفاده می‌کنید ابزاری انتخاب کنید که برای شما این جاب‌ها را انجام دهد و به شکل programmatic کنترلش کنید. مثلا celery که برای فریم‌ورک‌های زیادی قابل استفاده است و در این لینک اطلاعات بیشتری می‌توانید در موردش پیدا کنید.