Öncelikle gerçek bir tecrübeden daha güzel bir şey yoktur bunu düşünerek yazıyı okuyun, burada sizin kazancınız bir şeyi denemeden tecrübe etmiş kadar olacaksınız ve fikirler ararken farklı bakacaksınız.
Daha kısa bir yazı ile anlatmak isterdim fakat sizde belki bir mühendislik problemine çare bulmak isteyebilirisiniz;
Başlıyoruz…
Sene 2017'de ai ile tanıştım fakat çok yeni ve kaynak azdı denemeler yapacak kaynaklar bulamıyordum; aslında buna benzer bir konuyu 2012 yıllarında sanırım Nvidia'nın Cuda teknolojisini duyurduğunda da yaşamıştım. Cuda çok ilgimi çekmiş fakat nvida dokümantasyonu bile yeterli değildi çünkü gerçekten çok yeniydi; bu gibi durumlarda ise beklemekten başka çaremizin olmadığı dönemlerdi işte 🙂
Bu süreçte blockchain ilgimi çekti blockchain sayesinde yıllarca güzel projelerde yer aldım; bu süreçte cuda teknoloji de aldı başını gitti. 2017 yılında yetersiz ai dökümanları falan derken sanırım aralarında en dikkatimi çeken openai vardı çünkü elon musk yatırımcısıydı; openai bültenine abone olmuştum yenilikleri takip ediyordum. birgün mail geldi; beta başlamıştır diye ve beta başvurusu yaptım 10-15 gün sonra ilk beta katılımcılarından oldum geri bildirimler falan işte 🙂 bu esnada sanırım 2020-2021 yılları emin değilim.
İlk sorduğum sorulardan bir tanesi bitcoin durumlarıydı 🙂 şaşırmadınız değil mi :). neyse gpt 3 tü sanırım bu modelin duyurusunda denemek istedim; ilk sorduğum soru bir exchange sitesi için match motoru ve orderbook mikro saniyeler içerisinde işlemler fifo yöntemleri falan ve işte o an şok olduğum andı 🙂 benim yıllar içerisinde tecrübe ettiğim kodların 20 saniye içerisinde önüme koymaya başladı. işte o an daha zorlayıcı şeyler geldi aklıma. çünkü yazdığımız programlar tamamen birbirinin aynısıydı neden daha zorlarını sormayayım dedim. bak dedim yapay zeka ben bir yazılımcıyım ve 20 yıldır bu sektördeyim bana öyle sorunlar gösterki ben bu sorunları çözmek için zaman harcayayım kısacası bana yazılım sektöründeki çözülmesi zor mühendislik konularını göster. dedim. işte o an gerçekten bir çok proje fikri çıktı önüme fakat bunların hepsi yapılmıştı.
ilk verdiği şey aslında dağıtık programlama idi ben bununla 2008 – 20009 yılında sanırım java rmi ile karşılaşmıştım emin değilim arkadaşlar fakat javada dağıtık programlama üzerine bir şeyler var araştırırsanız görürsünüz tabi şuan daha farklı dağıtık programlama konuları mevcut; benim o dönemlerdeki amacım java ile yaptığım uygulamanın bazı metodlarını uzaktan çağırması idi bunuda byte olarak çözmüştüm zaten; fakat dağıtık programlama bana göre bir mühendislik sorunu değil beni aşan bir sorundu ve bu alana giremezdim.
sanırım 30 a yakın sorun gösterdi bana. bunları incelerken web yazılım sektöründeki en zor olanın Migration olduğunu söyledi; migration nedir bilmeyen arkadaşlar için söyleyeyim örneğin cpanel bir sunucunuz var fakat paneli değiştirmek plesk paneline geçmek istiyorsunuz burada cpaneldeki tüm verilerinizi kayıpsız olarak plesk'e taşımaya migration (göç veya taşıma) denir; günümüzde bakarsanız plesk ve cpanelde sadece birbirleri arasında transfer taşıma daha doğrusu migration sistemi var; ben yıllarca buna kızmıştım zaten yani o koca firmalar binlerce kullanıcısı olan belki milyon bilemiyoruz neden bunu genişletmiyor directadmin veya diğer panellere destek vermiyor ve ben özgürce geçemiyorum hep kızdım öyle böyle değil.
ben tabi o sıralar şöyle düşüyorum tabi başka panellerin kullanılmasını istemiyorlar 🙂 neyse kendi kendime ne kadar zor olabilir ki dedim; çünkü elimin altında ai tool'lar vardı copilot yeni çıkmış tab tuşuna basıyorum otomatik tamamlıyordu bana ise kontrol etmek kalıyordu hepsi bundan ibaret ya 😀
çalıştığım firmadan zaten cpanel ve plesk tartışması yapmıştık bir dönem neden fiyatlar yüksek aşırı eski insanları kendilerine bağlamışlar birde bu yazılımların fanları var sanıyorsunuz ki böyle bir yazılım asla yapılamaz. tabi 30 yıllık tecrübelerini saymazsak 🙂
firmadaki arkadaşlar ile konuştum fakat her zamanki gibi tek başıma start vermek zorunda kaldım; aradan 1 yıl geçmişti sanırım ve asıl soruna gelmiştim cpanel plesk ve diğer panellerden migration işlemi yaparak tüm dataları Panelica projesine taşımalıydım 🙂 burada başlıyoruz hazırmısınız.
önce arayüz nasıl olacak falan bu sanırım 2 hafta sürdü. sonrasında backend derken süreç inanılmaz bir hal aldı bırakın cpanelden panelica tarafına migration işlemini panelica'dan panelica sunucuya bile migrate etmek inanılmaz zordu.
işte tam burada aslında işin ne kadar zor olduğunu anlamaya başladım.
başta migration dediğim şey benim için dosyaları kopyalamak veritabanını taşımak domainleri yeni sunucuya geçirmekten ibaretti. hatta açıkçası ai ile konuşurken bile ilk başlarda böyle düşünüyordum. fakat işin içine girdikçe bunun aslında bir site taşımak olmadığını anlamaya başladım.
çünkü bir hosting hesabı sadece dosyalardan oluşmuyor.
bir müşterinin sunucusunda belki 10 tane domain var, her domainin altında subdomainler var, mysql kullanıcıları var, database'ler var, mail hesapları var, yüz binlerce mail olabilir, forwarderlar var, aliaslar var, dns kayıtları var, ssl sertifikaları var, cronlar var, ftp kullanıcıları var, php sürümleri var ve bunların birbirleri ile bağlantıları var.
bir tanesini taşıdığınızda diğerinin bozulmaması gerekiyor.
mesela çok basit bir örnek vereyim.
bir müşterinin wordpress sitesi var ve wp-config.php içerisinde database kullanıcısı ve parolası bulunuyor. siz database'i yeni sunucuya taşıdınız fakat database kullanıcısının parolasını değiştirdiniz. database taşınmış oluyor evet ama wordpress artık çalışmıyor.
daha kötüsü müşteriye "migration başarılı" diyebilirsiniz çünkü dosyalar gitmiş database gitmiş domain gitmiş fakat müşteri siteye girdiğinde 500 hatası alıyor 🙂
işte burada migration'ın aslında sadece veri taşımak olmadığını anlamaya başladım.
sadece database tarafında bile durum böyleydi.
mysql'in farklı sürümleri var mariadb var farklı authentication yöntemleri var kullanıcıların hashleri var. müşterinin parolasını bilmiyorsunuz çünkü zaten bilmemesi gereken bir şey 🙂 ama o parola yeni sunucuda da çalışmak zorunda.
yani benim yeni bir parola üretip wordpress'e yazmam gibi bir lüksüm yok.
çünkü müşterinin başka uygulamaları da olabilir.
aynı durum mail tarafında daha da beterdi.
bir müşterinin 10 yıllık mail hesabı olduğunu düşünün. içerisinde yüz binlerce mail olabilir. müşteri outlook kullanıyor olabilir, telefonda kullanıyor olabilir, thunderbird kullanıyor olabilir. parolası yıllardır aynı olabilir.
siz migration sırasında mail hesabını yeniden oluşturup yeni parola verirseniz teknik olarak mail hesabını taşımış olursunuz ama müşterinin gözünde sistemi bozmuş olursunuz.
daha kötüsü mail kutusunu oluşturup eski mailleri taşımayı unutursanız bunu ilk anda kimse fark etmeyebilir.
müşteri 3 ay önceki mailini aradığı zaman fark eder.
işte migration bana burada farklı bir şey öğretmeye başladı.
aslında yaptığınız şey "veriyi taşımak" değil.
bir sistemin mevcut durumunu başka bir sistemde yeniden üretmeye çalışıyorsunuz.
ve bunu yaparken kaynak sistem çalışmaya devam ediyor.
yani kaynak sunucu canlı.
müşteriler o sunucuyu kullanıyor.
siz bir tarafta bu sistemi okuyorsunuz diğer tarafta yeni sistemi oluşturuyorsunuz ve sonunda DNS'i çevirdiğiniz anda müşteri yeni sisteme geçmiş oluyor.
bunun üzerine bir de cPanel başka türlü Plesk başka türlü DirectAdmin başka türlü davranıyor.
örneğin cPanel'de bir şey dosyada tutuluyor Plesk'te aynı bilgi database içerisinde tutulabiliyor. başka bir panelde tamamen farklı bir yerde olabiliyor.
ilk başta bunları görünce gerçekten "bu iş düşündüğümden çok daha büyük" dedim.
hatta bir ara migration kodu yazmaktan çok panel araştırmaya başladığımızı hatırlıyorum 🙂
hangi panel nerede ne tutuyor?
hangi dosya ne anlama geliyor?
hangi database hangi kullanıcıya ait?
mail parolası nerede?
hash nasıl oluşturulmuş?
ssl nerede?
domain hangi kullanıcıya bağlı?
addon domain ile normal domain arasındaki fark ne?
hangi cron hangi kullanıcı ile çalışıyor?
php sürümü nereden geliyor?
bir panelde çalışan şey diğer panelde nereden oluşturuluyor?
bunların hepsini tek tek çözmek zorundaydık.
ve burada başka bir problem daha çıktı.
kaynak sunucuya kesinlikle zarar vermemeliydik.
çünkü bu bir test sunucusu değildi.
gerçek müşterilerin olduğu canlı bir sunucuydu.
yanlış bir komut çalıştırırsanız müşterinin sitesi gidebilir.
yanlış bir dosyayı silerseniz geri dönüşü olmayabilir.
yanlış bir database işlemi yaparsanız veri kaybedebilirsiniz.
dolayısıyla bizim için migration'ın ilk kuralı zaman içerisinde çok netleşti.
kaynak sunucuya mümkün olduğunca sadece READ yapacaktık.
yani kaynak bizim için okunacak bir sistem olacaktı.
hesapları okuyacağız.
domainleri okuyacağız.
database'leri okuyacağız.
mail hesaplarını okuyacağız.
configleri okuyacağız.
ama kaynağa bir şey yazmayacağız.
bunu özellikle tasarımın bir parçası haline getirdik.
sonra ikinci problem çıktı.
diyelim ki 500 site taşıyorsunuz.
site taşınırken hata verdi.
ne olacak?
bütün migration duracak mı?
site yüzünden 238, 239, 240. siteler de taşınmayacak mı?
bunu da istemedik.
her site kendi başına ilerlemeliydi.
bir site hata verdiğinde o site hata olarak işaretlenecek ama diğer siteler devam edecekti.
sonra başka bir şey düşündük.
migration saatler sürebilir.
500 site varsa günler bile sürebilir.
server restart olabilir.
network kopabilir.
ssh bağlantısı kopabilir.
backend restart olabilir.
transfer sırasında 200 GB dosyanın yüzde 80'i gitmiş olabilir.
şimdi bağlantı koptu diye tekrar baştan mı başlayacağız?
tabii ki hayır.
burada checkpoint/resume mantığı ortaya çıktı.
hangi site nerede?
hangi adım tamamlandı?
hangi adım başarısız oldu?
hangisi tekrar çalıştırılabilir?
bunların hepsini kayıt altına almamız gerekiyordu.
sonra migration'ı adımlara bölmeye başladık.
önce kullanıcı.
sonra domain.
sonra dosyalar.
sonra subdomainler.
sonra database.
sonra mail.
sonra ssl.
sonra dns.
sonra cron.
sonra ftp.
sonra cloudflare.
sonra doğrulama.
ve burada çok önemli bir şey yaptık.
her adım kendi başına çalışabilecek şekilde tasarlandı.
bir adım başarısız olduğunda bütün migration'ı çöpe atmıyoruz.
hatta mümkün olduğu kadar yapılan işlemleri geri alabilecek bir rollback mantığı da koyduk.
çünkü migration sırasında en korktuğum şeylerden birisi şuydu:
"bir şey oldu ama tam olarak ne oldu bilmiyoruz."
böyle bir sistem yazamazdık.
sistem bize açık açık söylemeliydi.
bu site başarılı.
bu site başarısız.
bu database taşınmadı.
bu mail hesabında problem çıktı.
bu ssl oluşturulamadı.
bu dns kaydı değiştirilemedi.
yani "başarılı" demek için gerçekten başarılı olması gerekiyordu 🙂
sonra iş daha da büyüdü.
biz sadece cPanel'den Panelica'ya migration yapmak istemiyorduk.
Plesk'ten Panelica'ya.
DirectAdmin'den Panelica'ya.
CyberPanel'den Panelica'ya.
Hestia'dan Panelica'ya.
CloudPanel'den Panelica'ya.
hatta panel olmayan bir Apache veya Nginx sunucusundan bile mümkün olduğu kadar migration yapabilmeliydik.
burada da mimariyi değiştirmek zorunda kaldık.
her panel için ayrı ayrı migration sistemi yazarsak bu iş sonsuza kadar büyürdü.
bunun yerine kaynak paneli önce tanıyacak bir sistem yaptık.
sunucuya bağlanıyorsunuz.
önce ne var diye bakıyor.
cPanel mi?
Plesk mi?
DirectAdmin mi?
Panelica mı?
başka bir panel mi?
hangi işletim sistemi?
hangi database?
hangi sürüm?
ondan sonra doğru okuyucuyu seçiyor.
yani migration motorunun kendisi aynı kalıyor.
değişen şey kaynağı nasıl okuyacağımız.
bu bizim için çok önemli bir mimari karardı.
çünkü yarın başka bir panel çıktığında migration motorunu baştan yazmamıza gerek kalmıyor.
yeni bir adapter yazıyoruz.
aslında burada iş artık benim ilk düşündüğüm "dosya kopyalama" işinden tamamen çıkmıştı.
bir çeşit translation layer yazıyorduk.
bir paneldeki dünya ile diğer paneldeki dünyayı birbirine çeviriyorduk.
ve bunu yaparken müşterinin mevcut durumunu mümkün olduğunca aynı tutmaya çalışıyorduk.
parolalar aynı kalacak.
mail aynı kalacak.
database aynı kalacak.
dosya izinleri mümkün olduğunca aynı kalacak.
cronlar aynı mantıkla çalışacak.
php sürümü mümkün olduğunca korunacak.
ssl bozulmayacak.
dns körlemesine değişmeyecek.
ve en önemlisi kaynak sunucu migration sırasında yaşamaya devam edecek.
işte Panelica migration sistemi aslında böyle ortaya çıktı.
başta "cPanel'den Panelica'ya bir migration yapalım" diye başlamıştık.
sonra bunun bir migration motoru olması gerektiğini anladık.
sonra bunun sadece panel migration'ı olmadığını anladık.
sunucudan sunucuya migration yapması gerekti.
Panelica'dan Panelica'ya migration yapması gerekti.
aynı sunucuda bile bir hesabı başka bir hesaba taşıyabilmesi gerekti.
ve en sonunda fark ettik ki bizim asıl yaptığımız şey migration değil.
bir hosting ortamını başka bir hosting ortamında yeniden üretmeye çalışıyoruz.
işin mühendislik tarafı tam olarak burada başlıyor.
çünkü bir dosyayı başka yere kopyalamak kolay.
bir database'i dump edip import etmek de kolay.
ama yaşayan bir hosting hesabının bütün ilişkilerini bozmadan başka bir makinede tekrar ayağa kaldırmak bambaşka bir şey.
ve biz yaklaşık olarak burada iki yıl önce başladığımız bir fikrin aslında ne kadar büyük bir probleme dönüştüğünü fark ettik.
bugün geriye dönüp baktığımda migration için yazdığımız kodların önemli bir kısmının aslında Panelica'nın kendisinden bile daha zor olduğunu düşünüyorum.
çünkü paneli yazarken sistemin nasıl çalışacağını siz belirliyorsunuz.
migration'da ise sistemin nasıl çalıştığını siz belirlemiyorsunuz.
karşınızda cPanel var.
Plesk var.
DirectAdmin var.
Linux'un farklı sürümleri var.
MySQL var.
MariaDB var.
farklı PHP sürümleri var.
yıllardır çalışan eski sistemler var.
ve sizin göreviniz bütün bunları okuyup mümkün olduğunca kayıpsız bir şekilde başka bir sisteme çevirmek.
işte benim başta "ne kadar zor olabilir ki" dediğim şey buraya kadar geldi 🙂
ve açıkçası bugün bana yazılım dünyasında gerçekten zor bir mühendislik problemi sorarsanız migration'ı ilk sıralara koyarım.
çünkü burada sadece kod yazmıyorsunuz.
başka insanların yıllardır çalışan sistemlerinin durumunu anlamaya çalışıyorsunuz.
ve o sistemi başka bir yerde tekrar yaşatmaya çalışıyorsunuz.
üstelik hata yaptığınız zaman sadece bir exception almıyorsunuz.
bir müşterinin yıllardır kullandığı maili kaybedebilirsiniz.
bir database'i bozabilirsiniz.
bir sitenin çalışmasını durdurabilirsiniz.
ve belki de en kötüsü müşteri bunu size günler sonra söyleyebilir.
biz Panelica'da migration tarafını geliştirirken en çok bu yüzden "başarılı görünüyor" mantığından uzak durmaya çalıştık.
ya gerçekten taşınmıştır.
ya taşınmamıştır.
arada bir yer varsa onu da açık açık göstermek zorundasınız.
çünkü migration'da sessiz bir hata aslında hata değildir.
felakettir.
Şimdi fikir halen arıyor ve gerçekten bir çözüm üretmek istiyorsanız zor mühendislik problemlerini araştırın emin olun yıllarca uğraşayacağınız bir proje çıkacaktır. Panelica projesini merak ederseniz merak ederniz : demo.panelica.com buradan canlı demoyu incelyebilirsiniz 🙂
Eveeet ve sanırım benim 2022'de yapay zekaya "bana çözülmesi zor mühendislik problemleri göster" dememden başlayıp bugün geldiğimiz noktanın en ilginç tarafı da bu.
o zaman sadece zor bir problem arıyordum.
sonunda yıllarca uğraşacağımız bir problem bulduk 🙂
Sizde aşağıdan yeni fikirler edinebilirsiniz.
Bugün Panelica migration sistemi evrensel olarak çalışmaktadır.
Cpanel to Panelica
Plesk to Panelica
Cyberpanel to Panelica
Artık cpanel alternatifi yada plesk alternatifi hatta diğer paneller için çalışan daha moderni için elimizden geleni ortaya koyduğumuz panelica yüzlerce sunucuda hizmet veriyor 🙂
Source: r/minikdev · by /u/SatoshiTURK