WordPress, Docker Compose ve HTTPS ile nasıl kurulur

WordPress; bloglar, kurumsal siteler ve mağazalar için açık kaynaklı bir içerik yönetim sistemidir. WordPress'i Docker'da çalıştırmak PHP'yi, Apache'yi ve veritabanını sürümlenmiş imajlarda tutar, kurulumu başka bir sunucuda tekrarlanabilir kılar ve birbirinden yalıtılmış birkaç siteyi yan yana çalıştırmanıza izin verir.

Bu rehber Docker Hub'daki resmi wordpress ve mariadb imajlarını Docker Compose ile kullanır. Gizli değerler bir .env dosyasında, veriler adlandırılmış volume'larda durur ve WordPress yalnızca 127.0.0.1 üzerinde, HTTPS sağlayan Caddy'nin arkasında yayınlanır. Ayrıca PHP yükleme sınırlarını artırır, WP-CLI'ı resmi cli imajından çalıştırır, yedekleme, geri yükleme ve güncellemeyi ayarlarsınız. Konteyner olmadan klasik bir kurulumu tercih ederseniz Nginx, PHP-FPM ve MariaDB üzerinde WordPress rehberine bakın.

Adım 1 — Proje klasörünü ve gizli değerleri oluşturun

Siteyi yönetici kullanıcınıza ait /opt/wordpress klasöründe tutun:

sudo mkdir -p /opt/wordpress
sudo chown $USER:$USER /opt/wordpress
cd /opt/wordpress

Veritabanı ayarlarını ve iki rastgele parolayı .env dosyasına yazın. Docker Compose bu dosyayı kendiliğinden okur:

cat > .env <<EOF
WORDPRESS_DB_NAME=wordpress
WORDPRESS_DB_USER=wordpress
WORDPRESS_DB_PASSWORD=$(openssl rand -hex 24)
MARIADB_ROOT_PASSWORD=$(openssl rand -hex 24)
EOF
chmod 600 .env

WordPress anahtarlarını ve salt değerlerini üretmeniz gerekmez: imaj wp-config.php dosyasını WORDPRESS_* değişkenlerinden oluştururken bunları benzersiz rastgele değerlerle doldurur.

PHP'nin yükleme ve bellek sınırlarını küçük bir ini dosyasıyla artırın. Resmi imaj belgeleri, PHP'nin conf.d klasöründeki dosyaların kendiliğinden yüklendiğini açıklar; Adım 2 bu dosyayı oraya bağlar:

mkdir -p /opt/wordpress/php
cat > /opt/wordpress/php/uploads.ini <<'EOF'
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 120
EOF

Adım 2 — Compose dosyasını yazın

/opt/wordpress/compose.yaml dosyasını oluşturun. Dosya, imaj belgelerindeki örneği bir MariaDB sağlık kontrolü, yalnızca loopback adresinde yayınlanan bir port, PHP ayar dosyası ve isteğe bağlı bir WP-CLI servisiyle genişletir:

services:
  wordpress:
    image: wordpress:php8.3-apache
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "127.0.0.1:8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
      WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
      WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
      WORDPRESS_CONFIG_EXTRA: |
        define( 'DISALLOW_FILE_EDIT', true );
    volumes:
      - wordpress:/var/www/html
      - ./php/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro

  db:
    image: mariadb:lts
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: ${WORDPRESS_DB_NAME}
      MARIADB_USER: ${WORDPRESS_DB_USER}
      MARIADB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
      MARIADB_ROOT_PASSWORD: ${MARIADB_ROOT_PASSWORD}
      MARIADB_AUTO_UPGRADE: "1"
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - db:/var/lib/mysql

  wpcli:
    image: wordpress:cli-php8.3
    profiles: ["cli"]
    user: "33:33"
    environment:
      HOME: /tmp
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
      WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
      WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
    volumes:
      - wordpress:/var/www/html
    depends_on:
      - db

volumes:
  wordpress:
  db:

Seçimlerin anlamı:

• wordpress:php8.3-apache, PHP 8.3 üzerindeki Apache varyantıdır ve bugün latest etiketinin gösterdiği imaj da budur. PHP serisini adıyla belirtmek, PHP yükseltmesini bilinçli bir değişiklik haline getirir; imajın php8.4 ve php8.5 varyantları ile ayrı bir web sunucusu kullanan kurulumlar için PHP-FPM imajı da vardır.
• WORDPRESS_CONFIG_EXTRA, wp-config.php içinde değerlendirilir. Burada WordPress'in önerdiği bir sağlamlaştırma adımı olarak yerleşik tema ve eklenti dosya düzenleyicisini kapatır.
• mariadb:lts, MariaDB'nin güncel uzun süreli destek serisini izler. MARIADB_AUTO_UPGRADE, mevcut veriler üzerinde daha yeni bir sunucu sürümü başladığında mariadb-upgrade komutunu çalıştırır ve önce sistem tablolarının bir yedeğini alır.
• MariaDB konteyneri veritabanını ve kullanıcıyı MARIADB_* değişkenlerinden yalnızca ilk açılışta oluşturur. Bu değişkenlerde sonradan yapılan değişikliklerin mevcut veriler üzerinde etkisi olmaz.
• wpcli servisi cli profiline aittir; bu yüzden docker compose up onu başlatmaz, ihtiyaç duyduğunuzda docker compose run ile çağırırsınız.

Adım 3 — WordPress'i başlatın

Yapıyı başlatın, veritabanının sağlıklı olduğunu bildirmesini bekleyin ve WordPress'in loopback portunda yanıt verdiğini kontrol edin:

cd /opt/wordpress
docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080

db servisi healthy göstermeli, curl ise /wp-admin/install.php adresine bir 302 yönlendirmesi döndürmelidir. PHP ayarlarının yüklendiğini doğrulayın:

docker compose exec wordpress php -i | grep -E 'upload_max_filesize|post_max_size'

İki değer de 64M olmalıdır. Kurulum sihirbazını 127.0.0.1:8080 üzerinden açmayın: WordPress kurulumu yaptığınız adresi site adresi olarak kaydeder.

Adım 4 — WordPress'i Caddy ile HTTPS üzerinden yayınlayın

Siteyi /etc/caddy/Caddyfile dosyasına ekleyin. İkinci blok www adresini çıplak alan adına yönlendirir; ana adres olarak www.example.com tercih ediyorsanız iki adı yer değiştirin:

example.com {
    reverse_proxy 127.0.0.1:8080
}

www.example.com {
    redir https://example.com{uri} permanent
}

Caddy'yi yeniden yükleyin, yalnızca SSH ve web trafiğine izin verin ve test edin:

sudo systemctl reload caddy
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
curl -I https://example.com

Yanıt yine kurulum sihirbazına bir yönlendirmedir; bu kez geçerli bir sertifikayla HTTPS üzerinden gelir. HTTPS algılaması ek iş gerektirmez: Caddy X-Forwarded-Proto: https başlığını gönderir ve konteyneri WORDPRESS_* değişkenleriyle yapılandırdığınız için imaj, eşleşen HTTP_X_FORWARDED_PROTO kontrolünü wp-config.php dosyasına ekler. İmaj ayrıca özel ve loopback adreslerden gelen X-Forwarded-For başlığına güvenir; böylece WordPress gerçek ziyaretçi IP adreslerini görür. Caddy yerine Nginx kullanıyorsanız proxy_set_header X-Forwarded-Proto $scheme; satırını kendiniz ekleyin; Nginx ve Certbot rehberine bakın.

Adım 5 — WordPress kurulum sihirbazını çalıştırın

https://example.com adresini açın, dili seçin ve site başlığını, bir yönetici kullanıcı adını, güçlü bir parolayı ve e-posta adresinizi girin. admin ve tahmin edilmesi kolay diğer kullanıcı adlarından kaçının; "Discourage search engines" seçeneğini yalnızca bir test sitesinde işaretleyin. Giriş yaptıktan sonra Settings → Permalinks (Ayarlar → Kalıcı bağlantılar) ekranını açın, Post name (Yazı adı) seçeneğini seçip kaydedin; Apache imajı rewrite modülünü içerdiği için okunaklı adresler hemen çalışır.

Adım 6 — Resmi cli imajından WP-CLI kullanın

WP-CLI, WordPress volume'unu ve veritabanı ayarlarını paylaşan kısa ömürlü bir konteynerde çalışır. cli imajları Alpine tabanlıdır ve orada www-data kullanıcısının UID'si 82'dir; Debian tabanlı Apache imajı ise UID 33 kullanır. Bu nedenle imaj belgeleri WP-CLI'ı HOME=/tmp ile 33:33 olarak çalıştırmayı önerir; Compose dosyası bunu zaten yapar:

cd /opt/wordpress
docker compose run --rm wpcli wp core version
docker compose run --rm wpcli wp plugin list
docker compose run --rm wpcli wp option get siteurl

Son komut https://example.com yazdırmalıdır. Örneğin wp user list veya wp search-replace gibi her WP-CLI komutu için aynı kalıbı kullanın.

Yedekleme ve geri yükleme

Site iki adlandırılmış volume'da, wordpress (çekirdek, temalar, eklentiler, yüklemeler, wp-config.php) ve db (MariaDB verileri), ayrıca /opt/wordpress içindeki dosyalarda yaşar. Compose volume adlarının başına proje klasörünün adını ekler; bu yüzden diskte adları wordpress_wordpress ve wordpress_db olur, bunu docker volume ls ile kontrol edin. Veritabanının dökümünü MariaDB'nin kendi aracıyla docker compose exec üzerinden alın, dosya volume'unu da geçici bir konteynerle arşivleyin:

sudo mkdir -p /opt/backups
sudo chown $USER:$USER /opt/backups
cd /opt/wordpress
docker compose exec -T db sh -c 'exec mariadb-dump --single-transaction -uroot -p"$MARIADB_ROOT_PASSWORD" "$MARIADB_DATABASE"' | gzip > /opt/backups/wordpress-db-$(date +%F).sql.gz
docker run --rm -v wordpress_wordpress:/data:ro -v /opt/backups:/backup alpine tar czf /backup/wordpress-files-$(date +%F).tar.gz -C /data .
tar czf /opt/backups/wordpress-config-$(date +%F).tar.gz -C /opt/wordpress .env compose.yaml php
chmod 600 /opt/backups/wordpress-*

Çekirdek dosyalar olmadan yalnızca içeriği istiyorsanız . yerine volume'un yalnızca wp-content alt klasörünü arşivleyin. /opt/backups klasörünü düzenli olarak sunucu dışına kopyalayın; aynı makinedeki bir yedek makineyle birlikte kaybolur.

Yeni bir sunucuya geri yüklemek için Docker'ı kurun, yapılandırma arşivini /opt/wordpress içine açın ve şunları çalıştırın:

cd /opt/wordpress
docker compose up -d --wait db
gunzip -c /opt/backups/wordpress-db-2026-10-09.sql.gz | docker compose exec -T db sh -c 'exec mariadb -uroot -p"$MARIADB_ROOT_PASSWORD" "$MARIADB_DATABASE"'
docker compose create wordpress
docker run --rm -v wordpress_wordpress:/data -v /opt/backups:/backup alpine tar xzf /backup/wordpress-files-2026-10-09.tar.gz -C /data
docker compose up -d

--wait, MariaDB sağlıklı hale geldiğinde geri döner; docker compose create ise dosya volume'unu WordPress'i başlatmadan oluşturur, böylece imaj önce volume'a yeni bir çekirdek kopyalamaz. Tarihleri kendi dosya adlarınızdakilerle değiştirin, ardından yeni sunucuya Adım 4'teki Caddy site bloğunu ekleyin.

WordPress güncelleme

Güncel tutulması gereken iki katman vardır. WordPress çekirdeği, eklentiler ve temalar volume içinde yaşar ve her WordPress sitesindeki gibi güncellenir: küçük sürümler ve güvenlik sürümleri kendiliğinden kurulur, gerisini Dashboard → Updates (Başlangıç → Güncellemeler) ekranı halleder. Kabuktan da güncelleyebilirsiniz:

cd /opt/wordpress
docker compose run --rm wpcli wp core update
docker compose run --rm wpcli wp core update-db
docker compose run --rm wpcli wp plugin update --all

İmajlar PHP'yi, Apache'yi, sistem kütüphanelerini ve MariaDB'yi getirir. Önce yedek alın, ardından imajları çekip konteynerleri yeniden oluşturun:

cd /opt/wordpress
docker compose pull
docker compose up -d
docker compose ps

Yeni bir wordpress imajı çekmek volume'daki WordPress sürümünü değiştirmez. Daha yeni bir PHP serisine geçmek için eklentilerinizin bunu desteklediğini kontrol ettikten sonra compose.yaml içindeki iki php8.3 etiketini de değiştirin. Büyük WordPress güncellemelerinden önce sürüm notlarını okuyun ve büyük değişiklikleri önce sitenin bir kopyasında test edin.

Sorun giderme

ERR_TOO_MANY_REDIRECTS

WordPress isteğin HTTP üzerinden geldiğini düşünüyor ve sürekli HTTPS'e yönlendiriyor. Proxy'nizin X-Forwarded-Proto gönderdiğinden (Caddy varsayılan olarak gönderir; Nginx'te proxy_set_header X-Forwarded-Proto $scheme; gerekir) ve sunucunun önündeki bir CDN'in sunucuya düz HTTP ile bağlanmadığından emin olun. Site adresi yanlış kaydedildiyse docker compose run --rm wpcli wp option update home 'https://example.com' ve siteurl için aynı komutla düzeltin.

Error establishing a database connection

docker compose ps çıktısını kontrol edin: db servisi healthy olmalıdır. İlk açılıştan sonra .env içindeki parolaları değiştirdiyseniz MariaDB hâlâ eskilerini kullanır, çünkü MARIADB_* değişkenlerini yalnızca veri klasörü boşken okur. Orijinal değerleri geri koyun ya da kullanıcının parolasını MariaDB içinde ALTER USER ile değiştirin.

The uploaded file exceeds the upload_max_filesize directive in php.ini.

PHP ayar dosyası bağlanmamış veya yolu yanlış. /opt/wordpress/php/uploads.ini dosyasının var olduğunu ve compose.yaml içindeki volume satırının /usr/local/etc/php/conf.d/uploads.ini hedefini gösterdiğini kontrol edin, ardından konteyneri yeniden oluşturmak için docker compose up -d çalıştırın. Caddy'nin önündeki bir proxy kendi gövde boyutu sınırını uygulayabilir.

Installation failed: Could not create directory

Volume'daki dosyaların sahibi www-data değil; bu genellikle bir geri yüklemeden veya WP-CLI'ı root olarak çalıştırdıktan sonra olur. Sahipliği docker compose exec wordpress chown -R www-data:www-data /var/www/html ile düzeltin ve WP-CLI'ı her zaman wpcli servisi üzerinden çalıştırın.

WordPress e-posta göndermiyor

Resmi imaj bir posta sunucusu içermez; bu yüzden PHP'nin mail() fonksiyonu mesajları teslim edemez. Bir SMTP eklentisi kurun ve onu smtp.example.com sunucusu, 587 numaralı port ve STARTTLS ile işlemsel e-posta sağlayıcısına bağlayın; ardından bir parola sıfırlamayla test edin.

Sonraki adımlar

• WordPress'i doğrudan sunucuda çalıştırmayı mı tercih ediyorsunuz? Nginx, PHP-FPM ve MariaDB ile WordPress rehberine bakın.
• Compose dosya biçimini Docker Compose temelleri rehberinde öğrenin.
• WordPress siteleri için planları WordPress hosting sayfasında karşılaştırın.
• Tüm değişkenler ve varyantlar için resmi wordpress imaj belgelerini okuyun.