// سطح: serverfactory-tertiary · سفارش 33

Server Factory — Additional Components mixedاجازه‌نامه: UNVERIFIED

Kotlin (service factories, on Core Framework)Shell (Utils, Definitions packs)GradleDocker (target runtime)SSH / OpenSSH (Utils bootstrap)SonarQube

منبع

Server Factory — Additional Components Family tree Data vs engine · bootstrap Maturity: solid = flagship (Mail) · dashed = early-stage service factories (UNVERIFIED) Core Framework Kotlin engine Mail Factory flagship Web Service Factory early-stage SonarQube Factory early-stage Caching-Proxy Factory early-stage Definitions packs Docker · Stack · Software Utils init_ssh_access.sh bootstrap
// معماری

بازیگران پشتیبان زنجیره ابزار تأمین Server Factory

فراتر از Mail Server Factory و چارچوب اصلی، سازمان Server-Factory شامل چندین مؤلفه کوچک‌تر است: «کارخانه»های اختصاصی هر سرویس (سرویس وب، SonarQube، پروکسی کش)، بسته‌های پیکربندی اعلانی (Docker/Stack/Definitions نرم‌افزاری) و ابزارهای مشترک Utils. این صفحه به‌جای معرفی آن‌ها به‌عنوان محصولات کاملاً مشخص‌شده، به‌طور صادقانه به آن‌ها می‌پردازد — چرا که بسیاری از آن‌ها در مراحل اولیه توسعه یا مستندات ناقصی دارند.

مجموعه‌ای از مخازن پشتیبان Server Factory: Web-Service-Factory، SonarQube-Factory و Caching-Proxy-Factory (ابزارهای تأمین هر سرویس، عمدتاً در مراحل اولیه توسعه)؛ Docker/Stack/Software-Definitions (بسته‌های پیکربندی اعلانی که توسط چارچوب مصرف می‌شوند)؛ و Utils (ابزارهای کمکی دسترسی به SSH و ابزارهای عمومی). همگی بر پایه چارچوب اصلی ساخته شده‌اند.

این صفحه مخازن باقی‌مانده Server-Factory را یکجا گردآوری کرده است، زیرا به‌صورت جداگانه، بیشتر آن‌ها کوچک یا عمداً کم‌مستند هستند و معرفی هر یک به‌عنوان محصولی نهایی، سطح بلوغ آن‌ها را بیش از حد واقعی نشان می‌دهد. این مؤلفه‌ها به سه دسته تقسیم می‌شوند. کارخانه‌های سرویس از الگوی Mail Server Factory برای نقش‌های دیگر سرور پیروی می‌کنند: Caching-Proxy-Factory («سرور پروکسی کش خود را اجرا کنید») ویژگی‌های کلیدی مانند پروکسی کش، گواهی خودامضا و نقطه پایانی HTTP برای دریافت گواهی امنیتی را فهرست می‌کند؛ SonarQube-Factory («سرور SonarQube خود را اجرا کنید») برای استفاده در توسعه نرم‌افزار طراحی شده است؛ و Web-Service-Factory سرور وب را نمونه‌سازی و پیکربندی می‌کند تا اهدافی مانند وب‌سایت‌ها و میکروسرویس‌ها را مستقر سازد. هر سه پروژه‌هایی بر پایه Kotlin هستند که بر چارچوب اصلی استوارند، اما فایل‌های README عمومی آن‌ها عمدتاً جایگاه‌نگهدار («تعیین خواهد شد» برای سازگاری، مشخصات، راه‌اندازی و استفاده) هستند — بنابراین قابلیت‌های واقعی آن‌ها فراتر از اهداف اعلام‌شده، تأییدنشده است. بسته‌های تعاریف — Docker-Definitions، Stack-Definitions و Software-Definitions — مخازنی از پیکربندی‌های اعلانی هستند که چارچوب از آن‌ها برای دانستن نحوه ساخت/استقرار تصاویر Docker، استک‌ها و نرم‌افزارها استفاده می‌کند؛ این بسته‌ها مجموعه‌ای از داده‌های نسخه‌بندی‌شده هستند، نه برنامه‌های کاربردی. Utils ابزارهای کمکی عمومی برای این خانواده فراهم می‌کند، از جمله اسکریپت init_ssh_access.sh که کلید SSH را تولید و آن را بر روی میزبان راه دور نصب می‌کند تا دسترسی ریشه بدون رمز عبور برای تأمین‌های بعدی را ممکن سازد. این مؤلفه‌ها در کنار هم، زنجیره ابزار تأمین حول محصول شاخص Mail Server Factory را تکمیل می‌کنند.

مدل Server Factory برای تعمیم‌پذیری طراحی شده است: وقتی می‌توانید یک سرور ایمیل را از طریق توصیف اعلانی تأمین کنید، همان موتور باید بتواند سرورهای وب، پروکسی‌های کش و سرورهای کنترل کیفیت کد را نیز تأمین کند — با تغذیه از بسته‌های تعاریف قابل استفاده مجدد و ابزارهای مشترک، نه منطق اختصاصی برای هر نقش. این مخازن همان تعمیم در حال پیشرفت هستند که الگوی اثبات‌شده را به انواع جدید سرور گسترش می‌دهند. ارزش آن‌ها در اینجا به‌عنوان شاهدی بر دامنه کاربرد این مدل است؛ سطح بلوغ آن‌ها متفاوت است و این صفحه عمداً مشخص می‌کند کدام‌یک در مرحله جهت‌دهی و کدام‌یک تکمیل‌شده هستند.

محتوا

این مجموعه به‌عنوان یک کل، قابلیت استفاده مجدد چارچوب اصلی را در انواع مختلف سرورها نشان می‌دهد و داده‌های اعلانی (تعاریف) را از اجرای عملی (کارخانه‌ها) جدا می‌سازد. به‌صورت جداگانه، کارخانه‌های سرویس در مراحل ابتدایی قرار دارند و باید به‌عنوان جهت‌گیری ارائه شوند، نه محصولات نهایی.

  • یک چارچوب تأمین منابع که به‌طور کلی برای نقش‌های ایمیل، وب، پروکسی کش و SonarQube تعمیم یافته است.
  • بسته‌های تعاریف اعلانی (Docker/پشته/نرم‌افزار) که از موتور اجرا جدا شده‌اند.
  • ابزارهای مشترک (مانند بوت‌استرپ دسترسی بدون رمز عبور با یک دستور SSH) که در کارخانه‌ها به‌طور مجدد استفاده می‌شوند.

  • استفاده از یک موتور مشترک برای نقش‌های مختلف سرور: با ساخت هر کارخانه بر پایه چارچوب اصلی حل شده است.
  • جداسازی پیکربندی از کد: با استفاده از مخازن تعاریف به‌عنوان بسته‌های داده با نسخه‌بندی مشخص حل شده است.
  • (تأییدنشده): فایل‌های README کارخانه‌های سرویس به‌عنوان نگهدارنده موقت هستند؛ کامل بودن پیاده‌سازی آن‌ها از طریق مستندات عمومی قابل تأیید نیست — باید به‌عنوان مرحله ابتدایی ارائه شوند.

  • Kotlin — کارخانه سرویس وب، کارخانه SonarQube، کارخانه پروکسی کش (ساخته‌شده بر پایه چارچوب اصلی).
  • Shell — ابزارها و بسته‌های تعاریف (اسکریپت‌ها/پیکربندی).
  • Gradle — جریان ساخت و تست با ./gradlew test در کارخانه‌ها.
  • Docker — محیط اجرایی هدف که توسط تعاریف Docker توصیف شده است.
  • SSH / OpenSSH — بوت‌استرپ دسترسی بدون رمز عبور ابزارها.
  • SonarQube — سروری که کارخانه SonarQube آن را تأمین می‌کند (و Mail Server Factory دروازه تمیزی برای آن گزارش می‌دهد).

نکته صداقت: بیشتر این مخازن فورک‌های داخلی سازمان هستند؛ کارخانه‌های سرویس به‌صورت نگهدارنده مستند شده و طبق بند ۱۱٫۴٫۶ اساسنامه به‌عنوان تأییدنشده علامت‌گذاری شده‌اند. به‌وضوح در رتبه‌ای پایین‌تر از Mail Server Factory و چارچوب اصلی قرار دارند.