مقایسه
دزکوب و GitOps
اگر تیم شما امروز GitOps دارد، این صفحه میگوید دو مدل کجا کنار هم مینشینند و کجا نمینشینند.
این مقایسه بر پایهٔ مستندات عمومی، کد متنباز (جایی که موجود است) و تحلیل فنی خودمان انجام شده. هر ادعای منفی دربارهٔ محصول دیگر، به منبع عمومی متکی است.
اگر جایی اشتباه کردهایم، بگویید تا اصلاح کنیم: hello@dezkube.com
آخرین بازبینی: ۵ شهریور ۱۴۰۵
دو مدل
| GitOps خالص | دزکوب | |
|---|---|---|
| منبع حقیقت | مخزن گیت | خودِ کلاستر |
| جهت | کنترلر از گیت میکشد | کنترلپلن به کلاستر مینویسد |
| تغییر | commit | عمل در پلتفرم، با ممیزی |
| تغییر خارج از مسیر | برگردانده به حالت گیت | reconciler میبیند: برمیگرداند یا گزارش میدهد |
| دامنه | تحویل پیکربندی | چرخهٔ حیات کامل زیرساخت |
چرا GitOps را موتور اصلی نکردیم: اگر یک موتور GitOps بالای کنترلپلن دزکوب بنشیند، دو مالک برای یک شیء پیدا میشود. هر دو مدل «درست» رفتار میکنند و نتیجهاش نوسان بیپایان است: یکی مینویسد، دیگری برمیگرداند.
این قابل حل است — ولی راهحلش انتخاب یک مالک بهازای هر شیء است، نه اجرای همزمان هر دو روی یک منبع.
علاوه بر این: GitOps موتور تحویل است، نه موتور ساخت. بیلد، اسکن، امضا و اصالت را نمیدهد. آنها باید جای دیگری باشند.
الگوهای همزیستی
تفکیک مالکیت
برخی namespaceها تحت GitOps، بقیه تحت دزکوب.
تقسیم لایه
GitOps برای پیکربندی اپلیکیشن، دزکوب برای زیرساخت و حاکمیت.
افزونه در کاتالوگ
موتور GitOps بهعنوان یک افزونهٔ پینشده نصب میشود.
آنچه یاد گرفتیم
این سکشن جای «کجا آنها بهترند» را نمیگیرد و وانمود هم نمیکند که میگیرد: اینجا حرفی از برنده و بازنده نیست.
- همهچیز باید به سمت یک وضعیت مطلوب همگرا شود. این در reconciler ما هست.
- تغییر خارج از مسیر باید دیده شود. ما هم واگرایی را تشخیص میدهیم.
- تحویل باید قابل ممیزی باشد. ما با زنجیرهٔ ممیزی به همین رسیدیم.
مرزها
- اجرای همزمان GitOps و مدیریت دستی روی یک منبع پشتیبانی نمیشود. باید در جلسهٔ استقرار صریح تعریف شود.
- همین هشدار دربارهٔ ارائهدهندهٔ Terraform هم صدق میکند.
اینها را هم ببینید
فهرست کوتاه خودتان را بیاورید.
در جلسه، محصول ما را در برابر همانها میگذاریم — از جمله جاهایی که آنها بهترند.