Preview'lar

Preview nedir?#

Preview (Review App), bir pull request'in (GitLab'da merge request) çalışan bir kopyasıdır. EJO her PR için paylaşılan cluster'ınızda ayrı bir namespace oluşturur, uygulamayı oraya deploy eder ve https://<preview-adı>.preview.example.com biçiminde bir URL'i PR yorumuna yazar. PR kapandığında namespace silinir.

Preview'lar GitHub, GitLab ve Azure DevOps'ta çalışır. Bu sayfada "PR", GitLab'daki merge request'i de kapsar.

• Preview adı (namespace adı da odur) ejo- ile başlar, repo adını içerir ve -pr-<numara> ile biter.
• Aynı PR'a gelen yeni push'lar aynı namespace'i günceller.
• Her PR için tek bir yorum açılır ve her push'ta güncellenir.

SCM'lere göre#

GitLab ve Azure DevOps'ta yorum ve status yazmak için EJO'da GitLab token'ı ya da Azure DevOps PAT'i tanımlı olmalıdır; tanımlı değilse yorum ve status yazılmaz, preview'ı Delivery > Preview'lar sayfasında görürsünüz. Bkz. Kaynak kod bağlantısı (SCM).

Ön koşullar#

• Kubernetes tipinde bir environment.
• Preview namespace'leri (Review App'ler) seçeneğiyle kurulmuş bir agent. Bu seçenek agent'a preview namespace'leri oluşturup silme yetkisi verir. Bkz. Agent kurulumu.
• Cluster'da bir ingress controller ve preview domain'i için bir wildcard DNS kaydı, örneğin *.preview.example.com.
• NetworkPolicy uygulayan bir CNI (örneğin Calico veya Cilium; k3s'in kendi controller'ı da uygular). Düz flannel uygulamaz.

Kurulum#

1. Environment sayfasında Önizlemeleri kur'a basın. Preview kurulum sihirbazı açılır.
2. Preview base domain'i alanına wildcard DNS'in gösterdiği domain'i girin, örneğin preview.example.com. Sihirbaz örnek bir URL gösterir.
3. Gerekirse ingress class, TLS secret'ı, TTL, kota ve egress ayarlarını yapın (aşağıdaki tablo).
4. Cluster'ımın CNI'ı NetworkPolicy uyguluyor kutusunu onaylayın.
5. Repo binding'inde PR'da preview (izole isim, PR kapanınca kaldırılır) seçeneğini açın. Bu, PR trigger'ını da açar. Bkz. Trigger'lar ve binding'ler.

Aynı ayarları .ejo dosyasındaki preview: bloğuyla da yapabilirsiniz. Bkz. .ejo dosyası.

Environment ayarları#

Binding ayarları#

Pipeline'da preview#

Preview run'larında K8S_DEPLOY ve HELM_UPGRADE step'leri otomatik olarak PR namespace'ine deploy eder ve Ingress oluşturur. K8S_DEPLOY rollout'un bitmesini bekler, ardından health path'e wait_seconds (varsayılan 60) boyunca istek atar; hiç cevap gelmezse step fail olur.

Bir PR'da birden fazla servis aynı preview host'unu paylaşabilir. Her step'e preview_service ile bir ad, preview_path ile bir yol verin:

steps:
  - name: web
    kind: K8S_DEPLOY
    config:
      image: "{{.WebImage}}"
      container_port: 3000
      preview_service: web
  - name: api
    kind: K8S_DEPLOY
    config:
      image: "{{.ApiImage}}"
      container_port: 8080
      preview_service: api
      preview_path: /api
      preview_health_path: /api/healthz

Environment'a tanımlı SECRET variable'lar her preview namespace'inde ejo-preview-vars adlı bir Secret'a yazılır ve K8S_DEPLOY container'a bu değerleri verir.

İzolasyon ve egress#

Preview namespace'leri NetworkPolicy ile izole edilir: varsayılan olarak yalnızca kendi namespace'lerine ve DNS'e erişebilirler. Uygulamaların gerçekten ihtiyaç duyduğu hedefleri egress allowlist ile açın:

Egress değişiklikleri mevcut preview'lara bir sonraki push'ta yansır.

Uyarı: CNI'nız NetworkPolicy uygulamıyorsa preview'lar izole olmaz. Production ve preview'ları aynı cluster'da çalıştırıyorsanız bunu mutlaka kontrol edin.

Merge gate ile kullanma#

Binding'de Review App URL'ini de bekle açıkken merge gate, PR run'ının bir preview URL'i olana kadar bekler. Bu bekleme her SCM'de EJO tarafında çalışır; SCM tarafında:

• GitHub'da merge gate ruleset'i ejo/preview status'ünü de zorunlu kılar.
• Azure DevOps'ta EJO, name preview için ikinci bir engelleyici status policy ekler.
• GitLab'da EJO ayrıca bir ayar yapmaz.

Preview'ları yönetme#

Delivery > Preview'lar sayfası tüm Kubernetes environment'larındaki preview'ları listeler. Bir preview'ın detay panelinden:

• Pin'le: Preview'ı TTL temizliğinden muaf tutar.
• TTL uzat (+24 saat): Süreyi uzatır. Uzatma 1 ile 168 saat arasında olabilir.
• Yeniden deploy et: Son pull request deployment'ını tekrar çalıştırır.
• Yeniden başlat, Uyut, Uyandır: Workload'ları yeniden başlatır, sıfıra ölçekler ya da eski replica sayısına geri getirir.
• Pod'ları, log'ları, event'leri ve quota kullanımını görüntüler.
• Kaldır: Preview'ı hemen kaldırır.

Pin'leme, uzatma ve kaldırma developer veya admin rolü ister.

Kaldırma#

Preview şu durumlarda kaldırılır: PR kapanınca (GitLab'da merge edilince veya kapanınca, Azure DevOps'ta tamamlanınca veya bırakılınca), TTL dolunca, label kaldırılınca ya da konsoldan kaldırılınca. Namespace silinir ve PR yorumu ### EJO preview removed başlığı ve sebebiyle güncellenir.

Sonraki adımlar#

• Trigger'lar ve binding'ler
• Supply chain güvenliği
• Sorun giderme