Ana içeriğe geç

Marketplace vs direct helm

Bir paketi marketplace'e yayınlamak ne zaman, bir chart'ı direkt kurmak ne zaman. İki yol var; birbiriyle değiştirilemez.

Kısa versiyon​

  • Marketplace'i ekibinizin birden fazla kez kuracağı veya tipli install formuna ihtiyacı olan veya org-spesifik varsayılanları olan chart'lar için kullanın.
  • Direct helm'i bir-defalık install'lar, ad-hoc CLI işi, troubleshooting için kullanın. Yayınlama gerektirmez.

Marketplace paketi gerçekte ne​

Marketplace paketi DT Edge Platform'un DB'sinde şunu söyleyen bir satırdır:

  • "Bu kurmak isteyebileceğin bir chart."
  • Bir chart_ref'e işaret eder (oci://... veya HTTP repo)
  • Varsayılan değerlerle bir veya daha fazla sürüm'e sahip
  • Opsiyonel olarak her sürüm bir x-form-schemas bloğu gönderir — UI'nın değerler için tipli form render etmesine izin veren bir JSON Schema

Bir paket yayınlamak chart byte'larını hiçbir yere taşımaz. Chart hâlâ registry'de yaşar; paket satırı ona işaret eder. Yayınladığınız şey discoverability + form schemas + varsayılan değerler.

Direct helm — neyi feda edersiniz​

DT Edge Platform'un marketplace satırı olmayan chart_ref + version + values alan bir backend endpoint'i var. UI'da değil; sadece API. Şunları feda edersiniz:

  • Discoverability — teyzedaşlarınız bu chart'ı marketplace grid'inde bulamaz
  • Tipli install formları — sadece YAML editör; form schema yok demek validasyon ipucu yok
  • Org-curated varsayılanlar — her install chart'ın kendi varsayılanlarından başlar; org-spesifik override'lar pre-filled değil
  • Standart kategorilendirme — chart global kategorilerle tag'lenmemiş, "tüm networking paketleri" tipi filtrelerde görünmüyor

Şunları korursunuz:

  • Aynı install pipeline (operation satırı + worker run + helm SDK)
  • Image-pull credential'ları (image_registry_ids'i request'te belirtirsiniz)
  • Audit log entry'leri
  • Tüm ownership + lifecycle feature'lar (upgrade, rollback, uninstall)

Marketplace ne zaman mantıklı​

Production iş için neredeyse her zaman:

  • Birden fazla kez kuracağınız bir chart — sadece staging + prod'da bile, marketplace yolu zaman tasarrufu sağlar (form schemas + varsayılanlar bound)
  • Kullanıcıların doğru config doldurmasını istediğiniz bir chart — form schemas kötü değerleri install denemesi öncesi type seviyesinde yakalar
  • Org'unuza spesifik bir chart — sadece sizsen ve kuracaksanız bile, org-curated varsayılan baseline'a sahip olmak nasıl yapılandırıldığını hatırlamanıza yardım eder
  • Image registry paylaşan chart'lar — registry'leri publish zamanında bir kez bağlayın; her install otomatik alır

Direct helm ne zaman mantıklı​

Niş durumlar:

  • Tekrarlamayacak bir-defalık install'lar — upstream chart debug etme, tutmayı planlamadığınız community chart deneme
  • CLI / CI script'leri UI yüzeyine ihtiyaç duymayan — yine de bunlar için bir API key + marketplace install endpoint'i genelde direct-helm endpoint'inden iyidir
  • Olay yanıtı sırasında marketplace kataloğunu bypass etmek — henüz yayınlanmamış bir chart'ın fix-version'ını install etmeniz gerektiğinde

Cluster'da CLI helm direkt nasıl olur​

DT Edge Platform'un dahili olmadan cluster'ın kubeconfig'i ile direkt helm install yapabilirsiniz. Sadece Applications listesinde görünmez.

Neden: DT Edge Platform release listesini dtedge.io/managed=true etiketiyle damgalanmış release'lere filtreler. Etiket DT Edge Platform'un helm install handler'ı tarafından eklenir (action.Install.Labels üzerinden). Laptop'unuzdan plain helm install etiketi eklemez, yani release DT Edge Platform'a görünmez kalır.

Bu kasıtlı — helm CLI'sını direkt kullanan operator'lar release'lerinin ekibin ana view'ına karışmasını istemez.

CLI-installed bir release'i DT Edge Platform'a "import" etmek isterseniz:

kubectl label secret -n <namespace> -l "owner=helm,name=<release-name>" \
  dtedge.io/managed=true

Bir sonraki sync (≤1 dakika) onu alır.

Neden her yerde CLI olmasın​

Marketplace yüzeyi size şunları verir:

  • Form schema → YAML düzenleme olmadan tipli install'lar
  • Cross-team discoverability
  • Operator-side audit trail (kim ne yükledi, ne zaman, hangi değerlerle)
  • Version pin'leme + görünür changelog (sürümler release notları gönderdiğinde)
  • Scoped image-pull credential'ları (per-install cred kaçakçılığı yok)

Bir ekibin günlük "standart logging stack'ini kur" işi için bu kazançlar birikir. CLI "olayla mücadele ediyorum ve bu fix-chart'ı 5 dakika önce deploy etmeliyim" içindir.

Ayrıca bakın​