MihraOps neden sunucuna bir PaaS koymuyor

Sunucudaki bir platformun lehine argüman

Güçlü bir argüman, o yüzden önce o geliyor. Sunucudaki bir platform hep uyanıktır: Git’e yapılan bir push, kimsenin dizüstü açık değilken gece üçte derleyip dağıtabilir. Telefon dahil her tarayıcıdan erişilir. Birkaç kişi onu kendi girişleriyle paylaşabilir. İmajları sunucuda derleyebilir, her pull request için bir önizleme ortamı açabilir ve log ile metrik geçmişini tek yerde tutabilir.

Coolify ve Dokploy bunların hepsini yapıyor, açık kaynaklar ve üzerinde çalıştıkları sunucunun ötesinde hiçbir maliyetleri yok. Birçok ekip için düpedüz doğru araç bunlar.

Panel ikinci bir sistemdir

Bedeli daha az görünür. Sunucudaki bir platform başlı başına bir uygulamadır: bir web arayüzü, bir veritabanı, arka plan işçileri, bir güncelleme takvimi ve kendi güvenlik duyuruları. Konteyner yönetmek için Docker soketine ihtiyaç duyar; bu da onu makinede root’a eşdeğer kılar.

Giriş sayfası, onu kullanmak istediğin her yerden erişilebilir olmalıdır; bu da çoğunlukla internetten demektir. Yani sunucu artık uygulamanın yanında internete açık, root’a eşdeğer ve ayrıca yamalı tutman gereken bir yönetim uygulaması da çalıştırır.

Test: araç gidince geriye ne kalıyor

MihraOps kendi tasarımına tek bir test uygular: uygulama yarın ortadan kalksa sunucunda geriye ne kalır ve biz olmadan da anlamlı olur mu?

Cevap sıradan Docker. Uygulamaların normal konteynerler. Compose stack’leri ~/.mihraops/compose/<project>/ içinde, elle docker compose ile çalışan normal Compose projeleri. Yayınlanmış bir domain, yapılandırması /opt/mihraops/caddy içinde duran normal bir Caddy konteyneri. Kaydetmeyi seçtiğin Git ve registry kimlik bilgileri ~/.mihraops/secrets içinde şifreli duruyor. Aşağıda anlatılan isteğe bağlı Agent’ı kurmadıkça sunucuda hiçbir MihraOps servisi çalışmaz ve ayakta tutulacak bize ait bir veritabanı yoktur.

Bu az şey değil ve kaldırma rehberi her yolu listeliyor. Ama her parça senin de kurabileceğin bir şey ve hiçbiri çalışmaya devam etmek için MihraOps’a ihtiyaç duymuyor.

Etki alanı

Kimlik bilgileri, kontrol düzlemi neredeyse oraya gider. Birkaç sunucuyu bunlardan birinin üzerinden yöneten bir platform, diğerlerinin her biri için bir SSH anahtarı tutar; o tek makinenin ele geçirilmesi hepsine ulaşır.

MihraOps sunucu erişimini çalıştığın bilgisayarlarda tutar. Sunucularına ulaşmak için kullandığın SSH anahtarları ve parolalar işletim sisteminin şifreli deposunda kalır; bir sunucuda saklanmaz ve bize hiç gönderilmez.

Sunucuda duranlar, o sunucunun kendi kodunu ve imajlarını çekmesi için gerekenlerle sınırlı. Bu kimlik bilgileri aynı sunucuda tutulan bir anahtarla şifrelenir; bu onları durağan hâlde korur — orada zaten root olan birinden değil.

Bu duruşun bedeli

Açıkça söylemek gerekirse: telefondan bakılacak bir panel yok, paylaşılan ekip girişleri yok ve uygulamanın kurulu olmadığı bir bilgisayarda web arayüzü yok.

Bazı işler de senin bir pencere açmanı bekleyemez. Onlar için — dağıtım webhook’ları, izleme ve e-posta uyarıları — MihraOps’un isteğe bağlı bir Agent’ı var: sunucuda yalnızca yapılandırdığın eylemleri çalıştıran, kaldırabileceğin küçük bir konteyner. Sunucu sunucu seçilen bilinçli bir istisna; ürünün varsayılan biçimi değil.

Kimler onun yerine Coolify kurmalı

1. 01Birkaç kişinin dağıtım yaptığı ve her birinin kendi girişine ihtiyaç duyduğu bir ekip.
2. 02Sunucuda derlemeli push-to-deploy ve her pull request için bir önizleme ortamı isteyen herkes.
3. 03Sunucularını çoğunlukla telefondan ya da yazılım kuramadığı makinelerden yöneten herkes.
4. 04Her bilgisayara bir uygulama kurmaktansa bir servis daha çalıştırmayı tercih eden herkes.

Sen buysan karşılaştırma sayfası farkları özellik özellik anlatıyor ve seni bundan vazgeçirmeye çalışmıyor.