Sorun: eski PHP ağır çekimde bir kesinti
Eski bir PHP uygulaması genellikle üç riski aynı anda taşır: artık güvenlik yaması almayan bir PHP sürümünde çalışır, modern PHP'nin kaldırdığı eklentiler üzerinden veritabanıyla konuşur ve kimsenin yeniden başlatmaya cesaret edemediği tek, yaşlanmış bir sunucuda yaşar. Geçen her ay onu daha savunmasız ve taşınması daha zor hale getirir, çünkü nasıl çalıştığına dair kurumsal hafıza silinirken saldırı yüzeyi büyür. Ona dokunmama içgüdüsü anlaşılırdır ve onu tam olarak tehlikeli yapan da budur — ne kadar uzun süre öylece dururse, nihai zorunlu taşıma o kadar büyür. Bu senaryo, taşımayı acil bir durum yerine kasıtlı ve geri alınabilir hale getirmek için var.
cdn.com.tr bunu nasıl çözer: modern runtime, yönetilen veri, edge kalkanı
PHP Platform, uygulamaya düzgün bir dosya yöneticisi ve sürüm seçimiyle desteklenen bir PHP 8 runtime verir; böylece artık eski kutuya ne kurulduğuna bağlı kalmazsınız. Yönetilen veritabanı, verileri o kırılgan sunucudan alıp yapılandırma dosyalarına yapıştırmak yerine runtime'a enjekte edilen kimlik bilgileriyle yönetilen bir MySQL servisine koyar. İkisinin önünde de edge katmanı, TLS'i Auto SSL ile sonlandırır ve trafiği WAF ile filtreler; böylece modern güvenlik uygulamalarından öncesine ait kod bile doğrudan internete maruz kalmaz. Runtime'ı ve veri katmanını modernize ederken orijinal uygulamanın hiç sahip olmadığı korumaya sarıyorsunuz.
PHP 8 uyumluluğu: taşımayı gerçekten kilitleyen iş
Taşıma, kod uyumluluğuyla ayakta durur veya düşer, gerçek çabanın gittiği yer burasıdır. Eski uygulamalar yaygın olarak kaldırılmış mysql_* fonksiyonlarını kullanır, PHP 7 ve 8'de silinen veya değiştirilen fonksiyonlara güvenir, PHP 8'in sıkılaştırdığı gevşek tip zorlamasını (type juggling) varsayar veya artık paketlenmeyen eklentilere bağımlıdır. Uygulamayı yeni runtime'ın bir staging kopyasında çalıştırmak, bu sorunları production'da sürprizler yerine somut hatalar olarak ortaya çıkarır. Bunları yöntemli bir şekilde düzeltirsiniz — mysql_*'i mysqli veya PDO ile değiştirirsiniz, kaldırılmış fonksiyonları değiştirirsiniz, uyarıları ele alırsınız — ve kritik yollar temiz olana kadar yeniden test edersiniz. Ancak o zaman canlıya geçmek bir inanç sıçraması değil, rutin bir adım haline gelir.
Verinizi bozmadan veritabanı taşıma
Veriyi taşımak, acele ederseniz sessiz hasarın olduğu yerdir. En yaygın tuzak karakter kodlamasıdır: birçok eski veritabanı latin1 veya karışıktır ve bunları dikkatsizce bir utf8mb4 hedefine içe aktarmak, Türkçe karakterleri ve diğer ASCII-olmayan metni sonradan geri döndürülmesi zor olan bir karmaşaya (mojibake) çevirir. Güvenli yol, yönetilen MySQL'e içe aktarmak, kaynak karakter setini ve collation'ı açıkça eşleştirmek ve sonuca güvenmeden önce gerçek kayıtlardan bir örneği — özellikle aksanlı veya Latin olmayan metin içeren her şeyi — doğrulamaktır. Tam okuma/yazma döngüsünü staging'de doğrularsınız, böylece geçiş anında veritabanı umut edilen değil, bilinen-iyi bir kopya olur.
Staging ve rollback: canlı trafikle asla kumar oynamayın
Eski bir taşımayı güvenli yapan disiplin, yeni ortam kendini kanıtlayana kadar production'ın dokunulmadan çalışmaya devam etmesidir. Her şeyi staging'de inşa eder ve test edersiniz, ve eski sunucuyu geçişten sonrasına kadar canlı ve sunmaya devam eder tutarsınız. DNS TTL'sini önceden düşürmek, edge'e geçişin — ve gerekirse geri dönüşün — saatler yerine dakikalar sürmesi anlamına gelir. Staging'in ortaya çıkarmadığı bir şey gerçek trafik altında bozulursa, DNS'i eski sunucuya geri döndürür, sorunu staging'de düzeltir ve tekrar denersiniz. Taşıma sırasında eski ortama dair hiçbir şey yok edilmediğinden, rollback bir blöf değil gerçek bir seçenektir.
İsteğe bağlı: gelecekteki deploy'ları GitHub ile standartlaştırın
Uygulama platformdayken, gelecekteki değişikliklerin tekrarlanabilir bir pipeline üzerinden çıkması için repository'sini GitHub Deploy üzerinden bağlayabilirsiniz — Composer install, build ve migration adımları bir kez tanımlanır ve her seferinde aynı şekilde çalışır. Bu, tek seferlik taşımayı devam eden, kontrollü bir deploy akışına dönüştürür; bu genellikle uzun süredir ihmal edilen bir uygulamanın nihayet sürdürülebilir bir yayın sürecine kavuştuğu andır. İsteğe bağlıdır, ama bir kurtarma taşımasının sadece bir adres değişikliği değil, gerçek bir modernizasyon haline geldiği yer burasıdır.
Adım adım nasıl kurulur
Uygulamayı envanterleyin ve hedef bir runtime seçin
Uygulamanın bağlı olduğu PHP sürümünü, eklentileri, cron işlerini ve dosya yollarını kataloglayın, ardından desteklenen bir PHP 8 runtime hedefleyen bir PHP Platform uygulaması oluşturun. Kaldırılmış fonksiyonlar veya eski MySQL eklentileri kullanan her şeyi not edin, böylece production'a dokunmadan önce hangi kod değişikliklerinin geleceğini bilirsiniz.
Bir staging kopyası kurun
Kodu platforma bir staging ortamı olarak dağıtın ve veritabanının bir kopyasını içe aktarın; böylece hiçbir canlı trafik olmadan uygulamayı yeni runtime üzerinde çalıştırabilirsiniz. Kodu GitHub Deploy veya dosya yöneticisi üzerinden gönderin ve taşıma kanıtlanana kadar bu ortamı koruyun.
Veritabanını yönetilen MySQL'e taşıyın
Yönetilen bir veritabanı oluşturun, dump'ınızı içe aktarın ve karakter setinin ve collation'ın orijinaliyle eşleştiğini doğrulayın (eski uygulamalar sıklıkla latin1 veya karışık bir kodlamadır). Uygulamayı sabit kodlamak yerine platformun sağladığı kimlik bilgilerini kullanarak yönetilen veritabanına yönlendirin ve staging'de okuma/yazmaları doğrulayın.
Uyumluluğu düzeltin ve staging'de yeniden test edin
Staging'de ortaya çıkan PHP 8 sorunlarını — kullanımdan kaldırılmış fonksiyonlar, mysql_*'ten mysqli/PDO'ya geçiş, daha sıkı tip işleme — uygulama sorunsuz çalışana kadar ele alın. Canlıya geçme konuşulmadan önce kritik yolları (login, formlar, yönetim paneli, ödemeler) staging URL'sinde uçtan uca test edin.
Alan adını, Auto SSL'i ve WAF'ı bağlayın
Alan adını CDN hesabına getirin, Auto SSL'in sertifikayı hazırlamasına izin verin ve eski kodun kamuya açık internetle karşılaştığı anda korunması için WAF'ı etkinleştirin. Uygulama sunucusunun asla doğrudan açığa çıkmaması için origin'in yalnızca edge üzerinden erişilebilir olmasını sağlayın.
Rollback hazırken DNS'i geçirin
Bir sorun ortaya çıkarsa hızlıca geri dönebilmek için önceden düşük bir TTL ayarlanmış sakin bir pencerede DNS'i edge'e geçirin. Yeni ortam gerçek trafik altında kendini kanıtlayana kadar eski sunucuyu çalışır ve dokunulmamış tutun, ardından devre dışı bırakın.
Örnek senaryolar
Desteği sona ermiş PHP üzerinde uzun süredir çalışan bir forum, PHP 8 ve yönetilen MySQL'e taşınır; okuma ağırlıklı arşiv bölümleri edge'de cache'lenir ve WAF bot istismarını köreltir.
Özel bir PHP CMS, uyumluluk düzeltmelerinden sonra olduğu gibi modern runtime'a taşınır; tam bir yeniden yazım olmadan yıllarca güvenli çalışma kazandırır.
Tek, yaşlanmış bir kutuda çalışan bir iş uygulaması, yönetilen runtime ve veritabanına taşınır; herkesi tedirgin eden tek arıza noktası ortadan kalkar.
Sıkça sorulan sorular
Uygulamam eski mysql_* fonksiyonlarını kullanıyor. PHP 8'de çalışır mı?
Olduğu gibi değil — bu fonksiyonlar yıllar önce kaldırıldı. Taşıma, bunları mysqli veya PDO ile değiştirmeyi içerir; bu tam olarak staging'in canlıya geçmeden önce düzeltebilmeniz için açık hatalar olarak ortaya çıkardığı, production'da keşfetmek yerine önceden ele aldığınız türden bir sorundur.
Veritabanı taşıması sırasında Türkçe karakterlerin bozulmasını nasıl önlerim?
Yönetilen MySQL'e içe aktarırken kaynak karakter setini ve collation'ı açıkça eşleştirin ve aksanlı veya Latin olmayan metin içeren örnek kayıtları staging'de doğrulayın. Kodlama uyumsuzlukları eski taşımalardaki en yaygın sessiz hatadır, bu yüzden bunu geçişten önce, sonra değil doğrularsınız.
Canlı siteye dokunmadan her şeyi test edebilir miyim?
Evet, yaklaşımın özü budur. Yeni runtime üzerinde veritabanının bir kopyasıyla tam bir staging kopyası çalıştırır, kritik yolları kanıtlar ve ancak o zaman DNS'i taşırsınız. Production tüm bu süre boyunca eski sunucuda çalışmaya devam eder.
Geçişten hemen sonra bir şey bozulursa ne olur?
Hâlâ çalışan ve dokunulmamış olan eski sunucuya DNS'i geri döndürür, ardından sorunu staging'de düzeltip tekrar denersiniz. Geçişten önce düşük bir DNS TTL ayarlamak, bu rollback'i dakikalara indirir.
Tüm kodumu bir kerede yükseltmem gerekiyor mu?
Uygulamanın hedef PHP 8 runtime'ında sorunsuz çalışması için yeterli uyumluluk işi yapmanız gerekir, ama uygulamayı yeniden yazmanız gerekmez. Birçok eski uygulama odaklı bir düzeltme setiyle taşınır; daha büyük bir refactor, uygulama platformda güvenle yerleştikten sonra gelebilir.
Eski kodum internete tekrar açıldığında güvende mi?
Edge WAF ve Auto SSL uygulamanın önünde durur, istekler origin'e ulaşmadan önce yaygın saldırı trafiğini filtreler ve HTTPS'i zorunlu kılar. Uygulama sunucusunun yalnızca edge üzerinden erişilebilir tutulmasıyla birleştiğinde, bu eski koda eski sunucusunda hiç sahip olmadığı bir koruma sağlar.