Enterprise Sunucu Yönetim Paneli Olması Gerekenler? / Beta Yayınlandı

Merhaba arkadaşlar,

Bu konuyu özellikle
Site & Server Administration kategorisinde açmak istedik.
Bu bölümde yer alan arkadaşların,
sunucu yönetimi ve panel geçişleri konusunda
çok ciddi saha tecrübesine sahip olduğunu biliyoruz.
Bu yüzden fikirlerin ve gerçek deneyimlerin bizim için
özellikle değerli olacağını düşünüyoruz.

Yaklaşık 1 yıldır üzerinde çalıştığımız Linux tabanlı bir hosting / application runtime altyapısının
geliştirme sürecinin sonuna gelmiş durumdayız.
Sistem büyük ölçüde tamamlandı ve gerçek sunucular üzerinde aktif olarak çalışıyor.

Bu çalışmayı klasik anlamda bir hosting paneli olarak değil,
daha çok bir altyapı yaklaşımı olarak konumlandırıyoruz.
Kendi içimizde bu yapıyı
ICA (Isolated Control Architecture) olarak adlandırıyoruz.

Temel fark şu:
Bu yapı sadece bir panel arayüzü değil,
native Linux üzerinde çalışan, 5 katmandan oluşan bir mimari.

Kısaca mimari yaklaşımdan bahsetmek gerekirse:

- Kernel / resource layer:
cgroup v2 üzerinden CPU, RAM, IO ve process limitleri native olarak enforce ediliyor.

- Isolation layer:
User ve domain bazlı izolasyon, filesystem ve process seviyesinde sağlanıyor.

- Service layer:
Web server, runtime, mail, cron, db gibi servisler birbirinden izole çalışıyor.

- Control & policy layer:
RBAC (Role-Based Access Control) ile root, admin, reseller, user gibi roller
net sınırlarla ayrılıyor.

Bu nedenle geliştirme sürecinde odağımız,
“daha iyi bir panel yapmak”tan çok,
altyapının davranışını daha öngörülebilir hale getirmek oldu.

Bir hosting panelini değiştirmek çoğu zaman kolay bir karar değil.

Genelde şu sorular kafayı kurcalıyor:
- Mevcut sistem gerçekten stabil mi?
- Taşıma sırasında bir şeyler bozulur mu?
- Mail, cron, kullanıcılar, izinler sorunsuz taşınır mı?
- Alışkanlıklar ne kadar zorlanır?
- Değiştirince gerçekten hissedilir bir fark olur mu?

Biz bu altyapıyı geliştirirken,
“daha iyi panel” iddiasından çok,
bu soruların pratikte nasıl karşılık bulduğunu anlamaya odaklandık.

Şu an geldiğimiz noktada:
- Çekirdek mimari native olarak çalışıyor
- İzolasyon ve universal migration tarafı aktif
- Rol bazlı yetkilendirme (RBAC) net şekilde uygulanıyor
- Ana fonksiyonlar gerçek senaryolarda kullanılıyor

Bazı ekran görüntülerini de bu yüzden paylaşıyoruz;
bir şey satmak için değil,
gelinen noktayı ve yaklaşımı daha net anlatabilmek için.

Asıl merak ettiğimiz konu şu:

Sizi bugün kullandığınız panelden vazgeçirecek şey ne olurdu?

- Gerçekten yaşadığınız bir sorun mu?
- Performans, güvenlik veya kontrol ihtiyacı mı?
- Maliyet mi?
- Yoksa sadece “alışkanlık” mı?

Paneli değiştirmiş olanlar için de şunu merak ediyoruz:
- Değdi mi?
- Yoksa beklediğiniz karşılığı bulamadınız mı?

Gerçek deneyimleri ve samimi görüşleri duymak isteriz.

Not:
Bu konu bir test çağrısı, satış duyurusu veya yönlendirme değildir.
Amaç, geliştirme sürecini gerçek kullanıcı tecrübeleriyle
daha sağlıklı yönlendirebilmektir.


Burada metriklerde yüksek kullanımlar dev ortamı olduğu içindir.
Boşta çalışma testlerimiz güzel değerler yakalıyor raspberry pi 4b üzerinde test edilmiştir.
Tüm servisler opsiyonel boot disable/enable özelliğe sahiptir yani tamamını kullanmamız gerekmiyor.






MOBIL IOS / ANDROID

Altyapının davranışını daha öngörülebilir hale getirmek, interface abstraction'dan geçiyor bence.
Eğer geliştirdiğiniz bu ICA mimarisi, Linux'un native davranışlarını (cgroups, systemd vb.) kendi mantığıyla maskelemek yerine; bu özellikleri tutarlı bir API veya CLI katmanı ile bizlere sunuyorsa, işte o zaman 'alışkanlık' bariyerini aşmak çok daha kolay olur. Çoğu sysadmin'in panel değiştirmeme sebebi 'yeni arayüzü öğrenmek' değil, panelin arka planda config dosyalarını kendi kafasına göre manipüle etmesi korkusudur.
Sizin bahsettiğiniz 5 katmanlı mimari, bu manipülasyonu ortadan kaldırıp işletim sistemi ile kullanıcı arasında şeffaf bir 'tercüman' görevi görüyorsa, bu sektörde ciddi bir açığı kapatabilir.
Raspberry Pi üzerindeki boşta çalışma testleriniz de bu verimliliğin sinyallerini veriyor, elinize sağlık.

Harika ve çok zor bir proje , sadece başlamış olmanız bile takdir edilmesi gereken bir şey ve siz çoktan ilerlemişsiniz.
Tebrik ediyorum ve başarılar diliyorum.

Hocam tam olarak bahsettiğiniz noktadayız aslında.

Altyapıyı tasarlarken en baştan şu kırmızı çizgiyi koyduk:
panel ya da altyapı, işletim sistemine bulaşan bir yapı olmamalı.

Kurulum sürecimiz bile klasik anlamda
servisleri işletim sistemine kurayım, configleri dağıtayım mantığında değil.
Tüm yapı kendi izole dizininde çalışıyor,
yani projeyi komple kaldırdığınızda
işletim sistemi tarafında kalıcı bir iz ya da hasar bırakmıyor.
Bu noktada özellikle şeffaflığı korumak istedik.

Config tarafında da benzer bir yaklaşım var.
Linux’un native davranışlarının arasına
ek bir mantık sokmak veya override etmek yerine,
geçerli olan kurallar tamamen sistemin kendi kuralları.
Panelin yaptığı şey; bu kuralları gizlemeden,
kullanıcının da görebileceği ve anlayabileceği şekilde
kontrol edilebilir hale getirmek.

Hatta bu sınırları daha net görmek için
IP, network ve bazı resource davranışlarının
kernel seviyesinde nasıl ele alındığını bile
ayrı ayrı test ediyoruz.
ek olarak doğan prosesleri 1-2 saniyeliğine bile izolasyon dışında tutmuyor sonradan slice taşıma yapmıyoruz.

Özetle;
arka planda kendi kafasına göre iş yapan bir yapı değil,
kullanıcının koyduğu kuralların dışına çıkmayan,
olan biteni saklamayan bir kontrol yüzeyi gibi duruyor.

Zaten bu başlığı açma sebebimiz de tam olarak bu yaklaşımın
sahadaki tecrübelerle ne kadar örtüştüğünü görmekti.
Yorumunuz bu açıdan çok değerli, teşekkür ederim.




Aslında başlarken büyük bir projeye başlıyoruz diyerek başladık, fakat işin sonunda şunu gördük en zor kısım Central ve Client tarafının sözleşmeli olarak güncelleme mimarisiydi,
Bizi bizden aldı resmen hocam, çünkü güncellemeleri test etmek gerekiyor, hangi sunucuda nasıl tepki veriyor, versiyon conflict sorunları bunları tek tek inceledik şükür şuan tam ve eksiksiz bir ürün fakat önemli olan savaş alanı
Çok teşekkür ederim yorumunuz için.

Bir ürünü üretmek belki zordur ama eğer pazarlamasını doğru şekilde doğru yerlerde yapamazsanız ki o daha zordur....

Hostinger gibi yapmışsınız sanıyorum?

Cpanele benzeyen tam veya pleske benzeyen tema ile bazı sorduğunuz sorunları çizebilirsiniz.

Konunuzu 10 yıllık dan tavsiyeniz üzerine baktım ve yazıyorum o ekipte vasıfsız bile olsa yer almak isterdim. Yani ücretsiz çalışan. Çaycı bile olabilir

Yorumunuz için teşekkür ederim.

Hostinger gibi bir kopya mantığı yok aslında. Bizim tarafta odak daha çok altyapı ve izolasyon mimarisi (ICA) tarafında. Arayüz kısmında ise cPanel veya Plesk kullananların yabancılık çekmemesi için bazı presetler ve benzer akışlar ekledik, alışma süreci daha kolay olsun diye.

Şu an resimler dev ortamından ama sistem fiilen bitti diyebilirim, 30-40 sunucuda kurup özellikle güncelleme dagitimi ve rollback senaryolarını test ediyoruz. Ürünleştirme tarafı dediğiniz gibi en zor kısım ve burada gerçekten desteğe ihtiyacımız oluyor.

Eğer siz de destek olmak isterseniz, özellikle bu test ve ürünleştirme sürecinde birlikte ilerleyebiliriz. Destek forumumuz var, ekipte aktif olan arkadaşlara kalıcı bir title veriyoruz. Siz de ilk destekleyenlerden olursunuz.

Müsait bir zamanda tanışıp fikir alışverişi yapalım, ben PM atacağım ilk fırsatta..


Sadece renk olarak benzetmeye çalıştık; mimari olarak plesk/cpanel projelerinden tamamen farklı; amacımız panelden daha çok alt yapı yönetimi.


Default preset


Cpanel Preset



Plesk Preset



Tüm Presetler Sağda



Hosting user tarafı




Mobil Preset Yok Fakat @MeSriTug; emekleri için teşekkür ediyorum gerçekten muhteşem bir şey çıkarttı ortaya.
Gerçekten bu kadar kaliteli bir uygulama beklemiyorduk; biz sadece external api tarafını açtık, geri kalan her şeyi kendisi yaptı aklıma gelmişken yazmak istedim.

Sizin ekipten böyle bir şey çıkmalıydı zaten başarılar diliyorum kardeşim

Sokaktaki cahil ama hevesli web yapımcısı olarak önceliklerim ;

Mevcut sistem gerçekten stabil mi?
- Taşıma sırasında bir şeyler bozulur mu?
- Mail, cron, kullanıcılar, izinler sorunsuz taşınır mı?
- Alışkanlıklar ne kadar zorlanır?
- Değiştirince gerçekten hissedilir bir fark olur
mu?

Aman Müşterilerin mailleri bozulmasın diye taşımayı bile düşünemediğim, aşırı fiyatları bile mecbur sineye çektiğim oldu. (Sıfır kâr, hatta zarar)..

İsme gerek yok 2005'te zamanın en büyük firması ile çalışmaya başladım.. bariz onlar İndex basıyordu ama inkar ediyorlardı.. Türkiye'nin en büyük firması idi gel gör ki habire sitelere İndex basıyorlardı.. 1-2-3-5 derken eee yeterse yeter dedim 2. Ye geçtim o gün bugün bir daha da o durumu yaşamadım..

Sonra 2. Tamam güzel çalışıyor, stabil, danışma yada sorun olsa hızlı dönüyorlardı eyvallah ama birader hostinglere çok zam yapıyorsun yahuu.. hadi bu sefer reseller'e geçiş.. sağolsun forumda iki ayrı firmada reseller kullandım. Hizmette kalitede 10 numara idi, ama maliyetler yüzünden birini bırakıp forumdan yine bir başkasına geçmek zorunda kaldım. Hizmet ve destek çok önemli ve haklarını yrmeyim gerçekten memnunum, anında (yaklaşık en fazla yarım saat içinde soru, sorun nesr çözümlüyorlar) ama günün sonunda yine karşımıza .olan sorun maliyet, fiyatlar..

Eğer geçiş yapacaksam önce fiyat avantajına bakarım uygunsa denerim oda sorunsuz ise taşırım ama baktım sorun var, destek yok hadi kardeşim hayırlı işler der maliyeti zarar bile ettirse eski sağlama geri dönerim. Önce müşterimin sitesinin stabilliği sonrası teferruat..

Benim durum böyle ama senin zaten yaptığın işleri az çok takip ediyorum ve çok güzel işler yaptığını biliyorum ve bunuda harika yapacağına eminim. Başarılar dilerim 😊

@Gkkrlmz teşekkürler.

Bizim tarafta hedef “yeni panel” iddiası değil, sahada en çok problem çıkaran iki şeyi daha yönetilebilir hale getirmek:
taşıma süreci ve altyapının öngörülebilir davranması.
O yüzden bu başlıkta pazarlama değil, gerçek dünya problemlerini konuşmak istiyoruz.




@Ajiba yazdıkların tam olarak işin gerçeği.

Panel değişimi çoğu zaman arayüz meselesi değil, risk meselesi.
Müşteri maili bozulursa, izinler dağılırsa, cronlar şaşarsa kimse o riski almak istemiyor.

Biz migration tarafında “kusursuz taşırız” gibi bir şey söylemiyoruz.
Bu işte her sunucu farklı; raw LAMP kurulumlarında path’ler, servis dizilimleri, custom ayarlar, elle dokunulmuş configler her yerde değişiyor.
Bu yüzden universal restore testlerinde başarı oranımız yaklaşık %80 bandında gidiyor.

Kalan %20 genelde aynı sebeplerden takılıyor:
bazı veriler karşı tarafta taşınabilir formatta bulunmuyor ya da güvenilir şekilde doğrulanamıyor.
Özellikle mail tarafında bazı senaryolarda şifreyi birebir import etmek mümkün olmuyor; bu durumda migration sonrası şifre sıfırlama gerekiyor.
Bunu gizlemek yerine baştan net söylüyoruz, çünkü sahada asıl sorun “sürpriz” yaşanması.

Bir de karşı sunucuya agent kurmuyoruz.
Tamamen SSH ile bağlantı açıp sunucu keşfi yapıyoruz; mümkün olan her configi bulup tek tek taşıyoruz.
Emin olmadığımız yerde “taşındı” diye geçmiyoruz; raporluyoruz ve manuel aksiyon alanını açık bırakıyoruz.

Özetle yaklaşım şu:
başarıyı şişirmek değil, taşımada neyin garanti edilebildiğini ve neyin edilemediğini açıkça yönetmek.