Sorun: çalışan bir image, çalışan bir servis demek değildir
Bir API'nin bir container image'a temiz bir şekilde derlenmesi kolay yüzde 20'sidir; onu production'a götürmek diğer yüzde 80'idir. Geleneksel olarak bu, bir VM kiralamak, bir runtime kurmak, bir reverse proxy yapılandırmak, TLS sertifikaları almak ve yenilemek, doğru portları açmak, uygulamanın çökme durumunda yeniden başlaması için bir process manager eklemek, log toplamayı bağlamak ve kutu çevrimiçi olduktan saatler içinde onu bulan saldırganlara karşı nöbet tutmak anlamına gelir. Bu adımların her biri, API'nizin gerçek işiyle hiçbir ilgisi olmayan farklılaşmamış altyapı işidir ve her biri güvenlik veya güvenilirliği ince bir şekilde yanlış yapabileceğiniz bir yerdir. Container Apps, tüm bu kontrol listesini birkaç alana indirgemek için var.
cdn.com.tr bunu nasıl çözer: edge'in arkasında yönetilen container'lar
Platforma bir image, bir port ve bir healthcheck verirsiniz; o da container'ı çalıştırır, edge üzerinden ona trafik yönlendirir ve onu canlı tutar. TLS, Auto SSL tarafından yönetilir; herkese açık giriş noktası ham container yerine edge route'tur; ve WAF, kötü niyetli trafiği servisinize ulaşmadan önce filtreler. Yapılandırma, çalışma zamanında enjekte edilen ortam değişkenleri ve secrets olarak gelir, ölçeklendirme sizin ayarladığınız bir replika sayısıdır ve log'lar ile durum panelde görünür. Sonuç olarak sorumlu olduğunuz tek şey uygulama image'ınızdır; sunucu, proxy, sertifika ve firewall endişeleri platform tarafından üstlenilir.
Healthcheck'ler: deploy güvenlik ağı
Healthcheck, bir deploy'u bir umuttan kontrollü bir işleme dönüştüren şeydir. Yeni bir sürüm gönderdiğinizde, platform container'ı başlatır ve sağlık uç noktanızı yoklar; yalnızca o uç nokta sağlıklı raporladığında yeni instance'a trafik yönlendirir. Açılışta çöken, veritabanına ulaşamayan veya gerekli bir secret'i eksik olan bir build kontrolü geçemez ve rotasyona alınmaz; böylece kötü bir deploy kullanıcılarınız tarafından değil, yayılımda yakalanır. Bu yüzden healthcheck, koşulsuz 200 döndürmek yerine gerçek hazırlığı — bağımlılıklara erişilebilirlik, yapılandırmanın mevcut olması — doğrulamalıdır. Anlamlı bir healthcheck, güvenli yeniden deploy'lar ile sessiz kesintiler arasındaki farktır.
Ortam değişkenleri ile secrets: sızıntısız yapılandırma
API'lerin yapılandırmaya ihtiyacı vardır — veritabanı URL'leri, üçüncü taraf key'leri, feature flag'ler — ve bunu sağlamanın yanlış yolu, image'a gömmek veya repository'ye commit etmektir; orada katmanlarda ve geçmişte sonsuza kadar yaşar. Platform, düz ortam değişkenlerini secrets'tan ayırır: hassas olmayan ayarlar ortam olarak girer, parolalar, token'lar ve API key'leri ise secrets olarak saklanır ve çalışma zamanında key ile enjekte edilir, asla geri gösterilmez veya build'inize yazılmaz. Bu, aynı image'ın farklı yapılandırmalarla ortamlar arasında hareket edebilmesi, kimlik bilgilerinizin versiyon kontrolünün dışında kalması ve bir secret'ı döndürmenin yeniden-build-et-ve-yeniden-deploy-et telaşı yerine bir platform eylemi olması anlamına gelir.
Ölçeklendirme, log'lar ve operasyonel döngü
API canlıya geçtikten sonra, onu çalıştırmak sunucu yönetimi yerine birkaç kontrolden ibarettir. Bir kaynak planı seçer ve kaç replika çalıştıracağınızı ayarlarsınız; bir lansman veya trafik artışı için yukarı, sonra tekrar aşağı ölçeklendirirsiniz. Log'lar panelde akar, böylece bir isteği izleyebilir, bir 500'ü debug edebilir veya bir deploy'un gerçekten alındığını doğrulayabilirsiniz; durum ise servisin sağlıklı olup olmadığını ve en son ne zaman yeniden başladığını gösterir. Her yeniden deploy aynı healthcheck kapısından geçer, böylece yeni bir build göndermek, hiçbir yere SSH ile bağlanmadan tekrarlanabilir, gözlemlenebilir bir eylem olur — image'ı push edersiniz, kontrolün geçtiğini izlersiniz ve log'larda doğrularsınız.
Depolama ve veriyi bağlamak
Çoğu API'nin durumu (state) saklayacak bir yere ihtiyacı vardır ve servis bunun için platformun geri kalanıyla temiz bir şekilde birleşir. Bir Object Storage bucket'ını container'a ortam değişkenleri olarak bağlayabilir, böylece medya veya belgeleri doğrudan okuyup yazabilir; ayrıca yönetilen bir veritabanı veya Redis bağlayarak, onları da işletmeden servise kalıcılık ve cache sağlayabilirsiniz. Bunlar platform üzerinden bağlandığından ve enjekte edilmiş yapılandırma olarak teslim edildiğinden, API özgürce ölçeklendirilebilen ve yeniden deploy edilebilen, verisi yanında yönetilen servislerde yaşayan, durum tutmayan (stateless) bir image olarak kalır.
Adım adım nasıl kurulur
Image'ınızı işaret edin
Panelde bir Container App oluşturun ve herkese açık veya özel bir registry'den önceden derlenmiş image'ınıza (örneğin myorg/api:1.4) referans verin. Özel image'lar için, platformun onu çekebilmesi için bir kez bir registry kimlik bilgisi ekleyin. API'nizin dinlediği portu ayarlayın, böylece edge trafiği nereye göndereceğini bilir.
Healthcheck'i tanımlayın
Uygulamaya, servis gerçekten sunum yapabildiğinde yalnızca 200 döndüren /health veya /ready gibi bir healthcheck yolu verin. Platform bunu, yeni bir deploy'un trafik almadan önce sağlıklı olup olmadığına karar vermek için kullanır; bu yüzden veritabanı bağlantısı gibi gerçekten önemli şeyleri kontrol etmesini sağlayın.
Ortam değişkenlerini ve secrets'ı ayarlayın
Hassas olmayan yapılandırmayı ortam değişkenleri olarak, hassas değerleri — API key'leri, veritabanı parolaları, token'lar — ise secrets olarak ekleyin; böylece image'a gömülmek veya repo'ya commit edilmek yerine çalışma zamanında enjekte edilirler. Secret değerleri güvenli şekilde saklanır ve key ile referans verilir, geri yansıtılmaz.
Deploy edin ve healthcheck'i izleyin
Deploy'u panelden veya cdnctl ile tetikleyin. Container başlatılır, healthcheck yoklanır ve servis yalnızca geçtiğinde hazır olarak işaretlenir — ve yalnızca o zaman rotasyona alınır — böylece bozuk bir build sessizce trafik almaz.
Auto SSL ve WAF ile bir alan adı bağlayın
Servisi açığa çıkararak otomatik HTTPS'e sahip ücretsiz bir name.cdn.com.tr URL'si edinin veya kendi alan adınızı bağlayın ve Auto SSL'in sertifikayı vermesine izin verin. API'nin edge filtrelemesinin arkasında oturması için WAF'ı etkinleştirin; origin container'a yalnızca o edge route üzerinden erişilebilir.
Ölçeklendirin ve gözlemleyin
Beklediğiniz yük için kaynak planını ve replika sayısını ayarlayın; deploy'ları, yeniden başlatmaları ve çalışma zamanı davranışını izlemek için log'ları ve durumu kullanın. Yeniden deploy'lar aynı healthcheck-kapılı yoldan geçer, böylece yeni bir sürüm göndermek rutin, gözlemlenebilir bir işlem olur.
Örnek senaryolar
Bir JSON API, Auto SSL ve WAF ile bir alan adının arkasında image'ından yayınlanır; frontend'e bakımı gereken bir sunucu olmadan istikrarlı, güvenli bir HTTPS endpoint'i sağlar.
Bir webhook alıcısı, görsel işleyici veya kimlik doğrulama servisi, kendi ölçeklendirmesi ve secrets'ıyla izole çalışır; geri kalan her şeyden bağımsız olarak deploy edilir ve yeniden deploy edilir.
Bir ürün ekibi, bir demo için paylaşılabilir bir HTTPS URL'si elde etmek üzere etiketlenmiş bir image'dan bir container ayağa kaldırır, ardından build ilerledikçe onu kaldırır veya yeniden deploy eder.
Sıkça sorulan sorular
Platform image'ımı derliyor mu, yoksa ben mi getiriyorum?
Önceden derlenmiş bir image'ı bir registry'den siz getirirsiniz. Container Apps, sağladığınız image'ı çalıştırır ve yönlendirir; özelse, platformun deploy sırasında çekebilmesi için bir kez bir registry kimlik bilgisi eklersiniz.
Yeni deploy'um bozuksa ne olur?
Healthcheck'i geçemez ve rotasyona alınmaz, böylece trafik çalışan sürüme gitmeye devam eder. Açılışta çöken veya bağımlılıklarına ulaşamayan bir container, kullanıcılarınıza hata sunmak yerine yayılımda yakalanır.
API key'lerini ve veritabanı parolalarını kodumdan nasıl uzak tutarım?
Bunları secrets olarak saklayın; bunlar çalışma zamanında container'a key ile enjekte edilir ve asla image'a gömülmez veya repo'ya commit edilmez. Hassas olmayan ayarlar düz ortam değişkenleri olarak girer, böylece aynı image farklı yapılandırmalarla farklı ortamlarda çalışır.
API'm bir veritabanına veya Object Storage bucket'ına ulaşabilir mi?
Evet. Bir Object Storage bucket'ını container'a ortam değişkenleri olarak bağlayabilir ve yönetilen bir veritabanı veya Redis bağlayabilirsiniz; böylece servis durum tutmayan, yeniden deploy edilebilir bir image olarak kalırken depolama, kalıcılık ve cache'e sahip olur.
Bir trafik artışını nasıl yönetirim?
Replika sayısını ve gerekirse uygulamanın kaynak planını artırın. Trafik edge üzerinden girip container'lar onun arkasında oturduğundan, yükle eşleşmek için instance sayısını ölçeklendirir ve ardından tekrar düşürürsünüz.
Panel yerine komut satırından deploy edebilir miyim?
Evet. cdnctl, aynı container işlemlerini terminalinizden yürütür — deploy, yeniden deploy, ölçeklendirme ve inceleme — böylece dağıtımları script'leyebilir veya CI'dan çalıştırabilir, panelle aynı healthcheck-kapılı davranışı elde edebilirsiniz.