Phelix چیست؟ ابزار دیپلوی بدون قطعی برای برنامه‌های Go و Rust

اگر چند سرویس Go یا Rust دارید و آن‌ها را روی سرور خودتان اجرا می‌کنید، احتمالاً این صحنه برایتان آشناست. یک اسکریپت بیلد دارید، یک process manager، یک reverse proxy، یک سری یادداشت پراکنده برای وقتی که دیپلوی خراب می‌شود، و یک جای دیگر برای دیدن لاگ‌ها. هر تکه به تنهایی کار می‌کند، ولی کنار هم گذاشتن‌شان هر بار وقت می‌گیرد و گاهی هم وسط یک دیپلوی ساده، همه‌چیز از هم می‌پاشد.

ما در Anophel همین مشکل را داشتیم و برای حل آن Phelix را ساختیم. در این مقاله توضیح می‌دهم Phelix دقیقاً چه کاری انجام می‌دهد، چطور کار می‌کند و چه زمانی انتخاب خوبی است.

Phelix چیست؟

Phelix یک ابزار خط فرمان (CLI) است که در قالب یک باینری واحد ارائه می‌شود و کل چرخه‌ی زندگی یک برنامه‌ی Go یا Rust را روی سرور مدیریت می‌کند: بیلد، اجرا، نسخه‌بندی، دیپلوی، بررسی سلامت، رولبک و مانیتورینگ.

نکته‌ی مهم این است که Phelix سرور شما را نمی‌سازد. شما سرور، شبکه و TLS را آماده می‌کنید و Phelix از جایی شروع می‌کند که کد شما به آن سرور می‌رسد. Git و CI هم همچنان مال خودتان می‌مانند.

خود Phelix با Go نوشته شده و از Cobra برای CLI استفاده می‌کند. نسخه‌های منتشرشده‌ی آن روی لینوکس و macOS در دسترس‌اند و در مخزن گیت‌هاب از پشتیبانی آزمایشی ویندوز هم نام برده شده است.

نصب و شروع سریع

نصب با یک دستور انجام می‌شود و برای خود نصب هم لازم نیست روی سرور ابزار Go یا Rust داشته باشید:

1curl -fsSL https://phelix.anophel.com/install.sh | bash
2phelix version

بعد از آن، داخل پوشه‌ی پروژه‌تان این چند دستور برای شروع کافی است:

1# ساخت فایل تنظیمات پروژه (phelix.yaml)
2phelix init
3
4# بیلد و اجرای برنامه (تشخیص خودکار Go یا Rust)
5phelix build myapp --port 8080
6
7# بیلد دوباره بعد از تغییر، بدون قطعی با blue-green
8phelix rebuild myapp --blue-green
9
10# برگشت به نسخه‌ی قبلی
11phelix rollback myapp

یک شرط ساده وجود دارد: برنامه‌ی شما باید پورتش را از متغیر محیطی PORT بخواند و عدد ثابت داخل کد ننویسد. دلیلش این است که Phelix وقتی چند نسخه را کنار هم بالا می‌آورد، خودش پورت‌ها را تعیین می‌کند. با دستور phelix doctor می‌توانید بررسی کنید همه‌چیز درست است یا نه.

هر بیلد یک نسخه است

وقتی phelix build را اجرا می‌کنید، خروجی فقط یک فایل اجرایی نیست. هر بیلد موفق به شکل یک نسخه‌ی شماره‌دار ذخیره می‌شود (v1، v2 و همین‌طور ادامه) و می‌توانید با --tag برچسب هم به آن بدهید. باینری و snapshot رمزنگاری‌شده‌ی متغیرهای محیطی با هم نگه داشته می‌شوند، پس وقتی به یک نسخه‌ی قدیمی برمی‌گردید، تنظیمات همان زمان هم برمی‌گردد.

برای هر بیلد یک گزارش هم ساخته می‌شود: کامپایلر، مدت زمان، وضعیت کش، حجم فایل و checksum. Phelix این گزارش را با پنج بیلد قابل مقایسه‌ی قبلی می‌سنجد و اگر حجم باینری یا زمان بیلد به شکل مشکوکی بدتر شده باشد، هشدار می‌دهد. این کار کاملاً آفلاین انجام می‌شود.

اگر برنامه‌تان باید برای چند نسخه‌ی کامپایلر یا چند پلتفرم ساخته شود، گزینه‌ی matrix build همه را با یک دستور انجام می‌دهد:

1phelix build myapp --matrix --go-versions 1.26,1.27 --platforms linux/amd64,linux/arm64

پنج روش برای دیپلوی

Phelix پنج استراتژی دیپلوی دارد که همگی از یک چرخه‌ی نسخه‌بندی مشترک استفاده می‌کنند:

• classic: برنامه متوقف و دوباره اجرا می‌شود. ساده است ولی کمی قطعی دارد.
• blue-green: نسخه‌ی جدید روی یک اسلات خالی بالا می‌آید و بعد از قبول شدن در health check، ترافیک یک‌جا به آن منتقل می‌شود.
• rolling: نمونه‌ها یکی‌یکی عوض می‌شوند (مثلاً با --replicas 3).
• canary: اول فقط درصد کمی از ترافیک (مثلاً ۵ درصد) به نسخه‌ی جدید می‌رود.
• progressive: درصد ترافیک مرحله‌به‌مرحله بالا می‌رود و در هر مرحله سلامت بررسی می‌شود.

مثلاً برای یک canary پنج‌درصدی:

1phelix rebuild myapp --canary 5

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

رولبک، یک دستور ساده

وقتی چیزی خراب می‌شود، آخرین چیزی که می‌خواهید این است که وسط شب دنبال اسکریپت قدیمی بگردید. در Phelix رولبک یک دستور معمولی است:

1phelix rollback myapp --to v7 --dry-run

با --dry-run اول پیش‌نمایش می‌بینید و بعد بدون آن اجرا می‌کنید. رولبک از همان توپولوژی دیپلوی فعلی برنامه استفاده می‌کند، پس در یک برنامه‌ی blue-green هم با همان منطق health-gated برمی‌گردید. گزینه‌های دیگری هم هست:

• رولبک خودکار وقتی دیپلوی ناموفق باشد
• پنجره‌ی تأیید بعد از رولبک (--verify) که ترافیک واقعی را رصد می‌کند
• تاریخچه‌ی ثبت‌شده با دلیل هر رولبک

بررسی سلامت و بازیابی خودکار

بررسی سلامت در Phelix چند لایه دارد و فرض نمی‌کند حتماً یک endpoint به اسم /health دارید. اول مسیر مشخص‌شده بررسی می‌شود، بعد پاسخ HTTP از هر نوع، بعد اتصال TCP و در آخر فقط زنده بودن پروسس. به این ترتیب حتی سرویس‌هایی که endpoint سلامت ندارند هم می‌توانند از دیپلوی ایمن استفاده کنند.

اگر health check چند بار پشت‌سرهم شکست بخورد، Phelix چند بار محدود تلاش می‌کند برنامه را دوباره بالا بیاورد. سقف تلاش‌ها مشخص است، پس برنامه‌ی خراب بی‌نهایت ری‌استارت نمی‌شود و بعد از رسیدن به سقف، تصمیم به عهده‌ی اپراتور می‌ماند.

متغیرهای محیطی امن

متغیرهای محیطی و اطلاعات ورود به رجیستری با الگوریتم AES-256-GCM رمزنگاری و ذخیره می‌شوند، هنگام اجرا به برنامه تزریق می‌شوند و هیچ‌وقت به صورت متن ساده در لاگ‌ها نمی‌آیند. چون همراه هر نسخه ذخیره می‌شوند، رولبک هم تنظیمات درست را برمی‌گرداند.

دیپلوی با هر push

اگر می‌خواهید با هر push روی گیت، دیپلوی خودکار انجام شود، Phelix یک webhook با احراز هویت HMAC دارد:

1PHELIX_WEBHOOK_SECRET=... phelix webhook

نکته‌ی جالبش این است که هدف دیپلوی همیشه همان commit دقیقی است که push شده، نه آخرین commit روی branch. هر درخواست قبل از تأیید در یک دفتر ثبت پایدار ذخیره می‌شود، پس ارسال دوباره‌ی همان رویداد هیچ‌وقت دو بیلد پشت‌سرهم ایجاد نمی‌کند. بقیه‌ی مسیر هم همان pipeline عادی است، یعنی استراتژی، health gate و تاریخچه‌ی رولبک شما سر جایشان می‌مانند.

پشتیبانی از Docker

اگر با Docker کار می‌کنید، Phelix دو راه جلوی پایتان می‌گذارد. می‌توانید با dockerize یک Dockerfile چندمرحله‌ای بهینه برای برنامه‌تان بسازید، یا نمونه‌های برنامه را مستقیم به شکل کانتینر زیر نظر همان پراکسی اجرا کنید. تولید فایل docker-compose برای سرویس‌های جانبی مثل Redis هم پشتیبانی می‌شود. روی لینوکس می‌توانید برای هر نمونه محدودیت CPU و حافظه هم با cgroups v2 تعیین کنید.

وقتی هوش مصنوعی هم دیپلوی می‌کند

این بخش احتمالاً جالب‌ترین قسمت Phelix است. ابزارهایی مثل Claude Code و Codex حالا می‌توانند کد بنویسند، اما سپردن دسترسی مستقیم دیپلوی به یک عامل هوش مصنوعی ایده‌ی ترسناکی است. Phelix یک سرور MCP داخلی دارد که این مسئله را با یک قاعده‌ی ساده حل می‌کند: عامل پیشنهاد می‌دهد، شما تأیید می‌کنید، Phelix اجرا می‌کند.

مراحل کار به این شکل است:

1. عامل از طریق stdio به Phelix وصل می‌شود (بدون شبکه و بدون listener)
2. اول فقط وضعیت پروژه را می‌خواند
3. یک plan می‌سازد، مثلاً rebuild api --blue-green
4. درخواست اجرا می‌دهد، ولی تا وقتی انسان تأیید نکرده باشد، چیزی اجرا نمی‌شود
5. شما همان plan مشخص را با hash محتوایش تأیید می‌کنید
6. فقط بعد از آن، اجرا انجام می‌شود

چون تأیید به hash دقیق همان plan گره خورده، هیچ تأییدی نمی‌تواند به اجرای یک plan دیگر اجازه بدهد. اگر روی سرور تنظیمات لازم را انجام نداده باشید، اجرای plan اصلاً رد می‌شود. جزئیات کامل در راهنمای MCP آمده است.

مانیتورینگ، فقط اگر خودتان بخواهید

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

اگر بخواهید چند سرور را یک‌جا ببینید، می‌توانید به داشبورد phelix.anophel.com وصل شوید. عامل‌های متصل وضعیت CPU، حافظه، uptime، وضعیت پروسس‌ها و لاگ‌ها را روی کانال TLS احراز هویت‌شده گزارش می‌دهند. این بخش اختیاری است و Phelix بدون آن هم کامل کار می‌کند.

مجوز و سورس

کد CLI در گیت‌هاب در دسترس است، ولی باید دقیق بدانید که Phelix source-available است و نه متن‌باز به معنای کلاسیک. مجوز آن Functional Source License نسخه‌ی ۱.۱ با مجوز آینده‌ی Apache 2.0 است. یعنی می‌توانید کد را بخوانید، تغییر بدهید و برای هر کاری به جز «استفاده‌ی رقابتی» مثل فروش مجدد یا ارائه‌ی سرویس رقیب استفاده کنید، و هر نسخه دو سال بعد از انتشار به Apache 2.0 تبدیل می‌شود. بک‌اند و فرانت‌اند داشبورد جزو این مخزن نیستند.

Phelix برای چه کسی مناسب است؟

مناسب است اگر:

• سرویس‌های Go یا Rust دارید که روی سرور یا VPS خودتان اجرا می‌شوند
• می‌خواهید دیپلوی بدون قطعی داشته باشید ولی نمی‌خواهید برای یک چند سرویس کوچک سراغ Kubernetes بروید
• دنبال یک نقطه‌ی واحد برای بیلد، نسخه‌بندی، دیپلوی و رولبک هستید
• می‌خواهید به عامل‌های هوش مصنوعی اجازه‌ی دیپلوی بدهید ولی کنترل نهایی دست خودتان بماند

شاید مناسب نباشد اگر:

• به‌دنبال ابزاری هستید که خودش سرور و شبکه را آماده کند
• برنامه‌هایتان به زبانی غیر از Go و Rust نوشته شده‌اند
• زیرساخت شما از قبل کاملاً روی Kubernetes استاندارد شده است

جمع‌بندی

Phelix تلاش می‌کند تکه‌های پراکنده‌ی بیلد، پروسس، پراکسی، سلامت و رولبک را به یک لایه‌ی عملیاتی واحد تبدیل کند، بدون این‌که کنترل زیرساخت از دست شما خارج شود. اگر Go یا Rust می‌نویسید و از اسکریپت‌های دست‌ساز دیپلوی خسته شده‌اید، یک بار امتحانش کنید. نصب فقط یک دستور است و دور زدن نسخه‌ی قبلی هم همیشه با phelix rollback ممکن است.

• مستندات: phelix.anophel.com/docs
• سایت محصول: phelix.anophel.com
• سورس: github.com/abdorrahmani/phelix
• راهنما: دیپلوی Go بدون Kubernetes
• راهنما: Blue-green deployment برای Go

سوالات متداول

Phelix چه زبان‌هایی را پشتیبانی می‌کند؟

Go و Rust. هر دو با ابزار و نسخه‌ی کامپایلری که روی خود سرور نصب است ساخته می‌شوند.

آیا Phelix دیپلوی بدون قطعی دارد؟

بله. در حالت‌های blue-green، rolling، canary و progressive، ترافیک فقط بعد از موفقیت health check به نسخه‌ی جدید منتقل می‌شود. اگر نسخه‌ی جدید سالم نباشد، نسخه‌ی فعلی به کارش ادامه می‌دهد.

آیا می‌توانم به نسخه‌ی قبلی برگردم؟

بله. با phelix rollback به نسخه‌ی قبلی یا با --to به هر نسخه‌ی نگه‌داری‌شده برمی‌گردید. پیش‌نمایش با --dry-run هم وجود دارد.

برای استفاده از Phelix حساب کاربری لازم است؟

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

آیا عامل‌های هوش مصنوعی می‌توانند با Phelix دیپلوی کنند؟

بله، از طریق سرور MCP داخلی. اما عامل فقط می‌تواند plan بسازد و درخواست اجرا بدهد. اجرا تا زمانی که انسان همان plan را تأیید نکند رد می‌شود.

آیا Phelix از Docker پشتیبانی می‌کند؟

بله. هم تولید Dockerfile چندمرحله‌ای و هم اجرای نمونه‌ها به شکل کانتینر زیر نظر پراکسی پشتیبانی می‌شود.

Phelix متن‌باز است؟

دقیق‌تر بگوییم source-available است. مجوز FSL-1.1-ALv2 دارد و هر نسخه دو سال بعد از انتشار به Apache 2.0 تبدیل می‌شود.