Docker ile PostgreSQL ve MySQL Kurulumu: Compose, Volume ve Yedek

Docker ile PostgreSQL ve MySQL kurulumunu nasıl yaparsınız?

Docker ile PostgreSQL ve MySQL kurulumu, resmi görüntüyü çekip bir konteyner başlatmaktan, parolayı ortam değişkeni ya da secret ile vermekten ve veri klasörünü bir volume'a bağlamaktan oluşur. Volume bağlamazsanız konteyneri sildiğinizde veri de gider. Geliştirme ortamında docker run ya da Compose yeterlidir; portu yalnızca localhost'a açın.

Bu yazı, kendi bilgisayarında ya da kendi VPS'inde veritabanı çalıştırmak isteyen web sitesi sahiplerine ve yazılımcılara yöneliktir. Komutları adım adım uygulayabilirsiniz. Yönetimi hosting sağlayıcınıza bırakmışsanız, hangi soruyu sağlayıcınıza yöneltmeniz gerektiğini öğrenirsiniz.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu nedenle anlatım resmi Docker, PostgreSQL görüntüsü ve MySQL görüntüsü dokümanlarına dayanır. Docker'ın ne olduğunu burada yeniden anlatmıyoruz; temel bilgi için Docker nedir rehberimize bakın.

Yazının sonunda, hangi durumda bu işi kendiniz yapmamanız gerektiğini de açıkça yazdık. Çünkü canlı bir mağazanın veritabanı, bir öğrenme projesinden çok farklı bir sorumluluktur.

Veritabanını hangi durumlarda Docker'da çalıştırmalısınız?

Veritabanı konteyneri en çok geliştirme, test ve deneme ortamlarında işe yarar. Aynı sürümü ekibin her bilgisayarında tek komutla ayağa kaldırırsınız. Üstelik projeyi bitirince konteyneri silip bilgisayarınızı temiz bırakırsınız. Böylece "bende çalışıyordu" sorunlarının büyük kısmı ortadan kalkar.

Canlı ortamda ise kararı daha dikkatli vermeniz gerekir. Konteyner tek başına yedek, izleme ve felaket kurtarma sağlamaz. Bu işleri ayrıca kurmanız gerekir. Aşağıdaki tablo, ekibimizin kaynakları okuyarak çıkardığı genel bir ayrımı özetler; bir garanti değil, bir karar çerçevesidir.

Başlamadan önce neye ihtiyacınız var?

İhtiyacınız olan şey, Docker Engine ya da Docker Desktop ile Compose eklentisidir. Kurulumu resmi dokümandan yapın. Ardından terminalde şu iki komutla çalıştığını doğrulayın. Komutlar bir sürüm numarası döndürüyorsa hazırsınız.

docker --version
docker compose version

Ayrıca üç şeye karar verin. Birincisi, hangi veritabanını kullanacağınız. İkincisi, verinin nerede duracağı. Üçüncüsü de bağlantıyı kimin kuracağıdır: yalnızca aynı bilgisayardaki uygulamanız mı, yoksa uzaktaki bir araç mı?

Bu üçüncü soru, yazının güvenlik bölümünü belirler. Cevabınız "yalnızca benim uygulamam" ise portu hiç dışarı açmayabilirsiniz. Çoğu proje için doğru cevap budur.

Görüntü etiketini ve sürümü nasıl seçersiniz?

Docker Hub'da hem postgres hem mysql adlı resmi görüntüler bulunur. Bu görüntülerin sayfasında desteklenen etiketler listelenir. Etiket olarak "latest" yazarsanız, bir sonraki çekişte farklı bir büyük sürüm gelebilir. Bu da veri klasörünün uyuşmaması gibi sorunlar çıkarır.

Bunun yerine, uygulamanızın desteklediği ve güncel kararlı sürüm hattındaki bir etiketi seçin. Etiketi Compose dosyasına yazın ve değişiklik yaparken bilinçli güncelleyin. Hangi sürümün sizin yazılımınızla uyumlu olduğunu öğrenmek için yazılımın kendi dokümanına bakın.

Ayrıca resmi görüntü sayfasındaki notları, her büyük sürüm geçişinden önce yeniden okuyun. Yukarıda gördüğünüz PostgreSQL volume yolu değişikliği gibi ayrıntılar yalnızca orada yazar.

Docker ile PostgreSQL kurulumunu docker run ile nasıl yaparsınız?

En kısa yol docker run komutudur. Resmi PostgreSQL görüntüsü POSTGRES_PASSWORD değişkenini zorunlu tutar; Docker Hub sayfasına göre değişken boş ya da tanımsız olamaz. Aşağıdaki örnek, isimli bir volume ile birlikte portu yalnızca localhost'a açar.

docker run --name ornek-postgres -d \
  -e POSTGRES_PASSWORD=BURAYA_GUCLU_PAROLA \
  -e POSTGRES_USER=uygulama \
  -e POSTGRES_DB=uygulamadb \
  -v pgveri:/var/lib/postgresql/data \
  -p 127.0.0.1:5432:5432 \
  postgres:SURUM_ETIKETI

SURUM_ETIKETI yerine seçtiğiniz sürümün etiketini yazın. Üretim benzeri ortamlarda latest etiketini kullanmayın, çünkü bir sonraki çekişte büyük sürüm değişebilir. Güncel sürüm listesini Docker Hub sayfasında görürsünüz.

Önemli bir ayrıntı var. Docker Hub dokümanına göre PostgreSQL 18 ve sonrasında PGDATA yolu sürüme özel bir dizine kayıyor. Örnekteki /var/lib/postgresql/data bağlama yolu 17 ve öncesi için geçerlidir. Daha yeni bir sürüm çekiyorsanız, o sürümün volume notunu resmi sayfadan okuyun.

Docker ile MySQL kurulumunu docker run ile nasıl yaparsınız?

MySQL görüntüsünde zorunlu değişken MYSQL_ROOT_PASSWORD'dür. MYSQL_DATABASE, MYSQL_USER ve MYSQL_PASSWORD ise ilk açılışta bir veritabanı ve kullanıcı oluşturur. Veri klasörü /var/lib/mysql yoludur ve kalıcılık için onu bir volume'a bağlamanız gerekir; resmi sayfa da bunu söyler.

docker run --name ornek-mysql -d \
  -e MYSQL_ROOT_PASSWORD=BURAYA_ROOT_PAROLASI \
  -e MYSQL_DATABASE=uygulamadb \
  -e MYSQL_USER=uygulama \
  -e MYSQL_PASSWORD=BURAYA_UYGULAMA_PAROLASI \
  -v mysqlveri:/var/lib/mysql \
  -p 127.0.0.1:3306:3306 \
  mysql:SURUM_ETIKETI

MySQL dokümanında MYSQL_RANDOM_ROOT_PASSWORD seçeneği de yer alır. Bu değişkene yes gibi boş olmayan bir değer verirseniz, başlangıç parolasını görüntü kendisi üretir. Parolayı daha sonra konteyner günlüğünden okursunuz. Boş root parolasına izin veren MYSQL_ALLOW_EMPTY_PASSWORD seçeneğini ise önermiyoruz; kullanmayın.

Parolaları komut satırına yazmak pratiktir, fakat riskli. Komut geçmişinde kalır. Bu yüzden sonraki bölümlerde .env dosyasını ve secret yöntemini anlatıyoruz.

Hangi veritabanını seçmelisiniz: PostgreSQL mi, MySQL mi?

İkisi de yaygın, açık kaynaklı ilişkisel veritabanlarıdır ve ikisini de Docker'da aynı yöntemle çalıştırırsınız. Seçimi çoğunlukla uygulamanız belirler. Kullandığınız yazılım ya da çatı hangisini destekliyorsa onu seçin. WordPress gibi hazır sistemler MySQL ya da uyumlu bir sürümünü bekler.

Projeniz sıfırdan başlıyorsa ve bir yazılımın şartı yoksa, ekibinizin tanıdığı sistemi seçin. Bilinmeyen bir sistemi işletmek, yedek ve güncelleme işini zorlaştırır.

Docker ile PostgreSQL ve MySQL kurulumunda veri volume ile nasıl kalıcı olur?

Konteynerin dosya sistemi geçicidir. Konteyneri silerseniz içindeki veri de gider. Veriyi kalıcı yapmak için veri klasörünü bir volume'a bağlarsınız. İki yaygın yol vardır: Docker'ın yönettiği isimli volume ve sunucudaki bir klasöre bağlanan bind mount.

Volume'ları listelemek ve ayrıntısına bakmak için şu komutlar yeterlidir.

docker volume ls
docker volume inspect pgveri

Bir tuzağa dikkat edin. Compose kullanırken docker compose down komutu konteynerleri siler ama volume'ları korur. Buna karşılık docker compose down -v komutu volume'ları da siler. Yani tek bir bayrak, veritabanınızın tamamını kaybetmenize yol açabilir.

Ortam değişkenlerini ve parolaları nasıl yönetirsiniz?

Parolayı Compose dosyasına doğrudan yazmayın. Bunun yerine, aynı klasörde bir .env dosyası oluşturun ve değerleri oradan okutun. Bu dosyayı sürüm kontrolüne eklemeyin; git kullanıyorsanız .gitignore içine yazın. Git konusunda bilgi için Git ve GitHub rehberimize bakabilirsiniz.

# .env dosyası (örnek değerler, kendi parolanızı üretin)
POSTGRES_PASSWORD=BURAYA_GUCLU_PAROLA
MYSQL_ROOT_PASSWORD=BURAYA_ROOT_PAROLASI

Compose, environment alanındaki değerlerin env_file içindekileri geçersiz kıldığını belgeler. Yani aynı değişkeni iki yerde tanımlarsanız environment kazanır. Parola üretmek için şifre oluşturucu aracımızı kullanabilirsiniz.

Bir uyarı daha ekleyelim. Ortam değişkenlerini docker inspect çıktısında görürsünüz. Bu nedenle sunucuya erişimi olan herkes değerleri okuyabilir. Daha sıkı bir yöntem için bir sonraki bölüme geçin.

Docker secrets ile veritabanı parolasını nasıl verirsiniz?

Hem PostgreSQL hem MySQL görüntüsü, değişken adının sonuna _FILE ekleyerek değeri dosyadan okur. Docker Hub sayfaları bunu özellikle secret kullanımı için önerir. Compose'ta bir secret tanımlarsanız, servis içinde /run/secrets/ADI yolunda yalnızca okuyabileceğiniz bir dosya olarak görünür.

services:
  db:
    image: postgres:SURUM_ETIKETI
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_parola
    secrets:
      - db_parola

secrets:
  db_parola:
    file: ./gizli/db_parola.txt

Parola dosyasını sürüm kontrolüne eklemeyin ve dosya izinlerini kısıtlayın. Örneğin yalnızca sizin kullanıcınız okuyabilsin. MySQL için aynı mantık geçerlidir; MYSQL_ROOT_PASSWORD_FILE değişkeni /run/secrets/ altındaki bir dosyayı gösterir.

Ancak şunu unutmayın: bu yöntem parolayı komut geçmişinden ve docker inspect çıktısından uzak tutar, ama sunucunun kendisi ele geçirilirse dosyayı yine okuyabilirler. Güvenlik katmanlıdır. Bu yazının güvenlik bölümü ve OWASP Top 10 rehberimiz diğer katmanları anlatır.

Docker Compose ile PostgreSQL kurulumunu nasıl yaparsınız?

Compose, tüm ayarı tek bir dosyada toplar ve tekrar çalıştırmayı kolaylaştırır. Aşağıdaki dosya PostgreSQL için volume, secret, sağlık kontrolü ve yalnızca localhost'a açık port içerir. Dosyayı bir klasörde compose.yaml adıyla kaydedip docker compose up -d komutuyla başlatırsınız.

services:
  db:
    image: postgres:SURUM_ETIKETI
    restart: unless-stopped
    environment:
      POSTGRES_USER: uygulama
      POSTGRES_DB: uygulamadb
      POSTGRES_PASSWORD_FILE: /run/secrets/db_parola
    secrets:
      - db_parola
    volumes:
      - pgveri:/var/lib/postgresql/data
    ports:
      - "127.0.0.1:5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U uygulama -d uygulamadb"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

secrets:
  db_parola:
    file: ./gizli/db_parola.txt

volumes:
  pgveri:

restart: unless-stopped, bilgisayar yeniden başladığında konteynerin açılmasını sağlar. Compose servis referansı restart için no, always, on-failure ve unless-stopped seçeneklerini sayar; varsayılan değer no'dur.

Docker Compose ile MySQL kurulumunu nasıl yaparsınız?

MySQL dosyası aynı mantığı izler. Fark, değişken adlarında ve sağlık kontrolü komutundadır. Sağlık kontrolü için mysqladmin ping komutunu kullanabilirsiniz. Ancak bu komut, sunucu ayakta olduğu sürece parola hatasında bile başarılı dönebilir; yani yalnızca "süreç yanıt veriyor" bilgisini verir.

services:
  mysql:
    image: mysql:SURUM_ETIKETI
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: uygulamadb
      MYSQL_USER: uygulama
      MYSQL_PASSWORD_FILE: /run/secrets/mysql_parola
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root
    secrets:
      - mysql_parola
      - mysql_root
    volumes:
      - mysqlveri:/var/lib/mysql
    ports:
      - "127.0.0.1:3306:3306"
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

secrets:
  mysql_parola:
    file: ./gizli/mysql_parola.txt
  mysql_root:
    file: ./gizli/mysql_root.txt

volumes:
  mysqlveri:

Compose dokümanı start_period alanını da tanımlar: bu alan, konteynere başlangıç için tanınan süredir. İlk açılışta veritabanı dosyalarını hazırlayacağı için bu değeri cömert tutun ve kendi makinenizde gerçek açılış süresini gözleyerek ayarlayın.

PostgreSQL ve MySQL'i aynı Compose dosyasında çalıştırabilir misiniz?

Evet, çalıştırabilirsiniz. İki servisi aynı dosyaya koyun ve yukarıdaki iki bloğu birleştirin. Dikkat edeceğiniz tek çakışma, ana makine portlarıdır. PostgreSQL varsayılan olarak 5432, MySQL ise 3306 portunu kullanır; ikisi farklı olduğu için çakışmaz. Aynı türden iki konteyner çalıştıracaksanız ana makine portunu değiştirmeniz gerekir.

Uygulamanız da Compose içinde çalışıyorsa, veritabanı portunu ana makineye hiç açmanıza gerek yoktur. Aynı Compose ağındaki servisler birbirine servis adıyla ulaşır. Yani uygulamanız db:5432 ya da mysql:3306 adresini kullanır.

Konteynerin içine nasıl bağlanır ve günlükleri nasıl izlersiniz?

Kurulumdan sonra ilk iş, veritabanının gerçekten yanıt verdiğini görmektir. Compose ile çalışıyorsanız, konteynerin içinde istemci programını açabilirsiniz. İki örnek komut aşağıda yer alır; kullanıcı ve veritabanı adlarını kendi ayarınıza göre değiştirin.

docker compose exec db psql -U uygulama -d uygulamadb
docker compose exec mysql mysql -u uygulama -p uygulamadb

MySQL komutu parolayı sorar; siz yazarsınız. Böylece parola komut geçmişine girmez. Çıkmak için PostgreSQL'de \q, MySQL'de exit yazarsınız.

Günlükler için docker compose logs komutu yeterlidir. Başına -f bayrağı eklerseniz akışı canlı izlersiniz. Özellikle ilk açılışta, init betiklerinin çalışıp çalışmadığını ve olası parola ya da izin hatalarını bu çıktıda görürsünüz.

docker compose ps
docker compose logs -f db

docker compose ps çıktısında sağlık durumu da yer alır. Durum "healthy" olana kadar uygulamanızı başlatmayın. Sorun yaşarsanız, günlük çıktısını bir not defterine kopyalayın; sağlayıcınızdan ya da yazılımcınızdan yardım istediğinizde bu çıktı işi çok hızlandırır.

Healthcheck neden gerekir ve depends_on ile nasıl kullanılır?

Bir konteynerin çalışıyor olması, veritabanının bağlantı kabul ettiği anlamına gelmez. İlk açılışta veritabanı dosyalarını hazırlar ve bu sırada bağlantıları reddeder. Uygulamanız bu aralıkta başlarsa hata verir. Healthcheck, bu boşluğu kapatır.

PostgreSQL için pg_isready kullanırsınız. Resmi dokümana göre 0 çıkış kodu sunucunun bağlantı kabul ettiğini, 1 sunucunun bağlantıyı reddettiğini (örneğin açılış sırasında), 2 yanıt alınamadığını, 3 ise parametre hatası yüzünden deneme yapılmadığını gösterir. Bu kodlar Docker'ın sağlıklı ya da sağlıksız kararına dönüşür.

services:
  uygulama:
    image: ORNEK_UYGULAMA_GORUNTUSU
    depends_on:
      db:
        condition: service_healthy

Compose dokümanına göre service_healthy koşulu, bağımlı servisin sağlık kontrolünü geçmesini bekler. Böylece uygulamanız veritabanı hazır olmadan başlamaz. Sağlık durumunu docker compose ps çıktısında görürsünüz.

Docker ile PostgreSQL ve MySQL kurulumunda port açmak neden risklidir?

Bu bölüm, yazının en önemli kısmıdır. Docker port yayımlama dokümanı açıkça şunu söyler: yayımladığınız bir port yalnızca Docker ana makinesine değil, dış dünyaya da ulaşır. Yani ports bölümüne 5432:5432 yazmak, veritabanınızı tüm internete sunmak anlamına gelebilir.

Daha da önemlisi, güvenlik duvarınız sizi korumayabilir. Docker güvenlik duvarı dokümanına göre, bir port yayımladığınızda Docker trafiği ufw kurallarına ulaşmadan önce başka yöne çevirir. Çünkü Docker trafiği nat tablosunda işler ve paketler ufw'nin kullandığı INPUT ve OUTPUT zincirlerine varmaz. Bu yüzden "ufw ile kapattım" demek yeterli değildir.

Çözüm basittir: IP adresini portla birlikte yazın. Dokümana göre 127.0.0.1 ya da ::1 adresini yayımlama bayrağına eklerseniz, yalnızca Docker ana makinesi o porta erişebilir. Yukarıdaki tüm örneklerde bu yüzden 127.0.0.1 ön ekini kullandık. Compose'ta kısa söz diziminde ana makine IP'sini yazmazsanız port tüm arayüzlere ulaşır.

Docker dokümanı, 28.0.0 öncesi sürümlerde aynı ağ segmentindeki makinelerin localhost'a yayımladığınız portlara erişebildiğini de belirtir. Docker sürümünüzü güncel tutun. Hangi adreslerin dışarıya açık olduğunu görmek için IP sorgulama aracımızı kullanabilirsiniz.

Uzaktaki bir veritabanına güvenli şekilde nasıl bağlanırsınız?

Bilgisayarınızdaki bir yönetim aracıyla sunucudaki veritabanına bağlanmak istiyorsanız, portu açmak yerine SSH tüneli kullanın. Tünel, yerel bir portu SSH bağlantısı üzerinden sunucunun localhost'una taşır. Veritabanı yine yalnızca localhost'ta dinler.

ssh -N -L 5433:127.0.0.1:5432 kullanici@sunucu.example.com

Bu komut çalışırken, yerel bilgisayarınızda 127.0.0.1:5433 adresine bağlanan araç, sunucudaki PostgreSQL'e ulaşır. Yerel portu 5433 seçtik, çünkü bilgisayarınızda zaten bir PostgreSQL çalışıyor olabilir. MySQL için aynı mantığı 3306 portuyla uygularsınız.

Bu yöntem, veritabanı parolası zayıf olsa bile saldırı yüzeyini küçültür. Çünkü saldırgan önce SSH anahtarınızı aşmak zorundadır. Yine de güçlü parola kullanmaya devam edin; bir savunma katmanı diğerinin yerini tutmaz.

Başlangıç verisini init betikleriyle nasıl yüklersiniz?

İki resmi görüntü de /docker-entrypoint-initdb.d klasöründeki dosyaları ilk açılışta çalıştırır. PostgreSQL sayfası .sql, .sql.gz ve .sh uzantılarını belirtir. MySQL sayfası ek olarak .sql.bz2, .sql.xz ve .sql.zst uzantılarını sayar ve dosyaların alfabetik sırayla çalıştığını söyler.

    volumes:
      - pgveri:/var/lib/postgresql/data
      - ./baslangic:/docker-entrypoint-initdb.d:ro

Kritik ayrıntı şudur: PostgreSQL sayfasına göre bu betikler yalnızca veri klasörü boşken çalışır. Yani betiği sonradan değiştirip konteyneri yeniden başlatırsanız, değişiklik devreye girmez. Betiği yeniden denemek istiyorsanız, volume'u silmeniz ve verinin kaybolacağını kabul etmeniz gerekir.

Bu nedenle şema değişikliklerini init betiğine bırakmayın. Canlı veride şema değişimi için bir göç (migration) aracı kullanın. Örneğin Laravel, Django ya da Prisma gibi çatılar bu aracı kendileri sunar.

Docker'daki veritabanından yedek nasıl alırsınız?

Yedek, bu yazının en az tartışılabilir kuralıdır. Volume dosyalarını açık bir veritabanından kopyalamak tutarlı bir yedek vermeyebilir. Bu nedenle mantıksal döküm (dump) tercih edin. MySQL sayfası, docker exec ile mysqldump örneğini doğrudan verir; PostgreSQL için pg_dump aynı işi görür.

# PostgreSQL yedeği
docker compose exec -T db pg_dump -U uygulama uygulamadb > yedek-pg.sql

# MySQL yedeği (resmi sayfadaki örneğe dayanır)
docker exec ornek-mysql sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD"' > yedek-mysql.sql

Resmi MySQL sayfasındaki örnek parolayı ortam değişkeninden okur. Secret kullanıyorsanız bu değişken tanımlı olmaz; bu durumda parolayı dosyadan okutmanız gerekir. Geri yükleme için ters yönde, docker exec -i ile mysql komutuna dosyayı verirsiniz.

# PostgreSQL geri yükleme
docker compose exec -T db psql -U uygulama uygulamadb < yedek-pg.sql

Yedeğin işe yaradığını anlamanın tek yolu, onu geri yüklemektir. Ayda bir test ortamında deneyin. Yedek stratejisinin genel çerçevesi için web sitesi yedekleme stratejisi yazımıza bakın.

Büyük sürüm yükseltmesini ve güncellemeleri nasıl yönetirsiniz?

Küçük güncellemeler genelde etiketi değiştirip konteyneri yeniden oluşturmaktan ibarettir. Büyük sürüm geçişleri ise farklıdır. Veritabanı yazılımları, eski büyük sürümün veri klasörünü yeni büyük sürümle her zaman açamaz. Bu yüzden önce yedek alın, sonra yeni sürümü ayrı bir volume ile deneyin.

Üç adımlı güvenli bir sıra izleyebilirsiniz. Önce mevcut veritabanından bir döküm alın. Ardından yeni sürümü boş bir volume ile başlatın ve dökümü içine yükleyin. Son olarak uygulamanızı bu yeni veritabanına bağlayıp test edin. Eski volume'u ancak her şey doğrulandıktan sonra silin.

• Etiketi sabitleyin ve latest kullanmayın.
• Güncellemeden önce her zaman bir döküm alın.
• Büyük sürüm geçişini önce test ortamında deneyin.
• Eski volume'u geri dönüş için bir süre saklayın.

Geçiş yöntemlerinin ayrıntısı her veritabanı için ayrı belgelenmiştir. Kendi sürümünüzün resmi yükseltme notlarını okumadan işlem yapmayın.

Üretimde veritabanı konteyneri kullanırken nelere dikkat etmelisiniz?

Üretimde konteyner, kaybetmeyi göze alamayacağınız bir veriyi taşır. Bu yüzden her adımı bilinçli kurun. Aşağıdaki liste, üretim öncesi gözden geçirmeniz gereken başlıkları toplar.

• Portu yalnızca localhost'a bağlayın ve uzaktan erişimi SSH tüneliyle yapın.
• Parolaları secret ya da _FILE değişkenleriyle verin.
• Veriyi volume'da tutun ve yedeği sunucudan ayrı bir yere kopyalayın.
• Healthcheck ve restart politikasını tanımlayın.
• Disk doluluğunu ve konteyner günlüklerini düzenli izleyin.
• Etiketi sabitleyin ve güncellemeyi planlı yapın.

Canlı bir mağaza ya da randevu sistemi için bu listenin her maddesinin sahibi olmalıdır. Sahibi olmayan madde, sorun çıktığında kimsenin cevap veremediği maddedir. Bu nedenle çoğu işletme, yönetilen veritabanı hizmetini daha güvenli bulur. Hosting kararınız için hosting seçimi yazımıza bakın.

Docker'da veritabanı kurarken en sık hangi hataları yaparsınız?

Hataların çoğu birkaç ana başlıkta öbeklenir. Aşağıdaki tablo, belirti ve nedenleri eşleştirir; böylece sorun yaşadığınızda hangi bölüme dönmeniz gerektiğini hızlıca bulursunuz.

İlk açılışta veritabanı oluşturma değişkenleri yalnızca veri klasörü boşken etki eder. Bu nedenle parola değişikliğini yalnızca env dosyasını düzenleyerek yapmayı beklemeyin. İlk açılıştan sonra parolayı veritabanının kendi komutuyla değiştirmeniz gerekir.

Ne zaman bunu kendiniz yapmamalı, hosting sağlayıcınıza bırakmalısınız?

Dürüst olalım: her proje için veritabanını kendiniz işletmek doğru karar değildir. Müşteri verisi, sipariş ya da ödeme bilgisi tutan canlı bir sistemde, yedek ve güvenlik güncellemesi sürekli ilgi ister. Bu ilgiyi verecek biri yoksa, işi sağlayıcıya bırakın.

Şu durumlarda kendiniz yapmayın. Veritabanı kesintisinin doğrudan satış kaybı yarattığı bir mağazanız varsa. Sunucuya düzenli bakım yapacak kimse yoksa. Yedeği geri yükleme denemesi hiç yapmadıysanız. Kişisel veri tutuyor ve KVKK ya da GDPR yükümlülüğünüz varsa. Bu durumlarda sağlayıcınızdan yönetilen bir veritabanı, otomatik yedek ve izleme isteyin.

Sağlayıcıya soracağınız sorular da basittir. Yedeği ne sıklıkla alıyorlar ve nerede saklıyorlar? Geri yükleme süresi ne kadar? Güvenlik güncellemelerini kim uyguluyor? Bu soruların net cevabı yoksa başka bir sağlayıcı arayın. Veritabanı bilginizi geliştirmek için SQL öğrenme rehberimiz ve önbellek konusunda Redis ve Memcached yazımız işinize yarar.

Docker ile PostgreSQL ve MySQL kurulumu için kontrol listesi nedir?

Kurulumu bitirdiğinizde şu listeyi baştan sona geçin. Her madde, bu yazıda anlattığımız bir riski kapatır. Hepsini işaretleyebiliyorsanız, geliştirme ya da küçük bir proje için sağlam bir temel kurmuşsunuz demektir.

1. Resmi görüntüyü ve sabit bir sürüm etiketini kullandınız.
2. Veri klasörünü bir volume'a bağladınız.
3. Parolaları .env ya da secret ile verdiniz ve sürüm kontrolünden uzak tuttunuz.
4. Portu 127.0.0.1 ile sınırladınız.
5. Healthcheck tanımladınız ve uygulamanızı service_healthy koşuluna bağladınız.
6. Bir yedek aldınız ve geri yüklemeyi denediniz.
7. Büyük sürüm geçişi için bir planınız var.

Bu altyapıyı bir web sitesi ya da uygulama projesinin parçası olarak kurmak istiyorsanız, ekibimizin özel yazılım geliştirme hizmetine göz atabilirsiniz.