Dockup’ta Özel Alan Adı ve Otomatik TLS

Özel alan adı ve otomatik TLS kurulumu üç ayrı katmandan oluşur: Dockup service sağlıklı durumda olmalı, DNS hostname’i platforma yönlendirmeli ve sertifika yayınlanmadan önce hostname doğrulamadan geçmelidir. Bu katmanları birbirinden ayrı ele almak cutover sürecini öngörülebilir hâle getirir ve DNS hatalarının application hatası gibi görünmesini önler.

Dockup ayrıca her service için bir *.dockup.tech adresi sağlar. DNS propagation süresince bu adresi erişilebilir tutarak application’ı custom hostname’den bağımsız şekilde test edebilirsiniz.

Dockup’a özel alan adı eklemeden önce neler hazır olmalı?

Öncelikle çalışır durumda olan ve readiness gate’i geçen bir service ile başlayın:

dockup status production/web --json
dockup health production/web --json

Mevcut *.dockup.tech URL’sini açın veya test edin. Application burada çalışmıyorsa alan adı eklemek sorunu çözmez. Önce runtime loglarını inceleyin.

Aşağıdaki bilgileri toplayın:

Öğe	Örnek	Neden önemli?
Tam hedef	production/web	Alan adının yanlış service’e bağlanmasını önler
Hostname	app.example.com	Kullanıcıların ziyaret edeceği DNS adı
DNS erişimi	Registrar veya DNS sağlayıcısı	Kaydı oluşturmak için gereklidir
Mevcut TTL	300 saniye	Propagation ve rollback hızını belirler
Application canonical URL’si	https://app.example.com	Redirect ve cookie davranışlarını etkileyebilir
Health route’u	/health	Cutover öncesinde service’i doğrular

Canlı bir provider’ı değiştirirken mevcut DNS TTL değerini önceden düşürün. Dockup hedefi, application configuration ve rollback planı netleşmeden eski kaydı silmeyin.

Host’a bağlı application davranışlarını gözden geçirin. Authentication callback’leri, CORS allowlist’leri, cookie domain’leri, OAuth redirect URL’leri, webhook hedefleri ve oluşturulan absolute link’ler yeni HTTPS hostname’ini gerektirebilir.

Alan adını nasıl ekleyip doğrularsınız?

Önce mevcut alan adlarını listeleyin:

dockup domain list production/web --json

Hostname’i ekleyin:

dockup domain add app.example.com production/web --json

Response, yapılandırılması gereken DNS hedefini içerir. DNS provider’da belirtilen CNAME kaydını oluşturun. Bir IP adresi uydurmayın veya başka bir service’ten değer kopyalamayın; bu domain için döndürülen hedefi kullanın.

DNS propagation tamamlandıktan sonra döndürülen domain ID ile doğrulama yapın:

dockup domain verify <domainId> production/web --json

Doğrulama, public DNS kaydının gereken şekilde çözümlendiğini kanıtlar. Hata genellikle şu dört durumdan birine işaret eder:

1. Kayıt adı yanlış.
2. CNAME hedefi yanlış.
3. Eski ve çakışan bir A, AAAA veya CNAME kaydı hâlâ mevcut.
4. Resolver cache’leri yeni değere henüz ulaşmadı.

Alan adını tekrar tekrar silip oluşturmak yerine authoritative DNS’i kontrol edin. Propagation, Dockup build süreci değil, dağıtık bir cache sürecidir.

HTTPS sertifikası nasıl yayınlanır ve yönetilir?

Doğrulama başarılı olduktan sonra sertifikayı isteyin:

dockup domain ssl <domainId> production/web --json

Dockup, doğrulanmış hostname için sertifika yayınlama işlemini yönetir ve custom domain’i HTTPS üzerinden sunar. Platform TLS lifecycle’ını yönettiği için application container’ının sertifika dosyalarını saklaması veya sertifika yenileme süreci çalıştırması gerekmez.

Sonucu platform dışından doğrulayın:

curl -I https://app.example.com

Şunları doğrulayın:

• Sertifika hostname ile eşleşiyor.
• Response HTTPS üzerinden sunuluyor.
• Redirect’ler döngüye girmiyor.
• Application beklenen status’u döndürüyor.
• Authentication ve callback akışları yeni origin’i kullanıyor.
• Static asset’ler mixed-content hataları olmadan yükleniyor.

Application’ın kendisi sağlıklı olsa bile sertifika yayınlama işlemi başarısız olabilir. DNS ve service tanılamasını birbirinden ayrı tutun. DNS sahipliği için domain verify, application davranışı için service log’larını kullanın.

Zero-downtime deployment’lar makalesi, bağımsız release readiness gate’ini açıklar.

Trafiği kesinti olmadan nasıl yönlendirirsiniz?

Güvenli bir cutover, yeni hostname doğrulanana kadar eski yolu erişilebilir tutar.

1. Dockup service’ini platform URL’sinde deploy edip doğrulayın.
2. Custom domain’i Dockup’a ekleyin.
3. DNS kaydını oluşturun.
4. DNS’i doğrulayın.
5. TLS’i yayınlayın.
6. HTTPS’i doğrudan test edin.
7. Callback’leri, canonical URL’leri ve monitoring ayarlarını güncelleyin.
8. DNS kurulumu izin veriyorsa operational trafiğin küçük bir bölümünü yönlendirin.
9. Log’ları ve uptime’ı gözlemleyin.
10. Eski provider’ı yalnızca yeni yol stabil olduktan sonra devreden çıkarın.

Dockup uptime kontrolleri her dakika çalışır ve p95 dahil response-time istatistiklerini raporlar:

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

Kritik domain’ler için bağımsız external monitoring kullanmaya devam edin. Platform probe’u public erişilebilirliği doğrularken external monitor, kullanıcı yolunu başka bir sistemden doğrular.

Custom domain mevcut bir production host’unun yerini alıyorsa rollback kaydı tutun: önceki DNS değeri, önceki TTL, eski provider durumu ve geri dönüşü tetikleyecek koşul.

Ek port alan adları nasıl çalışır?

Bir service, admin UI, metrics endpoint’i veya başka bir web process’i için ikinci bir HTTP port’u açabilir. Dockup, custom DNS gerektirmeden ek bir platform domain’i oluşturabilir:

dockup port list production/web --json
dockup port add 8080 production/web --name admin --json

Döndürülen domain, seçilen container port’una yönlendirilir. Bu, ana custom domain’den ayrıdır.

Bir process yalnızca port dinliyor diye o portu public hâle getirmeyin. Endpoint’in authentication’a sahip olup olmadığını, production data içerip içermediğini ve gerçekten public olması gerekip gerekmediğini değerlendirin. Yalnızca internal olması gereken bir admin interface, kolaylık amacıyla internet’e açılmamalıdır.

Kullanımdan kalkmış bir port domain’ini, hiçbir monitor, callback veya operator workflow’unun artık kullanmadığını doğruladıktan sonra yalnızca desteklenen domain interface üzerinden kaldırın. Port-domain değişiklikleri mutation işlemidir ve audit log’da görünür.

DNS, TLS ve application hatalarını nasıl giderirsiniz?

Katman katman tanılama yapın:

Belirti	İlk kontrol	Dockup komutu
Domain çözümlenmiyor	DNS kaydı ve propagation	domain verify
Sertifika yayınlanmadı	Domain doğrulama durumu	domain list, domain ssl
HTTPS çalışıyor ancak application hata veriyor	Runtime log’ları	logs --json
Redirect döngüsü	Application proxy/host ayarları	env list, runtime log’ları
Platform URL’si çalışıyor, custom host çalışmıyor	DNS/TLS katmanı	Domain komutları
Her iki URL de çalışmıyor	Deployment ve runtime	status, build/runtime log’ları
İkincil port çalışmıyor	Port-domain mapping ve process	port list, runtime log’ları

DNS ile ilgili sonuçları karıştırmadan service çıktısını inceleyin:

dockup logs production/web --json
dockup status production/web --json

Yakın zamanda yapılan bir environment değişikliği canonical URL’yi eklediyse bunun redeploy gerektirdiğini unutmayın:

dockup env set APP_URL=https://app.example.com \
  -s production/web \
  --json

dockup deploy production/web --wait --json

Environment variables ve secrets rehberi bu lifecycle’ı açıklar.

Domain kaldırma ve rollback

Dockup association’ını kaldırmak route için destructive bir işlemdir. Bu nedenle önce public DNS kaydını taşıyın veya kaldırın ve amaçlanan replacement’ı doğrulayın. Ardından tam domain ID’yi kullanarak association’ı desteklenen domain interface üzerinden kaldırın.

Recovery planı gerektirmediği sürece geçici bir sertifika veya propagation sorunu sırasında domain’i kaldırmayın. Configuration’ı yerinde tutmak, cache’ler güncellendiğinde doğrulamanın başarılı olmasını sağlar.

Mutation’ları şu komutla inceleyin:

dockup audit --search domains --json

Audit trail, hostname’i kimin eklediğini, doğruladığını, güvenli hâle getirdiğini veya kaldırdığını göstermelidir.

Production handoff checklist’i

Eksiksiz bir özel alan adı ve otomatik TLS handoff’u service hedefini, hostname’i, domain ID’yi, DNS kayıt türünü ve hedefini, doğrulama sonucunu, sertifika sonucunu, application callback değişikliklerini, monitoring URL’sini ve rollback DNS değerini içerir.

Sertifika private key’ini repository’de veya container’da saklamayın. Dockup’ın managed TLS sınırı tam olarak application ekibinin sertifika materyalini dağıtmadan hostname’i yönetebilmesi için vardır.

Mevcut flag’lerin tamamı için Dockup CLI reference sayfasını kullanın. Domain işlemlerinden önceki ilk deployment için Git repository’den production’a rehberini izleyin.

Apex ve subdomain tercihlerini planlayın

app.example.com gibi bir subdomain, DNS provider’ları bunu CNAME ile temsil edebildiği için genellikle en basit application hostname’idir. example.com gibi bir apex, provider’a özel flattening veya alias davranışı gerektirebilir. Dockup tarafından döndürülen DNS hedefini ve authoritative DNS provider’ın yeteneklerini izleyin.

Bir canonical host seçin ve alternatifleri application veya routing katmanında redirect edin. Canonical policy olmadan hem www hem de apex’i sunmak cookie’leri, analytics verilerini, cache entry’lerini ve search indexing’i bölebilir.

Sertifika yenileme varsayımlarını test edin

Managed TLS, container içinde renewal client çalıştırma gereksinimini ortadan kaldırır; ancak hostname’in doğru şekilde çözülmeye devam etmesi gerekir. Gelecekte yapılacak bir DNS migration, proxy değişikliği veya silinen kayıt validation sürecini bozabilir.

Rutin kontrollerinize domain durumunu dahil edin:

dockup domain list production/web --json
dockup uptime production/web --hours 24 --json

Özel alan adı ve otomatik TLS runbook’u DNS sahibini, renewal contact’ını ve son external certificate check tarihini belirtmelidir. Böylece sahiplik yalnızca bir sertifika incident’ı sırasında keşfedilmez.

Non-production hostname’lerini koruyun

Staging ve preview hostname’leri tamamlanmamış özellikleri ve production’a benzeyen data’yı açığa çıkarabilir. Gerektiğinde application authentication kullanın, application katmanında bir indexing policy tanımlayın ve non-production URL’lerinin dağıtımını kısıtlayın.

Search engine directive’leri access control değildir. Korunan bir environment’ın yine authentication’a ve uygun data yönetimine ihtiyacı vardır.

Propagation sonrasında tekrar kontrol edin

İlk DNS TTL süresi tamamen dolduktan sonra external HTTPS ve callback testlerini tekrarlayın.

Doğrulanabilir bir deployment ile başlayın

Önce kritik olmayan bir hostname bağlayın, propagation süresince platform URL’sini koruyun ve rollback için gereken tam DNS değerini kaydedin.

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

SSS

Dockup custom domain’i için hangi DNS kaydı gerekir?

dockup domain add komutunu çalıştırın ve response’unda gösterilen DNS kaydını oluşturun. Başka bir service’ten değer kopyalamak yerine döndürülen hedefi kullanın.

Dockup custom domain için ne zaman TLS yayınlayabilir?

Hostname’in DNS kaydı Dockup domain doğrulamasından geçtikten sonra, dokümante edilen domain ssl komutuyla sertifika yayınlama isteğinde bulunabilirsiniz.

Container’ımın TLS sertifikalarını saklaması gerekir mi?

Hayır. Dockup, doğrulanmış custom domain için TLS’i yönetir; bu nedenle application container’ının sertifika dosyalarına veya renewal process’ine ihtiyacı yoktur.

Dockup ek bir container port’u açabilir mi?

Evet. Port komutları, custom DNS gerektirmeden ek bir public port için ayrı, otomatik oluşturulan bir domain sağlayabilir.

Platform URL’si çalışıyor ancak custom domain başarısız oluyorsa neyi kontrol etmeliyim?

DNS kayıtlarına, propagation’a, domain doğrulamasına ve sertifika durumuna odaklanın. Sağlıklı platform URL’si, application katmanının büyük olasılıkla çalıştığını gösterir.