Dockup'ta Ortam Değişkenleri ve Gizli Bilgiler

Ortam değişkenleri ve gizli bilgiler, uygulama kodunu production yapılandırmasına bağlar; ancak bunların ifşa ve yaşam döngüsü gereksinimleri farklıdır. Herkese açık bir API base URL'sinin loglarda gösterilmesi güvenli olabilir; veritabanı parolası veya imzalama anahtarı için aynı şey geçerli değildir. Dockup bu ayrımı açıkça temsil eder ve depolanan gizli bilgi değerlerini okuma çıktısında maskeler.

Yapılandırma değişiklikleri ayrıca yeniden dağıtım gerektirir. Yeni bir değer ayarlamak, hedeflenen servis yapılandırmasını günceller; ancak hâlihazırda çalışan process başlangıçta aldığı ortamı kullanmaya devam eder.

Değişken ile gizli bilgi arasındaki fark nedir?

Her iki değer de uygulama process'ine ortam verisi olarak girer; ancak operasyonel olarak farklı şekilde ele alınır.

Tür	Örnek	Okuma çıktısında görünebilir mi?	Önerilen kullanım
Düz değişken	NODE_ENV=production	Evet	İncelenebilir yapılandırma
Düz değişken	PUBLIC_API_URL=https://...	Evet	dockup.yaml içinde bulunabilir
Gizli bilgi	DATABASE_URL=postgres://...	Depolanan değer gösterilmez	Gizli bilgi komutu veya CI store
Gizli bilgi	JWT_SIGNING_KEY=...	Depolanan değer gösterilmez	Döndürün ve erişimi kısıtlayın
Gizli bilgi	DOCKUP_TOKEN=...	Gerekli olmadıkça uygulama yapılandırması olarak asla saklamayın	Process seviyesinde kimlik doğrulama

Bir değerin açığa çıkması erişim, kimliğe bürünme, şifre çözme, imzalama veya yatay hareket olanağı sağlayacaksa bu değeri gizli bilgi olarak işaretleyin. “Frontend zaten bunu içeriyor” ifadesi, değerin gizli bilgi değil, herkese açık yapılandırma olduğunu gösterir.

Gizli bilgileri source control'a, dockup.yaml dosyasına, örnek çıktılara, ekran görüntülerine, agent prompt'larına veya issue açıklamalarına koymayın. Redakte edilmiş bir placeholder, gerçekçi görünen bir token'dan daha güvenlidir; çünkü kopyalanan örnekler zamanla production uygulamasına dönüşebilir.

Ortam yapılandırmasını nasıl ayarlar ve incelersiniz?

Tam hedef için mevcut anahtarları listeleyin:

dockup env list -s production/api --json

Yanıt her anahtarı, gizli bilgi olup olmadığını ve yalnızca korunmayan değerler için değerin kendisini içerir.

Sıradan bir değişken ayarlayın:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

Mevcut shell ortamından bir gizli bilgi ayarlayın:

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

Artık kullanılmayan bir değeri kaldırın:

dockup env remove OLD_FEATURE_FLAG \
  -s production/api \
  --json

Bir .env tarzı dosyayı toplu olarak içe aktarın:

dockup env import .env.production \
  -s production/api \
  --json

İçe aktarılan her değerin gizli bilgi olarak değerlendirilmesi gerektiğinde import işleminde --secret kullanın. Karışık dosyaların incelenmesi daha zordur ve çoğu zaman zararsız yapılandırmaların gereğinden fazla sınıflandırılmasına veya kimlik bilgilerinin yeterince sınıflandırılmamasına yol açar. Mümkün olduğunda bunları ayırın.

Komutların güncel kapsamı Dockup CLI referansında korunur.

Yapılandırma değişikliklerinden sonra neden yeniden dağıtım gerekir?

Ortam değişkenleri bir process başlatıldığında okunur. Platform yapılandırmasının güncellenmesi, çalışan bir Node.js, Python, Go veya başka bir process'in belleğini değiştirmez. Servis, yeni ortamla yeni bir container başlatmalıdır.

Doğru sıra şöyledir:

dockup env set FEATURE_FLAG=on \
  -s production/api \
  --json

dockup deploy production/api --wait --json

--wait ikinci adımın doğrulanabilmesini sağlar. Varsayılan timeout 900 saniyedir; çıkış 0 başarı anlamına gelir, hatalar ise yapılandırılmış kodlarla sıfır olmayan bir değer döndürür.

Dockup'ın zero-downtime blue-green süreci yeni sürümü başlatır, health gate'i uygular ve trafiği ancak bundan sonra yönlendirir. Böylece mevcut container, doğrulanmamış bir yapılandırmayla yerinde yeniden başlatılmaz.

Bir gizli bilgi döndürme işlemi hem producer'ı hem de consumer'ı değiştiriyorsa uyumluluğu planlayın. Uygulama yeni değeri almadan önce veritabanı parolasını döndürmek kesintiye neden olabilir. Harici sistem izin verdiğinde bir overlap süresi, dual-key desteği veya sıralı değişiklik kullanın.

Dağıtım mekanikleri zero-downtime deployments bölümünde açıklanır.

Gizli bilgilerin maskelenmesi agent riskini nasıl azaltır?

Coding agent'lar komut çıktılarını sık sık özetler. Depolanan gizli bilgileri döndüren bir araç, zararsız bir “mevcut yapılandırmayı göster” isteğini kimlik bilgilerinin açığa çıkmasına dönüştürür.

Dockup, gizli bilgi değerlerini maskeler. Agent DATABASE_URL anahtarının mevcut olduğunu ve gizli olarak işaretlendiğini görebilir; ancak depolanan bağlantı dizesini okuyamaz. Kullanıcı yeni bir değeri güvenli bir ortam üzerinden sağladığında agent bu değeri değiştirebilir.

Bu yaklaşım daha güvenli bir talimatı destekler:

Gerekli gizli bilgi anahtarlarının mevcut olduğunu doğrula, ancak değerlerini asla yazdırma. Bir değer değiştirilecekse yalnızca process ortamından oku ve gizli bilginin kendisi yerine anahtar adını döndür.

Gizli bilgi maskeleme diagnostic bilgilerine de uygulanmalıdır. Şunları kullanmaktan kaçının:

printenv

PRO exec komutu tek seferlik container komutlarını çalıştırabilse de agent transcript'inde bu kullanımdan kaçının. Bunun yerine değeri açığa çıkarmadan varlığı, uzunluk sınıfını veya bağlantı başarısını raporlayan hedefli bir uygulama kontrolü tercih edin.

AI agent production guardrails rehberi prompt ve tool sınırlarını birlikte ele alır.

Gizli bilgiler nasıl döndürülmeli ve denetlenmelidir?

Döndürme, metin düzenleme değil, kontrollü bir production değişikliğidir. Şu sırayı izleyin:

1. Yeni kimlik bilgisini sahibi olan sistemde oluşturun veya edinin.
2. Bu bilgiyi onaylı CI veya operator ortamında saklayın.
3. Yeni gizli bilgiyi değerini yazdırmadan Dockup'ta ayarlayın.
4. --wait ile dağıtım yapın.
5. Health durumunu ve uygulama davranışını doğrulayın.
6. Yeni sürüm etkinleştikten sonra eski kimlik bilgisini iptal edin.
7. Dockup audit log'unu inceleyin.
8. Değeri kaydetmeden döndürme tarihini ve sorumlusunu kayıt altına alın.

dockup audit --writes --json

Audit kanıtı, yapılandırmanın değiştiğini ve ardından bir dağıtım yapıldığını göstermelidir. Gizli bilgi değerini içermemelidir.

Veritabanı kimlik bilgileri için connection pool'larını dikkate alın. Yeni bağlantılar yeni parolayı kullanırken mevcut bağlantılar döndürme sonrasında da kimlik doğrulamasını koruyabilir. Doğrulama yalnızca eski bir pool tarafından sunulan istekleri değil, yeni bir bağlantıyı da içermelidir.

Yetkilendirilmiş API key'ler için oluşturma sırasında üretilen değeri güvenli biçimde alın. Değeri hemen onaylı secret system'e kaydedin, gerekli izinlerle sınırlandırın ve dağıtım çıktısında yeniden üretmeden döndürün.

Hangi yapılandırma politikası drift oluşmasını önler?

Her değerin hangi kaynağa ait olduğunu belirleyin:

Kaynak	Uygun içerik
Repository kodu	Ortama özel olmayan varsayılanlar
dockup.yaml	İncelenebilir düz dağıtım yapılandırması
Dockup secret değişkenleri	Runtime kimlik bilgileri
CI secret store	Dağıtım token'ı ve enjekte edilen döndürme değerleri
Managed database çıktısı	Tüketen servise aktarılan bağlantı verileri
Yerel .env	Git dışında tutulan, yalnızca geliştiriciye özel değerler

dockup.yaml apply varsayılan olarak additive çalışır. Dosyada bulunmayan düz ortam değerleri, --prune açıkça kullanılana kadar kalmaya devam eder ve gizli bilgiler bu yol üzerinden asla prune edilmez. Manifest cleanup kullanmaya başlamadan önce dockup.yaml config as code bölümünü inceleyin.

Ortamlar arasında tutarlı anahtar adları kullanın; ancak değerlerin birbiriyle değiştirilebileceğini varsaymayın. Bir staging anahtarı production erişimi vermemelidir. Private-networking projesindeki preview deployment'ları production verilerine erişim için otomatik olarak salt okunur bir database user alır; varsayılan olarak write credential'larını devralmamalıdır.

Sızan gizli bilgi için incident response

Bir gizli bilgi transcript'te, log'da, commit'te veya ekran görüntüsünde görünürse sonradan maskelemek yeterli değildir. Bu bilgiyi ele geçirilmiş kabul edin:

1. Kaynak sistemde iptal edin veya döndürün.
2. Dockup secret'ını güncelleyin.
3. Yeniden dağıtın ve doğrulayın.
4. Mümkün olan yerlerde açığa çıkan materyali kaldırın.
5. Kötüye kullanım için audit ve erişim log'larını arayın.
6. Nedeni ve önleme yönelik değişikliği belgeleyin.

Git geçmişini yeniden yazmak, gelecekte bulunabilirliği azaltabilir; ancak kopyalanmış bir kimlik bilgisinin ortadan kaldırıldığını kanıtlayamaz. Belirleyici işlem iptal etmedir.

Ortam inceleme checklist'i

Her production release'inden önce gerekli anahtarların mevcut olduğunu, gizli bilgi anahtarlarının secret olarak işaretlendiğini, hiçbir gizli bilginin commit edilmediğini, düz değerlerin hedeflenen ortamla eşleştiğini ve değişikliğin bir parçası olarak yeniden dağıtım yapıldığını doğrulayın. Ardından durumu ve uptime'ı kontrol edin:

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

Monitoring her dakika çalışır ve p95 response time bilgisini içerir. Başarılı bir yapılandırma dağıtımı yine de runtime regression'ları açısından izlenmelidir.

Servis oluşturma ve ilk kurulum için Git repository to production bölümünü izleyin.

Yapılandırmayı değerleri açığa çıkarmadan doğrulayın

Uygulamalar gerekli bir anahtar eksik olduğunda anlaşılır biçimde başarısız olmalıdır; ancak diagnostic çıktıları değeri yazdırmamalıdır. Bir startup check missing: ["DATABASE_URL"] veya invalid format: ["PUBLIC_URL"] gibi bir liste raporlayabilir ve ardından sıfır olmayan bir çıkış koduyla sonlanabilir.

İsteğe bağlı bir değer için fallback'i kodda tanımlayın ve bu fallback'in production'da güvenli olup olmadığını belgeleyin. Bir production anahtarının eksik olması nedeniyle sessiz development varsayılanları—yerel database host'ları, debug modları, izin verici CORS veya test credential'ları—etkinleşmemelidir.

Bu doğrulama, log'ları bir credential envanterine dönüştürmeden ortam değişkenlerini ve gizli bilgileri gözlemlenebilir kılar.

Birden çok servisi ve paylaşılan credential'ları bilinçli şekilde yönetin

Tek bir gizli bilgiyi birden çok servise kopyalamak, döndürme bağımlılığı oluşturur. Harici sistem destekliyorsa servise özel credential'ları tercih edin. Ele geçirilmiş bir worker token'ı, public API ile aynı erişimi vermemelidir.

Paylaşılan bir değer kaçınılmazsa sahibi ve tüketici listesini güncel tutun. Tüm tüketicileri koordineli bir zaman aralığında döndürün ve her yeniden dağıtımdan sonra yeni bağlantıları doğrulayın. Bir agent'tan, isim benzerliğine dayanarak “muhtemelen bu anahtarı kullanan tüm servisleri bulmasını” istemeyin; açık envanter ve audit kanıtı kullanın.

Private networking, veritabanı trafiğinin maruziyetini azaltabilir; ancak credential ihtiyacını ortadan kaldırmaz. Internal hostname'ler yolu, authentication ise veritabanını kimin kullanabileceğini kontrol eder.

Doğrulanabilir bir dağıtımla başlayın

Her anahtarı ayarlamadan önce sınıflandırın, gizli bilgi okumalarının maskelendiğini doğrulayın ve gerekli yeniden dağıtımı aynı incelenmiş değişikliğe dahil edin.

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 destekler.

SSS

Dockup depolanan gizli bilgi değerlerini döndürür mü?

Hayır. Gizli bilgi değerleri okuma çıktısında maskelenir. Operatörlerin gerekli yapılandırmanın mevcut olduğunu doğrulayabilmesi için anahtarlar ve secret işaretleri görünür kalır.

Ortam değişkenini değiştirdikten sonra neden yeniden dağıtım yapmalıyım?

Çalışan process ortamını başlangıçta alır. Yeni bir deployment, güncellenen değerlerle yeni bir container oluşturur ve bunu health gate üzerinden doğrular.

Gizli bilgileri dockup.yaml içine koyabilir miyim?

Hayır. dockup.yaml'ı düz ve incelenebilir yapılandırma için kullanın; credential'lar için secret environment komutlarını veya CI secret injection yöntemini tercih edin.

Birden çok ortam değişkenini nasıl içe aktarırım?

Bir .env tarzı dosyayla ve tam servis hedefiyle dockup env import komutunu kullanın. import --secret seçeneğini yalnızca içe aktarılan tüm değerler gizli bilgiyse kullanın.

Bir gizli bilgi log'da açığa çıkarsa ne yapmalıyım?

Hemen iptal edin veya döndürün, Dockup secret'ını güncelleyin, yeniden dağıtın, erişim log'larını inceleyin ve ifşaya neden olan süreci düzeltin.