Tek Süreçin Ötesinde: Bulut İçin Laravel Konteynerlerinin Mimarisi

Laravel Uygulama Mimarisi: Bulut İçin Konteynerlerle Yapılandırma

Bu rehber, Laravel uygulama ortamını bulutta yapılandırmanın teknik incelemesini sunar. Modern PHP uygulaması çalıştırmak için gerekli temel yapı taşlarına odaklanmaktadır. Gerçek zamanlı özellikler ve arka plan işleyicileri içeren bir yapıda, AWS, GCP veya özel bir VPS’ye dağıtımda bu mimari desenleri kullanabilirsiniz.

Docker ve Linux terminal komutları hakkında temel bir bilgi sahibi olmanız gerektiği varsayılmaktadır. Bu araçlara yeni olanlar için her yapılandırmanın arkasındaki mantığı açıklamakta, böylece spesifik komutlar hakkında daha fazla bilgi aramanız daha kolay olacaktır.

İçindekiler

Bulut bağımsız VM temel yapılandırması

• Sistem güncellemesi ve saat dilimi senkronizasyonu
• Docker motoru kurulumu ve yapılandırması
• UFW ve SSH ile güvenlik güçlendirmesi
• Sürekli depolama ve günlük döngüsü ayarı
• VM önyükleme betiği

Konteyner mimarisi

• Tek konteynerli çoklu işlem mantığı
• Supervisord ile orkestrasyon

Docker imajı tasarımı

• Çok aşamalı derlemeler ile bağımlılık izolasyonu
• Uygulama çalışma zamanı imajı (PHP-FPM, Nginx, Supervisor)
• Alpine Linux için optimizasyon

Nginx yapılandırması

• TCP döngü geri bağlantısı aracılığıyla PHP-FPM entegrasyonu
• Statik varlık yönetimi ve güvenlik başlıkları
• WebSocket proxying for Laravel Reverb

Supervisord ile süreç yönetimi

• Servis orkestrasyonu ve başlatma öncelikleri
• PHP-FPM ve Nginx yönetimi
• Arka plan kuyruk işleyicilerinin ölçeklenmesi
• Reverb sunucusunu çalıştırma

Çalışma zamanı başlatma

• Başlatma sırasında hacim izinlerinin çözümü
• Otomatik göçler ve şema senkronizasyonu
• Üretim önbelleklemesi ve optimizasyonu
• Giriş noktası betiği yürütülmesi

Konteynerin inşa edilmesi ve çalıştırılması

• İmaj oluşturma ve katman önbelleklemesi
• Çevre dosyaları ve hacimlerle başlatma
• Dağıtım stratejileri: Tek konteyner vs. Docker Compose

Üretime geçiş

• Ölçek ve güvenlik için kritik mimari geçişler

Bulut bağımsız VM yapılandırma betiği

Temel sanal makine basit bir şekilde tutulmaktadır. Amaç, bulut sağlayıcısından bağımsız olarak Docker’ı güvenilir bir şekilde çalıştırabilecek minimal bir host hazırlamaktır.

Farklı Linux dağıtımları farklı varsayılan paketler ile gelir. Aşağıdaki komutlar, AWS ve GCP’de yaygın olarak kullanılan Ubuntu için varsayılarak hazırlanmıştır. Eğer başka bir dağıtım kullanıyorsanız, paket yöneticisini ve servis adlarını buna göre ayarlayın.

Her şeyi basit tutmak için VM’yi önyükleme işlemini gerçekleştiren tek bir bash betiği kullanıyoruz. Bu betik aşağıdaki işlemleri gerçekleştirir:

• Sistem güncellemeleri ve saat dilimi yapılandırması
• Docker kurulumu ve yapılandırması
• UFW ile güvenlik ayarları
• SSH güçlendirmesi
• Sürekli veri ve günlükler için Docker hacimleri oluşturma

VM oluşturulmadan önce bir SSH anahtarı üretin ve örnek oluşturma sırasında iliştirmeyi unutmayın:

ssh-keygen -t ed25519 -C "username"

Yukarıdaki komuttaki yorum ( -C bayrağı) isteğe bağlıdır, ancak kullanıcı adını kullanmak bazı sağlayıcıların (örneğin GCP) otomatik olarak eşleşen bir sistem kullanıcısı oluşturmasını sağlar. Docker komutlarının sudo olmadan çalıştırılabilmesi için bir sonraki bash betiğinde USERNAME değişkenini güncellediğinizden emin olun:

#!/bin/bash

# Sistem güncellemeleri ve saat dilimi ayarı
sudo apt-get update -y
sudo timedatectl set-timezone UTC

# Docker resmi GPG anahtarını ekleyin:
sudo apt-get install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Apt kaynaklarına depo ekleyin:
sudo tee /etc/apt/sources.list.d/docker.sources  /dev/null  /dev/null 2>&1; then
    useradd -m -s /bin/bash "$USERNAME"
fi

# Docker grubunun mevcut olduğundan emin olun
if ! getent group docker > /dev/null; then
    groupadd docker
fi

# Kullanıcıyı docker grubuna ekle
sudo usermod -aG docker "$USERNAME"

# Güvenlik duvarı kurulum (yönetilen bulut güvenlik duvarları üzerindeyken isteğe bağlı)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw --force enable

# SSH güçlendirmesi
sudo apt-get install -y openssh-server
SSHD_CONFIG="/etc/ssh/sshd_config"
sudo cp "$SSHD_CONFIG" "${SSHD_CONFIG}.bak.$(date +%F-%T)"
sudo sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' "$SSHD_CONFIG"
sudo sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' "$SSHD_CONFIG"
sudo sed -i 's/^#PubkeyAuthentication.*/PubkeyAuthentication yes/' "$SSHD_CONFIG"
sudo systemctl restart ssh

# Sürekli veri için Docker hacimleri
sudo docker volume create laravel-storage
sudo docker volume create laravel-supervisord

Root ssh erişimi devre dışı bırakılmıştır, bu da tüm yetkili eylemlerin bireysel kullanıcılara bağlanmasını ve sistem günlüklerine kaydedilmesini sağlar. Bu, hesap verebilirliği artırır ve denetimi kolaylaştırır. Günlükler daha sonra VM’e gönderilebilir ve değişmezlik sağlanabilir.

Bu noktada, VM güvenli hale geldi, Docker yüklendi ve sürekli depolama kuruldu. Şimdi Laravel uygulamasının konteynerleştirilmesine odaklanabiliriz.

Docker Kurulumu

Tipik bir Docker konteyneri, tek bir uzun ömürlü süreci çalıştırmak için tasarlanmıştır ve systemctl içermez. Ancak bu kurulum, Laravel uygulamasının birden fazla işlevsel sürece ihtiyaç duymasından kaynaklanmaktadır:

• Nginx, HTTP trafiğini ve statik varlıkları sunmak için
• PHP-FPM, Laravel uygulamasını çalıştırmak için
• Arka planda görevleri işlemek için kuyruk işleyicileri
• Reverb, websocket bağlantıları için

Bu süreçleri bir konteyner içinde yönetmek için Supervisord kullanılır; bu, her hizmeti başlatan, yeniden başlatan ve denetleyen hafif bir süreç yöneticisidir.

Bu yaklaşım, yalnızca tek bir konteyner çalıştırma sınırlamanız olduğunda ve basitliği sıkı konteyner dağıtımına göre optimize ettiğinizde iyi çalışır.

Bağlam ve Tasarım Seçenekleri

Bu rehberde, kurulumu basit ve kendi kendine yeterli tutmak amacıyla SQLite kullanıyoruz. Amaç, konteyner yapısına ve süreç yönetimine odaklanmak; veritabanı sağlama üzerine değil. Aynı yaklaşım MySQL veya PostgreSQL için ek hizmet yapılandırmaları ile uygulanır.

Uygulama, aşağıdaki kalıcı veri ile birlikte Docker adlandırılmış hacimlerine güvenmektedir:

• SQLite veritabanı dosyası
• Laravel depolama ve önbellek dizinleri
• Supervisor günlükleri

Docker adlandırılmış hacimleri Docker motoru tarafından oluşturulup yönetilir. Yapı aşamasında, bu hacimler mevcut değildir ve çalışma zamanı sırasında bağlandıklarında, varsayılan olarak root sahibi olur. Sonuç olarak, dosya izinleri imaj oluşturmada sonlandırılamaz.

Bu nedenle, izin değişiklikleri kasıtlı olarak konteyner başlatma zamanına ertelenmiştir. İmaj, sürekli yolların sahipliğini varsaymadan inşa edilir ve izinler, hacimler bağlandığında çalışma zamanında uygulanır.

#Dockerfile

FROM composer:2.7 AS vendor

# Uygulama kaynak dizini konteyner içinde
WORKDIR /app/api

# Sadece bağımlılık dosyalarını kopyalayarak Docker katman önbelleklemesini kullanın
COPY ./api/composer.json ./api/composer.lock ./api/artisan ./

# PHP bağımlılıklarını yükle
RUN composer install \
    --optimize-autoloader \
    --prefer-dist \
    --no-interaction \
    --no-scripts

# Uygulamanın geri kalan kaynağını kopyala
COPY ./api ./

# SQLite veritabanı dosyasını oluştur (izinler çalışma zamanında işlenecektir)
RUN touch database/database.sqlite

Çok aşamalı bir yapı olmadan, Composer son imajda yer alır. Uygulama kaynaklarındaki herhangi bir değişiklik, Docker önbelleğini geçersiz kılacak ve composer install işlemini tekrar çalıştıracaktır. Bağımlılık yüklemesi en yavaş adım olduğundan, küçük kod değişiklikleri bile yerel inşaları ve CI boru hatlarını önemli ölçüde yavaşlatır.

Ayrı bir yapı aşaması kullanarak, kod değişiklikleri hızlıca uygulanır, inşalar öngörülebilir kalır ve son imaj Composer veya diğer yapı araçlarını içermez.

Çalışma Zamanı İmajı

Son çalışma zamanı imajı, çoklu hizmetleri çalıştırma işlevsel gereksinimi ile verimliliği dengelemelidir. Standart PHP-FPM imajları inceyken, web trafiğini sunma veya arka plan işleyicilerini yönetme gibi gerekli bileşenleri içermez. Alpine Linux temeli, son ayak izini azaltırken, Nginx ve supervisord eklemek, konteynerin istekleri ve kuyrukları aynı anda işleyebilen kendi kendine yeterli birim olarak çalışmasını sağlar.

#Dockerfile

# Minimal üretim ayak izi için Alpine kullanın
FROM php:8.4-fpm-alpine AS backend
WORKDIR /var/www/html/laravel

# Çoklu işlem mimarisi için gerekli sistem ikizlerini yükle
RUN apk add --no-cache \
    nginx \
    supervisor \
    libzip-dev \
    zip \
    unzip \
    mariadb-dev \
    linux-headers

# Laravel'in kuyruk ve dosya yönetimi için gereken temel PHP uzantıları
RUN docker-php-ext-install zip bcmath pcntl

# Son görüntüde yapı araçlarını temiz tutmak için önceden oluşturulmuş vendor dizinini alın
COPY --from=vendor /app/api .
    
# Varsayılan ayarları geçersiz kılmak için Nginx yapılandırmasını ekleyin
COPY path-to-nginx-config /etc/nginx/http.d/default.conf

Bu çok aşamalı geçiş, son imajın yalnızca yürütme için gerekli iktidarları ve uygulama kodunu içermesini sağlar. Composer’ı ve geçici yapı dosyalarını hariç tutarak, imaj boyutunu küçük tutmakla kalmaz, aynı zamanda dağıtım sürelerini ve konteynerin genel saldırı yüzeyini de azaltır.

pcntl ve Laravel’in ihtiyaçlarına özgü bir uzantıdır. Bu, kuyruk işleyicilerinin ana sistemden “durdur” veya “yeniden başlat” sinyallerini dinlemesine olanak tanır; böylece arka plan görevleri zarif bir şekilde kapanır. Bu mimari seçimi, standart bir PHP konteynerini güçlü bir uygulama sunucusuna dönüştürür ve dış süreç yöneticilerini gerektirmeden kendi yaşam döngüsünü yönetmesine olanak tanır.

Nginx Yapılandırması

Nginx, konteynere gelen trafiğin ana giriş noktasıdır. Statik varlıklar, dinamik PHP istekleri ve kalıcı WebSocket bağlantıları arasında etkili bir şekilde ayrım yapar. Resim, CSS ve JavaScript’i dosya sistemi üzerinden doğrudan sunarak, Nginx PHP motorunun yükünü azaltır. Dinamik içerikler için, HTTP isteklerini PHP-FPM’in işleyebileceği bir formata dönüştüren bir ters proxy olarak işlev görür.

PHP işlemlerinin yapılandırması, yalnızca geçerli dosyaların yürütülmesini sağlamalı ve Laravel’in yönlendiricisine doğru yol bilgisini geçirmelidir. HızlıCGI geçidi için TCP bağlantısı, konteynerin ağ yığınındaki web sunucusu ve PHP işlemcisi arasında kararlı bir iletişim kanalı sağlar.

#Nginx yapılandırması

server {
    server_name api.example.com;
    listen 80;

    # Laravel yayın dizinine giriş noktası
    root /var/www/html/laravel/public;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";
    index index.php;

    charset utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        # Geçersiz dosyaların işlenmesini engellemek için güvenlik önlemi
        try_files $uri =404;

        # Betik adlarını ve yol bilgisini yakalamak için desen belirle
        fastcgi_split_path_info ^(.+\.php)(/.+)$;

        # Standart PHP-FPM portu üzerinde TCP loopback ile iletişim
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi_params;

        # PHP yorumlayıcısı için mutlak dosya yolu ve yol bilgisini harita
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    # Gizli sistem dosyalarına erişimi engelle
    location ~ /\.(?!well-known).* {
        deny all;
    }

    # Laravel Reverb için WebSocket yükseltmelerini işlemek
    location /app/ {
        proxy_http_version 1.1;
        proxy_set_header Host $http_host;
        proxy_set_header Scheme $scheme;
        proxy_set_header SERVER_PORT $server_port;
        proxy_set_header REMOTE_ADDR $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # Sürekli protokoller için bağlantı yükseltme işlemini etkinleştirin
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # 8080 portunda çalışan Reverb sunucusuna trafiği yönlendirin
        proxy_pass http://0.0.0.0:8080;
    }
}

try_files direktifi bir güvenlik kapısı olarak işlev görür; istenen .php dosyası yoksa isteği derhal durdurur. Bu, sunucunun geçersiz verileri PHP motoruna geçmesini engeller. fastcgi_split_path_info ve PATH_INFO parametrelerinin dahil edilmesi, karmaşık URI yönlendirmesine güvenen uygulamalar için gereklidir; bu nedenle Laravel’in yol bilgilerini çözmesini sağlar.

/app/ bloğu Reverb için özel olarak yapılandırılmıştır. Gerekli Upgrade ve Connection başlıklarını arka plana geçirerek, HTTP isteğinin WebSocket akışına geçişini sağlar. Bu, standart web trafiği için kullanılan aynı portun, gerçek zamanlı, iki yönlü iletişimi de mümkün kılmasını sağlar.

Supervisord ile Süreç Yönetimi

#Dockerfile

COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf

Bir konteynerin yaşam döngüsü, onun ana ön planda çalışan sürecine bağlıdır. Birden fazla hizmetin gerekli olduğu bir ortamda, bağımsız bileşenlerin başlatma ve sağlık durumunu denetlemek için bir süreç yöneticisine ihtiyaç vardır. Supervisord, Nginx, PHP-FPM ve Laravel’e özgü işçilerin çalıştırılmasını izleyen ana giriş noktasıdır. Bu, bir hizmetin başarısız olması durumunda, tüm konteynerin çıkış yapmadan otomatik olarak yeniden başlatılmasını sağlar.

[supervisord]
nodaemon=true
logfile=/var/log/supervisord/supervisord.log
logfile_maxbytes=50MB  
loglevel=info

[program:php-fpm]
command=php-fpm -F
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/supervisord/php-fpm.log
stdout_logfile_maxbytes=20MB
stopwaitsecs=60
priority=5
user=root

[program:laravel-service-app-queues]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/laravel-service-app/api/artisan queue:work
autostart=true
autorestart=true
numprocs=4
redirect_stderr=true
stdout_logfile=/var/www/html/laravel-service-app/api/storage/logs/queue.log
groupstop=true
groupkill=true
stopwaitsecs=60
user=www-data
priority=7
stdout_logfile_maxbytes=20MB

[program:nginx]
command=nginx -g "daemon off;"
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/supervisord/nginx.log
stdout_logfile_maxbytes=20mb
stopwaitsecs=60
user=root
priority=6

[program:reverb]
command=php /var/www/html/laravel/artisan reverb:start
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/supervisord/reverb.log
stdout_logfile_maxbytes=20mb
stopwaitsecs=60
user=www-data
priority=6

Yapılandırma, nodaemon=true belirterek konteyneri aktif tutmak için kullanılır. Farklı priority değerleri atayarak sistem, başlatma sırasını kontrol eder; böylece PHP motoru, Nginx’in trafik dinlemeye başlamasından önce istekleri kabul edebilir. Bu, konteynerin hem web arayüzünü hem de kuyruklar ve gerçek zamanlı WebSocket’ler gibi gerekli altyapının yönetilmesini sağlayan tamamen işlevsel bir uygulama sunucusu olarak çalışmasını sağlar.

numprocs ayarı, ortamın içsel olarak nasıl ölçeklenebileceğini göstermektedir. Bu sayıyı artırmak, konteynerin aynı anda birden fazla arka plan görevini işleyebilmesini sağlar; bu, yüksek hacimli uygulamalar için gereklidir, çünkü mail gönderimi veya görüntü işleme esas isteklere engel olmamalıdır.

Çalışma Zamanı Başlatma

# Dockerfile

COPY run.sh /var/www/html/laravel/run.sh

# Portları aç
EXPOSE 80

# Servisleri supervisor kullanarak başlat
CMD ["/bin/sh", "/var/www/html/laravel/run.sh"]

Statik bir Docker imajından çalışan bir konteynere geçiş, çevresel özel ayarların yönetilmesi gereken bir köprü gerektirir. Çünkü veri ve veritabanları için Docker hacimleri genellikle çalışma zamanı sırasında bağlanır, bu nedenle içeriğe yapım aşamasında erişilemez. Bu, dosya izinlerinin ana makinenin root kullanıcısına sıfırlanması ve uygulama durumunun optimize edilmemesi için bir boşluk ortaya çıkarır. Bir başlatma betiği, ortam hazır, güvenli ve çalışabilir hale getirilmeden önce süreçlerin başlamasını sağlamak için konteynerin giriş noktası olarak işlev görür.

#!/bin/sh
set -e

# Uygulama dizinine geç
cd /var/www/html/laravel

# Eşleşen hacimler için çalışma zamanı izin düzeltmesi
chown -R www-data:www-data database storage bootstrap/cache
chmod -R 775 storage bootstrap/cache
chmod 664 database/database.sqlite

# Kamuya açık dosya erişimi için sembolik bağlantıyı oluştur
php artisan storage:link || true

# Veritabanı şemasının güncel kod sürümü ile senkronize edilmesi
php artisan migrate --force

# Önbellekleri (yapılandırma, rotalar, olaylar) yeniden inşa et
php artisan optimize:clear
php artisan optimize

# Uzun ömürlü süreç olarak Supervisord'a yürütmeyi devredin
exec supervisord -n -c /etc/supervisor/conf.d/supervisord.conf

Betik, Docker’ın hacim montajlama sisteminin neden olduğu sahiplik çatışmalarını çözmek için chown ve chmod kullanır. Çünkü konteyner içindeki www-data kullanıcısının SQLite veritabanına ve günlük dosyalarına yazabilmesi gerekir; bu izinler imajın kendisine eklenemez; sürekli depolama bağlandığı anda uygulanmalıdır.

php artisan migrate --force çalıştırmak, veritabanı şemasının her zaman uygulama kodu ile güncel olmasını sağlar. --force bayrağı, üretim ortamında gerekli olup, aksi halde etkileşimli onay istemi bulunan durumu geçersiz kılar; bu da konteynerin başlatma sürecini durdurur. Göç işleminin ardından, optimize komutları, çeşitli yapılandırmalara, rota ve görünüm dosyalarına önbellekleyerek, her HTTP isteği için gereken dosya okuma sayısını azaltır; bu da yüksek trafikli bulut ortamlarındaki yanıt sürelerini önemli ölçüde iyileştirir.

Son satır, exec kullanarak shell sürecini Supervisord ile değiştirir. Bu, supervisord’un konteyner içindeki PID 1 olmasını sağlar; böylece Docker motorundan doğrudan kapatma sinyalleri alır.

Konteynerin İ inşası ve çalıştırılması

Docker ile uygulanmış bir uygulamanın yaşam döngüsü iki ayrık aşamaya bölünmüştür: İnşa aşaması, değişmez bir plan(Instagram içirir); ve Çalıştırma aşaması, bu planlamanın aktüel bir ortama dönüştürülmesidir. Bunları ayırarak, bağımlılık yükleme ve sistem yapılandırmasının ağır yükü yalnızca bir kez gerçekleştirilmekte, uygulama çok sayıda sunucuya anında dağıtılabilmektedir.

1. İmajı İnşa Etme

İnşa süreci, Dockerfile’daki her talimatı yerine getirerek uygulamanın etiketlenmiş bir versiyonunu oluşturur. Kullanmak için –tag (veya -t) bayrağı, sürümlendirme sağlar; bu da geri dönüşler için kritik öneme sahiptir.

# Mevcut dizinden görüntüyü oluştur
docker build --t laravel-app .

Başlangıçtaki inşa süreci birkaç dakika alabilir çünkü Alpine temelini indirip PHP uzantılarını yükler. Ancak, Docker’ın katman önbelleklemesi, sonraki inşaların nerdeyse anında oluşmasını sağlar; yalnızca composer.json veya sistem düzeyindeki gereklilikler değiştirilmediğinde. Bu hız, yanıt vermesi gereken CI/CD boru hatları için hayati öneme sahiptir.

2. Konteyneri Başlatma

İmaj hazır olduğunda, Docker run komutu ile başlatılır. Bu aşama, statik imajı dış dünyaya bağlayarak portların haritalanması, çevresel dosyalar aracılığıyla gizli bilgilerin enjekte edilmesi ve sürekli depolama hacimlerinin eklenmesi gibi işlemleri içerir.

# Çevre değişkenleri ve sürekli hacimlerle konteyneri başlat
docker run --name laravel-app -p 80:80 \
  --env-file .env \
  -v laravel-storage:/var/www/html/laravel/storage \
  -v laravel-sqlite3:/var/www/html/laravel/database \
  -v laravel-supervisord:/var/log/supervisord \
  laravel-app:latest

-v (hacim) bayrakları, veri kalıcılığı için gereklidir. Bunlar olmadan, SQLite veritabanına veya depolama dizinine yazılan veriler, konteyner durdurulduğunda kaybolur. Adlandırılmış hacimleri bağlayarak, veriler, konteynerin yaşam döngüsünden bağımsız olarak ana makinede yaşamaya devam eder.

Dağıtım Yolunu Seçme

Bu yapı, basitlik ve kaynak verimliliği öncelikli olduğu küçük-orta bulut dağıtımları için güçlü bir temel sağlar. Web sunucusu, PHP motoru ve arka plan işleyicilerini tek bir konteynerde toplamak, birden çok ağ köprüsünün ve hizmet bağımlılıklarının yönetim yükünü azaltır.

Tek Konteynerli Yapı (Mevcut)

Uygun olduğuna dair: MVP’ler, Paylaşımlı Hosting, Basit VPS
Ölçekleme: Dikey (Büyük VM)
Karmaşıklık: Düşük, Yönetilecek Tek Dockerfile
Devamlılık: Yerel Adlandırılmış Hacimler

Çoklu Konteyner (Mikro-Hizmetler)

Uygun olduğuna dair: Yüksek Trafik Uygulamaları, Büyük Ekipler
Ölçekleme: Yatay (İşçileri bağımsız olarak ölçeklendirin)
Karmaşıklık: Yüksek, Orkestrasyon Gerektirir (Kubernetes/Swarm)
Devamlılık: Yönetilen Bulut Depolama (S3, RDS)

Üretime Geçiş

Bu rehber, temel yapı taşlarına odaklanmış olsa da, “üretim sertleştirilmiş” duruma geçmek, birkaç kritik geçiş içermektedir:

Docker Compose ile Orkestrasyon: Manuel komutlardan Docker Compose’a geçiş, tüm yığınların; ağ, hacim ve çevresel değişkenin tek bir docker-compose.yml dosyasında tanımlanmasını sağlar. Bu, altyapının sürüm kontrol altında tutulmasını ve tek bir komutla başlatılmasını garanti eder.
Veritabanını Dışsallaştırma: Yüksek kullanılabilirlik için SQLite’dan uzaklaşarak, AWS RDS veya GCP Cloud SQL gibi yönetilen hizmetlerde taşın.
Gizli Bilgi Yönetimi: Yerel .env dosyaları yerine, bulut tabanlı gizli yöneticileri kullanarak, kimlik bilgilerini çalışma zamanında enjekte et.
SSL/TLS: Mevcut yapı 80 numaralı portu kullanmaktadır. Üretimde, Nginx’in 443 numaralı porta SSL sertifikaları ile yapılandırılması veya SSL sonlandırmasını sağlamak için bir Bulut Yük Dengeleyici arkasında yer alması gerekir.