<p><strong>Railway veya Render kalıcı hacimlerinde iseniz</strong>, dosyalar platformun diskinde bulunur. Render'da, <code>render ssh</code> (veya kontrol panelindeki SSH bilgileri) diskten taratmanıza ve diğer tarama yapıp getirmeye izin verir. Railway’da, en az acı veren yol, Laravel'in kendi dosya sistemi soyutlamasını kullanarak yerel diski S3 uyumlu depolamaya gönderen tek seferlik artisan komutudur:<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight php"><code><span class="nv">$files</span> <span class="o">=</span> <span class="nc">Storage</span><span class="o">::</span><span class="nf">disk</span><span class="p">(</span><span class="s1">'local'</span><span class="p">)</span><span class="o">-&gt;</span><span class="nf">allFiles</span><span class="p">(</span><span class="s1>'uploads'</span><span class="p">);</span>

<span class="k">foreach</span> <span class="p">(</span><span class="nv">$files</span> <span class="k">as</span> <span class="nv">$path</span><span class="p">)</span> <span class="p">{</span>
    <span class="nc">Storage</span><span class="o">::</span><span class="nf">disk</span><span class="p">(</span><span class="s1>'s3'</span><span class="p">)</span><span class="o">-&gt;</span><span class="nf">writeStream</span><span class="p">(</span>
        <span class="nv">$path</span><span class="p">,</span>
        <span class="nc">Storage</span><span class="o">::</span><span class="nf">disk</span><span class="p">(</span><span class="s1>'local'</span><span class="p">)</span><span class="o">-&gt;</span><span class="nf">readStream</span><span class="p">(</span><span class="nv>$path</span><span class="p">)</span>
    <span class="p">);</span>
<span class="p">}</span>

<p>Bunu dağıtılmış hizmet içinden çalıştırın: <code>railway ssh</code> size çalışan konteyner içinde bir shell verir ve <code>php artisan uploads:push</code> komutunu oradan çalıştırirsiniz. Burada <code>railway run</code> çağırmayın; bu, yerel makineniz üzerinde komutu çalıştırır ve Railway'in çevresel değişkenlerini enjekte eder, böylece yerel diski okur ve yanlış dosyaları sessizce gönderir. Komut tamamlandıktan sonra, VPS'nizi hacme yönlendirin.</p>

<p>Bizim tavsiyemiz: yüklemeleri kalıcı olarak S3 uyumlu nesne depolamaya taşımak için bu geçişi bir bahane olarak kullanın, VPS'nizin yeterince diski olduğuna göre. Bu, sunucuları tüketilebilir hale getirir, sonraki göçleri basit hale getirir ve kovaların yedekleme araçları, rastgele dizinler için yedekleme araçlarından çok daha iyidir. İki kez senkronize edin: bir kez büyük miktar için günler öncesinde, bir kez de bakım penceresi sırasında kalıntılar için. <code>rclone sync</code>, idempotent olduğundan, ikinci geçiş yalnızca ne değiştiyse taşır.</p>

<h2><a name="step-6-cutover" href="#step-6-cutover"></a>Adım 6: Kesim Noksanı</h2>

<p>Kesim bir DNS değişikliğidir, ancak iyi kesimler, 48 saat içerisinde olanların sıkıcıdır.</p>

<p><strong>48 saat önce: DNS TTL'nizi düşürün.</strong> PaaS'ye işaret eden kaydı (genellikle bir CNAME, <code>yourapp.up.railway.app</code> gibi) bulun ve TTL'yi 300 saniyeye düşürün. Çözümleyicilerin eski, uzun TTL'yi geçersiz kılmak için zamana ihtiyacı vardır; bu nedenle bu işlemi erken yapmalısınız.</p>

<p><strong>24 saat önce: VPS’yi canlıymış gibi test edin.</strong> DNS'i beklemeyin. Kendi makinenizin alan adını yeni sunucuya zorlamak için:<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight shell"><code>curl <span class="nt">--resolve</span> app.example.com:443:203.0.113.10 https://app.example.com/up

<p>Laravel'in dahili <code>/up</code> sağlık yolu 200 döndürmelidir. Ardından uygulamayı aynı şekilde yürütün: giriş yapın, bir kayıt oluşturun, bir dosya yükleyin, bir işi tetikleyin ve onun işlenmesini izleyin, test bir Stripe webhook'unu ateşleyin. Adım 3'teki her servis, bir tek kullanıcı bile ona dokunmadan önce test edilmelidir.</p>

<p><strong>Kesim saati</strong>, sırayla:</p>

<ol>
    <li><code>php artisan down</code> komutunu PaaS uygulamasında çalıştırın (Adım 4).</li>
    <li>Son artımlı veritabanı senkronizasyonu ve depolama senkronizasyonu.</li>
    <li>Satır sayılarını doğrulayın.</li>
    <li>DNS'i çevirin: kaydı VPS IP'sine işaret eden A kaydına değiştirin.</li>
    <li><code>php artisan up</code> VPS'de çalıştırın.</li>
    <li>İşlemlerin gerçekleştiğini izleyin.</li>
</ol>

<p>Adım 6 için, VPS'de iki terminal açmayı unutmayın:<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight shell"><code><span class="nb">tail</span> <span class="nt">-f</span> /var/www/app/current/storage/logs/laravel.log

tail -f /var/log/nginx/access.log

<p>300 saniyelik TTL ile, çoğu trafik, TTL'nin süresi dolmasından hemen sonra yönlendirilir. Bazı inatçı çözümleyiciler birkaç saat alabilir; bu nedenle eski uygulamanın silinmemesi için bakım sayfası gösterilir. Hataları, 500 hataları (çevresel sorun), yüklemeler üzerindeki 404 hataları (depolama yolu sorunu) veya Redis'teki işlerin birikmesi (Supervisor sorunu) konusunda dikkatli olun. Sessizlik ve normal erişim günlükleri, birçok sorun halledilene kadar tamamlanmış olduğunun göstergesidir.</p>

<p>Artık, Adım 1'deki dış işaretleyicilerinizi güncelleyin: Stripe ve benzeri, webhook URL'leri, OAuth yeniden yönlendirme URI'leri, uptime izleyicileri.</p>

<h2><a name="step-7-the-rollback-plan-you-hopefully-wont-use" href="#step-7-the-rollback-plan-you-hopefully-wont-use"></a>Adım 7: Geri Dönüş Planı</h2>

<p>Bunu kesimden önce yazmalısınız, bir olayın ortasında değil.</p>

<p><strong>Kural bir: PaaS uygulamasını silmeyin.</strong> Eğer platform kullanıma göre faturalandırıyorsa, ölçeği düşürün, ama en az bir hafta boyunca dağıtılabilir durumda bırakın. Geri dönüş, kesimin tersine dönüşü olacaktır: DNS'i PaaS'ye geri işaret etmeye yönlendirmek ve uygulamasını bakım modundan çıkarmak.</p>

<p><strong>Kural iki: veritabanı geri dönüş noktanızı belirler.</strong> DNS hemen geri alınabilirken, veri değildir. Gerçek kullanıcılar VPS veritabanına yazılar yazdıktan sonra, PaaS'a geri dönmek, bu yazıları kaybetmek veya VPS veritabanını geri yüklemek anlamına gelir. Bu nedenle, karar penceresini açıkça tanımlamanız gerekir: "eğer yeni yığın DNS çevirisinden sonra 60 dakika içinde sağlıklı olmazsa, geri döneceğiz." Belirli bir süre içinde, yazılar az olur ve ters çevirmek hızlıdır. Başarı ilan ettikten sonra, PaaS veritabanı bozulmuş bir eser haline gelir ve VPS tek gerçek kaynak olur.</p>

<p><strong>Kural üç: sağlık kontrolünü de içeren prova yapın.</strong> “Sağlıklı” olmanın ne anlama geldiğini önceden belirleyin: <code>/up</code>'nın 200 dönmesi, kuyruk derinliğinin sıfıra yakın olması, günlüklerde normal bir günle karşılaştırılabilir hata oranı, satın alma işleminin tamamlanması. Belirsiz başarı ölçütleri, bir saatlik geri dönüş pencerelerinin üç günlük hata ayıklama seanslarına dönüşmesinin nedenidir.</p>

<p>Bu taşınmanın ardından, uygulama düzeyindeki geri dönüşler daha da kolaylaşacaktır. Sürüm tabanlı dağıtımlar, kötü bir dağıtımı geri almak için bir önceki sürüm dizinine geri dönmek kadar basitleşecektir.</p>

<h2><a name="step-8-postmigration-checklist" href="#step-8-postmigration-checklist"></a>Adım 8: Göç Sonrası Kontrol Listesi</h2>

<p>PaaS, sessiz bir şekilde birkaç şey yaptı; artık bunları siz yapacaksınız. Bunu ilk 48 saatte gerçekleştirin, "bir zamanlar" değil.</p>

<ul>
    <li>SSL. Let's Encrypt sertifikası verin ve otomatik yenilemenin gerçekten planlandığını doğrulayın. Manuel bir ayar için bu <code>certbot --nginx -d app.example.com</code>, ardından gelen sistemd zamanlayıcısıdır.</li>
    <li>Yedekleme. Yönetilen veritabanınızdaki otomatik yedeklemeler yok. Aylık yedeklemeler oluşturun, dış sunucuya S3 uyumlu bir depolamaya gönderin ve birini geri yükleyerek iletinin çalıştığını kanıtlayın. Hiç geri yüklemediğiniz bir yedek yanılgıdır, yedek değil.</li>
    <li>Firewall. Varsayılan olarak gelen tüm trafiği yoksayın, yalnızca sunacağınız şeylere izin verin: <code>ufw allow OpenSSH &amp;&amp; ufw allow 80,443/tcp &amp;&amp; ufw enable</code>. MySQL, Postgres ve Redis portları asla internetten erişilebilir olmamalıdır.</li>
    <li>İzleme. CPU, bellek, disk ve harici bir uptime kontrolü. Platform kontrol panelinizi kaybedeceksiniz; bunun yerine başka bir şeyle değiştirin </li>
    <li>Otomatik güvenlik güncellemeleri. <code>apt install unattended-upgrades</code> böylece çekirdek ve OpenSSL yamaları aklınızı başında tutmak zorunda kalmaz.</li>
    <li>SSH güvenliği. Anahtar sadece, <code>PermitRootLogin no</code> ve fail2ban'ı düşünün. Tam liste, üretim güvenlik kontrol listemizde bulunmaktadır.</li>
    <li>Log döngüsü. logrotate'ın Nginx ve Laravel günlüğünü kapsadığından emin olun, yoksa disk üçüncü ayda dolacaktır.</li>
</ul>

<p>Ayrıca, her şey taze iken: PaaS hizmetlerini iptal edin, geri dönüş penceresi kapandıktan sonra görevleri yapmayı takvim yapın ve ilk sertifika yenilemenin gerçekten gerçekleştiğini doğrulamak için bir hatırlatıcı oluşturun.</p>

<h2><a name="before-and-after-what-the-move-does-to-your-bill" href="#before-and-after-what-the-move-does-to-your-bill"></a>Önce ve Sonra: Taşınmanın Faturaya Etkisi</h2>

<p>Tipik bir Laravel uygulaması, genel bir PaaS'de dört ila altı ayrı faturalandırılan kalem için ödeme yapar. Bir VPS'de, bu bir sunucu ve düz bir yönetim ücreti haline gelir.</p>

<table>
    <tr>
        <th>Satır Kalemi</th>
        <th>Genel PaaS</th>
        <th>Kendi VPS’niz</th>
    </tr>
    <tr>
        <td>Web servisi</td>
        <td>Örnek/RAM başına faturalandırılır</td>
        <td>Sunucuya dahil</td>
    </tr>
    <tr>
        <td>Kuyruk işçisi</td>
        <td>Hücre olarak ikinci bir faturaladır</td>
        <td>Aynı kutudaki bir Supervisor programı</td>
    </tr>
    <tr>
        <td>Yönetilen Postgres/MySQL</td>
        <td>Depolama ve hesaplama ücretine göre ayrı bir eklentidir</td>
        <td>Sunucuya dahil</td>
    </tr>
    <tr>
        <td>Yönetilen Redis</td>
        <td>Diğer bir eklenti</td>
        <td>Aynı kutudaki Valkey</td>
    </tr>
    <tr>
        <td>Bant genişliği</td>
        <td>Faturalandırılan çıkış</td>
        <td>Hetzner ~<a href="https://betterstack.com/community/guides/web-servers/digitalocean-vs-hetzner/" target="_blank" rel="noopener noreferrer">€1.19/TB</a>; DO $10/TB, cömert dahil edilen izinler ile</td>
    </tr>
    <tr>
        <td>Sunucu yönetimi</td>
        <td>Dahil</td>
        <td>(ürün bu)</td>
    </tr>
</table>

<p>Özetle: 4 GB Hetzner örneği, <a href="https://betterstack.com/community/guides/web-servers/digitalocean-vs-hetzner/" target="_blank" rel="noopener noreferrer">~€7.99/ay</a> ve Deploynix Starter ile $12/ay, toplamda yaklaşık $21/ay, veya DigitalOcean üzerinde aynı 4 GB RAM <a href="https://betterstack.com/community/guides/web-servers/digitalocean-vs-hetzner/" target="_blank" rel="noopener noreferrer">$24/ay</a> olursa, US veri merkezi ve tanıdık bir kontrol paneli tercih ederim. "Tipik" bir PaaS faturasını belirtmeyeceğiz çünkü kullanımda ne kadar farklılık gösterdiği, esasında meseledir. Son faturanızla bu tabloyu yan yana getirip kıyaslayın. Çoğu uygulama, hobi aşamasını geçenler için, VPS sütununu daha fazla maliyetle birlikte onu bırakacaktır.</p>

<p>Kaybettiğiniz şey de gerçek: artık <code>git push</code> yapıp unutmuyorsunuz ve işletim sistemiyle artık sizin sorumluluğunuzdasınız (bu Adım 8 kontrol listesi ve bir yönetim katmanı içindir). Kazandığınız şey, Laravel'in birinci sınıf yurttaş olduğu bir yığın: zamanlayıcı bir cron satırı, Horizon bir daemon ve artık bu özellikler için size ekstra fatura edilmiyor.</p>

<h2><a name="where-this-leaves-you" href="#where-this-leaves-you"></a>Sizi Nereye Bırakıyor</h2>

<p>Bütün göç, sıkıştırılmış olarak: her şeyi envanterle ve dışa aktar, yeterince büyük bir VPS sağla, platform değişimlerini dört yapılandırma dosyasına dönüştür, ihtiyaç duyduğunuzdan önce veritabanı geri yüklemesini provaya al, yüklemeleri nesne depolamaya taşı, TTL'leri erken düşür, kesilerek bakım sayfası arkasında kes. Eski yığını canlılık kazanana kadar sağlıklı hale getirin.</p>

<p>Bireysel adımların hiçbiri zordur. Başarısızlık, sıkıcı olanları atlamaktan kaynaklanır: provanın geri yüklenmesi, satır sayısı doğrulaması, yazılı geri dönüş penceresi. Bunları yaparsanız, gerçek kesim, izleme günlüklerini izlemeye hazırlanmış sessiz 15 dakika olur.</p>

<p>Eğer Adımları 2, 3 ve 8’i bir güne sıkıştırmak isterseniz, <a href="https://deploynix.io" target="_blank" rel="noopener noreferrer">Deploynix</a>, sunucuyu sağlamakta, Nginx, PHP-FPM, veritabanınız, Supervisor işçileri, cron, SSL ve izleme yapılandırmasında yardımcı olup, ilk günden itibaren kesintisiz dağıtımlar sağlar.</p>

Kaynak: Orijinal Makale

Bu Makaleyi Paylaş