Ruby on Rails Sunucu Kurulumu: VDS Üzerinde Adım Adım Rehber

Ruby on Rails uygulamalarını “çalışır hale getirmek” ile “trafik aldığında sorunsuz sürdürmek” aynı şey değildir. Bu rehberde VDS (Virtual Dedicated Server) üzerinde Rails uygulamanız için gerekli bileşenleri nasıl kuracağınızı, hangi ayarların performans ve stabilite getirdiğini adım adım göreceksiniz. Kurulum sonunda uygulamanız Nginx üzerinden servis edilir, Puma ile application layer çalışır, PostgreSQL veri tabanı kullanılır ve systemd ile kalıcı (persistant) çalışır. Ayrıca log, güvenlik ve yedekleme noktalarını net kontrol listesiyle kapatacağız.

Hedef mimari ve kararlar (ilk 20 dakikada doğru seçim)

Rails kurulumu için önce “hangi parçalara ihtiyacım var?” sorusunu netleştirin. VDS üzerinde tipik üretim mimarisi şu şekildedir:

• Ruby: Uygulamanın çalıştığı dil katmanı (çoğunlukla Rails uyumlu sürüm)
• Rails: Uygulama framework’ü
• PostgreSQL (Postgres): Veri tabanı
• Puma (app server): Rails’i application process olarak çalıştırır
• Nginx (reverse proxy): HTTP/HTTPS trafiğini yönetir, statik dosyaları servis eder, Puma’ya proxy yapar
• systemd: Puma servisinin yeniden başlatılmasını ve otomatik çalışmasını sağlar
• yedekleme (backup): Veritabanı + uygulama kodu

Bu rehberde Nginx + Puma + systemd düzenini standart kabul edeceğiz. Dosya sayısı çok olan kurumsal projelerde bile bu kurulum modeli pratik ve denetlenebilir kalır.

VDS şartları: minimum ama net

Kurulum için “teknik olarak çalışır” yerine “makul yükte kararlı” hedefleyin.

Başlangıç için minimum hedef (tek uygulama): - 2 vCPU - 4 GB RAM - 80+ GB SSD/NVMe disk - Ubuntu 22.04/24.04 veya Debian 12 taban - 1 adet public IPv4 (gerekli olmayabilir; NAT yapılarına göre)

Rails’in kaynak kullanımı özellikle eşzamanlı istek, background job ve cache stratejisine bağlıdır. Bu yüzden ilk aşamada doğru sonraki adım ölçümdür; kurulum bitince CPU/RAM trendine göre ayar yapacaksınız.

1) Sistemi hazırlama: paketler, kullanıcı ve güvenlik

Kurulumun ilk bölümünde hedef, “yeniden kurunca da aynı güvenle ayağa kalkma” düzenini kurmak.

Kullanıcı ve klasör yapısı

Prod ortamında root ile çalışmayın. Uygulama için ayrı kullanıcı açın.

• app kullanıcı adı (örnek): rails
• Kod: /var/www/yourapp
• Ruby uygulama bağımlılıkları: kullanıcı home altında veya bundler vendor ile

Aşağıdaki örnek komutları kendi kullanıcınıza göre güncelleyin:

• sudo adduser rails
• Uygulama dizinine sudo chown -R rails:rails /var/www/yourapp

Temel paketler

Rails için sık kullanılan paketler şunlardır: - build araçları: build-essential - veri tabanı istemcileri: postgresql-client - derleme/openssl: libssl-dev, libreadline-dev - image processing (opsiyonel): imagemagick / libvips (projenize göre) - web sunucu ve TLS: nginx

Güvenlik tarafında en azından şunları yapın: - Firewall açılışları: 22/tcp, 80/tcp, 443/tcp, gerekirse 3000/tcp kapalı tutun (Nginx üzerinden bağlanıyorsanız) - Güncelleme: OS patch seviyesini güncel tutun

2) Ruby ve Rails bağımlılıklarını kurma (prod için doğru yöntem)

Rails için Ruby sürümü projenin Gemfile ve Gemfile.lock dosyasındaki gereksinimlerle uyumlu olmalıdır.

Sürüm yönetimi: RVM değil, sistemden taşınabilir tercih

Üretimde pratik bir yaklaşım rbenv veya asdf gibi sürüm yöneticilerdir. Ancak burada en kritik nokta şudur: - Proje Ruby sürümünü lock’lamak - Derleme gerektiren gem’ler için sistem paketlerini eksiksiz kurmak

Bu rehber “çalıştıran” kurgu verir; dağıtıma göre küçük farklar olur.

Bundler ve bağımlılıkların yüklenmesi

Uygulamayı rails kullanıcısı ile derleyip kurun:

• cd /var/www/yourapp
• bundle install --deployment --without development test

Buradaki --deployment yaklaşımı, Gemfile.lock ile uyumu daha sıkı hale getirir.

3) PostgreSQL kurulum ve Rails ayarı

Rails’in veri tabanı katmanı Postgres ile sağlıklı çalışır. Kurulumdan sonra iki adım kritiktir: kullanıcı/şifre + Rails environment ayarları.

Veritabanı ve kullanıcı

Proje için ayrı bir database ve ayrı kullanıcı oluşturun. Ayrı kullanıcı, izinleri yönetmeyi kolaylaştırır.

• database: yourapp_production
• kullanıcı: yourapp_user

Ardından Rails şema oluşturma adımı gelir: - RAILS_ENV=production bundle exec rails db:create - RAILS_ENV=production bundle exec rails db:migrate

database.yml üretim ayarı (net kontrol listesi)

Aşağıdaki alanlar “yanlış olunca” uygulamanın boot etmemesine yol açar: - adapter: postgresql - host (genelde local ise localhost) - database - username - password - pool (çok çekirdekli sistemlerde artırılır; temel düzeyde 5-10 bandı sık görülür)

4) Puma application server kurulumu

Rails uygulamasını doğrudan 3000 portundan servis etmek üretimde iyi pratik değildir. Nginx reverse proxy ile Puma’yı “iç ağ gibi” kullanacağız.

Puma config: kaynak ve concurrency

Puma ayarlarında hedef, “RAM taşmasın, istekler beklemede kalmasın” dengesidir.

Örnek mantık: - worker (process) sayısını düşük tutun - thread sayısını CPU’ya göre belirleyin

Puma config dosyanız (örnek: config/puma.rb) içinde şu konseptleri göreceksiniz: - threads min_threads, max_threads - workers N (cluster mode) - bind (örnek unix:/var/www/yourapp/shared/tmp/sockets/puma.sock)

Unix socket kullanmak genelde performans ve güvenlik açısından avantaj sağlar (TCP portunu dışa açmanıza gerek kalmaz).

5) Nginx reverse proxy: TLS ve statik dosyalar

Nginx’in rolü üç parçadır: 1) HTTPS (TLS) sonlandırma 2) statik içerikleri servis etme (public/assets) 3) Puma’ya proxy yapma

Domain yönlendirme ve sertifika

Önce DNS’i domain sağlayıcınızda doğru A/AAAA kaydına yönlendirin. Sonrasında cert yönetimi için popüler yaklaşım Let’s Encrypt’tir.

• 80 portu açık olmalı
• 443 portu açık olmalı

Nginx site config: servis akışı

Aşağıdaki tabloda “rails prod” için tipik ayarların işlevleri var.

Nginx config dosyanızda soket yolunu Puma config ile birebir tutun.

Static dosya ve cache stratejisi

Rails’de asset üretimi deploy öncesinde yapılır: - RAILS_ENV=production bundle exec rails assets:precompile

Bu sayede Nginx /assets isteklerini daha hızlı karşılar.

6) systemd ile Puma’yu servis yapın

Uygulamanızın “sunucu restart’ında” kendiliğinden ayağa kalkması için systemd şarttır.

unit dosyasının amacı

systemd ile şunları alırsınız: - Puma process yeniden başlatma - logların journalctl üzerinden izlenmesi - bağımlılıkların düzenli yönetimi

Pratik unit kontrol listesi

• WorkingDirectory doğru klasör olmalı
• User/Group doğru kullanıcı olmalı (rails)
• ExecStart Puma start komutunu doğru çağırmalı
• Restart=always veya on-failure
• environment değişkenleri Environment= veya bir env dosyası ile verilmeli

Başarılı kurulum sonrası: - sudo systemctl status puma-yourapp - sudo journalctl -u puma-yourapp -n 100 --no-pager

7) Loglar, sağlık kontrolleri ve problem teşhisi

Rails kurulumunda sorun yaşandığında genellikle 3 yerde ararsınız: - Nginx error log - Puma/systemd journal - Rails log (log/production.log)

Net hata senaryoları ve hızlı teşhis

• 502 Bad Gateway: Nginx Puma’ya proxy yapamıyor (soket yolu, izin, servis çalışmıyor)
• 500 Internal Server Error: Rails application exception (logları inceleyin)
• 401/403: Nginx veya application layer auth/izin sorunu (özellikle upload ve admin panel)

8) Yedekleme (backup) ve geri dönüş planı

Rails üretiminde yedekleme tek başına “dosyayı saklamak” değildir; geri dönüş testini içermelidir.

Minimum yedekleme stratejisi

• PostgreSQL: düzenli dump veya fiziksel yedek yaklaşımı
• Uygulama kodu: Git repo + deploy artifact (ya da dosya snapshot)
• Upload/static: /public ve dosya upload klasörleri

Örnek bir mantık: - DB yedek: her gün + her 1-2 saatte bir incremental ihtiyaç durumuna göre - Kod: Git commit bazlı

Restore testi: “en az bir kez” şart

Yedek aldığınız iddianın karşılığı, restore edebildiğiniz senaryodur. Ayda en az 1 kez staging üzerinde restore testi yapın.

Performans ve kaynak ayarlarında net ölçüm yöntemi

Kurulumdan sonra “RAM yetmiyor” veya “istekler yavaş” gibi problemleri ayarlamak için ölçüm gerekir. Uygulamayı trafik almadan açmayın; en azından staging veya kontrollü ortamda test edin.

Hız optimizasyonu için öncelik sırası

1) Doğru concurrency (Puma threads/workers) 2) Database bağlantı havuzu (pool) ve sorgu optimizasyonu 3) Cache (fragment/low-level cache) ve background job (Sidekiq veya eşdeğer) 4) Nginx gzip/buffer ayarları 5) Asset cache headers

VDS üzerinde Rails için spec seçimi: somut eşik mantığı

Aşağıdaki değerler “tek uygulama + makul trafik” yaklaşımıyla karar vermeyi kolaylaştırır.

En sık yapılan 10 kurulum hatası (ve net düzeltme)

1) Puma’yı 3000’den dışarı açıp güvenliği zayıflatmak 2) Nginx ile Puma soket yolunu farklı bırakmak 3) RAILS_ENV=production olmadan komut çalıştırmak 4) bundle install sırasında doğru grupları dışlamamak 5) assets:precompile adımını deploy öncesine almamak 6) systemd unit’inde yanlış User kullanmak 7) Logları takip etmeden “hata yoktur” varsaymak 8) Postgres için ayrı kullanıcı/izin yönetmemek 9) Yedek alıp hiç restore denememek 10) Cache ve session gibi kavramları düşünmeden ölçek denemek

Uygulamanızı yayına alma: pratik kontrol listesi

Kurulum tamamlandıktan sonra yayın öncesi şu sırayı uygulayın:

• RAILS_ENV=production ile migration tamamlandı
• assets:precompile üretildi
• Puma servisi systemd ile active (running) durumda
• Nginx config sözdizimi doğrulandı (nginx -t)
• Domain DNS yönlendirmesi tamamlandı
• HTTPS sertifikası aktif
• Uygulama endpoint’leri (login, temel sayfalar) test edildi
• Loglar izlenmeye başlandı
• DB yedek planı çalışır durumda

Sonuç: İlk yayını “ölçülebilir” kurun

Ruby on Rails sunucu kurulumunda kritik nokta, kurulum adımlarını doğru sırayla yapmak ve her aşamada ölçülebilir geri bildirim almak. Bu rehberdeki akışla Nginx + Puma + systemd + PostgreSQL dengesini kurun; ardından concurrency, log, yedekleme ve performans ayarlarını gerçek veriye göre güncelleyin. Yayına almadan önce test ve yedek restore senaryosunu mutlaka tamamlayın; böylece ilk hata anında müdahale süreniz dakikalarla sınırlı kalır.

İsterseniz mevcut VDS özelliklerinizi (RAM/CPU/disk), Rails sürümünüzü ve uygulama ölçeğinizi yazın; buna göre Puma concurrency ve Postgres pool için net başlangıç değerlerini birlikte belirleyebiliriz.