PrestaShop Migrasyonu: Hestia'dan DirectAdmin'e Geçiş

PrestaShop Migrasyonu: Hestia'dan DirectAdmin'e Geçiş

Bir PrestaShop migrasyonu, tüm yığının (stack) taşınması anlamına gelmek zorunda değildir. Bu durumda, bir akşam içinde backend'i eski bir Hestia kurulumundan yeni bir DirectAdmin tabanlı sunucuya taşıdım. Frontend mevcut platformunda kaldı. Bülten ve CRM hizmetleri de oldukları yerde durdu. Kapsam daha dar tutuldu: Yeni backend'in çok mağazalı (multistore) bir e-ticaret sistemi için REST API'leri, önbelleği ve cron job'larını yönetmesini sağlamak.

Aktif çalışma yaklaşık üç ila dört saat sürdü. Dosya transferi kolay kısımdı. Asıl iş, taşıma sonrasında yönlendirme, Redis, cron, önbellek geçersiz kılma (invalidation) ve mağazaya özel API yanıtlarının hala çalıştığını kanıtlamaktı.

PrestaShop Migrasyonunda Neleri Taşıdım

Backend, NVMe depolama, tahsis edilmiş CPU ve tahsis edilmiş RAM ile modern bir paylaşımlı hosting planına taşındı. Hosting paneli beklenen paketi ve disk kotasını raporladı.

Her şeyi taşımadım ve bu kasıtlıydı.

Taşınanlar:

Yerinde bırakılanlar:

Bu tür dar kapsamlı PrestaShop migrasyonlarını tercih ediyorum çünkü gürültüyü azaltır. Aynı anda frontend'i, pazarlama yığınını ve backend'i taşırsanız çok fazla değişken yaratırsınız. Burada, doğrulanacak tek bir net iş sistemi istiyordum.

Yönlendirme İlk Sorundu

PrestaShop, çok mağazalı (multishop) bir backend olarak çalışır. Bu, tek bir backend'in iki mağaza için doğru yanıt vermesi gerektiği anlamına gelir. Eski sunucuda, panel kuralları ve mevcut URL davranışı karmaşıklığın bir kısmını gizliyordu. Yeni sunucuda ise, PrestaShop isteği yeniden yönlendirmeden veya kanonikleştirmeden önce REST çağrılarının mağaza bağlamını koruması gerekiyordu.

Çözüm, mağaza önekli REST çağrılarını doğru şekilde yönlendirmekti:

Kağıt üzerinde bu önemsiz görünebilir. Pratikte ise dosyalar, veritabanı ve DNS doğru olsa bile migrasyonun bozuk hissedilmesine neden olan detay budur. Çalışmalarımda PHP, Redis veya veritabanını suçlamadan önce yönlendirmeyi kontrol ederim.

Redis Yardımcı Oldu, Ancak Önbellek Temizleme Daha Önemliydi

Redis, bir Unix socket üzerinden etkinleştirildi:

text /home/account/.redis/redis.sock

PrestaShop daha sonra önbellek backend'i olarak Redis'i kullandı. API yanıtları iyileşti, ancak önbellek yalnızca doğru zamanda temizlenirse anlam ifade eder.

Back office (yönetim paneli) gerçekliğin kaynağıdır. Birisi PrestaShop'ta bir fiyatı, ürün açıklamasını, PageBuilder bloğunu, kategoriyi veya kampanyayı değiştirdiğinde, frontend API'si güncel verileri sunmalıdır. Sadece önbelleği etkinleştirmek yeterli değildir. Ayrıca önbellek temizlemeyi ilgili PrestaShop hook'larına bağlamam gerekti.

Davranışı doğrudan doğruladım:

Bu, "önbellek etkin" ile "önbelleğe güvenilebilir" arasındaki farktır. E-ticarette bu fark hemen önem kazanır.

Cron Job'ları Dikkatli Filtreleme Gerektiriyordu

İlk Hestia cron kontrolü, PrestaShop backend'ine ait olmayan, başka bir servise ait job'ları buldu. Bu servis bu migrasyonun parçası olmadığı için bu job'ların yeni sunucuda yer almaması gerekiyordu.

İlgili PrestaShop job'ları eski canlı Hestia sunucusundaydı:

Askıya alınmış bir CRM job'unu taşımadım. Ayrıca Hestia'nın dahili sistem job'larını atladım. DirectAdmin'in kendi bakım ve yedekleme akışı vardır, bu nedenle panel artıklarını kopyalamak sadece kafa karışıklığı yaratırdı.

Bir veritabanı döküm (dump) job'u ilk başta temkinli bir geliştirme dökümü olarak eşlendi. Hosting panelinin zaten yedeklemeleri yönettiğini onayladıktan sonra bunu kaldırdım. Net bir kurtarma nedeni olmadıkça yedekleme akışlarını çoğaltmak gürültü yaratır.

Backend Taşımasından Elde Edilen Performans Sonuçları

Her mağaza için aynı genel REST endpoint'ini 12 kez test ettim:

text /rest/pagebuilder/placements

Sonuçlar şunlardı:

Stage sunucusu basit bir referans sunucusuydu ve tutarlı yanıt verdi. Yeni sunucu her iki mağaza için de daha hızlı yanıt verdi.

Yeni sunucu ayrıca daha yüksek bir ortalama sunucu yükü (load average) gösterdi, yaklaşık 10-13 civarında. SSH, fiziksel sunucuda hesap tahsisinden daha fazla CPU çekirdeği (thread) ortaya çıkardı, bu yüzden bu sayı tek başına endişe verici değildi. Hesap sessiz görünüyordu: Redis neredeyse boşta çalışıyordu, PHP worker'ları CPU'yu zorlamıyordu ve kontrol ettiğimde veritabanında düşük aktif sorgu yükü vardı.

Bu nedenle paylaşımlı hostingde yük ortalamasına dikkatli yaklaşırım. Bu yalnızca bir hesabı değil, sunucuyu yansıtır. Sağlayıcınız net CPU ve RAM özelliklerine sahip bir plan satıyor olsa bile, bu limitlerin CloudLinux veya LVE aracılığıyla nasıl uygulandığını sormak yine de faydalıdır.

Migrasyon İçin AI İş Akışım

SSH, DirectAdmin API çalışmaları, sunucu kontrolleri, crontab değişiklikleri, zamanlama testleri ve PrestaShop override çalışmaları için işletme ajanı olarak Codex'i kullandım.

İnceleme için açık iş akışım olan ai-collab-bridge kullanıyorum. Fikir basit: Bir AI değişikliği uygular, ardından başka bir AI diff, bağlam ve odaklanmış soruları içeren bir inceleme paketi alır. Claude Code daha sonra gevşek bir özete tepki vermek yerine ikinci bir teknik okuyucu olarak çalışmayı inceleyebilir.

Bu bir PrestaShop migrasyonunda önemlidir çünkü birçok küçük karar vardır:

AI, kontrollerini göstermesi gerektiğinde yardımcı olur. "Çalışıyor" demek yeterli değildir. Faydalı bir migrasyon çalışması; komutları, durum kodlarını, önbellek davranışını, cron durumunu ve kasıtlı olarak taşınmayan kısımları gösterir.

Bu Migrasyondan Çıkardığım Dersler

Panel davranışını körü körüne kopyalamayın. Hestia ve DirectAdmin hosting bakımını farklı şekilde çözer. Hestia panel cron'u DirectAdmin'e ait değildir.

Backend migrasyonunu dar tutun. Frontend zaten başka yerde çalışıyorsa, onu taşımak sadece risk ekler.

Önbelleği back office bakış açısıyla doğrulayın. E-ticaret değişiklikleri fiyat, stok, metin ve kampanya düzenlemeleri yoluyla gerçekleşir. Temizlenemeyen önbellek bir iş sorununa dönüşür.

Aynı endpoint'i tekrar tekrar ölçün. Tek bir `curl` isteği pek bir şey ifade etmez. Mağaza başına on iki çalışma bana çok daha net bir sinyal verdi.

Betiklerde veritabanı şifrelerini sabit kodlamayın (hardcode). Gerektiğinde uygulamanın mevcut yapılandırmasından okuyun ve yedeklemelerin sahipliğini hosting paneline bırakın.

Sonuç

Taşımadan sonra, testlerimde backend hem eski canlı sunucudan hem de stage referansından daha hızlı yanıt verdi. Redis ve LiteSpeed yardımcı oldu. DirectAdmin API, ihtiyacım olan panel ayarları için yeterliydi. OPcache belleğinin sunucu seviyesinde bir ayar olduğu ortaya çıktı, bu nedenle bu uygulama kodundan ziyade hosting desteği ile ilgilidir.

Ana sonuç daha düşük bir TTFB değildi. Önemli sonuç, backend'in hala bir e-ticaret backend'i gibi davranmasıydı: verinin sahibi back office'tir, API mağaza başına yanıt verir, değişikliklerde önbellek temizlenir ve cron yalnızca yeni sunucuya ait job'ları çalıştırır.

SSS

Migrasyon ne kadar sürdü?

Aktif backend migrasyonu yaklaşık üç ila dört saat sürdü. Zamanlama testleri, cron envanteri, önbellek doğrulaması ve destek notları ile çalışma dört ila beş saate yaklaştı.

Neden her şeyi taşımadınız?

Frontend zaten başka yerde çalışıyordu. Bülten otomasyonu ve CRM'in kendi ortamları vardı. Dar kapsamlı bir backend taşıması riski azalttı.

Neden Redis önemliydi?

Redis backend önbellek hızını artırdı, ancak asıl değer önbellek temizlemenin PrestaShop hook'larına bağlandığında ortaya çıktı. Bunun olmadan, back office değişiklikleri API'ye ulaşamayabilir.

Neden paylaşımlı hostingde yük ortalamasını okumak zordur?

Yük ortalaması genellikle yalnızca hesabınızı değil, tüm sunucu kuyruğunu gösterir. Bu migrasyonda, sunucu daha yüksek yük gösterirken hesap sessiz görünüyordu. Bu nedenle CloudLinux veya LVE limitlerinin destek tarafından onaylanması gerekir.

Neden bir sunucu migrasyonunda AI kullanılasın?

AI, kanıtlarla çalıştığında faydalıdır: yapılandırma okumaları, zamanlama testleri, cron karşılaştırması, API kontrolleri ve belgelenmiş değişiklikler. Açık bir iş akışı üzerinden akran incelemesi, başka bir modelin riskleri incelemesini kolaylaştırır.