Strapi’yi Güncelledim, Deploy Belleğe Takıldı: Hetzner ve Coolify Deneyimim

Portföy sitemin içerik yönetiminde Strapi kullanıyorum. Yeni sürüme geçmek için başladığım güncelleme, bir süre sonra kendimi sunucunun RAM ve swap kullanımını incelerken bulduğum bir sürece dönüştü.

Yerelde Strapi güncellemesi tamamlanmıştı. Ama Coolify üzerinden yaptığım deploy, Nuxt’un build aşamasında başarısız oldu.

Bu yazıda güncelleme ile deploy sorununu nasıl ayırdığımı, hangi kontrolleri yaptığımı ve ek swap alanından sonra aldığım sonucu anlatıyorum.

Strapi güncellemesi yerelde tamamlandı

İlk adımda Strapi’yi 5.40.0 sürümünden 5.57.0 sürümüne güncelledim.

Bağımlılık kurulumundan sonra geliştirme ortamını başlattım:

npm install
npm run develop

Bu komutlar, sürüm güncellemesi için gerekli paket değişikliklerinin ardından çalıştırdığım kurulum ve kontrol adımlarıydı. Tek başına `npm install`, belirli bir Strapi sürümüne geçiş komutu değildir.

Terminalde Strapi’nin 5.57.0 sürümüyle başladığını gördüm. Yerel ortamım Node.js 22.18.0 ve SQLite kullanıyordu. Migration işlemleri tamamlandı ve uygulama başarıyla açıldı.

Yereldeki bu sonuç, güncellemenin ilk doğrulamasıydı. Sunucudaki deploy sürecinin de ayrıca tamamlanması gerekiyordu.

Coolify’de deploy neden başarısız oldu?

Deploy sırasında Nuxt’un client ve SSR build adımları, ardından prerender işlemleri tamamlandı. Ancak Nitro build aşamasında işlem durdu.

Loglarda şu ifadeler vardı:

Killed
cannot allocate memory
ResourceExhausted

Bu mesajlar, incelemeyi sunucunun bellek durumuna yönlendirdi.

Burada önemli bir ayrım vardı: Hata veren işlem Strapi’nin yerel güncellemesi değil, Nuxt uygulamasının sunucuda derlenmesiydi.

Önce sunucu kaynaklarını kontrol ettim

Aşağıdaki komutları SSH ile bağlandığım sunucuda çalıştırdım:

free -h

Bu komutla RAM ve swap kullanımına baktım.

Ardından etkin swap alanlarını listeledim:

swapon --show

Diskte ne kadar boş alan kaldığını kontrol ettim:

df -h /

Container’ların o andaki kaynak kullanımını görmek için de şu komutu kullandım:

docker stats --no-stream

Kontrol anında sunucuda yaklaşık 1,9 GiB RAM vardı. Kullanılabilir bellek yaklaşık 501 MiB görünüyordu.

Zaten mevcut bir swap dosyası bulunuyordu:

/swapfile — 2 GiB

Bunun yaklaşık 833 MiB’ı kullanılıyordu. BuildKit container’ı ise kontrol anında yaklaşık 463 MiB bellek tüketiyordu.

Bu değerler build’in en yüksek bellek kullanımını ölçen bir kayıt değildi; o andaki durumu gösteriyordu. Ancak hata mesajlarıyla birlikte değerlendirince bellek baskısı üzerinde durmak anlamlıydı.

Mevcut swap alanına 2 GiB ekledim

Mevcut swap dosyasını değiştirmek yerine ayrı bir dosya oluşturdum:

/swapfile-extra

Bu işlem diskte alan ayırdığı için önce boş disk alanını kontrol etmiştim.

Aşağıdaki komutları sunucuda root kullanıcısıyla çalıştırdım. Bunlar yeni bir swap dosyası oluşturmak içindir; aynı yolda mevcut bir dosya varsa doğrudan tekrar çalıştırılmamalıdır.

fallocate -l 2G /swapfile-extra
chmod 600 /swapfile-extra
mkswap /swapfile-extra
swapon /swapfile-extra

Komutların görevleri şöyleydi:

- fallocate: Dosya için 2 GiB disk alanı ayırdı.

- chmod 600: Dosyaya erişimi sahibiyle sınırladı.

- mkswap: Dosyayı swap alanı olarak hazırladı.

- swapon: Yeni swap alanını etkinleştirdi.

Swap dosyası oluşturma yöntemi dosya sistemine göre değişebilir. Buradaki yöntem benim sunucumda çalıştı.

Sonrasında tekrar kontrol ettim:

swapon --show
free -h

Mevcut 2 GiB swap’a ek olarak yeni 2 GiB alan da görünüyordu. Toplam swap kapasitesi 4 GiB olmuştu.

Deploy’u yeniden denedim

Ek swap alanını etkinleştirdikten sonra Coolify üzerinden tek bir deploy başlattım.

Bu denemede deploy başarıyla tamamlandı.

Build yapılandırmasını değiştirmeden ve çalışan container’ları durdurmadan aldığım bu sonuç, ek swap alanının bu denemede bellek baskısını karşılamaya yardımcı olduğuyla uyumluydu.

Yine de yalnızca bu sonuçtan hareketle, gelecekte bütün build işlemlerinin sorunsuz tamamlanacağını söylemek mümkün değil.

Swap ayarını kalıcı hale getirdim

swapon ile etkinleştirmek, tek başına swap dosyasının yeniden başlatma sonrasında otomatik açılmasını sağlamıyor. Bunun için /etc/fstab dosyasına kayıt ekledim.

Aynı kaydı tekrar eklememek için önce mevcut olup olmadığını kontrol ettim:

grep -qE '^/swapfile-extra[[:space:]]' /etc/fstab || \
  echo '/swapfile-extra none swap sw 0 0' >> /etc/fstab

Ardından etkin swap alanlarını ve disk durumunu tekrar kontrol ettim:

swapon --show
df -h /

Bu aşamada iki swap dosyası da etkin görünüyordu. Yeniden başlatma için gerekli kayıt da eklenmişti; bu çalışma sırasında ayrıca reboot testi yapmadım.

Swap eklemek uzun vadede yeterli mi?

Bu işlemden sonra deploy tamamlandı, ama fiziksel RAM miktarı değişmedi.

Swap, diski bellek yönetiminde kullanır. Disk erişimi RAM’den daha yavaş olduğu için yoğun swap kullanımı performansı etkileyebilir. Bu nedenle ek swap alanını, sunucunun kapasitesini değerlendirmenin yerine koymamak gerekiyor.

Benim için burada iki farklı ihtiyacı ayırmak önemliydi:

Uygulamanın çalışırken kullandığı kaynaklar ve build sırasında ihtiyaç duyduğu kaynaklar aynı olmayabiliyor.

Yeni projeler eklendiğinde yalnızca uygulamaların normal kullanımına değil, deploy sırasında oluşan yükün de sunucuya sığıp sığmadığına bakmam gerekecek.

Bu yüzden ileride takip edeceğim noktalar:

• Normal kullanımda RAM ve swap durumu.
• Build sırasında kaynak kullanımı.
• Aynı anda çalışan deploy sayısı.
• Diskte kalan alan.
• Proje sayısı arttıkça sunucu kapasitesi.

Build’i ayrı bir ortamda yapmak veya sunucu kaynaklarını artırmak da ihtiyaç büyüdüğünde değerlendirebileceğim seçenekler.

Bu süreçten ne öğrendim?

Başlangıçta yaptığım iş bir Strapi güncellemesiydi. Ancak deploy sırasında karşıma çıkan sorun, Nuxt’un build işlemi ve sunucu kaynaklarıyla ilgiliydi.

Bu deneyim, aynı gün içinde yaşanan iki sorunun otomatik olarak aynı nedenden kaynaklandığını varsaymamam gerektiğini hatırlattı.

Önce hatanın hangi aşamada çıktığını belirledim. Ardından RAM, swap, disk ve container kullanımını kontrol ettim. Mevcut swap alanına 2 GiB ekledikten sonra deploy’u yeniden çalıştırdım ve bu deneme başarıyla tamamlandı.

Benim için asıl kazanım, deploy hatasını yalnızca yeniden denemek yerine, sunucunun hangi noktada zorlandığını incelemek oldu.