Helm: Menyediakan sarana pengaturan .Chart.AppVersion saat menginstal atau meningkatkan tanpa mengedit Chart.yaml

Untuk kejelasan, #3555 ditutup oleh OP (ref https://github.com/helm/helm/issues/3555#issuecomment-633187773) dengan komentar berikut:

"Sepertinya banyak orang di sini meminta cara untuk mengganti bidang 'appVersion'. Maksud/permintaan asli dalam masalah ini adalah untuk mengizinkan —aplikasi-versi sebagai pengganti —versi, sehingga pengguna dapat menjalankan ' helm fetch —app-version=v0.15.0' dan Helm akan mencari tahu apa versi grafik terbaru yang terakhir menetapkan v0.15.0 sebagai appVersion dan mengambilnya.

Dalam proyek/bagan (cert-manager) kami, kami ingin memperjelas kepada pengguna akhir versi mana yang mereka instal, jadi mengizinkan mereka menginstal berdasarkan versi aplikasi alih-alih versi bagan akan menjadi pengalaman instalasi yang jauh lebih alami.

Yang mengatakan, masalah ini dibuka 2 tahun yang lalu sekarang, dan sejak itu kami telah memilih untuk menyimpan kedua nomor versi ini dalam sinkronisasi/langkah kunci. Setelah beberapa tahun melakukan ini, ternyata sangat mudah dan tanpa rasa sakit, meskipun pengguna terkadang harus menunggu beberapa minggu untuk rilis resmi baru jika ada perubahan yang dilakukan pada manifes penerapan kami.

Mengingat usia masalah ini, panjangnya, variasi besar gerbang fitur yang sedikit berbeda, dan perubahan dalam proyek Helm sejak saat itu (Helm 3, grafik OCI, dll), saya tidak berpikir masalah ini dalam kondisi yang baik untuk didorong maju sebagai permintaan fitur dalam bentuknya saat ini. Saya akan menutup masalah ini, tetapi siapa pun yang memiliki permintaan fitur serupa Sebaiknya membuka edisi baru dan menautkan ke komentar lain yang relevan dalam masalah ini untuk memberikan bukti. Semoga itu akan bekerja lebih baik untuk proses triase tim Helm sehingga permintaan Anda bisa mendapatkan visibilitas yang mereka butuhkan!

Saya juga berpikir fungsi semacam ini bisa, dan mungkin yang terbaik, diimplementasikan sebagai alat eksternal atau pembungkus
Helm, terutama saat mempertimbangkan perubahan OCI yang menurut saya akan membuat ini lebih sulit untuk diterapkan."

jelek tapi berfungsi, akan menyukai bendera bawaan di helm

sed -i "s/^version:.*$/version: $(git describe)/" chart/Chart.yaml
sed -i "s/^appVersion:.*$/appVersion: $(git describe)/" chart/Chart.yaml
helm upgrade app ./chart

Saya berharap itu lebih seperti ....

helm upgrade --version "$(git describe)" --app-version "$(git describe)" app ./chart

@loa Saran Anda tidak mengikuti yang berikut dari judul (dan merupakan inti dari ini"

tanpa mengedit Chart.yaml

@timothyclarke Saya hanya ingin mengklarifikasi kasus penggunaan.

Saat ini tanpa kemampuan untuk mengubah appVersion pada saat upgrade, hasil dari helm history adalah:

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.0       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.0       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.0       Upgrade complete

Idealnya berlari

helm upgrade --wait --app-version "$MY_AWESOME_VERSION" app ./chart

Akan menghasilkan helm history lebih user friendly, seperti di bawah ini. Itu menunjukkan bahwa grafik tidak berubah tetapi aplikasi memiliki rilis baru.

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.1       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.2       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.3       Upgrade complete

Apakah use case ini sesuai dengan proses helm?

Idealnya, apakah versi aplikasi yang disediakan melalui baris perintah juga tersedia di template ( $.AppVersion )?

Ini akan memungkinkannya untuk ditambahkan ke data Meta dari konfigurasi kubernetes.

Ini akan sangat berguna. Beri komentar tentang topik "versi aplikasi" yaitu apa itu aplikasi, dan bagaimana Anda menentukan versi ketika ada lebih dari satu gambar buruh pelabuhan di "aplikasi" dll, bagaimana mengotomatiskan pembaruan di CI/CD. Saya melewati masalah ini dengan mendefinisikan 2 versi:

1. versi bagan: mewakili _source_ untuk template;
   
   
   
   • jika sumber template berubah, versi bagan harus berubah; sumber template berarti folder template, Chart.yaml, nilai default.yaml, helmignore, catatan, dll.
   
   
   • Saya tidak menyimpan bagan helm di repo bagan karena bagan tersedia dari git kapan saja dan dapat diinstal melalui instalasi helm
   
   
2. versi instalasi: nilai unik berdasarkan kombinasi semua nilai yang digunakan saat instalasi, yaitu setelah menggabungkan semua file nilai (termasuk file rahasia yang didekripsi) dan nilai default set dan bagan. Saya menentukan ini melalui MD5 atau SHA256 berdasarkan set nilai akhir.

Karena helm tidak memiliki konsep versi instalasi, saya menggunakan versi aplikasi untuk menyimpan file md5.

Ini membuatnya menafsirkan apa yang diinstal:

REVISION    UPDATED                     STATUS      CHART           APP VERSION      DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    3efe0e3...       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    ie21b02...       Upgrade complete
3           Mon Jun  8 12:20:51 2020    superseded  spring-1.0.0    3efe0e3...       Upgrade complete
4           Mon Jun  8 12:20:51 2020    deployed    spring-1.1.0    123abcd...       Upgrade complete

Sekarang cukup jelas bahwa revisi 1 dan 3 adalah instalasi yang sama persis: sumber bagan yang sama dan pohon nilai akhir yang sama.

Jika ada yang tertarik untuk mencoba ini, https://github.com/schollii/sandals/blob/master/helm.py menyediakan beberapa fungsi yang berguna untuk ini. Saat ini saya mendapatkan hash melalui dry-run untuk mendapatkan nilai gabungan, dan saya harus menyalin bagan ke folder temp untuk mengedit versi aplikasi di Chart.yaml (atau menggunakan solusi pengemasan, karena mendukung --app-version ). Jadi --app-version untuk pemasangan akan luar biasa. Saya juga ingin mengimplementasikan sesuatu seperti --app-version-is-md5 yang akan membuat dry-run tidak perlu, tetapi itu akan menjadi masalah lain (#8453).

Saya menggunakan ini sebelum setiap pemasangan ketika saya tidak menggunakan tag git yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_SHORT_SHA"

Ketika saya menggunakan tag, saya memutakhirkan revisi dalam proses ci saya menggunakan ini sebelum setiap instalasi yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_TAG"
Kemudian komit Chart.yaml diperbarui ke kontrol versi.

Menggunakan gitlab ci

Saya tahu ada banyak orang yang suka menyetel versi aplikasi tepat sebelum mereka memublikasikan bagan. Tapi sebenarnya kami tidak ingin mempublikasikan grafik terutama ketika kami masih menguji perubahan yang baru saja kami buat. menginstal atau meningkatkan ke lingkungan dev adalah kasus penggunaan utama untuk fitur ini.

@woodcockjosh , saya tidak yakin bahwa masalah ini terletak di sekitar versi bagan, tetapi lebih banyak versi aplikasi yang dapat dibaca manusia (appVersion) yang telah digunakan menggunakan bagan.

Saya akan mengatakan kasus penggunaan utama untuk fitur ini lebih untuk memberikan desainer bagan, admin server, dan pengembang kemampuan untuk:

1. Mudah melihat versi (bukan versi grafik) dari aplikasi yang digunakan. Dimana aplikasi adalah kode dan semua dependensi yang dibutuhkan. Catatan: Saya tidak berpikir appVersion akan menjadi nilai yang valid untuk digunakan untuk menghapus, mengembalikan, atau mencari rilis.
2. (keinginan pribadi) Untuk mengekspos nilai ke bagan sehingga pengelola bagan, atas kebijaksanaannya sendiri, dapat menentukan apakah mereka ingin menggunakan appVersion pada saat penginstalan/pembaruan. Contohnya adalah menambahkannya ke meta data penerapan Kubernetes

Dengan menutupi dua kasus penggunaan di atas, IMO, itu akan memungkinkan helm untuk tetap tidak beropini tentang bagaimana implementasi dan penggunaan grafik helm dilakukan.

versi instalasi: nilai unik berdasarkan kombinasi semua nilai yang digunakan saat instalasi, yaitu setelah menggabungkan semua file nilai (termasuk file rahasia yang didekripsi) dan nilai default set dan bagan. Saya menentukan ini melalui MD5 atau SHA256 berdasarkan set nilai akhir.

@schollii Saya suka ide versi instance, tetapi sebagai pembuat dan pelaksana bagan kemudi tempat saya bekerja, saya masih ingin versi aplikasi yang dapat dibaca manusia yang terpisah dari versi instance. Alasan mereka berpisah adalah
versi instalasi tidak akan unik jika hanya kode aplikasi yang diubah dan bukan bagan dan/atau nilai yang diterapkan ke bagan.

@rcampbel ya tentunya kita ingin melihat versi aplikasi yang terinstall. Apa yang saya katakan adalah bahwa keadaan di mana Anda ingin memiliki versi yang berbeda untuk appVersion dari yang ada di Chart.yaml adalah jika bagan itu milik Anda dan Anda menggunakan versi tingkat pengembangan dari aplikasi. Jika itu bukan versi tingkat pengembangan maka Anda dapat menyimpan nomor versi aplikasi di dalam Chart.yaml dan meminta pengguna akhir bagan menggunakan versi aplikasi tersebut sebagai versi aplikasi default.

Jika saya mengembangkan layanan mikro baru misalnya, saya tidak ingin mengemas dan mengunggah bagan helm baru ke repositori helm setiap kali saya ingin menguji versi aplikasi saya yang disebarkan. Tetapi saya juga masih ingin melihat versi atau id komit yang digunakan untuk setiap rilis, itulah sebabnya kami ingin mengganti appVersion untuk rilis pengembangan tetapi mungkin bukan rilis produksi.

Apa yang saya katakan adalah bahwa keadaan di mana Anda ingin memiliki versi yang berbeda untuk appVersion dari yang ada di Chart.yaml adalah jika bagan itu milik Anda dan Anda menggunakan versi tingkat pengembangan aplikasi. Jika itu bukan versi tingkat pengembangan maka Anda bisa menyimpan nomor versi aplikasi di dalam Chart.yaml dan meminta pengguna akhir bagan menggunakan versi aplikasi itu sebagai versi aplikasi default.

Inilah tepatnya mengapa helm harus tetap tidak berpikiran tentang bagaimana implementasi dan penggunaan diagram helm dilakukan.
Helm seharusnya tidak peduli dengan strategi penyebaran ke lokal dan di luar, itu untuk mengetahui alur kerja tim/proyek. Tapi ini menyimpang dari fitur yang diminta, izinkan .Chart.AppVersion disetel saat menginstal/upgrade tanpa memperbarui Chart.yaml

Saya tidak ingin mengemas dan mengunggah bagan helm baru ke repositori helm setiap kali saya ingin menguji versi aplikasi saya yang disebarkan

Dari apa yang saya tahu, helm sudah tidak berpendapat tentang ini, karena ia memiliki sarana untuk melakukan hal ini saat memanggil helm upgrade

Argumen bagan dapat berupa: referensi bagan ('contoh/mariadb'), jalur ke direktori bagan, bagan terpaket, atau URL yang sepenuhnya memenuhi syarat. ~ https://helm.sh/docs/helm/helm_upgrade/

@woodcockjosh Ada banyak kasus penggunaan dan sebagai @rcampbel menyatakan helm harus tetap tidak berpendapat tentang hal ini dan memungkinkan orang untuk bekerja dengan cara mereka sendiri.
Jika saya mengikuti logika "harus dipublikasikan dalam bagan" (secara ekstrem) mengapa helm memiliki flag --set atau --values , -f dan dalam hal ini mengapa harus file values.yaml sama sekali? Semua yang disediakan oleh flag adalah penggantian waktu penerapan yang seharusnya ada di bagan yang dipublikasikan. Saya tahu itu buruk untuk memasukkan rahasia ke dalam bagan, tetapi jika itu satu-satunya alasan maka arg seharusnya --secrets daripada --values .

Dalam situasi saya, kami menerapkan sejumlah aplikasi yang menggunakan bagan yang sama. Aplikasi ini dipromosikan melalui lingkungan menggunakan metode CI/CD. Aplikasi menggunakan flag --values untuk menyediakan konfigurasi khusus aplikasi dan lingkungan (umumnya detail ingress dan sumber data). Jika saya menerbitkan bagan baru untuk setiap versi aplikasi untuk setiap lingkungan, saya akan membuat ratusan hingga ribuan versi bagan per minggu. Dalam kebanyakan contoh, satu-satunya perbedaan adalah versi aplikasi. Saya kemudian terpaksa menabrak versi grafik. Bagi saya persyaratan yang diperkenalkan oleh seluruh paragraf ini, sementara logis dengan satu hal memicu yang lain, gila.

Karena .Chart.appVersion ada tidak berfungsi untuk kami, kami telah kembali ke .Chart.appVersion statis dan menggunakan .Values.image.tag (Ini bukan undangan untuk membuka kembali debat itu)

Saya yakin appVersion adalah cara yang tepat mengenai versi aplikasi setelah membaca dokumentasi, hingga membaca semua kasus penggunaan yang valid ini.

Untuk pengguna paket bagan lebih mudah untuk menabrak image.tag , ini menyiratkan hanya memodifikasi nilai, bagan dapat hidup di tempat lain. Tetapi dengan menggunakan image.tag Anda tidak mendapatkan informasi tentang versi paket saat melakukan helm history <release>

Saya juga memperhatikan bahwa helm package <chart> akan menghasilkan file tar dengan Chart.version . Jika Anda hanya ingin mendistribusikan versi baru aplikasi Anda, dan appVersion digunakan, Anda diharapkan untuk menambahkan version juga, jika tidak, Anda akan menimpa file sebelumnya. Jika appVersion dan version berbeda, akan lebih sulit untuk menghitung semver bump yang benar dengan alat otomatis untuk version (misalkan appVersion di-bump berdasarkan pesan komit ). Bagaimana Anda menghadapinya?

Kami hanya membutuhkan sesuatu yang merupakan versi aplikasi nyata yang dapat kami lihat saat membuat daftar bagan yang diterapkan.

Ketika saya memiliki bagan kemudi yang dibuat untuk menerapkan layanan mikro standar saya daripada yang saya ingin pilih selama penerapan versi aplikasi mana yang dimiliki layanan mikro ini selama penerapan. Saat ini, semua layanan saya memiliki selamanya appVersion 1.0.0 dan saya tidak menggunakan helm untuk memeriksa versi aplikasi mana yang saya miliki - karena memungkinkan ini dengan metode saat ini (mengkemas ulang bagan) akan membuat hidup saya seperti neraka.

Hanya, tolong biarkan kami memutuskan bagaimana kami akan menggunakan parameter ini. Jika ini tidak memungkinkan karena beberapa alasan teknis, beri tahu kami alasannya.

Saya lebih suka untuk tidak menggunakan "sed" seperti yang disebutkan dalam 8194
Sampai ini terpecahkan (atau tidak) Inilah cara saya menyelesaikan ini di CI/CD (GitLab):

Kemas bagan dengan versi aplikasi, lalu terapkan.
Saya tahu bahwa versi Bagan tidak dimaksudkan untuk sama dengan appVersion, tetapi dalam kasus kami ini baik-baik saja sebagai solusi.

Juga tidak perlu mengunggah ke repo helm, tetapi dimungkinkan menggunakan artefak CI yang dihasilkan (chart.tgz)

Jadi jika pengemasan pertama tidak menjadi masalah, dan Anda memerlukan solusi untuk hari ini , Anda dapat menggunakan sesuatu seperti ini.

deploy:
  image: alpine/helm:3.2.4
  stage: deploy
  environment:
    name: ${ENV}
  script:
    - helm package --app-version=${CI_COMMIT_TAG} --version=${CI_COMMIT_TAG} ${NAMESPACE}
    -  | 
       helm upgrade -i --wait ${CI_PROJECT_NAME} ./${NAMESPACE}-${CI_COMMIT_TAG}.tgz \
       --set image.repository="${CI_REGISTRY_IMAGE}" \
       --set image.tag="${CI_COMMIT_TAG}" 
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

Dalam output saya sekarang memiliki versi yang tersedia.

 $ helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
 REVISION   UPDATED                     STATUS      CHART       APP VERSION DESCRIPTION                                                                                                         
 45         Sun Aug  9 15:40:42 2020    superseded  prd-0.1.0   1.16.0      Upgrade complete                                                     
 46         Mon Aug 10 11:38:56 2020    superseded  prd-v0.2.25 v0.2.25     Upgrade complete                                                     
 47         Mon Aug 10 11:55:41 2020    deployed    prd-v0.2.26 v0.2.26     Upgrade complete                                                     
 Job succeeded

@haimari
Terima kasih atas cuplikannya, bagi siapa pun yang mencari ada contoh lain sebelumnya di tapak ini https://github.com/helm/helm/issues/8194#issuecomment -635879040 yang mencapai hasil yang sama.

Masalah yang dihadapi bagaimanapun adalah bahwa pengemasan ulang bagan tidak diinginkan dan pengelola helm memaksakan pendapat dan cara kerja itu. Permintaan ini adalah agar helm tidak terlalu beropini dan memungkinkan helm digunakan dengan cara yang lebih sesuai dengan bagian lain dari masyarakat.
Masalah ini dan https://github.com/helm/helm/issues/3555 telah mengeksplorasi perbedaan antara .Chart.version dan .Chart.appVersion , khususnya bagaimana sebagian besar grafik publik mengikat appVersion ke tag penampung yang telah memaksa versi bagan berubah hanya karena ada versi baru dari sebuah aplikasi yang dirilis. Sementara itu mungkin asumsi yang baik untuk sebagian besar grafik publik, asumsi tersebut tidak berlaku untuk sejumlah besar grafik pribadi. Karenanya permintaan ini kepada pengelola helm untuk berhenti memaksakan pendekatan itu ke komunitas.

ps Cuplikan kode Anda menyiratkan versi bagan per rilis / per lingkungan yang kemudian akan menggantikan kebutuhan untuk pengaturan image.repository dan image.tag . Saya mengharapkan langkah setelah pengemasan ulang untuk menerbitkan bagan ke repo helm jika Anda perlu menerapkan kembali, lihat https://github.com/helm/helm/issues/8194#issuecomment -658715462 di atas yang mengeksplorasi kelinci itu lubang

@haimari
Terima kasih untuk cuplikannya, bagi siapa pun yang mencari ada contoh lain sebelumnya di tapak #8194 (komentar) ini yang mencapai hasil yang sama.

Masalah yang dihadapi bagaimanapun adalah bahwa pengemasan ulang bagan tidak diinginkan dan pengelola helm memaksakan pendapat dan cara kerja itu. Permintaan ini adalah agar helm tidak terlalu beropini dan memungkinkan helm digunakan dengan cara yang lebih sesuai dengan bagian lain dari masyarakat.
Masalah ini dan #3555 telah mengeksplorasi perbedaan antara .Chart.version dan .Chart.appVersion , khususnya bagaimana sebagian besar bagan publik mengikat appVersion ke tag penampung yang telah memaksa versi bagan berubah hanya karena ada versi baru dari sebuah aplikasi yang dirilis. Sementara itu mungkin asumsi yang baik untuk sebagian besar grafik publik, asumsi tersebut tidak berlaku untuk sejumlah besar grafik pribadi. Karenanya permintaan ini kepada pengelola helm untuk berhenti memaksakan pendekatan itu ke komunitas.

ps Cuplikan kode Anda menyiratkan versi bagan per rilis / per lingkungan yang kemudian akan menggantikan kebutuhan untuk pengaturan image.repository dan image.tag . Saya mengharapkan langkah setelah pengemasan ulang untuk menerbitkan bagan ke repo helm jika Anda perlu menerapkan kembali lihat # 8194 (komentar) di atas yang mengeksplorasi lubang kelinci itu

@timothyclarke Terima kasih atas informasinya.

1. Ini bukan praktik terbaik tetapi solusi untuk _"Menyediakan sarana pengaturan .Chart.AppVersion saat menginstal atau meningkatkan tanpa mengedit Chart.yaml"_
2. Tidak perlu mendorong bagan ke repositori, Ini berfungsi dengan beberapa k8s cluster langsung dari Gitlab.
3. Ini menyediakan semua yang saya butuhkan untuk memiliki rilis:

image.repository & image.tag tetap diset dengan cara yang sama persis di pipeline,
jadi walaupun tanpa packaging line, ini adalah cara menggunakan helm dari gitlab.

variabel CI_COMMIT_TAG berisi tag rilis terkini dari pipeline yang berjalan.
Jadi kami selalu dapat memutar kembali ke versi sebelumnya langsung dari pipeline CI dengan satu klik.

Perusahaan saya memiliki bagan helm kami yang dipisahkan dari tag kontainer. Sama sekali tidak perlu mengemas ulang bagan untuk setiap pembuatan wadah.

Tidak adanya opsi untuk menyetel appVersion (dan karenanya selalu menyetelnya ke nilai yang sama) selama penginstalan merupakan kekurangan besar dalam proses penerapan kami. Sangat menjengkelkan bahwa pengguna kami tidak dapat melihat versi aplikasi dengan melakukan "daftar helm"

Memiliki kemampuan untuk menggunakan sesuatu seperti "helm install ... --app-version v1.2.3" akan menambah banyak nilai untuk menggunakan Helm dalam kasus kami.

Proposal saya adalah untuk mencela appVersion dan mencantumkan chart version dan container tag saat melakukan helm list atau helm history <name> .
Helm seharusnya tidak mencoba memberikan versi aplikasi yang sebenarnya di dalam penampung, itu harus memberikan apa yang ada, tag dan versi bagan, berikut beberapa contohnya:

| BAGAN | TAG KONTAINER |
| ----- | ----- |
| 0.1.0 | 0.3.0 |
| 0.1.0 | 0.4.0 |

Dalam contoh di atas kita dapat menyimpulkan bahwa bagan sedang digunakan kembali untuk tag yang berbeda

| BAGAN | TAG KONTAINER |
| ----- | ----- |
| 0.3.0 | 0.3.0 |
| 0.4.0 | 0.4.0 |

Dalam contoh di atas, kami berpotensi menyimpulkan bahwa bagan memiliki versi yang sama dengan tag.

Kelemahan utama dari appVersion tampaknya adalah bahwa hal itu membutuhkan paket untuk diterbitkan ulang, bahkan jika bagan tidak berubah, tetapi kode di dalam wadah telah berubah. Sementara itu, tag container dapat diberikan melalui values.yaml dan tidak perlu dipublikasikan ulang.

Alternatif

Saya pikir yang paling sederhana adalah membuat daftar tag wadah ketika melakukan helm list atau helm history , tetapi akan aneh jika appVersion berkeliaran. Setidaknya ini, akan memberikan beberapa info tambahan, dan orang dapat mengabaikan appVersion .

Solusi lain, alih-alih mencela appVersion , itu bisa dipindahkan ke values.yaml , dengan cara ini akan terlepas dari Bagan, mencegah banyak publikasi ulang.

Pikiran?

@Woile bagaimana jika aplikasi Anda memiliki lebih dari 1 wadah?

@Woile bagaimana jika aplikasi Anda memiliki lebih dari 1 wadah?

Anda benar, mengingat kasus penggunaan itu juga (maaf saya sedang memikirkan kasus penggunaan saya), saya pikir memindahkan appVersion ke values.yaml akan memperbaiki situasi.

• helm list dan helm history bisa tetap sama
• Anda dapat memiliki lebih dari satu wadah
• Anda tidak perlu memublikasikan ulang setiap kali, tetapi Anda dapat melakukannya jika Anda ingin menjaga agar Chart dan appVersion sinkron.

Apa yang saya lewatkan?

Preferensi saya akan memungkinkan untuk mengontrol appVersion secara eksplisit. Ini mungkin sama dengan tag wadah, atau mungkin perlu disetel ke nilai yang berbeda (mis. skrip instal saya mencari repositori wadah/namespace/tag tertentu dan kemudian menerapkan regex untuk mengubahnya menjadi ramah pengguna format untuk menampilkan versi aplikasi)

@woodcockjosh @Woile
$0,02 saya. Konsep appVersion bagus dari sudut pandang helm ls . Implementasinya adalah masalah yang ingin saya perbaiki. Memiliki beberapa tag / versi di appVersion seharusnya baik-baik saja misalnya appVersion: nginx-1.16.0-php-7.5

Saya perhatikan bahwa helm 3.2.4 memiliki {{ .Values.image.tag | default .Chart.AppVersion }} sehingga memungkinkan pemutusan semacam itu

Kemampuan untuk memilih appVersion selama penginstalan/peningkatan akan menjadi pendekatan yang paling disukai. Tidak masuk akal untuk menabrak versi bagan setiap kali appVersion berubah karena bagan itu sendiri tidak berubah. Perkembangan linier pembuatan versi juga tidak selalu berlaku - terutama untuk aplikasi multi container yang diterapkan di lingkungan yang berbeda dengan kombinasi versi container yang berbeda. Saran untuk menggunakan appVersion dan chartVersion yang sama juga buruk karena memaksa appVersion menjadi semVer kompatibel. semVer bukanlah cawan suci pembuatan versi dan appVersion harus bebas menggunakan skema pembuatan versi apa pun yang paling sesuai untuk aplikasi.

@bacongobbler Apakah komentar ini berarti bahwa helm berencana untuk mengimplementasikan bendera seperti itu?

Saya pikir pengenalan versi aplikasi (dalam opt baris perintah) dan appVersion (dalam Chart.yaml) secara efektif memberikan cara yang baik untuk melihat versi aplikasi yang digunakan dengan contoh bagan. Tetapi ini juga menghasilkan banyak pertanyaan dan praktik berbeda yang perlu diklarifikasi.

• Tujuan dari helm (bagan) adalah untuk mengemas & menginstal sumber daya di cluster kubernetes (untuk aplikasi).
• Versi aplikasi hanya dapat disediakan pada fase paket, sehingga informasi ini menjadi bagian dari bagan.
• Disimpan dalam repositori helm (seperti artefak java atau python) bagan menjadi tidak berubah. Jadi versi aplikasi tidak boleh diganti.
• Di sisi lain selama fase penginstalan atau peningkatan, nilai memungkinkan untuk menimpa nilai apa pun dari bagan (untuk penyesuaian lingkungan) tetapi appVersion tidak bisa.
• Seperti yang dapat kita lihat dalam banyak kasus penggunaan, versi aplikasi yang sebenarnya adalah versi gambar yang disediakan oleh image.tag selama fase penginstalan atau peningkatan

Kesimpulan saya

• Bagan payung dapat dianggap sebagai agregasi dari beberapa bagan (dependensi) yang mengikuti siklus hidup yang tepat
• Bagan payung adalah satu-satunya kasus di mana appVersion tidak langsung ditautkan ke gambar yang digunakan.
• Aplikasi selalu menyediakan bagan di mana dalam banyak kasus versi aplikasi = tag gambar (jadi berdasarkan transitivitas ke kode aplikasi)
• Pemisahan sumber antara kode aplikasi dan kode bagan hanya menimbulkan beberapa kesulitan pada kepatuhan antara gambar buruh pelabuhan dan bagan.
• Bagan bersama seperti "bagan boot-musim semi" harus selalu digunakan sebagai dependensi dalam bagan aplikasi (Bahkan jika aplikasi Anda hanya terdiri dari dependensi ini) ... Anda tidak menerapkan bagan bersama tetapi aplikasi !

Pilihan saya saat ini

• bagan bersama hanya menghasilkan bagan dengan versinya dan versi aplikasi selalu kosong (tidak pernah digunakan)
• bagan bersama tidak pernah digunakan secara langsung untuk melakukan penerapan.
• bagan aplikasi (komponen) selalu menghasilkan bagan yang tepat, di mana versi bagan = versi aplikasi = tag gambar
• bagan payung mengikuti adalah siklus hidup yang tepat di mana versi bagan mewakili versi aplikasi

Pertanyaan / Ide

Saya tidak tahu mengapa versi aplikasi diperkenalkan (mungkin untuk menutupi penggunaan bagan bersama yang buruk).
Saya pikir mungkin ide yang baik untuk menghapusnya dan memperkenalkan kemampuan untuk mengatur tag gambar pada fase paket tanpa menggunakan solusi seperti sed atau yq.

Mungkin posting yang terlalu panjang tetapi saya memerlukan beberapa masukan

@grazius
Pemahaman saya tentang posting Anda adalah bahwa flag --set , -f dan --values buruk dan tidak boleh digunakan. Semua penerapan tidak dapat diubah dan harus dirender ke dalam bagan, meskipun bagan itu sedikit lebih dari values.yaml dan bagan payung sebagai dependensi. Bagan ini harus dirender pada waktu pembuatan (aplikasi) dan dipublikasikan ke repo bagan

Dalam situasi di atas di mana Anda menyimpan rahasia atau informasi sensitif serupa? Di mana pun saya bekerja, itu telah dimasukkan melalui file --values

Untuk beberapa konteks, penerapan saya secara efektif memiliki 3 elemen yang diversi secara independen

• Bagan
• Aplikasi
• (Lingkungan) Nilai Konfigurasi

Jika saya mengubah salah satunya, saya seharusnya tidak dipaksa untuk membangun kembali yang lain. Saya biasanya menggunakan beberapa lingkungan sehingga aplikasi dapat diuji sebelum _live_. Karena penyebaran seperti itu ingin chart-v1.0 application_build-50 config_non-prod-v1.3 dengan file konfigurasi env disimpan gpg terenkripsi.
Platform CI saya mengelola pembuatan, penerapan, promosi aplikasi saat build mengalir dari sumber melalui pengujian ke produksi. Jika kami perlu menerapkan kembali versi historis aplikasi, kami menjalankan kembali pekerjaan tersebut.

Pertanyaan: Mengapa kita harus menggunakan repositori bagan untuk menyimpan status yang ditangani oleh platform CI saya di luar kotak? Kita seharusnya tidak pernah menginstal semua ini dengan tangan

@timothyclarke pastikan untuk menggunakan plugin rahasia sehingga Anda dapat menggunakan file nilai terenkripsi

@timothyclarke Halo, Terima kasih atas umpan balik pertama ini;)

• Keuntungan dari repositori (seperti, pypi, maven central, docker registry untuk pengembangan) adalah bahwa artefak yang dihasilkan dapat dibagikan dan diterbitkan (untuk helm ini adalah tgz) dengan jaminan yang tidak dapat diubah.
• Untuk nilai berdasarkan lingkungan (itu subjek lain) mereka dapat disimpan di tempat yang Anda inginkan (scm repo, solusi khusus seperti hashicorp untuk rahasia, illumio untuk netpol, dll ...).

Bagan memberikan nilai default.yaml (tidak dapat diubah untuk setiap versi bagan) yang dapat digunakan (atau diganti) oleh konsumen bagan.
Untuk Chart.yaml itu juga merupakan bagian yang tidak dapat diubah dari grafik ... dan app-version disertakan.

Dalam kasus Anda, apa yang ditampilkan dalam daftar helm untuk versi aplikasi? 50 ?
Jika ya, bagaimana Anda menempatkan versi aplikasi di bagan versi aplikasi di saluran Anda ?

@grazius

Bagan memberikan nilai default.yaml (tidak dapat diubah untuk setiap versi bagan) yang dapat digunakan (atau diganti) oleh konsumen bagan.
Untuk Chart.yaml itu juga merupakan bagian yang tidak dapat diubah dari bagan ... dan versi aplikasi disertakan.

Mungkin saya salah memahami apa yang Anda katakan di sini, tetapi ini memunculkan pertanyaan mengapa bahkan memiliki versi aplikasi jika tidak dapat diubah untuk setiap versi bagan? Jadi untuk setiap perubahan versi aplikasi harus ada juga perbedaan pada versi grafik, bahkan jika tidak ada perubahan lain yang dilakukan pada grafik? Jika demikian mengapa bahkan memiliki versi grafik atau versi aplikasi sama sekali?

Saya pikir ini juga bertentangan dengan apa yang diminta, "Sediakan cara untuk mengatur .Chart.AppVersion saat menginstal atau memutakhirkan tanpa mengedit Chart.yaml" Saya percaya apa yang dikatakan @timothyclarke sebelumnya dalam obrolan ini merangkum hal-hal yang cukup bagus: https:/ /github.com/helm/helm/issues/8194#issuecomment -671331311

Saya pikir hal lain yang penting untuk diingat adalah bahwa tidak semua orang memiliki kendali atas bagan yang digunakan, tetapi mungkin memiliki kemampuan untuk meneruskan gambar yang digunakan dan nilai-nilai lain ke dalam bagan pada saat penerapan. Dalam hal ini, bagaimana Anda menyarankan memperbarui versi aplikasi yang digunakan?

Masalah yang sama di sini!
Mempertimbangkan penggunaan flag --description sebagai solusi untuk menyediakan beberapa cara untuk menampilkan versi aplikasi di helm list

Versi aplikasi sangat diperlukan saat Anda membuat bagan payung. Untuk bagan komponen, minat untuk membuat versi bagan dan versi aplikasi secara terpisah menurut saya sangat rendah.

Mungkin masalah utamanya adalah jenis di Chart.yaml tidak cukup tepat? Tidak ada cara untuk membedakan payung, bagan bersama atau aplikasi

@grazius Itu
Meskipun mungkin berlaku untuk banyak proyek sumber terbuka, itu tidak berlaku untuk banyak bangunan sumber tertutup. Harap tinjau kembali utas ini termasuk semua berbagai pernyataan dan kasus penggunaan yang dibuat karena permintaan ini bukan permintaan untuk menghapus .Chart.AppVersion dari spesifikasi bagan. Bahkan bukan permintaan untuk menutupi APP VERSION dari output helm ls .
Utas ini adalah permintaan untuk membuat Chart.AppVersion dikonfigurasi pada saat bagan digunakan (tanpa harus membangun kembali atau mengubah bagan) sehingga bidang APP VERSION dari helm ls tidak menyesatkan.

Seperti berdiri, saya saat ini berpendapat bahwa APP VERSION adalah bidang yang berlebihan di helm ls dan tidak boleh terlihat oleh perintah runtime karena seberapa dekat .Chart.AppVersion terkait dengan .Chart.Version . helm inspect chart --version <.Chart.Version> <.Chart.Name> memberikan informasi yang sama.
Saya juga akan memperluasnya ke dalam penggunaan .Chart.AppVersion untuk digunakan sebagai tag penampung karena semuanya adalah hal yang sedikit berbeda yang dapat diversi secara independen untuk alasan yang valid, tetapi saat ini diseret menjadi satu hal.
Saya telah mencoba untuk mempertahankan pendapat saya tentang hubungan itu di luar permintaan ini karena proyek dapat memiliki alasan yang sepenuhnya valid untuk hubungan semacam itu. Dengan tidak memaksakan proses yang sama kepada semua orang yang menggunakan helm, kami menjadikan helm sebagai alat yang lebih baik dan lebih inklusif.
Saya tidak berpikir perubahan yang diminta ini mengurangi kendali atau memaksa penggunaannya ke orang lain.

@bacongobbler Bisakah Anda mengomentari ini? Ini adalah fitur yang sangat diminta

Ini adalah fitur yang sangat diminta

Hai, @jasondamour - terima kasih atas minat Anda! Dua opsi bagus: membuat plugin helm , dan menulis HIP .

Hai, mungkin solusi terbaik adalah memberikan argumen rilis-aplikasi-versi untuk perintah install/upgrade yang jika ada menimpa tampilan versi aplikasi ketika kita melakukan daftar helm.?