Dockup'ta Private Networking ve .internal Alan Adları

Private networking, tek bir Dockup projesindeki hizmetlerin ve yönetilen veritabanlarının aynı proje içindeki trafiği public internet üzerinden göndermeden iletişim kurmasını sağlar. Her kaynak sabit bir <slug>.internal hostname alırken, ayrı projeler birbirinden izole kalır.

Ağ isteğe bağlıdır. Etkinleştirildiğinde mevcut proje kaynaklarını bağlar; uygulama trafiğinin hemen bu ağı kullanmaya başlamasını gerektirmez ve hizmetler redeploy sonrasında internal bağlantı değişkenlerini alır.

Service-to-service networking public erişimi nasıl azaltır?

Public bir veritabanı endpoint'i, authentication yetkisiz kullanımı engellese bile internet üzerinden erişilebilir durumdadır. Private bir route, uygulama trafiğinin internet üzerindeki erişimini kaldırır ve hizmetlere public bir adrese bağlı olmayan sabit bir internal ad verir.

Aynı ilke service-to-service çağrıları için de geçerlidir. Bir API; bir worker'ı, internal admin hizmetini veya backend'i public bir custom domain üzerinden değil, proje ağı üzerinden çağırabilir.

Trafik yolu	Public route	Private route
API'den PostgreSQL'e	Public host ve port	main-db.internal
Web'den API'ye	Public custom domain	api.internal
Worker'dan Redis'e	Public host ve port	app-redis.internal
Preview'dan production DB'ye	Public DB credential	Salt okunur internal kullanıcı
Projeler arası çağrı	Public endpoint gerekli	Proje izolasyonu tarafından engellenir

Private, authentication gerektirmediği anlamına gelmez. Database kullanıcılarını, service authorization mekanizmalarını ve secret'ları kullanmaya devam edin. Ağ erişilebilirliği belirler; credential'lar izni belirler.

Proje private networking özelliğini nasıl etkinleştirirsiniz?

Ağı proje slug'ı için etkinleştirin:

dockup network enable production --json

Bu işlem, hizmetleri ve yönetilen veritabanlarını proje ağına bağlar. Mevcut public listener'lar varsayılan olarak kullanılabilir durumda kalır; böylece geçiş kademeli olarak yapılabilir.

Internal environment variable'ları alması gereken her application service'i redeploy edin:

dockup deploy production/api --wait --json
dockup deploy production/worker --wait --json

Dockup; DATABASE_URL_INTERNAL, veritabanına özel internal URL ve host değişkenleri ile service host/port değerleri gibi bağlantı bilgilerini inject eder. Secret'ları açığa çıkarmadan service environment key'lerini inceleyin:

dockup env list -s production/api --json

Bir URL'yi görünen addan yola çıkarak manuel olarak oluşturmayın. <slug>.internal hostname'ini resource slug'ları belirler.

Uygulama config'ini değiştirmeden önce her dependency'nin aynı proje içinde bulunduğunu doğrulayın. Ayrı projelerin ayrı ağları vardır ve internal path üzerinden birbirlerini resolve edemez veya birbirlerine erişemezler.

.internal alan adları service configuration'ını nasıl değiştirir?

Internal DNS, container'lar ve node'lar arka planda değişse bile sabit bir ad sağlar. api slug'ına sahip bir API service, aynı projedeki hizmetler tarafından api.internal adresi üzerinden erişilebilir durumdadır; main-db slug'ına sahip bir veritabanına ise main-db.internal üzerinden erişilebilir.

Mevcut olduğunda inject edilen connection variable'ları tercih edin. Bu değişkenler doğru protocol'ü, credential'ları, veritabanı adını ve host formatını içerir. Manuel oluşturulmuş bir string; TLS'i, password encoding'i veya veritabanı parametrelerini atlayabilir.

Her seferinde tek bir dependency'yi taşıyın:

1. Ağı etkinleştirin.
2. Tüketen service'i redeploy edin.
3. Internal variable'ın mevcut olduğunu doğrulayın.
4. Uygulamayı bu değişkeni kullanacak şekilde değiştirin.
5. --wait ile deploy edin.
6. Yeni bağlantıları doğrulayın.
7. Runtime log'larını ve response time'ı gözlemleyin.
8. Sonraki dependency'ye geçin.

Bir service, kullanıcı trafiği için public custom domain'ini korurken backend çağrıları için private hostname'leri kullanabilir. Public ve private path'ler farklı trust boundary'lerine hizmet eder.

Environment variable'lar ve secret'lar rehberi, bağlantı değişikliklerinin neden redeploy gerektirdiğini açıklar.

Yönetilen bir veritabanını yalnızca private olacak şekilde nasıl yapılandırırsınız?

Gerekli tüm consumer'lar internal path'i kullanmaya başladıktan sonra public listener'ı kaldırın:

dockup db private production/main-db --json

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

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

Bu veritabanı işlemi, verileri koruyarak container'ı yeniden oluşturur. İş yüküne uygun bir maintenance window planlayın, yakın tarihli bir backup bulunduğunu doğrulayın ve uygulamanın yeniden bağlantı kurmasını test edin.

Yalnızca private hale getirmeden önce şunları kontrol edin:

• Veritabanını kullanan her production service aynı proje içinde.
• Operasyon araçları public endpoint'e ihtiyaç duymuyor.
• Preview erişimi desteklenen private path'i kullanıyor.
• Bir backup mevcut ve recovery süreci anlaşılmış durumda.
• Connection pool'lar güvenli şekilde retry ediyor.
• Tam project/db hedefi kaydedilmiş durumda.

Yalnızca private olan bir veritabanına operator laptop'ından public internet üzerinden doğrudan erişilemez. Listener'ı dikkatsizce yeniden açmak yerine desteklenen platform erişimini ve application-level diagnostics yöntemlerini kullanın.

Veritabanı işlemleri için managed PostgreSQL sayfasına bakın.

PR preview'ları production verilerine güvenli şekilde nasıl erişir?

Her Dockup PR veya branch preview'ı kendi izole deployment'ını ve URL'sini alır. Private networking kullanılan bir projede preview, proje ağına katılır ve <slug>.internal adresini resolve edebilir.

Dockup, preview tarafından kullanılan production managed database için otomatik olarak salt okunur bir kullanıcı oluşturur. Preview, production yapısındaki verileri sorgulayabilir ancak bu kullanıcı üzerinden yazma işlemi gerçekleştiremez.

Bu tasarım, bir feature branch'in customer record'larını değiştirme riskini azaltır; ancak read access'in de sonuçları vardır:

• Kişisel veya hassas veriler preview'da görünebilir.
• Yeni uygulama kodu sorgulanan verileri log'layabilir.
• Güvenlik açığı bulunan bir preview URL'si, sorgu sonuçlarını açığa çıkarabilir.
• Pahalı sorgular production yükünü etkileyebilir.
• Schema varsayımları branch ile production arasında farklı olabilir.

Preview deployment'ını yalnızca gözden geçirilmiş bir policy kapsamında etkinleştirin:

dockup pr-preview production/api --on --json
dockup preview branch feature/search production/api --json

Feature flag'ler ve database dışı secret'lar için preview'ın izole environment'ını kullanın. Otomatik oluşturulan salt okunur credential'ı production write credential'ı ile değiştirmeyin.

Private networking nasıl gözlemlenmeli ve sorunları nasıl giderilmelidir?

Bir platform kesintisi varsaymak yerine topology ve configuration ile başlayın.

Belirti	Olası alan	Kontrol
Ad bulunamadı	Yanlış slug/proje veya service redeploy edilmemiş	Service listesi ve env key'leri
Connection refused	Kaynak durmuş veya port yanlış	Status ve DB/service log'ları
Authentication failed	Yanlış credential	Secret rotation ve kullanıcı
Public çalışıyor, private çalışmıyor	Internal variable veya network adoption sorunu	Network enable, redeploy
Preview okuyabiliyor ancak yazamıyor	Beklenen salt okunur policy	Credential'ı değiştirmeyin
Projeler arası çağrı başarısız	Beklenen izolasyon	Public ve authenticated API kullanın

Application runtime log'larını inceleyin:

dockup logs production/api --json

Veritabanı boyutunu ve uygulamanın bağlantı hatalarını inceleyin:

dockup db size production/main-db --json
dockup logs production/api --json

Incident notlarına full internal connection URL'lerini yazdırmayın. Hostname'in kendisi secret olmasa da bu URL'ler credential içerebilir.

Migration ve rollback planı

İlk aşamada public listener'ı açık tutun. Internal deployment başarısız olursa uygulamanın önceki configuration'ını geri yükleyip redeploy edin. Veritabanını yalnızca private hale getirmeden önce internal path'in kararlı olduğundan emin olun.

Tüm proje ağını devre dışı bırakmak için:

dockup network disable production --json

Bu işlem, ilk troubleshooting adımı değil, bilinçli bir rollback olmalıdır. Ağı devre dışı bırakmak projedeki bağlı tüm kaynakları etkiler.

Network mutation'larını audit log üzerinden kaydedin:

dockup audit --writes --json

Production için private networking checklist'i

Eksiksiz bir private networking runbook'unda proje slug'ı, service ve database slug'ları, internal hostname'ler, inject edilen variable adları, public-listener policy'si, preview erişim policy'si, backup durumu, redeployment sırası ve rollback yolu yer alır.

CPU, RAM ve disk kullanıma dayalı olarak ölçülmeye ve dakika başına ücretlendirilmeye devam eder; private routing bir architecture choice'tur, sabit bir instance class değildir. Maliyet modellemesi için PaaS pricing explained sayfasını kullanın.

Güncel Dockup CLI referansı, mevcut network ve database komutlarını içerir. Genel deployment isolation için security best practices sayfasına bakın.

Service authorization'ı reachability'den ayrı modelleyin

Bir internal hostname yalnızca çağrıyı yapan tarafın proje ağında olduğunu kanıtlar. İsteği hangi service'in yaptığını veya bu service'in işlemi gerçekleştirme yetkisine sahip olup olmadığını kanıtlamaz. Hassas internal API'ler için application authentication'ı, data access için de database credential'larını koruyun.

Tek bir ortak internal token yerine service'e özel secret'lar kullanın. Bir preview salt okunur database access alıyorsa, ona API üzerinden write işlemlerini tetikleyebilecek bir production service token'ı da vermeyin.

Cutover etkisini ölçün

Internal endpoint'lere geçişten önceki ve sonraki connection latency, error rate ve p95 response time değerlerini karşılaştırın. Temel hedef isolation ve kararlı bir private path sağlamaktır; latency iyileşmesi vaat edilmek yerine ölçülmelidir.

dockup uptime production/api --hours 24 --json

Observation window'u ve deployment ID'sini saklayın. Böylece private networking değişikliği “DNS çözümlendi” noktasında sona ermek yerine ölçülebilir bir tamamlanma kriterine sahip olur.

Public-path istisnasını belgeleyin

Bazı external integration'lar, operator araçları veya cross-project service'ler hâlâ public endpoint gerektirebilir. Her istisnayı; authentication yöntemi, sahibi ve kaldırılma koşuluyla birlikte listeleyin. Bu, neden var olduğunu kimsenin hatırlamaması nedeniyle public listener'ın süresiz olarak açık kalmasını önler.

Eksiksiz bir private networking rollout'u kısmi olabilir; ancak her public path bilinçli olarak tanımlanmalıdır.

Yeniden adlandırmalardan sonra internal dependency'leri gözden geçirin

Bir kaynağın yeniden adlandırılması veya değiştirilmesi, .internal adreslemesinde kullanılan slug'ı değiştirebilir. Adları değiştirmeden önce consumer'ları envanterleyin, güncellenmiş inject edilmiş variable'larla redeploy edin ve her private bağlantıyı doğrulayın.

Bu yaklaşım, proje geliştikçe private networking yapısının kararlı kalmasını sağlar.

Doğrulanabilir bir deployment ile başlayın

Production olmayan bir projede networking'i etkinleştirin, bir dependency'yi .internal endpoint'ine taşıyın ve herhangi bir public listener'ı kaldırmadan önce rollback yolunu doğrulayın.

app.dockup.ai'de ücretsiz başlayın. Free plan aylık $0'dır, başlangıç kredisi olarak $10 içerir ve bir workspace, üç database ve üç deployment desteği sunar.

SSS

Dockup kaynakları private network'te hangi hostname'i kullanır?

Aynı projedeki her service ve yönetilen database, <slug>.internal biçimindeki sabit bir hostname üzerinden erişilebilir.

Private networking'i etkinleştirmek public database erişimini kaldırır mı?

Hayır. Ağ varsayılan olarak ek bir erişim katmanı sağlar. Consumer'lar internal path'i kullanmaya başladıktan sonra public listener'ı kaldırmak için ayrı database private komutunu kullanın.

Farklı Dockup projeleri birbirlerine private olarak erişebilir mi?

Hayır. Her projenin izole bir ağı vardır; bu nedenle projeler arası iletişim uygun bir public ve authenticated interface kullanmalıdır.

Bir PR preview production database'e yazabilir mi?

Private-networking kullanılan bir projede Dockup, preview için otomatik olarak salt okunur bir database kullanıcısı oluşturur. Bu kullanıcı okumaya izin verir ancak yazma işlemlerini engeller.

Networking etkinleştirildikten sonra hizmetler neden redeploy edilmelidir?

Redeployment, yeni container'a internal connection variable'larını verir ve uygulamanın private endpoint configuration'ı ile başlamasını sağlar.