Loading...

پلتفرم‌ها · 9 دقیقه مطالعه

اجرای Dokku یا Coolify در برابر یک پلتفرم git-push مدیریت‌شده

Dokku و Coolify جادوی Heroku را — git push، و اپ زنده است — به چیزی تبدیل کردند که می‌توانید روی سرور خودتان اجرا کنید، و محبوبیتشان حق آن‌هاست. بخشی که README نمی‌تواند درستش کند این است که شما تیم پلتفرم می‌شوید: میزبان، upgradeها، دیسک و pager ساعت ۳ بامداد همه مال شماست. این راهنما حق هر دو ابزار را ادا می‌کند، نیمه‌ی عملیات را صادقانه قیمت‌گذاری می‌کند، و نشان می‌دهد همان گردش‌کار push-to-deploy روی یک پلتفرم مدیریت‌شده چه شکلی است — از جمله مهاجرت، که کوچک‌تر از انتظار شماست.

Updated

اجرای Dokku یا Coolify در برابر یک پلتفرم git-push مدیریت‌شده

Dokku و Coolify چه چیزهایی را درست انجام می‌دهند

اول اعتبار، چون حقشان است. Dokku حلقه‌ی اصلی Heroku را — git push، تماشای build، اپ زنده است — در ابزاری تک‌سروری خلاصه کرد که یک دهه است قابل‌اتکا بوده. Coolify همان ایده را در UIای واقعاً دلپذیر پیچید، با دیتابیس‌های یک‌کلیکی و کتابخانه‌ی templateای رو به رشد. هر دو TLS را مدیریت می‌کنند، هر دو زبان Dockerfile را می‌فهمند، و هر دو روی سخت‌افزاری اجرا می‌شوند که کاملاً در کنترل شماست — که وقتی داده باید سر جایش بماند یا وقتی یک VPS با قیمت ثابت کل بودجه است، اهمیت دارد.

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

قلمی که README جا می‌اندازد: شما تیم پلتفرم هستید

یک PaaS سلف‌هاست نرم‌افزاری است که روی سروری که خودتان اداره می‌کنید اجرایش می‌کنید. دو لایه، هر دو مال شما. سرور به وصله‌های امنیتی OS، سفت‌کاری SSH، و دیسکی نیاز دارد که بی‌صدا از image‌های Docker و کش‌های build پر می‌شود تا صبحی که استقرارها با «no space left on device» شکست بخورند — سانحه‌ی کلاسیک Dokku، که همیشه هم لحظه‌اش را خوب انتخاب می‌کند. خود PaaS به upgradeهایی نیاز دارد که برایشان changelog می‌خوانید، چون بین کد شما و production نشسته و یک breaking change در آن، خودش یک تغییر production است.

بعد پرسش‌های تیزتر. بکاپ‌ها: دیتابیس‌هایی که PaaS شما با یک کلیک به وجود آورد — چه کسی از آن‌ها dump می‌گیرد، dumpها کجا می‌روند، و آخرین بار کی کسی یک restore را تست کرد؟ دسترس‌پذیری بالا: یک سرور یعنی reboot میزبان همه‌ی اپ‌ها را با هم پایین می‌آورد. هیچ‌کدام از این‌ها کار عجیبی نیست. یک شغل پاره‌وقت مهندسی پلتفرم است که بی‌صدا با اسکریپت نصب از راه رسید و از شب‌های شما صورتحساب می‌گیرد.

همان حلقه، اداره‌شده برای شما

گردش‌کاری که واقعاً دوستش دارید push-to-deploy است، و قرار نیست همان را از دست بدهید. روی cdn.com.tr، GitHub Deploy یک repository را متصل می‌کند و یک push را به یک deploy تبدیل می‌کند: پلتفرم branch را pull می‌کند، Dockerfile شما را در یک builder ایزوله build می‌کند (بی‌نیاز از حساب registry)، مراحلی را که تعریف می‌کنید اجرا می‌کند، و release را پشت یک healthcheck بیرون می‌دهد — ترافیک فقط وقتی به کانتینر جدید می‌رود که اعلام آمادگی کند، پس یک build خراب هرگز سایت را پایین نمی‌آورد. کش edge جلوی اپ هم هنگام deploy به‌صورت خودکار purge می‌شود.

آنچه عوض می‌شود این است که pager به دست چه کسی می‌رسد. وصله کردن میزبان، upgrade مربوط به builder، دیسک، و دسترس‌پذیری خود پلتفرم دیگر سمت میز شما نیست. Postgres و Redis مدیریت‌شده جای کانتینرهای یک‌کلیکی را می‌گیرند، با دیتابیس‌هایی که به‌صورت سرویس اداره و بکاپ می‌شوند، و object storage سازگار با S3 جای الگوی volume-روی-همین-سرور را برای آپلودها می‌گیرد. معامله‌ی صادقانه، مثل همیشه: بدون root روی میزبان، بدون نصب در سطح OS، ترافیک عمومی HTTP(S) است. Dockerfile شما همان قرارداد است — که در ضمن دری است که برای رفتن هم باز می‌ماند.

سمت پنل چه شکلی است

اجرای Dokku یا Coolify در برابر یک پلتفرم git-push مدیریت‌شده — سمت پنل چه شکلی است
پلتفرم‌های مدیریت‌شده و container apps روی cdn.com.tr.

به‌ویژه کاربران Coolify این ساختار را آشنا خواهند یافت: اپلیکیشن‌هایی با دامنه، متغیرهای محیطی و secretها، لاگ‌هایی که بدون SSH می‌خوانید، و دیتابیس‌های متصل به اپ‌ها — منهای صفحه‌های تنظیمات سرور، چون سروری از شما آن زیر وجود ندارد. اپ‌های کانتینری healthcheck، تعداد replica و storage ماندگار خود را به‌عنوان تنظیمات درجه‌یک حمل می‌کنند، و هر چیزی که روی صفحه است از همان CLI هم اسکریپت‌پذیر است، پس UI یک نما از پلتفرم است، نه تنها درِ ورود به آن.

هر چه در پنل هست، به فاصله‌ی یک CLI هم هست

# see your apps and read logs without SSH
cdnctl container apps list --account <uuid>
cdnctl container apps logs --account <uuid> --app <app_uuid> --tail 100

# scale, restart, roll back — the operations you actually reach for
cdnctl container apps scale   --account <uuid> --app <app_uuid> --replicas 2
cdnctl container apps restart --account <uuid> --app <app_uuid>
cdnctl container apps rollback --account <uuid> --app <app_uuid> --revision <revision_uuid>

مهاجرت: کوچک‌تر از آنچه فکر می‌کنید

اپ شما از قبل در Git زندگی می‌کند، و زیر Dokku یا Coolify از قبل از یک Dockerfile یا ساختاری قابل build ساخته می‌شود — یعنی بخش سخت مهاجرت مدت‌ها پیش اتفاق افتاده. جابه‌جایی یعنی عوض کردن مقصد push، به‌علاوه‌ی یک گذر داده.

repository را به GitHub Deploy وصل کنید (یا اگر اپ با یک docker-compose.yml توصیف شده، همان را import کنید: سرویس‌های دارای بخش `build:` از Dockerfile خودشان build می‌شوند و دیتابیس‌ها به افزونه‌های مدیریت‌شده تبدیل می‌شوند). متغیرهای محیطی و secretها را بازسازی کنید. داده را جابه‌جا کنید: از دیتابیس dump بگیرید و در دیتابیس مدیریت‌شده restore کنید، و فایل‌های آپلودشده را در object storage کپی کنید. چند روز هر دو پلتفرم را موازی اجرا کنید — سرور قدیمی سرو می‌کند و شما deploy جدید را راستی‌آزمایی می‌کنید — بعد DNS را جابه‌جا کنید و سرور را با برنامه‌ی خودتان بازنشسته کنید.

اپ توصیف‌شده با compose: اول پیش‌نمایش نقشه، بعد اجرا

# see exactly what your compose file becomes — nothing is created yet
cdnctl container compose preview --account <uuid> --file docker-compose.yml

# apply when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.yml

# data: dump on the old box, restore into the managed database
pg_dump -Fc appdb > appdb.dump
pg_restore -d "$MANAGED_DATABASE_URL" appdb.dump

# uploads: from the old server's volume into object storage
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./uploads s3://app-uploads

کی سلف‌هاست بمانید

انصاف این بخش را ایجاب می‌کند. Dokku یا Coolify را نگه دارید وقتی سرور برای شما واقعاً مجانی است — یک homelab، سخت‌افزاری که از قبل دارید و از اداره‌اش لذت می‌برید. نگهش دارید وقتی محل نگهداری داده یک قید سخت است و ماشین باید مال شما باشد. نگهش دارید وقتی خودِ کار عملیات هدف است: اداره‌ی پلتفرم خودتان یکی از بهترین راه‌های یادگیری کل این حوزه است. و نگهش دارید وقتی چیزی لازم دارید که معامله‌ی مدیریت‌شده کنار می‌گذارد — root، پورت‌های خام TCP، وابستگی‌های سیستمی عجیبی که جایشان در یک image کانتینر نیست.

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

پرسش‌های متداول

با ترک Dokku گردش‌کار git-push را از دست می‌دهم؟

نه — آن گردش‌کار اینجا خودِ محصول است. GitHub Deploy یک push را به چرخه‌ی pull-build-release با گیت healthcheck تبدیل می‌کند، و Docker Compose Instant Deploy اپ‌های چندسرویسی را پوشش می‌دهد. چیزی که دیگر انجام نمی‌دهید، اداره‌ی ماشینی است که آن را اجرا می‌کند.

اپ Dokku من از buildpack استفاده می‌کند، نه Dockerfile. می‌تواند مهاجرت کند؟

بله، با یک قدم کوچک: یک Dockerfile اضافه کنید. برای بیشتر اپ‌های buildpackای این یعنی چند خط (image پایه، copy، install، فرمان start)، و اپ را به هر پلتفرم کانتینری — از جمله همین — قابل‌حمل می‌کند. حتی اگر روی Dokku بمانید هم ارزشش را دارد.

چه چیزی جای دیتابیس‌های یک‌کلیکی Coolify را می‌گیرد؟

افزونه‌های مدیریت‌شده‌ی Postgres و Redis — به همان شکل به اپ‌هایتان متصل می‌شوند، اما به‌صورت سرویس اداره و بکاپ می‌شوند، نه به‌صورت کانتینرهایی که دیسک و dumpهایشان مسئولیت شماست.

می‌توانم به‌جای یک برش، تدریجی مهاجرت کنم؟

بله، و باید هم: روی پلتفرم مدیریت‌شده deploy کنید در حالی که سرور قدیمی همچنان production را سرو می‌کند، با build واقعی راستی‌آزمایی کنید، داده را از پیش sync کنید، و وقتی راضی شدید DNS را جابه‌جا کنید. سرور قدیمی تا لحظه‌ای که خاموشش کنید یک نقشه‌ی rollback عالی است.