Docs

Deployment'lar

Özet

  • Bir deployment, bir backend'in runtime materyalleşmesidir — bir runtime üzerinde container'lar olarak çalışan tipli graf, trafiğe hizmet veren endpoint URL'lerinin arkasında, ekibin izlediği operasyonel durumla birlikte.
  • Bir deployment, bir backend ile 1:1'dir. Her backend'in en fazla bir canlı deployment'ı vardır; aynı iş akışını iki ortamda çalıştırmak, önce backend'i fork etmek ve her fork'u bağımsız olarak deploy etmek demektir. "Şu anda üretimde ne var" sorusunu kesin kılan kısıt budur.
  • Endpoint URL'leri bir backend özelliğidir, bir deployment özelliği değil. Backend, alias'larını bildirir bildirmez onları yayımlar; deployment, bu URL'lere hizmet ettiren canlı süreçtir. Deployment'ı teardown edin, URL'ler kalır ama 404 yanıtlar.
  • Deployment, canlı runtime'a sahiptir; graf tanımına (o backend'de yaşar) veya UI'a (o application'da yaşar) sahip değildir. Runtime, diğer katmanlardan hiçbirine dokunmadan teardown edilebilir, değiştirilebilir veya taşınabilir.
  • "Sağlıklı", davranışsal doğruluğu değil runtime hazırlığını ifade eder. running bir deployment, container'ların ayağa kalktığını doğrular; çözümün çalıştığını doğrulayan şey, beklenen çıktıyı üreten temsili girdidir.

Bir deployment aslında nedir

Bir deployment, bir backend'in runtime materyalleşmesidir. Backend üzerindeki operasyon log'u girdidir; bir runtime üzerinde çalışan container'lar çıktıdır. Backend, workspace'te yaşayan tipli bir graf tanımıdır; deployment, o grafın gerçek hesaplama üzerindeki bir materyalleşmesidir, yaşam döngüsü aylarla değil dakikalardan haftalara kadar ölçülür.

Graf ile runtime arasındaki ayrım kasıtlıdır. Backend, incelenebilir tanım olarak kalır ve deployment, atılabilir runtime'dır — talep üzerine teardown edilir, runtime bakımından sonra yeniden başlatılır, bir sürüm yükseltmesinde toptan değiştirilir, grafı yeniden yazmadan farklı bir runtime'a taşınır. Dolayısıyla bir backend düzenlemesi, çalışan bir sistemi çökertme riski taşımaz, bir yeniden deploy graf düzenlemesiyle iç içe geçmez ve bir ortam farkı, çoğaltılmış graf durumu yerine ayrı bir backend olur.

Runtime tarafının birimi graf değil, container'dır. Deploy edilen backend'deki her vertex bir component container'ı olur; her edge, aralarındaki platform transport'u olur. Vertex'in bir Python model sunucusu, bir C++ stream işlemcisi veya bir transformation primitive'i olması bu şekli değiştirmez — içeride neyin çalıştığını değiştirir. Bir deployment'ı işletmek, başka herhangi bir container'lı yükü işletmek gibi görünür, bu yüzden mevcut container hata ayıklama içgüdüleri doğrudan geçerlidir.

Zihinsel model — bir backend, bir deployment

   ┌────────────────────┐ endpoint sahibi  ┌──────────────────┐
   │ Backend  prod-bid  │── aliases ──▶    │ Deployment       │
   └─────────┬──────────┘                  │ Runtime X · prod │
             │ fork                        └──────────────────┘
             ├─────────────────────────┐
             ▼                         ▼
   ┌────────────────────┐   ┌────────────────────┐
   │ Backend  stg-bid   │   │ Backend  dbg-bid   │
   └─────────┬──────────┘   └──────────┬─────────┘
             │ alias sahibi            │ alias sahibi
             ▼                         ▼
   ┌────────────────────┐   ┌────────────────────┐
   │ Deployment         │   │ Deployment         │
   │ Runtime Y · stg    │   │ Runtime Z · debug  │
   └────────────────────┘   └────────────────────┘

Backend, tipli graf tanımıdır; deployment, o tam backend'in belirli bir runtime üzerindeki canlı materyalleşmesidir. "Aynı grafı" başka bir yerde ayağa kaldırmak için backend'i kardeş bir nesneye fork edin ve fork'u deploy edin. Fork'lar bir ata ve bir başlangıç grafını paylaşır; fork noktasından itibaren kendi operasyon geçmişleri ve kendi deployment'ları olan bağımsız nesnelerdir.

Her deployment satırı kimliğini, durumunu, indiği runtime'ı, sabitlediği backend'i, sahip olduğu container sayısını, bir süre dolması zaman damgasını ve bir debug bayrağını taşır. Kimlikler, her deployment kapsamlı komutun aldığı şeydir — deployment containers, backend undeploy --deployment vb.

1:1 kısıt neden önemli

"Aynı backend'i iki kez deploy edelim" diyen biri olduğunda bu çerçeveyi kullanın.

İki eşzamanlı deployment'ı olan bir backend, "hangisi gerçek?" sorusuna tek bir yanıt vermez — backend üzerindeki operasyon log'u iki runtime'dan en az biriyle ayrışır, gözlemlenebilirlik araçları deployment'a göre runtime durumunu graf durumuna karşı sıralamak zorunda kalır ve "üretimde ne var" sorusu her zaman nitelendirme gerektirir.

Fork-sonra-deploy deseni, her deployment'ı durumu tam olarak çalıştırılan durum olan bir backend ile eşleştirilmiş tutar. Staging farklı bir backend'dir; üretim farklı bir backend'dir; geçen haftanın olayının bir debug kopyası farklı bir backend'dir. Her birinin kendi operasyon log'u, kendi forward URL'leri, kendi denetim izi vardır. Bedeli, kardeş backend'leri açıkça oluşturmaktır; sonuç ise runtime modelinin her zaman hangi kodun nerede çalıştığını yansıtmasıdır.

1:1 bağlantı, "redeploy"'u anlamlı bir operasyon yapan şeydir de. Backend başına bir deployment vardır; yeniden deploy, o tek deployment'ın container'larını mevcut backend durumunu yansıtan yenileriyle değiştirir. Forward URL'leri (deployment'a değil, backend + vertex + endpoint'e bağlı) değişimden sağ çıkar, böylece çağıranlar bir URL rotasyonu yerine kısa bir boşluk görür.

Yaşam döngüsü

   deploy ─▶ deploying ─▶ running ─┬─▶ tearing_down ─▶ (yok)
                                   └─▶ failed

Bir deployment küçük bir yaşam döngüsü yürür. Deploying, satırın var olduğu ve platformun container'ları ayağa kaldırdığı anlamına gelir; backend'in endpoint URL'leri zaten çözülür ama container'lar dinleyene kadar 404 yanıtlar. Running, her container'ın ayağa kalktığı ve URL'lerin trafiğe hizmet ettiği anlamına gelir — deployment'ın çağıranların beklediği anlamda "canlı" olduğu tek durum. Tearing down, açık bir undeploy'un, sahip bir lease'in commit-veya-rollback'inin ya da bir süre dolmasının runtime'ı geri aldığı anlamına gelir; endpoint'ler 404'e geri düşer. Failed, bir container'ın crashloop bütçesini tükettiği, transport'un kurulamadığı veya bir başlatma önkoşulunun karşılanmadığı kalıcı durumdur; ekip müdahale edene kadar endpoint'ler 404'te kalır.

Bir deploy, herhangi bir container başlamadan önce de reddedilebilir: mevcut tek runtime doluysa veya runtime sınıfı grafın ihtiyaç duyduğuyla eşleşmiyorsa, platform kısmi bir runtime indirmek yerine deploy'u baştan reddeder. Bu kasıtlıdır — yerleştirme kısıtlarını karşılayamayan bir deploy, çalışamayan container'lar üretmek yerine hızlı başarısız olur.

running dışındaki her şey, bir çağıranın bakış açısından "hazır değil"dir. Forward URL'leri boyunca var olabilir, ama sözleşme, deployment running olana kadar gerçek trafiğin gelmemesi gerektiğidir. Canlı backend ile test akışının wait adımı, "fixture göndermeye başla"'yı bu geçişe bağlar.

Endpoint URL'leri backend'e aittir

Bir çağıranın URL'inin bir yeniden deploy'dan sağ çıkması gerektiğinde bu çerçeveyi kullanın.

Forward URL deseni, token'ları (deployment, vertex, endpoint)'e değil, (backend, vertex, endpoint)'e bağlar. Çağıranların deployment her değiştiğinde URL'leri yeniden çekmemesinin nedeni bu bağlama şeklidir. Deployment'ı teardown edin, aynı backend'e karşı yenisini ayağa kaldırın ve aynı URL aynı endpoint'e hizmet eder. Deployment, değiştirilebilir runtime'dır; URL, backend'in genel sözleşmesinin bir parçasıdır.

Bunun diğer yüzü, bir deployment şu anda canlı olsun olmasın endpoint URL'lerinin var olmasıdır. Backend, alias'larını bildirildikleri an yayımlayabilir; URL'ler yönlendirilebilir; arkalarında running bir deployment yokken 404 yanıtlarlar. Bu, çağıranların deployment'tan önce URL'lerle yapılandırılmasına olanak tanır ve "deployment teardown edildi" ile "yeni deployment ayakta" arasındaki boşluğu bir URL rotasyon olayı yerine kısa bir 404 yapar.

Alias modeli için Çözümler ve forward token sözleşmesinin ayrıntısı için Deploy et ve izle sayfalarına bakın.

Canlı bir backend'de ne değişebilir

Bir backend düzenlemesinin yeniden deploy gerektirip gerektirmediğini merak ettiğinizde bu çerçeveyi kullanın.

Deploy edilmiş bir backend, dar bir yerinde-düzenleme kümesini kabul eder: component'inde mutable: true bildirilmiş slot'lardaki parametre değerleri, mutable: true bildirilmiş slot'lardaki dosya değerleri ve component yazarının izin verdiği benzer runtime-güvenli değerler. Platform yeni değeri çalışan container'a iter ve component bir sonraki çağırmada onu subscribe-config kancası aracılığıyla alır. Yeniden deploy yok; container yeniden başlatma yok.

Topoloji değişiklikleri farklıdır. Bir vertex eklemek, bir vertex kaldırmak, bir component release değiştirmek, bir edge değiştirmek, bir endpoint alias değiştirmek, mutable olmayan bir slot'a farklı bir dosya bağlamak — bunların hepsi bir deployment canlıyken reddedilir. Deployment, girdi olarak operasyon log'u ile tam olarak bu grafın materyalleşmesidir; grafı değiştirmek materyalleşmeyi operasyon log'uyla anlaşmazlığa düşürür ve çalışan container'ları kaydedilen backend durumuyla senkron dışı bırakır. Platform bunun yerine değişikliği reddeder.

Zaten canlı bir deployment'ı olan bir backend'e karşı bir topoloji değişikliği için iş akışı şudur: backend'i fork edin, fork'u düzenleyin, fork'u ayrı bir deployment olarak deploy edin. Orijinal backend, mevcut grafıyla çalışmaya devam eder; fork, topoloji değişikliğini taşır. Fork kanıtlandığında, iş akışına bağlı olarak ekip orijinal deployment'ı emekliye ayırır veya fork'u yeni üretim backend'i olarak promote eder. Bu, paralel ortamları çalıştıran aynı desendir — grafı üretimi etkilemeden değiştirmenin yolu, çalışan grafı düzenlemek yerine yeni bir tane deploy etmektir.

İşletim modları

Bunları, bir deployment'ın nasıl çalıştığını değiştiren küçük düğme kümesi olarak kullanın.

Debug deployment'ları. --debug, her container'dan daha zengin log yakalamayı etkinleştirir. Başlatma daha yavaştır, bu yüzden onu varsayılan yerine belirli sorunları kovalamak için saklayın. Deployment satırı debug: true taşır, böylece debug çalıştırmalarını bir bakışta ayırt etmek kolaydır.

Sabitlenmiş ömür. Varsayılan olarak bir deployment, runtime'ın tavanına kadar otomatik uzatılır. Deploy zamanında --fixed-duration <go-duration> iletmek kesin bir son tarih sabitler — otomatik uzatma devre dışı kalır ve platform runtime'ı programa göre geri alır. Bu, bir demo penceresi veya programlanmış bir batch gibi bilinen duvar saati bütçelerine uyar ve üretim için seçim değildir.

Lease'e ait deployment'lar. Bir lease içinde oluşturulan bir deployment, o lease'e aittir ve lease kapandığında geri alınır. Bu, kısa ömürlü test çalıştırmaları için ve işlerini aşmaması gereken batch hesaplamaları için standart şekildir — bkz. Lease'ler ve Lease yaşam döngüsü.

"Sağlıklı" ne demektir

running bir deployment, her container'ın ayağa kalktığını doğrular. İş akışının doğru çıktılar üretip üretmediğini, modelin doğru ağırlıkları yükleyip yüklemediğini veya edge'ler boyunca akan tipli değerlerin anlamsal olarak doğru olup olmadığını doğrulamaz. Sağlık, runtime hazırlığıdır; davranışsal doğruluk, kanıt döngüsü tarafından yanıtlanan ayrı bir sorudur.

Yararlı disiplin, trafiği running'e bağlamak (runtime hazır) ve promote'u kanıt döngüsüne bağlamaktır (runtime doğru sonuçları üretir). Bunları birleştirmek her iki tür hatayı da üretir — runtime hazır olmadan önce trafik göndermek ve doğru sonuçları üretmeden çalışan bir deployment'ı promote etmek.

Bu sözleşmenin kanıt döngüsü tarafı için Davranışı kanıtla sayfasına bakın.

Bunun yeri

Bir deployment, platformun runtime tarafıdır: işletim yüzeyi küçük bir fiil kümesidir, yaşam döngüsü dört durum artı baştaki yerleştirme kontrolüdür ve endpoint sözleşmesi backend üzerinde tek bir alias modelidir. Graf tanımını backend'de ve UI'ı application'da tutmak, çalıştırdığı iş akışları zenginleşse bile deployment'ın container'ları çalıştırmaya ve gözlemlemeye odaklanmış kalmasını sağlayan şeydir.

İlgili

Bu sayfa yardımcı oldu mu?