El kitabı: dağıtım hedefleri ve kendi alan adınız

Kendi sunucunuza dağıtım yapmak, bir ajana ödeme yaptığınız ve üzerinde belki başka şeylerin zaten yaşadığı bir kutuya SSH benzeri erişim vermek demektir. Bu, ücretsiz bir alt alan adına yayınlamaktan farklı bir güven seviyesidir ve kurulum bunu yansıtır — bir kez doldurulan birkaç alan, ondan sonra her yapı bir düğmedir. İşte insanların birini bağlamadan önce ve sonra gerçekten sordukları sorular.

Bir hedef oluşturmak için neye ihtiyacım var?

Ayarlar → Dağıtım'da beş şey:

1. Sonra tanıyacağınız bir isim — "prod-vps", "client-hostgator", gece 11'de bir açılır menüde hayatta kalan her ne ise
2. Sunucu ve port
3. SFTP kimlik bilgileri
4. Bir webroot yolu

API belirteci yok, sunucuya kurulacak CLI yok, izlenmesi gereken cron görevi yok. Sunucunuz SFTP erişimi sunuyorsa — ki bu neredeyse her paylaşımlı sunucuyu, her VPS'i, her yönetilen WordPress kutusunu kapsar — yaklaşık iki dakikada bitirmiş olursunuz.

Şifre mi yoksa anahtar mı?

Sunucunuz destekliyorsa anahtar. Şifreler de gayet iyi çalışır ve bunları hesabınıza özel olarak saklarız, ama bir anahtar bir yerde daha az sır tutmak demektir — daha sonra bir şeyler ters giderse "bir anahtarı iptal et" ile "o şifrenin yeniden kullanıldığı her yerde şifreyi sıfırla" arasındaki fark. Bir sürü ucuz paylaşımlı barındırma SFTP kurulumu yalnızca şifre kimlik doğrulaması sunar ve bu da sorun değil. Sadece o şifreyi başka hiçbir yerde yeniden kullanmayın.

Doğru webroot yolunu nasıl bulurum?

Bu, insanların ilk seferde yanlış anladığı alandır çünkü yanlış cevap yine de mantıklı görünür. Bu sizin ana dizininiz değil, bu /var/www — bu, web sunucunuzun sunmak üzere yapılandırıldığı tam klasördür.

Emin değilseniz, herhangi bir SFTP istemcisi kullanarak doğru olduğunu düşündüğünüz klasöre atılabilir bir test.txt bırakın, ardından yoursite.com/test.txt adresinde yüklenip yüklenmediğini kontrol edin. Burayı yanlış anlarsanız dağıtım yine de başarılı olarak raporlanır — ajan dosyaları sadakatle yanlış klasöre yazar ve siz değişmemiş canlı bir sitenin karşısında, neden değişmediğini merak ederek kalırsınız.

Bir hedef birden fazla alan adını kapsayabilir mi?

Evet, ve ilk sitenizi geçtikten sonra gerçekten zaman kazandıran kısım burası. Bir hedef tek bir sunucu ve tek bir kimlik bilgisi setidir — tek bir alan adına bağlı değildir. Alan Adı Yönetimi'nde her alan adını kendi webroot geçersiz kılmasıyla bir hedefe bağlarsınız. Nginx sunucu bloklarıyla bir VPS üzerinde üç site mi çalıştırıyorsunuz?

• site-a → /var/www/site-a
• site-b → /var/www/site-b
• site-c → /var/www/site-c

Bir hedef, üç bağlantı. Bir SSH şifresini üç kez yeniden girmiyorsunuz ve bir anahtarı değiştirdiğinizde ve birini unuttuğunuzda birbirinden sapan neredeyse birbirinin aynısı üç hedef bakımı yapmıyorsunuz. Üçünden herhangi birinde dağıtıma tıklayın, hangi sunucuyu ve hangi klasörü zaten biliyor — dağıtım anında hiçbir zaman seçim yapmıyorsunuz.

Bağlandığında ajan gerçekte ne yapar?

Önce etrafına bakar — salt okunur, henüz hiçbir şey yazılmaz. Bu inceleme şunları kontrol eder:

• Boş bir klasör
• Bu tam yapının önceki bir versiyonu
• Eski bir WordPress kurulumu
• Sunucunuzun varsayılan olarak oraya bıraktığı bir "yakında" yer tutucusu

Bu, stratejiyi belirler. Boş bir webroot doğrudan bir yükleme alır. İçinde zaten bir şeyler olan bir webroot daha dikkatli ele alınır, çünkü birçok gerçek kurulumda sitenin yanında yaşayan ve kaybolmaması gereken şeyler vardır:

• A .well-known SSL doğrulaması için klasör
• Kimsenin git'e koymadığı bir uploads dizin
• A wp-config.php kimsenin dokunulmasını istemediği

Buradaki iş, "sil ve değiştir"den çok "neyin değiştiğini bul ve uzlaştır"a daha yakındır.

Ardından, tek bir bayt üzerine yazılmadan önce, mevcut webroot kendi sunucunuzda bir versiyon olarak yakalanır. Bir veritabanı kaydı değil, hesapladığımız ve doğru olmasını umduğumuz bir diff değil — orada duran şeyin gerçek bir anlık görüntüsü. Bu, herhangi bir hedefe yapılan ilk dağıtımda en çok önem taşır, çünkü o dağıtım her zaman bir şeyin üzerine iniyordur, o şey hiçbir şey olsa bile. Boş klasör, boş anlık görüntü. Kimsenin oluşturduğunu hatırlamadığı beş yıllık statik bir site — dokunulmadan önce tam olarak, ücretsiz olarak korunur. O ilk dağıtım aynı zamanda en emin olmadığınız dağıtımdır, bu yüzden bunun en çok önem taşıdığı dağıtımdır.

Kaynak kodumu mu yoksa oluşturulmuş siteyi mi yüklüyor?

Her zaman derlenmiş site. Statik bir site için bu, oluşturulan sayfalardır. Bir framework derlemesi için — Next.js, Vite, site türünün gerektirdiği ne olursa olsun — bu, derlenmiş çıktıdır, dist veya build klasörüdür, asla kaynak ağacı değil. Bunun sunucuya SSH ile girip sunucudaki şeye karşı npm run dev çalıştıramamanız anlamına gelmesine rağmen doğru karar olduğunu düşünüyorum. Kaynağı yüklemek, üretim web kök dizininizin sadece HTML sunmak için bir Node çalışma zamanına ve bir derleme araç setine ihtiyaç duyması anlamına gelir — asla bir derleme hattı çalıştırmak için tasarlanmamış paylaşımlı bir barındırma kutusunu buna dönüştürür ve her dağıtımı "sunucunun npm install'i bitirecek kadar belleği olmasını umut et"e çevirir. Yalnızca derlenmiş çıktıyı göndermek, web kök dizinini tam olarak statik bir dosya sunucusunun beklediği şey olarak tutar. Sıkıcı. Sıkıcı olan, saat sabahın ikisinde bir şeyler ters gittiğinde ve gerçekte neyin sunulduğunu anlamaya çalışırken o klasöre bakarken istediğiniz şeydir.

Bir dağıtımın gerçekten işe yaradığını nasıl anlarım?

Yüklemeden sonra ajan canlı URL'ye gider ve çözülüp çözülmediğini kontrol eder — 500 hatası değil, boş sayfa değil. Ne bulursa, artı inceleme sırasında fark ettiği ve sizin görüşünüzü istediği her şey ("bu web kök dizininde dokunmadan bıraktığım bir wp-content klasörü var, bunun beklendiğini onaylayın"), derlemenin sohbet iş parçacığına düşer. Bu platformun tamamındaki desen budur: sessiz başarı yok, destek talebine dönüşen sessiz başarısızlık yok. Ajan, ne gördüğünü ve ne karar verdiğini, dağıtımı istediğiniz aynı iş parçacığında size söyler.

Sürüm geçmişinde gerçekte neler var?

Her dağıtım bir sürüm ekler — sadece ilki değil. Yani geçmiş, derlemelerinizin soyut bir zaman çizelgesine yerleştirilmiş hali değildir; siz ortaya çıkmadan önce orada ne varsa ondan başlayarak, o web kök dizininden sırayla sunulan şeylerin gerçek dizisidir. Birinci sürüm her zaman platform öncesi o durumdur ve otomatik olarak yakalanır. Bunu düşünmenize gerek yok.

Geri alma işlemi tam olarak neyi geri yükler?

Bir öncesindeki canlı sürümü, tam olarak — eski bir derlemenin yeniden çalıştırılması değil, bir yaklaşıklık değil. Trafiği o andan önce sunan gerçek dosyalar. Bu, başka yerlerde kullandığım çoğu "geri alma" özelliğinden anlamlı ölçüde daha güçlü bir garanti; onlar genelde "eski bir commit'ten yeniden dağıt" demektir ve sessizce derleme sürecinizin deterministik olduğunu, ortamınızın o zamandan beri kaymadığını varsayar. Burada geri alma, bilinen iyi durumdaki bir anlık görüntünün geri yüklenmesidir; bu yüzden baskı altındayken başvurmak güvenlidir — geri almanın, geri aldığı şeyden farklı davranıp davranmayacağını düşünmenize gerek kalmaz.

Ve buna gerçekten ihtiyaç duyduğunuz an asla sakin bir an değildir; genelde "yeni derleme ödeme akışını bozdu ve şu anda trafik canlı" anıdır.

Tek tık, önceki sürüm geri yüklendi, tamam. Bunun bir sonradan akla gelen değil de birinci sınıf bir özellik olarak ele alınmasının arkasındaki mantık Korkusuz yineleme yazısında anlatılıyor — ihtiyaç duymadan önce bir kez okumaya değer. Hem geçmiş hem de geri yükleme kontrolü hem derleme kartında hem de hedefin kendi geçmiş görünümünde bulunur.

Bu, veritabanımı da yedekliyor mu?

Hayır, ve kimsenin aksini varsaymasına izin vermek yerine bunu açıkça söylemeyi tercih ederim. Sunucudaki sürüm geçmişi, bu dağıtım hattının web kök dizinine ne koyduğunu kapsar. Sitenizde bir veritabanı, kullanıcı yüklemeleri ya da dağıtımlar dışında değişen başka herhangi bir şey varsa, bu tamamen ayrı bir konudur — geri alma buna dokunmaz ve bunu kapsayan bir yedekleme stratejisiyle karıştırılmamalıdır.