Deploy verification nedir?#
Deploy verification açıkken agent, bir deploy bittikten sonra tanımladığınız check'leri belirli bir süre boyunca örnekler. Bir check limitini üst üste birkaç kez aşarsa deploy fail olur ve seçildiyse önceden çalışan image'a rollback yapılır.
EJO bunu pipeline'ın sonuna eklenen bir Verify deployment step'i olarak çalıştırır. Bu step'i siz eklemezsiniz.
Ön koşullar#
- Prometheus check'leri için agent'ın erişebildiği bir Prometheus. Adres cluster içi bir adres olabilir.
Kurulum#
- Environment sayfasında Deploy verification bölümünü açın.
- Buradaki deploy'ları doğrula seçeneğini açın.
- Ayarları girin:
| Ayar | Açıklama |
|---|---|
| Prometheus URL'i | Agent'ın erişebildiği Prometheus adresi. |
| Token variable'ı (opsiyonel) | Bir SECRET variable'ın adı. Değeri Authorization: Bearer olarak gönderilir ve hiç gösterilmez. |
| Süre | Check'lerin ne kadar süre örnekleneceği. Varsayılan 5m; 30s ile 60m arası. |
| Aralık | İki örnek arasındaki süre. Varsayılan 30s; 10s ile 5m arası. |
| Ardışık breach | Deploy'un fail sayılması için bir check'in üst üste kaç kez limiti aşması gerektiği. Varsayılan 3; 1 ile 10 arası. |
| Fail olunca | Rollback ya da Sadece deploy'u fail et. |
- Check ekle ile en fazla 10 check tanımlayın:
- Prometheus: bir PromQL sorgusu, bir karşılaştırma (Değer şu olduğunda sağlıklı:
<,<=,>,>=) ve bir Eşik. - HTTP: bir URL ve Beklenen status.
- Prometheus: bir PromQL sorgusu, bir karşılaştırma (Değer şu olduğunda sağlıklı:
- Test ile check'leri deneyin.
Not: Test agent'ta değil, EJO'da çalışır. Prometheus'a yalnızca agent'ın ağından erişilebiliyorsa test fail olabilir; deploy'lar yine de çalışır.
Sorgularda ve URL'lerde şu template variable'ları kullanılabilir; agent bunları her deploy için doldurur: {{.Service}}, {{.Environment}}, {{.Namespace}}, {{.Deployment}}, {{.CommitSHA}}, {{.ImageDigest}}.
sum(rate(http_requests_total{service="{{.Service}}",code=~"5.."}[5m]))
Servise özel check'ler#
Servisler kendi check'lerini .ejo dosyasındaki verify: bloğuyla ekleyebilir. Bu check'ler environment check'lerinin yanına eklenir; onları kaldıramaz. Bkz. .ejo dosyası.
Verify step'i ne zaman çalışır?#
- Environment'ta verification açıksa ve environment'ta ya da servisin
.ejodosyasında en az bir check varsa. - Pull request ve teardown run'ları doğrulanmaz.
Sonuç deployment sayfasında görünür: running, passed, failed veya inconclusive.
Otomatik rollback#
Fail olunca ayarı Rollback ise, doğrulama fail olduğunda EJO önceden çalışan image'a bir rollback deployment'ı başlatır. Bu deployment'ın başlatanı auto-rollback olarak, sebebi auto: verification failed: ile başlayan bir metin olarak görünür.
Environment'ın Prod fail oranı yüksek olduğunda ayarı, production'daki fail oranı yükseldiğinde ne olacağını belirler: Sadece bildir, freeze ya da rollback.
Elle rollback#
- Bir deployment sayfasındaki Rollback yap ile daha önceki bir deploy'a geri dönebilirsiniz.
- Environment sayfasındaki Son başarılı deploy'a rollback yap son başarılı deploy'a döner.
Environment onay gerektiriyorsa rollback'ler de onay bekler. Freeze window'lar rollback'i engellemez. Supply chain policy'si açıksa rollback image'ı da policy'den geçmelidir.
Fail olan bir run'ı rerun etme#
| Seçenek | Ne yapar |
|---|---|
| Fail olan step'leri rerun et | Başarılı olmayan step'leri ve onlardan sonra gelen her şeyi rerun eden yeni bir deployment başlatır. Başarılı step'ler reuse edilir. |
| Buradan rerun et | Seçtiğiniz step'i ve sonrasındaki her step'i rerun eder. Önceki başarılı step'ler reuse edilir. |
| Tekrar dene | Pipeline'ın tamamını baştan çalıştırır. |
Rerun, kaynak deployment'ın pipeline versiyonunu kullanır. Reuse edilen step'lerin dosyaları restore edilmez; sonraki step'ler bu dosyalara ihtiyaç duyuyorsa daha önceki bir step'ten Buradan rerun et ya da Tekrar dene kullanın.
Fail olan bir step'i debug etme#
Binding'de Fail olunca debug açıkken bir step fail olduğunda agent step'in container'ını açık tutar ve konsoldan bu container'a etkileşimli bir debug oturumu açabilirsiniz.
- Oturum yalnızca fail olan step'in container'ına bağlanır; agent host'una shell verilmez.
- Oturumu yalnızca admin'ler ve run'ı başlatan kullanıcı açabilir.
- Her step için toplam en fazla 30 dakika.
- Eski agent'larda "upgrade the agent" mesajı görünür.