Kontrol Paneli Olmadan VPS Yönetimi ve Site Yayını

Kontrol Paneli Olmadan VPS Yönetimi Neden Mantıklı?

Kontrol paneli olmadan VPS yönetimi; paketleri, kullanıcıları, web sunucusunu ve dağıtımları SSH üzerinden düzenlemek demektir. Panel lisansı ve ek hizmetler azalabilir; toplam maliyet ise bakım zamanı, yedekleme ve destek ihtiyacına da bağlıdır. Birkaç uygulamayı doğrudan yönetmek isteyen ve Linux bakımını üstlenebilen ekipler için bu yaklaşım uygun olabilir.

Bu rehberde DCHost üzerinde kiraladığınız bir Linux VPS’i hiçbir kontrol paneli olmadan, yalnızca SSH komut satırı kullanarak web sitesi yayını için temel kurulumu nasıl yapabileceğinizi adım adım anlatacağız. Hedefimiz şu:

• Alan adınız (örneğin example.com) DCHost üzerindeki VPS’inize işaret etsin,
• VPS’te Nginx + PHP-FPM + bu rehberde kullanılan MariaDB yığını kurulu olsun,
• HTTPS (SSL) ile güvenli ve modern bir web sitesi yayında olsun,
• Tüm bunlar panel olmadan, sadece SSH ile yönetilebilsin.

Bu rehberin ana örneği Ubuntu 24.04 LTS, PHP 8.3 ve MariaDB 10.11 kullanır. Mevcut üretim sunucusunu dönüştürmek yerine yeni bir test VPS’i üzerinde ilerleyin; uygulamanızın bu sürümlerle uyumluluğunu doğrulayın. Alan adları ve IP’ler yer tutucudur. Komutlar; yerel bilgisayar, sunucu ve veritabanı istemcisi ayrımı belirtilerek uygulanmalıdır. Örnek kurulum, uygulamanın kabul testlerinin yerini tutmaz.

Ön Hazırlık: VPS, Domain ve Erişim Bilgileri

Önce konsepti netleştirelim: Elinizde DCHost üzerinde kiralanmış bir VPS, bir alan adı ve SSH erişimi olmalı. Bu rehberdeki alan adıyla yayın senaryosu için bu üçüne ihtiyaç duyacağız.

1. Uygun VPS Planını Seçmek

Panel hizmetlerini kurmamak bazı kaynak tüketimini azaltabilir; uygulamanın CPU, RAM ve disk ihtiyacı yine ölçülmelidir. Daha küçük bir VPS’in yeterli olacağını yalnızca panel bulunmamasından çıkarmayın.

WordPress, Laravel veya başka bir PHP projesinin başlangıç kapasitesini belirlerken CPU, RAM ve trafik hesaplama rehberini kullanabilirsiniz. Son kararı temsili trafik, PHP çalışan belleği, veritabanı yükü ve yedekler için gereken disk alanıyla doğrulayın.

2. İşletim Sistemi ve Sürüm Tercihi

Ana örnek Ubuntu 24.04 LTS içindir. İşletim sistemi seçerken şu ölçütleri birlikte değerlendirin:

• Geniş dokümantasyon ve topluluk desteği,
• Uzun süreli (LTS) güvenlik güncellemeleri,
• PHP, Nginx ve MariaDB gibi paketlere kolay erişim.

DCHost planınızda sunulan imajları ve yönetim kapsamını doğrulayın. Başka Ubuntu/Debian sürümlerinde veya RHEL ailesinde paket adları, servis birimleri, PHP soketi ve güvenlik politikaları değişir; aşağıdaki web yığını komutları doğrudan bu sistemlere kopyalanmamalıdır.

3. SSH Bilgilerini Hazır Etmek

Bağlantı için şu bilgileri hazır edin; kullanıcı ve kimlik doğrulama yöntemi sunucu imajına göre değişebilir:

• Sunucu IP adresi (örneğin 203.0.113.10)
• İlk giriş kullanıcı adı; aşağıdaki örnekler root erişimi varsayar
• Bu kullanıcıya ait parola veya yetkilendirilmiş SSH anahtarı

Yerel bilgisayarınızda bir SSH istemcisine ihtiyacınız var:

• macOS / Linux: Terminal içindeki ssh komutu,
• Windows: OpenSSH istemcisi kuruluysa PowerShell veya Windows Terminal üzerinden ssh; alternatif olarak PuTTY.

Yeni aldığınız VPS’in donanım ve ağ performansını test etmek için de ayrıca zaman ayırmanızı öneririm. Bunun için adım adım örnekler bulmak isterseniz, yeni VPS aldığınızda ilk yapmanız gerekenler ve benchmark rehberimizi inceleyebilirsiniz.

SSH ile İlk Bağlantı ve Kullanıcı Oluşturma

Şimdi ilk kez VPS’e bağlanalım. Örnek IP adresini sunucunuzun gerçek IP adresiyle değiştirin. Aşağıdaki komut root erişimi varsayar; farklı bir ilk giriş kullanıcınız varsa onu kullanın ve yönetim komutlarını sudo yetkisiyle çalıştırın. Yerel terminalinizde:

ssh root@203.0.113.10

İlk bağlantıda sunucunun anahtar parmak izi sorulur. Onaylamadan önce bunu güvenilir bir kanal üzerinden edindiğiniz sunucu parmak iziyle karşılaştırın; uyuşmuyorsa devam etmeyin. Ardından yapılandırılmış parola veya SSH anahtarıyla oturum açın. Ancak root ile günlük çalışma yapmak kötü bir alışkanlıktır. Hemen yeni bir kullanıcı oluşturup sudo yetkisi verelim.

1. Yeni Kullanıcı ve Sudo Yetkisi

# Mevcut root oturumunda; sudo kullanıcısıysanız uygun komutlara sudo ekleyin.
# sudo kurulu değilse önce apt update ve apt install sudo çalıştırın.
adduser deploy
usermod -aG sudo deploy
visudo -c

Mevcut SSH oturumunu açık tutun. Parolayla giriş açıksa ikinci bir yerel terminalden deploy kullanıcısıyla bağlanın. Yalnızca anahtarla giriş açıksa önce sonraki bölümdeki açık anahtarı mevcut yönetici oturumundan deploy hesabına yerleştirin; dosya ve dizinlerin sahibi deploy olmalıdır. Ardından bağlantıyı deneyin:

ssh deploy@203.0.113.10

adduser sırasında deploy hesabı için güçlü bir parola belirleyin; bu parola, SSH anahtarı kullanılsa da sudo tarafından istenebilir. Yeni oturumda sudo -v ve sudo whoami ile yetkiyi doğrulayın. Yalnızca gruba eklemek, tüm özel sudo politikalarını veya hesap kısıtlamalarını doğrulamaz.

2. SSH Anahtar Tabanlı Giriş

Yerel bilgisayarınızda bir SSH anahtarı oluşturun veya mevcut uygun anahtarınızı kullanın. Aşağıdaki örnek için ayrı bir dosya adı seçilmiştir; mevcut anahtar dosyasını üzerine yazarak kaybetmeyin. Özel anahtarı güçlü bir anahtar parolasıyla koruyun:

ssh-keygen -t ed25519 -f ~/.ssh/dchost_deploy -C "deploy-access"

Yerel ~/.ssh/dchost_deploy.pub dosyasının tamamını kopyalayın; özel anahtar sunucuya gitmez. Mevcut yönetici oturumunda sudo -iu deploy ile deploy hesabına geçin; root oturumundaysanız su - deploy kullanılabilir. Aşağıdaki yer tutucuyu tek satırlık gerçek açık anahtarla değiştirin:

umask 077
mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat >> ~/.ssh/authorized_keys <<'PUBLIC_KEY'
REPLACE_WITH_YOUR_COMPLETE_PUBLIC_KEY_LINE
PUBLIC_KEY
chmod 600 ~/.ssh/authorized_keys

Dosyaların sahibi deploy olmalıdır. Mevcut yönetici oturumunu açık tutun ve ayrı bir yerel terminalde yalnızca anahtarla bağlantıyı test edin; sunucu parolası yerine anahtar parolası sorulabilir. Bu bağlantı ve sudo testi geçmeden SSH politikasını daraltmayın:

ssh -i ~/.ssh/dchost_deploy -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no deploy@203.0.113.10
# Yeni uzak oturumda:
sudo -v
sudo whoami

Sonraki SSH/rsync/Git komutlarının bu özel dosya adlı anahtarı kullanması için yerel ~/.ssh/config dosyasına aşağıdaki host bölümünü mevcut ayarlarla uyumlu biçimde ekleyin; IP’yi kendi sunucunuzla değiştirin:

Host 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/dchost_deploy
    IdentitiesOnly yes

SSH güvenliğini daha ileri seviyeye taşımak (örneğin FIDO2 güvenlik anahtarları, SSH CA ve anahtar rotasyonu gibi konular) istiyorsanız, VPS’te SSH güvenliği nasıl sağlamlaşır rehberimizi mutlaka okumanızı öneririm.

Temel Güvenlik: Güncellemeler, SSH Ayarları ve Güvenlik Duvarı

Kontrol panelinin bulunması güvenlik sorumluluğunu tek başına belirlemez. Yönetilmeyen bir VPS’te işletim sistemi ve uygulama güvenliği sizin sorumluluğunuzdadır; yönetilen hizmetlerde görev paylaşımı sözleşmeye bağlıdır. Aşağıdaki adımlar temel riskleri azaltmaya yöneliktir.

1. Sistem Güncellemeleri

sudo apt update
sudo apt upgrade

Bu komutlarla paket listesini yenileyip kullanılabilir paket yükseltmelerini uygularsınız. İşlem çıktısında bekleyen yükseltmeleri ve yeniden başlatma gereksinimini kontrol edin; komutların tamamlanması, çalışan çekirdek dahil her bileşenin güncel olduğunu tek başına göstermez.

2. SSH Yapılandırmasını Sertleştirmek

Ubuntu OpenSSH belgesindeki yapılandırma düzenini kontrol edin. Ana dosyada genellikle başta Include /etc/ssh/sshd_config.d/*.conf bulunur; çoğu direktifte ilk değer kullanılır ve dosyalar ad sırasıyla okunur. Mevcut include dosyalarını ve Match bloklarını inceleyin. Yalnızca dosyanın sonuna eklemek veya var olan ayarın altına ikinci bir satır yazmak yeterli değildir:

sudoedit /etc/ssh/sshd_config

Aşağıdaki politika doğrudan root SSH girişini kapatır ve public-key doğrulamasını zorunlu kılar. Değerleri gerçekten okunan global bölümde, Match kapsamına yanlışlıkla girmeden düzenleyin; dahil edilen dosyalardaki daha önceki değerleri ve kullanıcı/adres bazlı istisnaları da uyarlayın. UsePAM yes hesap/oturum denetimlerini korur; parola ve keyboard-interactive yolları ayrıca kapatılır. Çalışan erişim oturumunuz ve konsol/kurtarma yolunuz hazır olmalıdır:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey
UsePAM yes

Önce sözdizimini ve anahtarları test edin; sonra -T -C ile gerçek bağlantınıza uyan etkin ayarları inceleyin. Örnekteki istemci adı, kaynak/hedef IP ve portu değiştirin. Farklı Match koşulları olan kullanıcı/adresler için kontrolü tekrarlayın. Çıktıda permitrootlogin no, passwordauthentication no, kbdinteractiveauthentication no, pubkeyauthentication yes, authenticationmethods publickey ve usepam yes beklenir:

sudo /usr/sbin/sshd -t && sudo /usr/sbin/sshd -T -C user=deploy,host=client.example.com,addr=198.51.100.25,laddr=203.0.113.10,lport=22

Kontroller başarılı ve etkin politika beklediğiniz gibiyse Ubuntu 24.04 üzerinde:

sudo systemctl reload ssh.service

Yeniden yüklemeden sonra yeni bir terminalde aynı anahtar ve sudo testini tekrarlayın; eski oturumu ancak bunun ardından kapatın. sshd -t sözdizimini doğrular, gerçek girişin başarılı olacağını kanıtlamaz. Bu örnek SSH dinleme portunu değiştirmez; başka dağıtımlarda servis adı ve socket activation düzeni ayrıca kontrol edilmelidir.

3. Basit Bir Güvenlik Duvarı (UFW)

Önce UFW’yi kuralım:

sudo apt install ufw

UFW’yi açmadan önce gerçek SSH portuna izin verin; diğer mevcut hizmetlerin gereksinimlerini de kaydedin. Sağlayıcı güvenlik duvarı ile işletim sistemi kuralları birlikte etkili olur. IPv6 kullanıyorsanız onun kurallarını da doğrulayın. Çalışan oturumu açık tutup yeni bir bağlantıyla erişimi test edin:

# Bu örnek SSH için TCP 22 varsayar; gerçek portunuzu kullanın.
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

İleride başka servisler açmanız gerekirse yalnızca gerekli kaynak adreslerine erişim verin. Yalnızca sizin bağlanacağınız bir veritabanı için portu herkese açmak yerine SSH tüneli veya özel ağ kullanmayı değerlendirin; port izni tek başına kullanıcı kısıtlaması değildir.

Daha kapsamlı bir güvenlik stratejisi için, sadece SSH değil, web uygulaması ve veritabanı katmanını da kapsayan önerilerimizi görmek isterseniz, VPS sunucu güvenliği nasıl sağlanır rehberimizi incelemenizi öneririm.

Web Yığını Kurulumu: Nginx + PHP-FPM + MariaDB

Bu örnek Nginx, PHP-FPM ve MariaDB kullanır. Nginx seçimi tek başına Apache’den daha hızlı olacağı anlamına gelmez. Statik sitenin PHP veya veritabanına ihtiyacı yoktur; yalnızca uygulamanın gerektirdiği bileşenleri kurun.

1. Nginx Kurulumu

sudo apt install nginx
sudo systemctl enable --now nginx.service

Paket kurulumundan sonra servisin etkin ve çalışır olduğunu doğrulayın; imaj veya servis politikası otomatik başlamayı değiştirebilir:

sudo systemctl status nginx

HTTP isteği Nginx karşılama sayfasına ulaşıyorsa temel web erişimi çalışır. Bu, PHP, veritabanı veya uygulamanın çalıştığını henüz göstermez. Mevcut bir web sunucusu port 80’i kullanıyorsa çakışmayı çözmeden devam etmeyin.

2. PHP ve Gerekli Uzantılar

Ubuntu 24.04 depolarındaki PHP 8.3 paketlerini açık adlarıyla kurun. Uygulamanızın gerektirdiği ek uzantıları kendi belgelerinden doğrulayın:

sudo apt install php8.3-fpm php8.3-cli php8.3-mysql php8.3-xml php8.3-gd php8.3-curl php8.3-zip php8.3-mbstring php8.3-intl
sudo systemctl enable --now php8.3-fpm.service
sudo systemctl status php8.3-fpm.service

Bu sürümde FPM birimi php8.3-fpm.service, varsayılan havuz dosyası /etc/php/8.3/fpm/pool.d/www.conf şeklindedir. Dosyadaki listen değeri Nginx’teki soketle aynı olmalıdır:

sudo grep -E '^[[:space:]]*(user|group|listen)[[:space:]]*=' /etc/php/8.3/fpm/pool.d/www.conf
sudo php-fpm8.3 -t

Örnek, Ubuntu havuzunda uygulamanın www-data kullanıcı/grubuyla ve /run/php/php8.3-fpm.sock soketiyle çalıştığını varsayar. Özel havuzda kullanıcı, soket izinleri ve dosya erişimini birlikte uyarlayın; CLI PHP sürümünün web PHP ile aynı olduğunu ayrıca doğrulayın.

3. MariaDB Kurulumu

sudo apt install mariadb-server
sudo systemctl enable --now mariadb.service
sudo systemctl status mariadb.service

Ubuntu 24.04 depolarındaki MariaDB dalı 10.11’dir. Kurulu paketleri ve kimlik doğrulama yöntemini doğruladıktan sonra MariaDB’nin kurulum denetim aracını çalıştırabilirsiniz:

sudo mariadb-secure-installation

Eski mysql_secure_installation adı bazı paketlerde uyumluluk bağlantısıdır; burada MariaDB’nin güncel araç adı kullanılır. Sorulara mevcut yapılandırmayı dikkate alarak yanıt verin:

• Yerel root için unix_socket doğrulaması kullanılıyorsa sırf parola eklemek amacıyla bu yöntemi değiştirmeyin.
• Anonim hesapları, gereksiz uzak root hesaplarını ve test veritabanını denetleyin.
• Veritabanının yalnızca gereken yerel soket/loopback veya özel ağdan erişildiğini kontrol edin; kurulum aracı güvenlik duvarını sizin yerinize tasarlamaz.

4. Örnek Veritabanı ve Kullanıcı Oluşturma

Yeni uygulama için exampledb ve yalnızca bu veritabanına erişen example_user hesabını oluşturun. İlk komut sunucu kabuğunda, SQL satırları açılan MariaDB istemcisinde çalışır. Parola yer tutucusunu benzersiz rastgele bir sırla değiştirin ve SQL dizesi için gereken kaçışları uygulayın; örnek metni gerçek parola olarak kullanmayın:

sudo mariadb

CREATE DATABASE exampledb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'example_user'@'localhost' IDENTIFIED BY 'REPLACE_WITH_UNIQUE_RANDOM_PASSWORD';
GRANT ALL PRIVILEGES ON exampledb.* TO 'example_user'@'localhost';
EXIT;

Uygulama bağlantısını bu hesapla test edin; root hesabını uygulamada kullanmayın. CREATE USER/GRANT sonrasında ayrıca FLUSH PRIVILEGES gerekmez. Parolayı Git’e veya public dizinine koymayın; yapılandırma dosyası uygulama tarafından okunabilir, gereksiz kullanıcılar tarafından erişilemez olmalıdır. SQL istemci geçmişinin hassas veri tutma politikasını da kontrol edin.

Alan Adını VPS’e Yönlendirmek: DNS Ayarları

Kayıtları alan adının yetkili DNS hizmetinde düzenleyin; bu her zaman alan adı kayıt firmasının ekranı değildir. Yeni siteyi yerel hosts eşlemesi veya doğru Host başlığıyla test edin. Mevcut site taşınıyorsa DNS değişiminden önce dosya/veritabanı senkronizasyonu ve geri dönüş planı hazırlayın.

1. A Kaydı Oluşturma

Örneğin example.com için:

• Tür: A
• Ad: @ (veya boş bırakılır)
• Adres: 203.0.113.10 (VPS IP’niz)
• TTL: 300–3600 (5–60 dakika) arası tercih edilebilir

TTL’nin düşürülmesi eski önbellek kayıtlarını anında silmez; geçişten önce önceki TTL süresini hesaba katın. IPv6 yönlendirmesi, web dinlemesi ve güvenlik duvarı test edilmeden AAAA eklemeyin. www.example.com da aynı siteyi gösterecekse:

• Tür: CNAME
• Ad: www
• Hedef: example.com

DNS kayıt türleri ve sık yapılan hatalar hakkında daha derinlemesine bilgi isterseniz, DNS kayıtları A’dan Z’ye rehberimizi detaylıca inceleyebilirsiniz.

Yeni bir alan adı aldıysanız, SSL, e-posta ve SEO tarafında ilk 30 gün neleri kontrol etmeniz gerektiğini de DNS, SSL, e‑posta ve SEO kontrol listemizde adım adım anlattık.

Nginx Sanal Host (Server Block) ile Siteyi Yayına Alma

Yeni örnek site için public dizinini oluşturun. Bu komutlar deploy sahibini ve Nginx/PHP için www-data okuma grubunu varsayar. Setgid biti yeni alt dosya/dizinlerin grup mirasını kolaylaştırır; mevcut başka sitelerin ağacına toplu izin değişikliği uygulamayın:

sudo install -d -o deploy -g www-data -m 2750 /var/www/example.com /var/www/example.com/public

Basit bir test dosyası oluşturalım:

umask 027
printf '%s\n' '<h1>Merhaba Dunya</h1>' > /var/www/example.com/public/index.html

1. Nginx Server Block Dosyası

Yeni bir yapılandırma dosyası açın:

sudoedit /etc/nginx/sites-available/example.com.conf

Aşağıdaki PHP yapılandırması public dizinini web kökü yapar ve yalnızca mevcut PHP dosyalarını FPM’e iletir. Noktayla başlayan gizli yollar, Git bilgileri ve PHP yüklemeleri için erişim kuralları PHP eşleşmesinden önce yer alır. ACME doğrulama yolu ayrı tutulur. Uygulamanız farklı bir yükleme dizini kullanıyorsa onu da uygun biçimde sınırlandırın:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.php index.html;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    location ^~ /.well-known/acme-challenge/ {
        default_type text/plain;
        try_files $uri =404;
    }
    location ~ /\. {
        deny all;
    }
    # WordPress yüklemeleri: diğer uygulamalarda yolu uyarlayın.
    location ~* ^/wp-content/uploads/.*\.php(?:/|$) {
        deny all;
    }
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Yeni yapılandırmanın henüz etkin olmadığını ve aynı adı taşıyan bağlantı bulunmadığını kontrol edin. Sözdizimi testi başarısızsa yeniden yükleme yapılmamalıdır:

sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf
sudo nginx -t && sudo systemctl reload nginx.service

Doğru Host adıyla yapılan HTTP isteği test sayfasını göstermelidir. Önce yalnızca IPv4 dinlenir; AAAA yayımlayacaksanız IPv6 desteğini doğrulayıp uygun listen [::]:80; satırını ekleyin ve IPv6 üzerinden ayrıca test edin. PHP, gizli dosya engellemesi ve 404 davranışını ayrı ayrı kontrol edin.

Ücretsiz SSL ile HTTPS Etkinleştirme (Let’s Encrypt + certbot)

HTTPS, tarayıcı ile sunucu arasındaki trafiğin gizliliği ve sunucu kimliğinin doğrulanması için gereklidir. Sertifika kurulumu; DNS, HTTP doğrulaması, web sunucusu ve yenileme takibinin birlikte çalışmasını gerektirir.

1. Certbot Kurulumu

sudo apt install certbot python3-certbot-nginx

2. Sertifika Alma ve Otomatik Nginx Entegrasyonu

Nginx HTTP-01 doğrulaması için her iki alan adının yayımlanmış A/AAAA kayıtları çalışan sunucuya ulaşmalı ve dışarıdan port 80 erişilebilir olmalıdır. AAAA varsa bozuk IPv6 yolu sertifika alımını engelleyebilir. Nginx yapılandırmasının yedeğini alın ve testini geçirin; ardından açıkça HTTPS yönlendirmesi isteyin:

sudo certbot --nginx --redirect -d example.com -d www.example.com

İletişim ve kullanım koşulları sorularını yanıtladıktan sonra gerçek sonucu doğrulayın:

• Sertifika her iki alan adını kapsamalı, HTTPS port 443 üzerinden çalışmalıdır. Port 80 TLS sunmaz; HTTP doğrulaması ve yönlendirme için kullanılabilir.
• HTTP yönlendirmesini, uygulama URL’lerini ve karma içerik hatalarını kontrol edin.
• systemctl list-timers --all ile Certbot zamanlayıcısını veya ilgili cron görevini doğrulayın; sudo certbot renew --dry-run ile yenileme yolunu test edin. Paket kurulması, yenilemenin sürekli başarılı olacağını kanıtlamaz.

HTTP’den HTTPS’e geçişin SEO’ya etkileri, HSTS ve 301 yönlendirme stratejileri hakkında daha detaylı bilgi isterseniz, HTTP’den HTTPS’e geçiş rehberimizi mutlaka okuyun.

Deploy Senaryoları: Statik Site, PHP Uygulaması, WordPress

Artık altyapı hazır. Sırada projenizi sunucuya taşıyıp canlıya almak var. Burada üç tipik senaryoyu ele alalım.

1. Statik HTML/CSS/JS Site

Statik sitede yalnızca yayımlanacak derleme çıktısını public dizinine aktarın; kaynak depo, sırlar ve özel yapılandırma dosyaları bu dizine girmemelidir. Örnekte rsync iki uçta da kurulu olmalıdır:

rsync -av --no-owner --no-group --chmod=D2750,F640 --dry-run ./build/ deploy@203.0.113.10:/var/www/example.com/public/
# Önizlemeyi kontrol ettikten sonra aynı komutu --dry-run olmadan çalıştırın.

Kaynak sondaki / sayesinde build dizininin içeriği kopyalanır. scp -r ./build/ .../public ek bir build alt dizini oluşturabilir. Git ile derleme yapıyorsanız depoyu public dışında tutup yalnızca çıktıyı yayımlayın.

Statik sitede PHP location bloğunu kaldırın, index index.html; kullanın ve ana location için try_files $uri $uri/ =404; ayarlayın. Yalnızca index satırını değiştirmek PHP yönlendirmesini kaldırmaz. Eksik dosyaları olmayan index.php’ye göndermeyin.

2. Basit PHP Uygulaması (Framework’süz veya Küçük Bir MVC)

PHP projesinin tamamını public içine koymayın. Projenin public kökü, bağımlılıkları, yapılandırması ve yazılabilir dizinleri kendi yerleşimine göre ayrılmalıdır. Sırlar ve kullanıcı yüklemeleri yerel kod aktarımından ayrı yönetilmelidir. Aktarım önizlemesi:

rsync -av --no-owner --no-group --dry-run --exclude=.git --exclude=.env ./project-root/ deploy@203.0.113.10:/var/www/example.com/
# Hedef yolları, hariç tutulan dosyaları ve izinleri doğruladıktan sonra --dry-run kaldırılır.

Sondaki / dizin içeriğini taşır; kabukta * kullanmak gizli dosyaları atlayabilir. Gerekli bağımlılıkları, uygulama sırlarını ve exampledb/example_user bağlantısını ayrı hazırlayın. Kullanıcı verilerini koruyun; dosya aktarımı tek başına veritabanı geçişi, cron veya worker dağıtımı değildir.

3. WordPress Kurulumu

WordPress için bu örnek yeni bir kurulum varsayar. Mevcut sitenin üzerine dosya kopyalamadan önce yedek ve geçiş planı gerekir. PHP/veritabanı gereksinimlerini resmi WordPress belgeleriyle karşılaştırın.

1. WordPress’i indirin:

# Sunucuda deploy hesabıyla; yeni kurulum dizini için.
wp_stage=$(mktemp -d)
curl -fL https://wordpress.org/latest.tar.gz -o "$wp_stage/wordpress.tar.gz"
tar -xzf "$wp_stage/wordpress.tar.gz" -C "$wp_stage"
rsync -av --no-owner --no-group --chmod=D2750,F640 "$wp_stage/wordpress/" /var/www/example.com/public/

2. Dosya izinlerini ayarlayın:

sudo chown -R deploy:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 2750 {} +
sudo find /var/www/example.com -type f -exec chmod 640 {} +
sudo install -d -o deploy -g www-data -m 2770 /var/www/example.com/public/wp-content/uploads

3. Kurulum ve kabul testi: HTTPS üzerinden sihirbazı açın; uygulama veritabanını, benzersiz yönetici hesabını ve site URL’sini yapılandırın. PHP www-data olarak çalışırken kod ağacı salt okunurdur; WordPress wp-config.php dosyasını yazamazsa önerilen yapılandırmayı deploy hesabıyla güvenli biçimde oluşturun.
4. Yazma ve güncellemeler: Örnekte yalnızca uploads yazılabilir. Gereken cache dizinlerini ayrıca ve dar kapsamda açın. Çekirdek/eklenti/tema güncellemelerini deploy sürecinden yönetin; panel içinden otomatik dosya güncellemesinin bu izinlerle çalışacağını varsaymayın.
5. Doğrulama: Görsel yükleme, kalıcı bağlantılar, SMTP/e-posta ve zamanlanmış görevleri test edin. PHP çalıştırılması uploads altında engellenmelidir; dosya izinleri tek başına bu engeli sağlamaz.

WordPress’i VPS üzerinde performanslı ve güvenli şekilde koşturmak için sunucu tarafında yapılabilecek ileri seviye ayarları merak ediyorsanız, WordPress için sunucu tarafı optimizasyon rehberimizi mutlaka okuyun.

Panel Kullanmadığınızda Bakım, Yedek ve İzleme Nasıl Olmalı?

Hazır yedekleme veya grafik ekranları bulunmuyorsa bunları ayrıca kurup sürdürmeniz gerekir. SSH üzerinden betik ve izleme araçlarını ihtiyacınıza göre düzenleyebilirsiniz; hata bildirimi, yetkilendirme ve bakım sorumluluğu da bu kurulumun parçasıdır.

1. Log’ları İzlemek ve Hata Ayıklamak

• Nginx erişim logları: /var/log/nginx/example.com.access.log
• Nginx hata logları: /var/log/nginx/example.com.error.log
• PHP-FPM logları: Genelde /var/log/php8.3-fpm.log veya journalctl -u php8.3-fpm
• Sistem logları: journalctl -xe

Bu loglar sayesinde 404 hataları, yavaş istekler veya konfigürasyon problemlerini hızlıca yakalayabilirsiniz.

2. Otomatik Yedekleme (Cron ile)

Dosyalar, veritabanı ve hizmet yapılandırmaları için zamanlanmış yedekler hazırlayın. MariaDB’de mariadb-dump kullanın; --single-transaction InnoDB verisi için tutarlılık sağlar, eşzamanlı DDL veya dosyaların aynı ana ait olması sorununu çözmez. Uygulama yazmalarını durdurma veya uygulamaya uygun yedekleme planı gerekebilir. Cron görevinde doğru hesap, PATH, sır yönetimi, çakışma kilidi, hata bildirimi ve saklama süresini belirleyin; uzak kopya ve izole geri yükleme testi yapın. Cron ile yedek ve bakım işleri rehberi bu planın zamanlanmasına yardımcı olur.

3. İzleme ve Alarm Kurmak

VPS’in CPU, RAM, disk ve yanıt süresini Prometheus + Grafana veya daha hafif araçlarla izleyebilirsiniz. Araç seçimini sunucu sayısı, saklama süresi ve alarm ihtiyacıyla eşleştirin. VPS izleme ve alarm kurulumu rehberi temel kurulumun planlanmasına yardımcı olur; alarmın gerçekten ulaştığını ve ölçümlerin doğru sunucuyu izlediğini test edin.

4. Güvenlik Kontrol Listesini Unutmayın

SSH politikası, güvenlik duvarı, güncellemeler, dosya izinleri ve uygulama kontrollerini birlikte değerlendirin. Fail2ban kuruluyorsa günlük kaynağı, aktif jail ve gerçek engelleme davranışını doğrulayın; paket kurulumu tek başına koruma kanıtı değildir. VPS güvenliği için doğrulanabilir yaklaşımlar rehberini kontrol listesine ekleyebilirsiniz.

Paylaşımlı Hosting’den VPS’e Geçenler İçin Notlar

Paylaşımlı hosting ortamından VPS’e geçerken yönetim kapsamı değişir. İşletim sistemi ve uygulama ayarlarını daha doğrudan düzenleyebilirsiniz; sağlayıcının yönettiği bileşenleri, kendi bakım sorumluluklarınızı ve kurtarma erişimini hizmet kapsamından doğrulayın.

Paylaşımlı hosting’den VPS’e geçiş kontrol listesi; dosya, veritabanı, e-posta ve DNS geçişini birlikte ele alır. TTL’yi düşürmek tek başına kesintisiz geçiş sağlamaz. Test edilen yeni ortam, son veri senkronizasyonu, yazma trafiğinin yönetimi ve geri dönüş planı gerekir.

Sonuç: SSH ile VPS Kurulumu ve Sürekli Bakım

Kontrol paneli olmadan web sitesi yayımlamak mümkündür. Bu rehberin temel kontrol listesi şöyledir:

• Anahtar ve sudo erişimini yeni oturumda doğruladıktan sonra etkin SSH politikasını kontrol etmek.
• Ubuntu 24.04/PHP 8.3/MariaDB 10.11 örneğini uygulamanın gereksinimlerine göre uyarlamak.
• Nginx, dosya izinleri, DNS, HTTPS ve sertifika yenilemesini ayrı ayrı test etmek.
• Statik/PHP/WordPress dağıtımını kullanıcı verilerinden ve sırlardan ayırmak.
• Yedeklerin geri yüklenmesini, e-posta/cron işlerini, günlükleri ve alarmları düzenli doğrulamak.

SSH ile yönetim, Linux ve uygulama bakımını öğrenmeyi gerektirir. Komutları tekrar etmek kadar hangi hesabın, dosyanın ve hizmetin etkilendiğini kaydetmek de önemlidir. Kontrol paneli kullanmak veya kullanmamak tek başına daha güvenli ya da daha hızlı bir sistem oluşturmaz.

DCHost VPS veya dedicated sunucu seçeneklerini karşılaştırırken işletim sistemi desteği, yedek/konsol imkânı, kaynak sınırları ve yönetim sorumluluğunu netleştirin. Önce test projesinde kurulum ve geri yükleme pratiği yapın; üretim kapasitesini ölçülen ihtiyaca göre belirleyin.

Çalışan yapılandırmaları, sürümleri ve kabul testlerini belgeleyin. Yeni projelerde bu kayıtları başlangıç olarak kullanın; farklı dağıtım, uygulama veya trafik için aynı komutların otomatik olarak uygun olacağını varsaymayın.