And why we replaced n8n with Laravel along the way
Dahili otomasyon platformumuzu kurmaya başladığımızda, doğru teknoloji yığınına sahip olduğumuzu düşünüyorduk. İş akışı orkestrasyonu için n8n, Ansible playbook'larını çalıştırmak için Semaphore UI ve barındırma operasyonlarını tamamen otomatikleştirme vizyonumuz vardı. Birkaç ay sonra, tam anlamıyla bir örümcek ağına benzeyen bir şeye bakıyordum — ve her şeye baştan başlamamız gerektiğini anladım.
Hollanda merkezli bir yönetilen barındırma şirketi olan Savvii'nin CTO'suyum. PHP tabanlı web sitelerinde (e-ticaret, WordPress ve benzeri iş yükleri) uzmanlaşıyoruz ve üç müşteri segmentine hizmet veriyoruz: küçük işletmeler, bayiler (reseller'lar) ve ajanslar. Her birinin farklı ihtiyaçları, farklı ölçekleri ve farklı beklentileri var.
Baskıyı en çok hissettiğimiz alan ajans segmentiydi. Ajanslar sofistike müşterilerdir, ancak şirket içi ekipleri genellikle teknik ve teknik olmayan kişilerin bir karışımıdır. Bir GUI'ye (grafiksel arayüze) ihtiyaçları vardır. Komut satırında yaşayamazlar. Ve bünyemize kattığımız ajans sayısı arttıkça şu gerçek daha da belirginleşti: arkasında gerçek bir otomasyon bulunan düzgün bir kontrol paneline ihtiyacımız vardı.
Ansible Tower ve benzeri araçlar radarımızdaydı, ancak kurulumları ya çok karmaşıktı, tutarsız belgelere sahipti ya da performans ve veri egemenliği endişeleriyle birlikte geliyordu. Kendi sunucularımızda barındırabileceğimiz (self-host), drama yaşamadan yükseltebileceğimiz ve bir haftalık eğitime gerek kalmadan destek ekibimize devredebileceğimiz bir çözüm istiyorduk.
Herhangi bir karara varmadan önce tam bir karşılaştırma yaptık. İki faktör alanı hızla daralttı.
Veri egemenliği. Durumu veya kimlik bilgilerini üçüncü taraf bir bulutta depolayan hiçbir araç kabul edilemezdi. Self-hosting tartışılamaz bir zorunluluktu.
Mühendis olmayanlar için kullanıcı deneyimi (UX). Birinci basamak destek ekibimiz sistem yöneticisi değil, güçlü iletişimcilerdir. Seçtiğimiz her ne olursa olsun, her olayı DevOps'a iletmek zorunda kalmadan yönetilebilir olmalıydı. Değerlendirdiğimiz araçlar şunlardı:
| Kriter | Semaphore UI | n8n | AWX / Tower | Rundeck |
|---|---|---|---|---|
| Varsayılan olarak self-hosted | Evet — tek ikili dosya / tanıdık dağıtım | Evet — self-hosted sürüm | Evet (AWX) / karma (AAP bulut seçenekleri) | Evet |
| Birinci basamak destek UX'i | Güçlü görev ve envanter netliği | Yazarlar için iyi; operasyon devri için zayıf | Ağır RBAC kavramları; destek için dik öğrenme eğrisi | İş odaklı; daha karmaşık Ansible ergonomisi |
| Ansible envanteri ve yürütme UX'i | Projeler ve şablonlar etrafında inşa edilmiş | Bir Ansible kontrol düzlemi değil | Yerel ancak karmaşık yükseltme yolu | Mümkün; öncelikli olarak Ansible odaklı değil |
| Özel ara yazılım için API | Tutarlı görev ve proje API'leri | Kapsamlı; farklı bir operasyonel model | Tower API kapsamı sürüme göre değişir | Olgun iş API'si; farklı temel yapılar |
| Yükseltme ve operasyonel yük | Pratikte sorunsuz yükseltmeler | İş akışlarının karmaşıklığına bağlı | Genellikle ağır (K8s / paket bağımlılıkları) | Orta düzey; JVM ayak izi |
Semaphore UI her iki alanda da kazandı. Kurulumu oldukça basitti. Yükseltmeler zahmetsizdi. Kullanıcı arayüzü, mühendis olmayan birinin ne olduğunu anlayabileceği kadar sadeydi. Mevcut Ansible envanterimizi bağlamak neredeyse hiç pürüzsüz gerçekleşti — yardıma ihtiyaç duyduğumuz tek nokta envanterimizi bağlamaktı ve bu da destekle hızla çözüldü. Semaphore'un belgeleri sağlamdı ve bu bize güven verdi.
İlk mimaride HostBill (faturalandırma), Semaphore UI ve CMDB arasındaki orkestrasyon katmanı olarak n8n kullanıldı. Kağıt üzerinde harika görünüyordu — az kodlu (low-code), görsel, sürdürmek için bir geliştiriciye gerek yoktu.
n8n'in görsel arayüzü basit doğrusal akışlar için mükemmeldir. Ancak koşullar, hata yönetimi, çok adımlı geri aramalar ve durum yönetimi devreye girdiğinde genel bakış kayboldu. Temiz bir diyagram olarak başlayan şey sürrealist bir devre kartına dönüştü.
Güvenli durum depolaması yok
Kullandığımız sürümde adımlar arasında ara durumu saklamanın güvenli bir yolu yoktu.
Güvenlik endişeleri
Günlüklerde güvenilir parola gizleme eksikliği — Ansible geri aramaları oluşturulan kimlik bilgilerini içerdiğinde ciddi bir endişe.
Kırılgan geri aramalar
n8n, Semaphore ve CMDB arasındaki geri arama yönetimi akışları kırılganlaştıran aşırı gidiş-dönüş trafiği gerektiriyordu.
n8n'i bir Laravel uygulamasıyla değiştirdik. Bu gerçek bir ara yazılımdır — kodsuz bir araç değil, ekibimizin tamamen sahip olduğu ve anladığı bir yapıdır.
Güvenlik modeli
Her sunucuda, Semaphore SSH anahtarının fiilen neler yapabileceğini kısıtlayan bir authorized_keys dosyası bulunur. authorized_keys içindeki command yönergesini kullanarak Semaphore'un çalıştırmasına izin verilen komutları tam olarak tanımlıyoruz. İlk kurulumdan sonra Semaphore root erişimini de kaybeder — yalnızca kullanıcı hesaplarına bağlanabilir.
Bu, herhangi bir güvenlik ihlali durumunda etki alanını (blast radius) önemli ölçüde sınırlar.
Başladığımız ajans segmenti, bu mimari aracılığıyla yaklaşık 600 sunucu çalıştırıyor. Her üç segmentteki toplam kapsam zamanla 3.000 ila 4.000 sunucuya ulaşacak ve platformu kademeli olarak devreye alıyoruz.
Sunucu güncellemeleri için sırada Semaphore'un zamanlayıcısı var — şu anda harici araçlarla yönetiliyor ancak bunu yönlendiren zamanlayıcı ile Ansible'a geçiş yapılıyor.
Destek bağımsızlığı
Destek ekibi, her olayda DevOps'u dahil etmeden Semaphore'u bağımsız olarak kullanabilir.
Gerçek zamanlı uyarılar
Slack entegrasyonu, playbook'lar başarısız olduğunda mühendislik ekibine anında uyarı verir.
Sade şablonlar
Değişkenleri API aracılığıyla aktararak düşük şablon sayısı sağlandı — karmaşıklık önlendi.
Doğru CMDB
CMDB otomatik olarak güncel kalır — artık manuel bakıma gerek yok.
Farklı yapacağımız en önemli şey: tek bir otomasyon satırı yazmadan önce mimari tasarıma daha fazla zaman ayırmak. Birden fazla kez baştan başladık çünkü hangi akışların ölçekleneceğini ve hangilerinin arızaları zarif bir şekilde karşılayacağını yeterince dikkatli düşünmemiştik.
Önce mimari
Tek bir otomasyon satırı yazmadan önce mimari tasarıma daha fazla zaman ayırın. Hangi akışların ölçekleneceğini ve arızaları zarif bir şekilde karşılayacağını dikkatlice düşünün.
Yalnızca yeteneklere değil, kullanıcı deneyimine de bakın
Destek ekibiniz gece 02:00'de kıdemli bir mühendisi aramadan aracı kullanamıyorsa, o araç yanlıştır.
Veri egemenliği önemlidir
Üretime geçmeden önce kimlik bilgilerinizin ve durum verilerinizin nerede yaşadığını bilin.
İyi belgeler önemli bir işarettir
Bir aracın belgeleri dağınıksa, aracın kendisi de muhtemelen öyledir.
Start with OSS, upgrade to Pro when your team grows. Enterprise support and SLA are available — including for hosting providers running thousands of servers.
