Dockup’ta Managed PostgreSQL: Kapsamlı Rehber

Managed PostgreSQL, bir uygulamaya service container’dan bağımsız yaşam döngüsü işlemlerine sahip, provision edilmiş bir veritabanı sağlar. Dockup; oluşturma, başlatma ve durdurma, loglar, boyut inceleme, backup, platform üzerinden restore, read-only kullanıcılar, node migration ve private networking özelliklerini destekler.

Temel işletim ilkesi ayrımdır: application image disposable’dır, PostgreSQL verileri durable’dır, credentials secret olarak saklanır ve database recovery, application rollback’ten bağımsız olarak test edilmelidir.

Managed PostgreSQL veritabanı nasıl oluşturulur?

İstediğiniz workspace’i seçin, ardından veritabanını oluşturun:

dockup db create \
  --name main-db \
  --type postgresql \
  --json

Tam slug ve status bilgisini doğrulamak için veritabanlarını listeleyin:

dockup db list --json

Veritabanı işlemlerinde project/db target’ları kullanılır:

dockup db size production/main-db --json

Bir uygulamayı bağlamadan önce provisioning işlemi tamamlanana kadar bekleyin. Hostname, port, username veya password bilgilerini veritabanı adından tahmin etmeyin.

Free plan, tek bir workspace içinde üç veritabanına izin verir ve başlangıçta $10 kredi içerir. Aylık $5 fiyatlı Hobby, $20 fiyatlı Pro gibi ücretli planlar sınırsız veritabanı, workspace ve deployment kullanımına izin verir. CPU, RAM ve disk tüketimi, dahil edilen kullanım bakiyesine göre dakika başına ölçülür.

Bir uygulama güvenli şekilde nasıl bağlanır?

Database interface üzerinden Dockup’ın database connection ayrıntılarını alın ve connection string’i secret olarak değerlendirin. Bunu repository’ye veya agent transcript’ine yapıştırmayın.

Servis üzerinde ayarlayın:

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Çalışan process environment bilgisini startup sırasında aldığı için redeploy gereklidir. Environment configuration okunurken kayıtlı değer maskelenir.

Uygulamanın connection pooling ayarlarını bilinçli şekilde yapılandırın. Büyük pool’lara sahip çok sayıda application worker, CPU ve memory sağlıklı görünse bile database connection’larını tüketebilir. Pool size değerini bir framework’ün kabul ettiği maksimum sayıdan değil, workload ve database capacity’den yola çıkarak belirleyin.

Deployment sonrasında yeni bir connection test edin. Bir health endpoint, HTTP process’in çalıştığını doğrulayabilir; ancak yeni bir database session oluşturulabildiğini kanıtlamayabilir.

Environment variables ve secrets rehberinde credential rotation ve masked output konuları ele alınır.

Private networking PostgreSQL trafiğini nasıl korur?

Project-private network’ü etkinleştirin:

dockup network enable production --json

Bu project içindeki servisler ve managed database’ler, sabit <slug>.internal hostname’leri alır. Inject edilen internal connection variable’larını almak için uygulamayı redeploy edin.

Database’in public listener’ını kaldırmak ve yalnızca private erişime açmak için:

dockup db private production/main-db --json

Gerektiğinde public ve private erişimi yeniden etkinleştirin:

dockup db private production/main-db --off --json

Database’i yalnızca private erişime açmak, verileri koruyarak container’ını yeniden oluşturur. Değişikliği zararsız bir DNS düzenlemesi olarak değil, bir database operation olarak planlayın ve doğrulayın.

Private networking route’u kontrol eder; PostgreSQL credentials ise identity ve authorization’ı kontrol eder. İkisini de koruyun. Her project’in kendi network’ü olduğundan ayrı project’ler birbirine erişemez.

Private networking ve internal domain’ler makalesinde tüm topology açıklanır.

PostgreSQL backup ve restore nasıl çalışır?

Mevcut backup’ları listeleyin:

dockup db backups production/main-db --json

Server-side backup başlatın:

dockup db backup production/main-db --json

Backup command, raw volume’un hot copy’si yerine database-aware bir backup oluşturur. Backup ID’sini, oluşturulma zamanını, database version’ını ve nedenini kaydedin.

Dockup, managed database backup’larının platform üzerinden restore edilmesini destekler. Mevcut CLI reference dokümantasyonunda dockup db restore command’ı yer almadığından bu rehberde böyle bir command uydurulmamalıdır. Restore işlemini desteklenen Dockup interface üzerinden gerçekleştirin, tam backup’ı seçin, production approval alın ve sonucu doğrulayın.

Bir restore planı şunları içermelidir:

1. Recovery point ve beklenen lost-write window.
2. Application write freeze veya maintenance davranışı.
3. Database ve extension compatibility.
4. Gerektiğinde mevcut durumun fresh backup’ı.
5. Restore owner’ı ve approval.
6. Application reconnection ve smoke test.
7. Audit ve incident kaydı.

Backup’lar, restore drill başarıyla tamamlanana kadar kanıtlanmış sayılmaz. Procedure’ü test etmek için non-production database veya onaylanmış bir recovery environment kullanın.

Backup’ları onaylanmış bir policy’ye göre saklayın. Artık ihtiyaç duyulmayan recovery point’leri, hiçbir recovery veya compliance gereksiniminin bunlara bağlı olmadığını doğruladıktan sonra yalnızca desteklenen database interface üzerinden kaldırın.

Read-only PostgreSQL kullanıcıları nasıl çalışır?

Ek read-only kullanıcılar; analytics, support investigation, preview deployment’ları ve yazma işlemi yapmadan sorgulaması gereken araçlar için kullanışlıdır.

Kullanıcıları listeleyin:

dockup db users production/main-db --json

Bir kullanıcıyı label ile oluşturun:

dockup db user-add production/main-db \
  --label analytics \
  --json

Oluşturma sırasında üretilen credential’ı güvenli şekilde kaydedin ve bir agent response içinde yeniden paylaşmayın. Amacı sona erdiğinde ek kullanıcıyı desteklenen database user-management interface üzerinden revoke edin.

Database permission layer’daki read-only erişim, bir query tool’a “yazma” demekten daha güçlüdür. Yine de okunabilir production verilerine erişim sağlar; bu nedenle privacy ve least-privilege kuralları geçerlidir.

Dockup, private-networking project’inde bir PR veya branch preview için otomatik olarak read-only database user oluşturur. Preview, aynı production database’ine <slug>.internal üzerinden erişebilir ve write permission almadan veri okuyabilir.

Boyut, loglar ve yerleşim nasıl izlenir?

Disk üzerindeki boyutu inceleyin:

dockup db size production/main-db --json

Password veya tam connection string bilgilerini açığa çıkarmadan connection failure’ları görmek için application runtime log’larını inceleyin:

dockup logs production/api --json

Database maintenance, bağlı servisleri kullanılamaz hâle getirebilir. State-changing operation’ları planlayın, açık operational approval alın ve işlem öncesinde etkisini bildirin.

Database’i target node ID ile node’lar arasında taşıyın:

dockup db migrate production/main-db \
  --node <nodeId> \
  --json

Migration stateful bir işlemdir. Backup status’ünü, maintenance beklentilerini, private-network connection’larını ve taşıma sonrasında yapılacak application check’lerini doğrulayın.

Managed PostgreSQL production checklist

Eksiksiz bir runbook aşağıdakileri kaydeder:

Alan	Gerekli kanıt
Identity	Tam project/db target’ı
Connectivity	Secret connection string ve test edilmiş fresh session
Network	Public, private veya private-only policy
Access	Application role ve label verilmiş read-only kullanıcılar
Capacity	Güncel boyut ve growth review
Backups	Güncel backup ID’leri ve retention
Recovery	Başarılı restore drill
Operations	Start, stop, restart ve migration approval
Audit	Database mutation’larının bir actor ile izlenebilir olması

Application deployment rollback, PostgreSQL’i restore etmez. Database restore da application code’u otomatik olarak rollback etmez. İkisini yalnızca schema compatibility gerektiriyorsa koordineli şekilde uygulayın.

Daha kapsamlı scaling kararları için database scaling strategies içeriğini okuyun. Tam command listesi için Dockup CLI reference sayfasını kullanın.

Deploy ve rollback için schema migration’larını tasarlayın

Application deployment ve database schema change farklı zaman çizelgelerinde gerçekleşir. Güvenli bir migration genellikle en az bir release window boyunca backward compatible olmalıdır: bir nullable column ekleyin, bunu zorunlu hâle getirmeden önce code’u her iki schema’yı da destekleyecek şekilde deploy edin, kontrollü bir process ile backfill yapın ve eski yapıyı daha sonra kaldırın.

Bir health check’in uzun süren bir migration çalıştırmasına izin vermeyin. Uygulama birden fazla replica başlatıyorsa değişikliğin sahibi olabilecek yalnızca bir migration runner bulunduğundan emin olun. PRO container exec command’ı tek seferlik bir command çalıştırabilir ve gerçek exit code’unu aktarabilir:

dockup exec "npm run migrate" \
  -s production/api \
  --json

Bunu yalnızca migration command incelenmişse ve servis desteklenen main server üzerinde çalışıyorsa kullanın. stdout, stderr ve exit code bilgilerini kaydedin. Başarılı bir application deploy, başarısız bir migration’ın göz ardı edilebileceği anlamına gelmez.

Database credentials’ı kesinti olmadan rotate edin

Yeni credential veya read-only user oluşturun, consuming service secret’ını güncelleyin, eski credential’ı revoke etmeden önce redeploy yapın ve fresh connection’ı doğrulayın. Mevcut connection pool’ları, yeniden bağlanana kadar yeni password’deki hatayı gizleyebilir.

Primary application credential için desteklenen Dockup interface’ini ve database policy’yi kullanın. Ek bir analytical user için label verilmiş bir read-only account oluşturun ve yalnızca onaylanmış consumer’a dağıtın.

Rotation record; user label’ını, consuming service’leri, deployment ID’lerini, verification query’sini, revocation time’ını ve audit event’ini listelemelidir—password’ü asla listelemeyin.

Scaling öncesinde growth’u gözlemleyin

Database size tek başına bir sinyaldir:

dockup db size production/main-db --json

Bu veriyi application query latency, connection count, cache behavior, backup duration ve storage growth ile birlikte değerlendirin. Daha yüksek CPU veya memory allocation, eksik index’leri ya da sınırı olmayan query’leri düzeltmeyebilir.

Node’ları taşımadan veya kaynakları artırmadan önce database scaling strategies içeriğini inceleyin. Managed PostgreSQL provisioning işini azaltır; ancak schema ve query design hâlâ uygulamanın sorumluluğundadır.

Availability ile correctness’ı birbirinden ayırın

Çalışan bir database container’ı PostgreSQL’in kullanılabilir olduğunu kanıtlar; application query’lerinin doğru olduğunu değil. Post-deploy verification sürecine düşük riskli bir fresh connection ve temsili bir read işlemi ekleyin. Bir write test’i için güvenle silinebilecek özel bir transaction veya test record’ı kullanın.

Managed PostgreSQL runbook’unda replica’ların, analytics user’larının, preview’ların veya background worker’ların ek connection pressure oluşturup oluşturmadığı da belirtilmelidir.

PostgreSQL erişimini düzenli olarak gözden geçirin

Ek kullanıcıları listeleyin, her label’ın aktif bir owner’a sahip olduğunu doğrulayın ve artık kullanılmayan account’ları kaldırın. Bu basit review, preview, analytics project’i veya support investigation sona erdikten sonra managed PostgreSQL read erişiminin birikmesini önler.

Doğrulanabilir bir deployment ile başlayın

Production’a geçmeden önce non-production bir PostgreSQL database oluşturun, masked secret üzerinden bir test service’i bağlayın, backup alın ve restore drill’i tamamlayın.

app.dockup.ai’da ücretsiz başlayın. Free plan aylık $0’dır; başlangıçta $10 kredi içerir ve bir workspace, üç database ve üç deployment destekler.

SSS

Dockup hangi managed database türlerini destekler?

Dockup; PostgreSQL, MySQL, MongoDB ve Redis managed database’lerini destekler.

Bir uygulama PostgreSQL connection string’ini nasıl almalıdır?

Connection string’i secret bir environment variable olarak değerlendirin, tam olarak ilgili service üzerinde ayarlayın ve yeni container’ın bu değeri alması için redeploy edin.

Dockup read-only bir PostgreSQL user oluşturabilir mi?

Evet. Database user-add command’ı ek bir read-only user oluşturur ve password’ünü oluşturma sırasında bir kez döndürür.

Dokümante edilmiş bir dockup db restore CLI command’ı var mı?

Mevcut CLI reference böyle bir command dokümante etmemektedir. Dockup, backup restore işlemini platform interface üzerinden destekler; bu nedenle flag veya command uydurmak yerine desteklenen yolu kullanın.

Application rollback PostgreSQL database’ini restore eder mi?

Hayır. Application deployment history ile database backup history ayrı recovery system’leridir ve schema değişiklikleri her ikisini de gerektiriyorsa koordineli şekilde yönetilmelidir.