2026'da Ghost'u Self-Host Etme: MySQL, Bültenler ve İçerik Yedekleri

Başarısız bir Ghost deployment'ı her zaman çökmeyebilir. url ayarı HTTP olabilir veya content volume değiştirilmiş olabilir; bu durumda sistem bir login sayfası sunmaya devam edebilir. Bunun yerine uçtan uca bir kontrolle başlayın: owner kurulumunu tamamlayın, görsel içeren bir yazı yayınlayın, bir member kaydedin ve yapılandırılmış e-posta üzerinden test bülteni gönderin.

Bu kontrol, Ghost'un kataloglanmış amacına uygundur: membership ve bülten özelliklerine sahip bir publishing platformu. Ayrıca eksik dependency'leri, hatalı proxy varsayımlarını ve uptime probe'larının tespit edebileceğinden daha erken ephemeral verileri ortaya çıkarır.

Ghost runtime sınırını çizin

Ghost'un etrafına üç sınır çizin: 2368 portuna gelen trafik, kalıcı state ve supporting requirements. Container değiştirilebilir; ancak diğer iki alanın açık sahipleri olmalıdır. Ghost için network contract; MySQL 8, SMTP ve media ağırlıklı siteler için isteğe bağlı object storage'dır. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Ghost'a kapsamı sınırlandırılmış bir service credential verin.

Temiz bir client owner kurulumunu tamamlayabildiğinde, görsel içeren bir yazı yayınlayabildiğinde, bir member kaydedebildiğinde ve yapılandırılmış e-posta üzerinden test bülteni gönderebildiğinde diyagram tamamlanmış olur. MySQL sorguları, image storage, theme rendering, member count ve bulk-mail provider limitleri için süre ve resource verilerini kaydedin. Transaction başarısız olursa, dokümante edildiği gibi davranmayan ilk sınır; routing, local capacity veya supporting service alanlarından hangisini incelemeniz gerektiğini gösterir.

Ghost'un değiştirme işleminden sağ çıktığını kanıtlayın

Bir container image yeniden indirilebilir; MySQL database ile themes, images ve content files yeniden indirilemez. Bootstrap işleminden önce /var/lib/ghost/content dizinini mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Bir Compose dosyasına güvenmek yerine etkin mount'u inceleyin ve runtime user'ın Ghost'un ihtiyaç duyduğu konumlara yazabildiğini kontrol edin.

Retention ve off-host destination seçin, ardından production'a dokunmadan recovery provası yapın. Drill yalnızca posts, members, newsletters, themes ve images geri geldiğinde ve test member'ı geri yüklenen publication'ı açabildiğinde başarılıdır. Database-backed state için storage snapshot'larını, point-in-time recovery ve snapshot'lar bölümünde açıklandığı gibi application-consistent export'larla birlikte kullanın.

Credentials, roller ve dışa açık yüzeyler

Uygulamaya özgü security risk'i, desteklenmeyen bir production topology için SQLite kullanmak veya mail credentials'ı sızdırmaktır. Operasyonel çözüm; Ghost Admin'i korumak, mail ve database credentials'ını server-side tutmak ve yayınlamadan önce final HTTPS URL'sini ayarlamaktır. Bootstrap işlemini restricted route üzerinden tamamlayın ve geçici setup erişimini hemen ardından kaldırın.

url bir secret değil, configuration değeridir; Ghost'un kullandığı ayrı credentials'ı korurken bu değeri açıkça belirtin. Ghost process'ine yalnızca dokümante edilmiş mount'ları ve dependency route'larını verin; host root ve Docker socket erişiminden kaçının. Başarısız authentication ve configuration error kayıtlarını tutun; ancak token'ları, connection string'leri ve user content'i redact edin.

Ghost deployment'ını uçtan uca kanıtlayın

Ghost için release record'unda “iyi görünüyor” gibi ifadeler değil, somut gerçekler bulunmalıdır. Seçilen image digest'i, configuration checksum'ı, public hostname'i ve şu işlemlerin timestamp içeren sonuçlarını saklayın: owner kurulumunu tamamlamak, görsel içeren bir yazı yayınlamak, bir member kaydetmek ve yapılandırılmış e-posta üzerinden test bülteni göndermek. Kontrolün her deployment'tan sonra çalıştırılabilmesi için production dışı örnek veriler kullanın.

İki lifecycle event'ını ayrı ayrı kanıtlayın. Container replacement normal çalışmayı korumalıdır; clean recovery ise posts, members, newsletters, themes ve images'ın geri geldiğini ve test member'ının geri yüklenen publication'ı açabildiğini göstermelidir. Kontroller çalışırken MySQL sorgularını, image storage'ı, theme rendering'i, member count'u ve bulk-mail provider limitlerini ölçün ve sonucu bu sürüm için beklenen envelope olarak saklayın.

Reddedilen veya geçersiz bir durumu da test edin: test identity'nin MySQL 8, SMTP ve media ağırlıklı siteler için isteğe bağlı object storage erişimini geçici olarak engelleyin. Ghost teşhis edilebilir bir şekilde başarısız olmalı ve sağlıklı state'in üzerine yazmamalıdır. Geçerli koşulu geri yükleyin, örneği yeniden çalıştırın ve ilgili redact edilmiş log'ları ekleyin. Bu artifact'ler, gelecekteki rollback kararlarına somut kanıt sağlar.

Ghost için bir Docker baseline'ı

İlk Ghost çalıştırma işlemini, pull request içinde incelenebilecek kadar tekrarlanabilir tutun.

docker run -d \
  --name ghost \
  --restart unless-stopped \
  -p 127.0.0.1:2368:2368 \
  -v ghost-data:/var/lib/ghost/content \
  -e url=https://app.example.com \
  -e database__client=mysql \
  -e database__connection__host=mysql.internal \
  -e database__connection__user=ghost \
  -e database__connection__password=replace-with-a-strong-database-password \
  -e database__connection__database=ghost \
  ghost:latest

Gerçek veriler oluştuktan sonra latest sürümüne güvenmeyin. Çalışan digest'i, container user'ını ve mount ownership'ini kaydedin. Route'u production trafiğinin arkasına almadan önce application log'unu eksiksiz bir test boyunca takip edin — owner kurulumunu tamamlayın, görsel içeren bir yazı yayınlayın, bir member kaydedin ve yapılandırılmış e-posta üzerinden test bülteni gönderin — ve varsa migration'ları not edin.

TLS kolaydır; üretilen URL'ler değildir

Yayınlamadan önce url değerini final HTTPS domain'ine ayarlayın. Seçilen hostname'i container'ın 2368 portuna gönderin, original host'u ve HTTPS scheme'ini iletin ve ikinci bir direct origin yayınlamaktan kaçının.

Ghost'u temiz bir external client üzerinden test edin. Ingress failure'ını bilinen application boundary'den ayırın — url ayarı HTTP olabilir veya content volume değiştirilmiş olabilir. Certificate, DNS veya 502 error routing'e aittir; Ghost'a ulaşan ve daha sonra başarısız olan bir request ise application state, capacity veya supporting requirement alanlarına aittir. Custom-domain TLS rehberi ilk grubu ele alır.

Capacity ve upgrade kontrolleri

Capacity test'leri / adresine tekrarlanan bir request göndermek yerine MySQL sorgularını, image storage'ı, theme rendering'i, member count'u ve bulk-mail provider limitlerini çalıştırmalıdır. “Owner kurulumunu tamamla, görsel içeren bir yazı yayınla, bir member kaydet ve yapılandırılmış e-posta üzerinden test bülteni gönder” senaryosunu gerçekçi concurrency ile çalıştırın; latency, error rate ve storage growth değerlerini kaydedin.

Upgrade planlaması şu riski hesaba katmalıdır: Ghost migration'ları, Node runtime beklentileri ve custom theme'ler cloned site üzerinde test edilmelidir. Yeni release'i representative input ile test edin, ardından acceptance transaction'ı tekrarlayın ve sonucu karşılaştırın. url ayarı HTTP ise veya content volume değiştirilmişse, başarısız transaction'ı kaydedin ve ingress'in sorumlu olduğunu varsaymak yerine ilgili ilk sınırı inceleyin.

Tekrarlanabilir infrastructure işlerini Dockup'a taşıyın

Routing, certificate'lar, service replacement ve attached storage makul automation hedefleridir. Dockup bunları Ghost için yönetir ve ilgili managed database'i provision edebilir veya müşterinin kendi server'ındaki service'lere bağlanabilir.

Ghost trust policy'sini kendisi icat etmemelidir. Deployment sonrasında yayınlamadan önce url değerini final HTTPS domain'ine ayarlayın, şu sınırı uygulayın — Ghost Admin'i koruyun, mail ve database credentials'ını server-side tutun ve yayınlamadan önce final HTTPS URL'sini ayarlayın — ve şu senaryonun sonucunu doğrulayın: owner kurulumunu tamamlayın, görsel içeren bir yazı yayınlayın, bir member kaydedin ve yapılandırılmış e-posta üzerinden test bülteni gönderin. Sonuç, application-specific acceptance test'i olan one-click infrastructure'dır.

Sık sorulan sorular

Production deployment için Ghost'un neye ihtiyacı vardır?

Ghost container'ını 2368 portu üzerinden tek bir HTTPS origin'e yönlendirin. Supporting network requirement; MySQL 8, SMTP ve media ağırlıklı siteler için isteğe bağlı object storage'dır. Owner kurulumunu tamamlayamıyor, görsel içeren bir yazı yayınlayamıyor, bir member kaydedemiyor ve yapılandırılmış e-posta üzerinden test bülteni gönderemiyorsanız Ghost'u hazır kabul etmeyin.

Hangi Ghost verileri yedekte bulunmalıdır?

/var/lib/ghost/content dizinini kalıcı hale getirin ve aynı recovery manifest'ine MySQL database ile themes, images ve content files'ı dahil edin. Temiz bir Ghost restore işlemi yalnızca posts, members, newsletters, themes ve images geri geldiğinde ve test member'ı geri yüklenen publication'ı açabildiğinde başarılıdır.

Reverse proxy arkasında Ghost için HTTPS gerekir mi?

Public Ghost origin için HTTPS kullanın ve 2368 portunu internal route üzerinde tutun. Ghost ayarını doğru uygulayın: yayınlamadan önce url değerini final HTTPS domain'ine ayarlayın. Ghost için HTTPS, credentials veya user content'in aktarım sırasında korunmasını sağlar ve origin'e duyarlı client davranışını tutarlı hale getirir.

Ghost upgrade'ı nasıl test edilmelidir?

Mevcut Ghost state'ini isolated bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Ghost migration'ları, Node runtime beklentileri ve custom theme'ler cloned site üzerinde test edilmesi gerektiğinden bu noktalara özellikle dikkat edin. Data migration ve rollback sınırı anlaşılana kadar önceki Ghost image'ını saklayın.