Skip to main content

تنظیمات Custom Config

تنظیمات قابل ویرایش در دارکوب​

Strategy​

اگر بخواهید ورژن جدیدی از اپ خود را بالا بیاورید، کوبرنتیز باید اپ ورژن قدیمی را پاک کرده و آن را با اپ جدید جایگزین کند. بخصوص اگر اپ‌ شما Replica داشته باشد، انتخاب استراتژی مناسب نقش بسزایی در مدیریت داون‌تایم و خطاهای احتمالی پیدا می‌کند. کوبرنتیز دو استراتژی برای این فرآیند در نظر گرفته است.

RollingUpdate​

این حالت، استراتژی پیش‌فرض کوبرنتیز و دارکوب است. اول ورژن جدید اپ در کنار ورژن قدیمی بالا می‌آید. بعد از اینکه مشخص شد پاد جدید سالم است، پاد قدیمی حذف می‌شود. اگر چند پاد وجود داشته باشد، این فرآیند به صورت تدریجی برای همه پادها اتفاق می‌افتد. به این ترتیب اپلیکیشن شما بدون هیچ داون‌تایمی اپگرید می‌شود.

Recreate​

در این استراتژی، اول همه پادهای ورژن‌های قدیمی به طور کامل پاک می‌شوند. سپس همه پادهای ورژن‌ جدید، همگی به صورت همزمان بالا می‌آیند. به دلیل وقفه‌ای که بین پاک شدن و ساخت مجدد اپ‌ها وجود دارد، این استراتژی داون‌تایم خواهد داشت. اما برخلاف RollingUpdate، همه تغییرات را یکجا به کاربر عرضه می‌کند و بنابراین در اپدیت‌های بزرگ، احتمال بروز خطا برای کاربر را پایین‌ می‌آورد.

نحوه تنظیم Strategy​

فرمت استراتژی rollingUpdate، دو فیلد قابل تنظیم دارد. هردو این مقادیر می‌توانند به شکل عددی (۱) یا درصدی (10%) تنظیم شوند.

  • MaxUnavailable: مشخص می‌کند که در آن واحد، چند تا از کل پادهای در حال جایگزینی اجازه دارند از دسترس خارج شوند.
  • MaxSurge: مشخص می‌کند که در هر لحظه، مجموع تعداد پادهای ورژن قدیمی و جدید چقدر می‌تواند از تعداد اپ‌های نهایی، بیشتر باشد. به عنوان مثال اگر ۳ پاد داریم و MaxSurge را 33% ست کنیم، تعداد کل پادهای ورژن قدیمی و جدید حداکثر می‌تواند ۴ تا باشد.

به بخش CustomConfig بروید و مقدارهای مورد نظر خود را طبق فرمت زیر وارد کنید:

# rollingUpdate
strategy:
  rollingUpdate:
    maxSurge: 3
    maxUnavailable: 1
  type: RollingUpdate

# Recreate
strategy:
  type: Recreate

Configmap​

ممکن است اپلیکیشن شما در فرآیند اجرا، به یک فایل تنظیمات یا مقادیر read-only خاصی نیاز داشته باشد که نیاز است در فایل یا فولدر خاصی ذخیره شوند؛ مثلا آدرس و پورت دیتابیس، یا فایل کانفیگ nginx، یا کانفیگ لاراول. از آنجایی که این فایل‌ها مختصر هستند و در داخل اپلیکیشن هم بازنویسی خاصی روی آنها صورت نمی‌گیرد، می‌توان به جای دیسک از کانفیگ‌مپ برای اضافه کردن انها به اپ استفاده کرد. کانفیگ‌مپ یک فایل یا فولدر را در آدرس مورد نظر شما، روی پاد اپ اضافه می‌کند و با هر بار ریستارت اپ، مقادیر این فایل‌ها بدون تغییر باقی می‌مانند.

اضافه کردن یک پوشه به عنوان کانفیگ‌مپ​

کانفیگ‌مپ زیر، محتوای فعلی پوشه conf.d را به صورت کامل پاک می‌کند و فایل nginx.conf را در آن قرار می‌دهد. اگر این پوشه وجود نداشت، آن را ایجاد می‌کند:

configmap:
 configmapItems:
   nginx-config:
     path: /etc/nginx/conf.d
     value:
       nginx.conf: |-
         server {
           listen 80;
         root /usr/share/nginx/html;
         }

به این ترتیب، محتوای فعلی پوشه conf.d پاک شده و با محتوای جدید، یعنی یک فایل nginx.conf جایگزین می‌شود. در صورت تمایل می‌توانید فایل‌های دیگری را نیز در قسمت value بعد از nginx.conf اضافه کنید تا داخل همین پوشه ایجاد شوند.

اضافه کردن یک فایل به عنوان کانفیگ‌مپ​

در صورت لزوم، می‌توانید به جای کل پوشه، تنها یک فایل از آن را بازنویسی کنید. برای این کار متغیر subPath را به کانفیگ‌مپ اضافه کنید:

configmap:
 configmapItems:
   nginx-config:
     path: /etc/nginx/conf.d/nginx.conf
     subPath: nginx.conf
     value:
       nginx.conf: |-
         server {
           listen 80;
         root /usr/share/nginx/html;
         }

به این ترتیب، فایل nginx.conf در داخل پاد از آدرس /etc/nginx/conf.d/nginx.conf در دسترس قرار می‌گیرد. دیگر فایل‌های احتمالی موجود در این پوشه نیز دست‌نخورده باقی می‌مانند.

اضافه کردن کانفیگ‌مپ‌های متعدد​

در صورتی که نیاز دارید چند فایل/فولدر با آدرس‌های مختلف را ماونت کنید، می‌توانید چندین کانفیگ‌مپ‌ را به شکل زیر به اپ خود اضافه نمایید:

configmap:
  configmapItems:
    config1:
      path: /etc/nginx/conf.d/config1.conf
      subPath: config1.conf
      value:
        config1.conf: |-
          server {
            listen 80;
          root /usr/share/nginx/html;
          }
    config2:
      path: /configs/config2
      value:
        config2.conf: |-
          server {
            listen 80;
          root /usr/share/nginx/html;
          }

HostAliases​

برخی اوقات نیاز است به صورت دستی، IP به یک دامنه اختصاص دهیم. برای انجام این کار، باید فایل etc/hosts/ کانتینر را ویرایش کنیم. اما اگر کانتینر به هر دلیلی ریست شود، همه موارد اضافه‌شده هم پاک خواهند شد. برای حل این مسئله، می‌توانید آدرس‌ها و آی‌پی‌های خود را در قالب hostAliases به تنظیمات اضافه کنید.

hostAliases:
  enabled: true
  value:
    "1.2.3.4":
        - "cloud.google.com"
        - "opensource.google.com"
    "4.5.6.7":
        - "google.com"

hostname​

برای تنظیم کردن hostname یک کانتینر، کلید hostname را مقداردهی کنید.

hostname: my-host

Probes​

شما می‌توانید برای اپ خود، تست‌های سلامت یا Probe تعریف کنید. تست سلامت، هر چند ثانیه یک بار وضعیت کانتینر را چک کرده و در صورت وجود مشکل، اقدامی در راستای آن انجام می‌دهد. این تست می‌تواند به شکل اجرای دستور در ترمینال، زدن ریکوئست http GET، باز کردن سوکت tcp به پاد، و یا استفاده از پروتکل gRPC انجام شود.

livenessProbe​

این تست بررسی می‌کند که آیا کانتینر نیاز به ریست دارد یا خیر. اگر جوابی از کانتینر نرسد، کوبرنتیز آن را ریستارت می‌کند.

readinessProbe​

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

نحوه تنظیم Probeها​

پس از انتخاب روش مورد نظرتان، probe را با کمک فیلدهای زیر تنظیم کنید:

  • periodSeconds : مشخص می‌کند که تست، هر چند ثانیه یک بار انجام شود.
  • initialDelaySeconds: فاصله‌ای که بین بالا آمدن کانتینر و اولین اجرای probe وجود دارد.
  • timeoutSeconds: مدت زمان انتظار کوبرنتیز برای گرفتن جواب از probe.
  • successThreshold: تعداد probeهای موفق متوالی برای آنکه تست، موفق محسوب شود.
  • failureThreshold: تعداد probeهای ناموفق متوالی برای اینکه تست، ناموفق محسوب شود.

کد زیر، یک Probe با ریکوئست HTTP را نشان می‌دهد:

container:
  livenessProbe:
    httpGet:
      path: /is-live
      port: 8080
      httpHeaders:
      - name: Custom-Header
        value: custom-value
    initialDelaySeconds: 3
    periodSeconds: 3

container:
  readinessProbe:
    httpGet:
      path: /is-ready
      port: 8080
      httpHeaders:
        name: Name
        value: value
    initialDelaySeconds: 3
    periodSeconds: 3

Lifecycle Hooks​

یک پاد کوبرنتیز، چرخه حیات مشخصی دارد که از پذیرفته شدن یک پاد توسط کلاستر شروع شده و با پایان کار پاد به پایان می‌رسد. شما می‌توانید تنظیم کنید که هروقت پاد به یکی از این رویدادها رسید، دستور بخصوص اجرا شود. برای این کار، باید از هوک (hook) استفاده کنیم. هوک می‌تواند اجرای دستور در ترمینال، فرستادن ریکوئست GET، یا باز کردن سوکت TCP به پاد باشد.

کوبرنتیز دو هوک برای چنین اقداماتی در نظر گرفته است:

postStart​

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

preStop​

این هوک در فاصله بین ارسال دستور متوقف شدن اپ و توقف واقعی آن، اجرا می‌شود. به عنوان مثال شاید بخواهید اپلیکیشنتان قبل از توقف ناگهانی، دیتای دیتابیس را ذخیره کند و برخی تسک‌های نیمه‌اجراشده را متوقف نماید. در چنین حالتی می‌توانید یک اندپوینت GET تعریف کنید که در آن همه این موارد انجام می‌شوند. سپس می‌توانید در هوک preStop، اندپوینت را صدا بزنید.

# Running a command
container:
  lifecycle:
    preStop:
      exec:
        command: [ "sh", "-c", "script.sh"]

# Sending an http request
container:
  lifecycle:
    postStart:
      httpGet:
        path: /startup
        port: 80
تنظیمات بیشتر

اگر کلاستر On Premise دارید، می‌توانید تنظیماتی فراتر از این لیست را نیز اضافه کنید. در صورت نیاز، به ما تیکت بزنید.


برای طی کردن ادامه‌ی مراحل ساخت اپ، به تنظیمات پلن و کلاستر مراجعه کنید.