Skip to Content
مدل سرویس‌های گردو

مدل سرویس‌های گردو

ساختار گردو از حساب به پروژه، از پروژه به محیط و از محیط به سرویس می‌رسد. فهم این چهار سطح بیشتر ابهام‌های پنل و CLI را برطرف می‌کند.

حساب، پروژه و محیط

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

سرویس واحد

در نسخه فعلی، «اپلیکیشن» و «کانتینر» دو محصول جدا نیستند. همه workloadها یک سرویس هستند و از مسیر یکسان برای وضعیت، لاگ، متغیر، دامنه، بیلد و ریلیز مدیریت می‌شوند. منبع سرویس می‌تواند GitHub/GitLab، پوشه محلی، Docker Image یا Template بازارچه باشد.

نوع دسترسی مستقل از منبع است:

  • HTTP: وب‌سایت یا API با URL و HTTPS؛
  • TCP: پروتکل خام مثل دیتابیس یا broker با endpoint و پورت؛
  • Private: فقط برای ارتباط داخلی سرویس‌ها؛
  • Cron: اجرای زمان‌بندی‌شده و کوتاه‌مدت، بدون endpoint عمومی.
سرویس‌های عادی همیشه روشن‌اند. Stop یک اقدام صریح است و با Start دوباره اجرا می‌شود؛ درخواست ورودی سرویس متوقف‌شده را خودکار روشن نمی‌کند.

بیلد و ریلیز

بیلد خروجی ثابت یک نسخه سورس است. ریلیز همان بیلد را همراه snapshot تنظیمات در یک محیط فعال می‌کند. Rollback یک بیلد آماده قبلی را دوباره ریلیز می‌کند و به build مجدد نیاز ندارد. Promote نیز بیلد جاری را به محیط دیگر می‌برد.

ترتیب متغیرها

وقتی چند سطح یک کلید یکسان دارند، مقدار نزدیک‌تر به سرویس غالب است. ترتیب از کم‌اولویت به پر‌اولویت:

  1. Secret مشترک پروژه؛
  2. Variable محیط؛
  3. متغیر اتصال Add-on؛
  4. Variable یا env خود سرویس.

متغیر build-time هنگام ساخت image در دسترس است؛ متغیر runtime فقط هنگام اجرای کانتینر تزریق می‌شود. مقدارهای secret پس از ذخیره ماسک می‌شوند.

داده ماندگار

فایل داخل filesystem موقت کانتینر را ماندگار فرض نکنید. داده مهم باید روی Volume یا در Add-on ذخیره شود. Volume در restart باقی می‌ماند، اما بکاپ نیست؛ بکاپ را خارج از همان سرویس نگه دارید و بازیابی را آزمایش کنید.