Helm: Proposal: Izinkan templating di values.yaml

Apakah Anda mengusulkan interpolasi nilai literal dari file _values.yaml_ hipotetis ini ke dalam templat bagan, dan kemudian menginterpolasi seluruh templat itu lagi untuk memperluas nama rilis (untuk menggunakan contoh Anda), atau apakah Anda membayangkan menginterpolasi file _values.yaml_ terlebih dahulu, dan kemudian memperlakukan bentuknya yang diperluas sebagai input untuk menginterpolasi sisa templat bagan?

Ini telah dibahas panjang lebar sebelumnya, dan karena berbagai alasan teknis hal ini bermasalah. Tetapi solusi yang jauh lebih tidak bermasalah adalah mendukung perluasan hal-hal yang terlihat dan berperilaku seperti variabel lingkungan.

Jadi, misalnya, Anda dapat melakukan myval: ${RELEASE_NAME}.foo.bar di values.yaml Anda.

Di sisi Golang, itu harus sesederhana memanggil os.Exand() dengan daftar variabel khusus yang harus diperluas.

Untuk poin @seh , agak sulit untuk memutuskan _kapan_ Anda ingin menjalankan ekspansi. Saya pikir Anda ingin melakukannya setelah nilai digabungkan, tetapi sebelum nilai dikirim ke mesin template. Itu akan membawa peringatan bahwa variabel harus direpresentasikan sebagai YAML yang terbentuk dengan baik. Tapi saya pikir itu bisa diterapkan

@seh Saya pribadi membayangkannya sebagai sesuatu yang lebih dekat dengan opsi pertama, di mana nilai literal ditempatkan ke dalam template sebelum rendering.

@technosophos mengingat itu, saya pikir apa yang Anda sarankan terdengar seperti solusi yang baik.

Salah satu tantangan dengan sistem yang bekerja seperti ini adalah interpolasi sederhana seringkali tidak cukup. Nilai pengganti harus masuk sebagai pengganti yang valid secara leksikal, yang kemudian mengarah pada keinginan beberapa fungsi yang tersedia mengubah nilai yang diberikan menjadi sesuatu yang sesuai.

Saya belum menentang gagasan itu; kita hanya perlu curiga bahwa penggantian sederhana yang disinggung oleh @technosophos di atas ternyata sudah cukup.

Tapi jika masuk melalui file values.yaml, transformasi dan validasi masih bisa terjadi di template, kan? Misalnya: myPort: ${port} masih bisa diakses di template seperti ini: {{ .myPort | int }} .

Kendala yang lebih besar adalah bahwa file values.yaml HARUS selalu berupa file YAML yang valid.

Batasan itulah yang ada dalam pikiran saya: Apa yang terjadi jika variabel "port" memegang nilai

"sebuah

atau urutan lain yang membuat YAML tidak valid? Seperti yang Anda katakan, ada batasan sintaksis yang perlu diingat, meskipun seseorang dapat mengatasinya:

myport: '${port}'

Benar, jadi nilainya harus diloloskan atau dikutip dengan cara tertentu, misalnya di values.yaml:

portValue: "{{ .myPort | int }}"

Berdasarkan kasus di mana saya menginginkan ini sejauh ini, saya menduga templating lengkap diperlukan, bukan hanya interpolasi sederhana.

Ide untuk menginterpolasi nilai literal dari values.yaml ke dalam template, dan kemudian menginterpolasi template lagi jika nilai literalnya benar-benar template menarik, tapi sepertinya itu akan tergantung pada bagaimana template ditulis. misalnya ini tidak akan berfungsi seperti yang diharapkan:

nilai.yaml:

otherServiceName: "{{ .Release.Name }}-my-service"

penyebaran.yaml

otherService: {{ .Values.otherServiceName | lower }}

Apakah ada masalah dengan interpolasi values.yaml terlebih dahulu (jelas tanpa akses ke .Values ) dan kemudian menggunakan values.yaml yang dihasilkan untuk menginterpolasi template lain?

@braedon Ya, ada beberapa masalah:

1. File values.yaml HARUS YAML yang valid dalam keadaan tidak diuraikan. Ini menempatkan batasan menarik pada arahan templat.
2. Nilai digabungkan secara bertahap, dan beberapa tahapan tidak memiliki akses ke subsistem template (yaitu, resolusi --set, batasan requirements.yaml, dan operasi penggabungan -f.)
3. Semua nilai harus dihitung sebelum bagian tertentu dari sistem template dapat diinisialisasi. Jika tidak, {{ define }} dan {{ include }} tidak dapat diprediksi, dan {{ template }} juga tidak berfungsi.

Pada dasarnya, sintaks env var cukup mudah untuk disematkan di values.yaml sehingga kita dapat melakukannya tanpa banyak kerumitan. Tetapi menggunakan templat yang lengkap adalah tugas besar, dan bahkan jika berhasil, itu akan menghasilkan serangkaian laporan bug yang tak berkesudahan yang diajukan ketika orang-orang mencapai kasus tepi.

Tapi saya pasti melewatkan sesuatu... Saya tidak mengerti contoh Anda di atas. Yang sedang diusulkan adalah:

nilai.yaml

otherServiceName: "${RELEASE_NAME}-my-service"

penyebaran.yaml

otherService: {{ .Values.otherServiceName | lower }}

Urutan operasi akan membuat values.yaml dirender setelah objek Rilis dibuat, tetapi sebelum template dikompilasi atau dirender. Jika nama Rilis adalah FOO , hasil di atas adalah otherService: foo-my-service .

@technosophos Saya membayangkan menjalankan mesin templating pada file values.yaml sebelum penguraian/penggabungan/dll lainnya. dari file telah selesai (jika fitur ini tidak berhasil, saya telah mempertimbangkan untuk menjalankan sistem templating terpisah untuk menghasilkan file values.yaml untuk kemudian diteruskan ke Helm).

Sepertinya itu harus menghindari masalah 1 dan 2, dan menjadi sistem yang cukup intuitif untuk grok? Saya tidak tahu seberapa sulit untuk mengimplementasikannya dalam basis kode Helm, dan 3 masih akan menjadi masalah (tidak yakin seberapa membatasi pelarangan fungsi-fungsi itu?).

Contoh saya mengacu pada solusi yang didiskusikan @seh dan @benjigoldberg , bukan proposal Anda.
Dalam proposal mereka (dengan asumsi saya memahaminya dengan benar) contoh saya akan menghasilkan ini setelah pass pertama:

otherService: {{ .release.name }}-my-service

(yaitu nilai mentah otherServiceName dari values.yaml akan diteruskan ke deployment.yaml, dan huruf kecil)
Yang kemudian tidak akan berjalan sebagaimana dimaksud pada lintasan kedua.

Apa yang saya pikirkan adalah:

Jika ada file /templates/values.yaml , maka logikanya adalah membaca variabel dari /values.yaml untuk merender template, dan kemudian values.yaml yang dirender mengambil alih sepenuhnya, sebelum semua template lain dirender . Dengan kata lain, /values.yaml mem-bootstrap template.

Saya juga mengalami kasus penggunaan yang menurut saya akan mendapat manfaat dari ini. Saya menduga ini mungkin mirip dengan contoh otherService @braedon .

Masalah yang saya hadapi adalah saat ini tidak mungkin untuk memasukkan .Release.Name saat mengganti nama layanan melalui values.yaml . Kasus penggunaan untuk ini adalah ketika membangun bagan yang sepenuhnya dipisahkan yang kemudian dapat dihubungkan bersama menggunakan bagan induk.

Misalnya, bagan elasticsearch dapat memiliki nilai serviceNameOverride dalam file values.yaml yang memungkinkan pengguna mengganti nama layanan. Demikian pula, bagan kibana dapat memiliki nilai elasticsearch.host dalam file values.yaml yang dapat digunakan pengguna untuk mengatur lokasi cluster elasticsearch. Bagan ini tidak tahu apa-apa tentang detail implementasi satu sama lain. Mereka independen dan akan memungkinkan pengguna untuk, misalnya, menyebarkan kibana untuk memantau cluster elasticsearch yang ada yang tidak digunakan dengan helm.

Idealnya, bagan independen ini juga dapat digunakan sebagai blok penyusun untuk membuat bagan induk "elasticsearch-kibana" yang "menghubungkan" mereka bersama-sama melalui subchart. Bagan induk akan menghubungkan layanan bersama dengan mengatur yang berikut di values.yaml :

elasticsearch.serviceNameOverride: {{ .Release.Name }}-elasticsearch
kibana.elasticsearch.host: {{ .Release.Name }}-elasticsearch

Saat ini dimungkinkan untuk melakukan ini tanpa menyertakan {{ .Release.Name }} dalam nilai, tetapi tidak nyaman karena akan mencegah pengguna menginstal beberapa bagan "induk" di namespace yang sama tanpa mengubah file nilai untuk setiap penginstalan.

@alexbrand Anda dapat menggunakan fungsi tpl untuk merender nilai yang berisi variabel:

nilai.yaml

elasticsearch.serviceNameOverride: {{ .Release.Name }}-elasticsearch
kibana.elasticsearch.host: {{ .Release.Name }}-elasticsearch

template.yaml:

name: {{.Values.elasticsearch.serviceNameOverride | quote | tpl }}

@eicnix Untuk melakukan itu, Anda harus memiliki kendali atas template.yaml di subchart, dan ingin secara eksplisit menambahkan dukungan untuk ini di mana pun diperlukan.

Apa yang saya cari adalah cara untuk menulis bagan induk yang melakukan hal semacam ini sambil memperlakukan subbagan sebagai kotak hitam. Saya pikir itu juga yang dikatakan @alexbrand ?

Seseorang di atas telah merujuk ke fungsi tpl yang baru saja ditambahkan (#1978). Saya mungkin salah memahami beberapa kerumitan yang terlibat di sini, tetapi untuk kasus penggunaan saya dan beberapa lainnya yang dijelaskan di atas, semua yang tampaknya diperlukan adalah melewati nilai implisit yang mengevaluasinya melalui tpl atau yang setara, sebelum merender template . (Saya kira Anda mungkin perlu terus melakukan pass sampai tidak ada perubahan yang dibuat, untuk mengatasi referensi rekursif.) Saya kira Anda mungkin ingin meminta ini diaktifkan melalui, katakanlah, argumen --expand-values pada perintah baris, tetapi apakah ada masalah lain dengan solusi seperti itu?

@eicnix Terima kasih atas sarannya!

Saya tidak dapat membuat pipa di template.yaml berfungsi tetapi pekerja di bawah ini untuk saya (dengan values.yaml di atas):

template.yaml

name: {{ tpl .Values.elasticsearch.serviceNameOverride . }}

Saya pikir ini dan #2133 adalah masalah yang sama, BTW. (Tidak yakin mana yang terbaik untuk tetap terbuka.)

Kami tampaknya baik-baik saja di 2.6.1 server Helm (tetapi tidak di 2.3.0)

@obriensystems dapatkah Anda menguraikan pemikiran itu sedikit lagi? :)

Apa yang tampaknya baik-baik saja tentang proposal untuk v2.6 ini tetapi tidak untuk v2.3? Mungkin Anda mengacu pada tiket lain?

Saya suka pendekatan yang diusulkan oleh @travishaagen dan @braedon . Saya juga bisa membayangkan menggunakan beberapa argumen -f values.yaml, misalnya

helm install -f raw_values.yaml -tf values_rendered_with_templating.yaml ...

Pertama akan terbaca raw_values.yaml yang harus valid yaml. Kemudian helm akan membaca values_rendered_with_templating.yaml dan menjalankan ini melalui mesin template yang memiliki akses ke variabel di raw_values.yaml . Template yang dirender kemudian diumpankan ke tahap berikutnya dan seterusnya.

Saya telah menggunakan tf pada baris perintah di atas untuk memberi sinyal bahwa itu adalah file nilai yang harus dirender dengan templat sebelum digunakan. Struktur file yang diusulkan oleh @travishaagen akan menjadi pengaturan default.

Masalah ini bersama dengan #2399 adalah pemblokir yang cukup besar yang sangat memengaruhi pembuatan bagan induk dari bagan anak. Seperti yang terjadi sekarang, helm tidak mengizinkan komposisi bagan untuk hal-hal non-sepele. Saya ingin tahu apakah ada solusi yang lebih baik untuk menyusun bagan yang akan menyelesaikan masalah yang ada serta #2399.

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

Saya kira kita tidak perlu mempersulit helm untuk melakukan ini. Misalnya, alat sederhana seperti https://github.com/roboll/helmfile dapat digunakan untuk templating nilai.

@mumoshu Saya mengalami beberapa kasus di mana saya memerlukan akses ke nama rilis di values.yaml (terbaru ini bagan Kafka yang dapat diatur untuk tidak menggunakan Bagan Zookeeper sebagai persyaratan, tetapi kemudian perlu lokasi Zookeeper sebagai Value , yang dalam penerapan kami didasarkan pada nama rilis...). Namun saya ingin tidak memerlukan beberapa alat tambahan dan menerapkannya pada pengguna kami untuk mencapai ini :senyum:

@NicolasT Terima kasih telah membagikan kasus penggunaan Anda 👍

Anda mungkin sudah tahu tetapi untuk siapa pun yang belum ada di sana - Anda dapat memberi nama Zookeeper Anda merilis nama konkret dengan helm install incubator/zookeeper --name myzookeeper dan kemudian menggunakan kembali nama itu sebagai nilai rilis Kafka.

Dan kasus penggunaan Anda tampaknya tidak didukung oleh solusi yang disarankan di utas ini. Maaf jika saya tidak mengikuti Anda, tetapi Anda tidak dapat mengakses nama rilis lain dari rilis independen lain, bukan?

Anda tampaknya lebih banyak tentang "memperluas apa yang dapat direferensikan dari templat" daripada "mengizinkan templat dalam nilai".

Namun saya ingin tidak memerlukan beberapa alat tambahan dan menerapkannya pada pengguna kami untuk mencapai ini

Saya sangat setuju
Alat lengkap untuk mendukung kasus penggunaan semua orang benar-benar merupakan anugerah.

Sebenarnya, saya pernah berharap jika helm dapat berintegrasi dengan manajer alur kerja deklaratif dengan fitur resolusi ketergantungan layanan dinamis (kasus penggunaan Anda) seperti atlassian/smith .

Bayangkan solusi terintegrasi Helm CRD + Smith - semoga dengan elegan menyelesaikan masalah Anda?

Namun, di sisi lain, saya merasa bahwa mengintegrasikan/menerapkan mesin alur kerja yang serius seperti itu ke dalam alat untuk tujuan lain akan menjadi mimpi buruk dalam hal pemeliharaan.

Jadi, saya lebih suka inti helm tetap sederhana dan sistem plugin helm diperpanjang entah bagaimana untuk mendukung titik ekstensi seperti "transformator nilai" yang mampu mengubah values.yaml sebelum diteruskan dari satu ke yang lain. Hmm, kedengarannya seperti hampir pandai besi!

Kasus penggunaan utama saya adalah #2506. Dalam kasus umum, saya memerlukan bagan induk untuk dapat meneruskan nilainya sendiri ke subbagan tanpa harus mengetahui nilai-nilai itu pada waktu paket.

Halo guru, saya bingung dengan diskusi ini. Solusi yang diusulkan tidak dapat menyelesaikan masalah kasus penggunaan saya:

nilai.yml:
ui_rahasia:# Menggunakan "{{ tpl randAlpha 8 }}" di sini melaporkan kesalahan.

template1.yml:
UI_RAHASIA: {{ .Nilai.ui_rahasia }}

template2.yml:
UI_RAHASIA: {{ .Nilai.ui_rahasia }}

Saya tahu param ui_secret dapat dibuat di luar helm dan meneruskannya melalui --set 'ui_secret=xxx'. Tapi mengapa tidak membiarkan helm menghasilkan nilai acak default?
Nilai acak default dapat digunakan untuk salt/password/ca_certificate/certificate_pair, dll.

Tapi mengapa tidak membiarkan helm menghasilkan nilai acak default?

Hai! Bagaimana Anda ingin mencapainya?

Bagi saya, templating di values.yaml sepertinya tidak menyelesaikannya. Bagaimana jika Anda memiliki nilai IMAGINARY.yaml seperti:

ui_secret: "{{ randAlpha 8 }}"

dan Anda menjalankan helm upgrade --install yourrelease yourchart -f values.yaml beberapa kali?
Bagi saya, sepertinya tidak ada cara untuk helm/anakan kapan harus melakukan/tidak menghasilkan file ui_secret.

Jadi, saya yakin Anda harus memberikan rahasia yang telah dibuat sebelumnya melalui --set seperti yang Anda catat, terlepas dari proposal ini diterima atau tidak.

Sebagai gantinya, apakah mungkin bagi Anda untuk hanya menghasilkan nilai acak di dalam rahasia k8s?
Sehingga semua pod yang dibuat melalui bagan helm Anda dapat merujuk rahasia dengan namanya.

@mumoshu untuk skenario peningkatan:
1) jika ui_secret diatur dalam values.yaml, maka tidak ada dampak;
2) helm lain harus mengambil values.yaml yang ada dari suatu tempat (mungkin Tiller), lalu gabungkan values.yaml yang ada ini dengan '-f values.yaml'

helm harus mandiri untuk menghasilkan salt/password/ca_certificate/certificate_pair acak, dan tidak mengharuskan pengguna akhir untuk membuat helm luar. Ini memberikan kegunaan yang jauh lebih baik.

"menghasilkan nilai acak di dalam rahasia k8s" dapat dilakukan, tetapi tidak langsung dibandingkan dengan 'ui_secret: {{ randAlpha 8 }}'

lain helm harus mengambil values.yaml yang ada dari suatu tempat (mungkin Tiller), lalu gabungkan values.yaml yang ada ini dengan '-f values.yaml'

Tidak terlalu menyinggung tetapi tampaknya memperkenalkan lebih banyak kasus tepi.
Bagaimana helm/tiller membedakan nilai yang sudah disetel atau belum, dan kapan harus menimpa jika dari --set atau -f values.yaml atau tidak, mengingat nilai Anda.yaml selalu berisi ui_secret: {{ randAlpha 8 }} ?

"menghasilkan nilai acak di dalam rahasia k8s" dapat dilakukan, tetapi tidak langsung dibandingkan dengan 'ui_secret: {{ randAlpha 8 }}'

Setuju. Tapi bagaimanapun, templating sepertinya bukan solusi bagi saya.

Anda akan memerlukan mesin alur kerja seperti https://github.com/atlassian/smith untuk menangani dependensi layanan (dengan kemampuan untuk meneruskan nilai untuk dikonsumsi oleh helm install s secara berurutan, tergantung).

Saya kira Anda dapat mengirimkan permintaan fitur ke helm untuk mendukung kasus penggunaan ini (mesin alur kerja, manajemen ketergantungan layanan). Namun, saya tidak tahu apakah itu layak dalam lingkup helm/tiller.

saat memasang bagan, '--set' > '-f values.yaml' > values.yaml di bagan
saat memutakhirkan bagan, '--set' > '-f values.yaml' > menghasilkan values.yaml untuk bagan yang diinstal

Apa yang saya usulkan diimplementasikan di BOSH https://bosh.io/docs/variable-types.html. BOSH mendukung definisi tipe variabel eksplisit, sedangkan values.yaml di bagan helm mendukung yaml biasa. Jadi akan sangat bagus untuk mendukung fungsi template di values.yaml, misalnya 'ui_secret: {{ randAlpha 8 }}'.

Meskipun ini akan memberikan kegunaan yang lebih baik untuk beberapa pengguna, ini juga akan membuat helm membengkak.

Rekomendasi saya untuk menangani segala jenis rahasia dalam kombinasi dengan helm adalah mengelolanya dalam penyimpanan rahasia (rahasia kube, lemari besi, dll.) dan hanya merujuknya dari bagan.

Apa yang saya usulkan diimplementasikan di BOSH https://bosh.io/docs/variable-types.html. BOSH mendukung definisi tipe variabel eksplisit, sedangkan values.yaml di bagan helm mendukung yaml biasa

Saya telah meninjau dokumentasi Bosh tentang Interpolasi Variabel. Ternyata bagi saya bahwa Bosh tidak mendukung kedua (1) mengisi variabel dari output aplikasi Anda (objek k8s yang dibuat oleh helm/tiller dalam kasus kami), dan (2) menghasilkan nilai persisten melalui template. Lihat gagasan -v internal_ip=192.168.56.6 di https://bosh.io/docs/cli-int.html.

Bahkan Bosh tampaknya tidak mendukung kasus penggunaan Anda di luar kotak.
Kemudian, tebakan terbaik saya adalah bahwa Anda memerlukan sesuatu seperti mesin alur kerja seperti yang telah saya jelaskan sebelumnya.
Atau masih ada yang kurang..?

@johngmyers Hai! Maaf untuk mengatakannya, tetapi kasus penggunaan Anda tampaknya tidak didukung oleh templating saja.

UNTUK mendukung kasus penggunaan Anda, tidak hanya templating, helm/tiller juga perlu mengelola koordinasi bagan dan rilisnya, propagasi keluar/masuk dari rilis preseden ke bagan dependen.

AFAICS, apa yang tidak diketahui oleh helm/tiller saat ini. Melakukannya dalam lingkup helm/anakan akan sangat membengkak, seperti yang ditunjukkan @eicnix .

Untuk memisahkan diskusi, saya dapat menyarankan Anda untuk mengirimkan masalah lain. Tetapi di sisi lain, sejujurnya, saya tidak memiliki cara yang layak untuk menerapkannya di dalam helm/anakan tanpa membuatnya membengkak.

Jadi taruhan terbaik Anda adalah menyelidiki mesin alur kerja lain seperti atlassian/smith (saya tidak dibayar oleh penulis smith. tolong beri tahu saya jika ada alternatif 😉) + kemungkinan helm CRD yang akan datang.

@mumoshu Saya yakin kasus penggunaan saya cukup dijelaskan oleh #2506. Saya tidak melihat bagaimana mengirimkan masalah lain membantu.

Saya tidak melihat bagaimana templating values.yaml tidak menangani kasus penggunaan saya. Helm mendukung subchart, yang dikoordinasikan oleh requirements.yaml atau menyematkan subchart di direktori charts . Bagan induk dapat menurunkan nilai dengan sesuatu seperti:

subchart:
  serviceName: {{.Chart.Name}}
  serviceVersion: {{.Chart.AppVersion}}

Tentu saja, membuat template values.yaml bukan satu-satunya cara untuk mengimplementasikan yang memungkinkan bagan meneruskan nilai yang tidak diketahui pada waktu paket ke subbagan. Tetapi jika Helm itu "membengkak", maka menambahkan hampir semua fitur akan menjadi Helm yang "membengkak".

Mungkin kita bisa menambahkan rendering nilai terbatas sebelum proses templating. Saya hanya akan mengizinkan akses ke .Chart dan .Release untuk menghindari masalah rumit seperti misalnya referensi siklik di antara nilai. Tetapi ini masih akan menyelesaikan banyak kasus penggunaan di mana orang ingin mereferensikan rilis atau contoh bagan dari nilainya.

Saya memiliki kasus penggunaan di mana saya memerlukan bagan induk untuk menurunkan nilai yang bersumber dari .Values-nya. Hal ini memungkinkan pemisahan masalah ke dalam sub-bagan tanpa induk mengekspos fakta bahwa itu diimplementasikan menggunakan sub-bagan.

Misalnya, kita akan memiliki subchart "platform" yang merangkum hal-hal umum yang dibutuhkan oleh layanan yang diimplementasikan di perpustakaan platform dalam kita. Itu ingin memiliki nilai "platform.oauthClient" yang akan diteruskan oleh bagan layanan untuk menunjukkan apakah layanan perlu dikonfigurasi untuk menjadi klien OAuth. Implementasinya mungkin untuk meneruskan .Values.oauthClient itu ke subchart dari subchart "platform". Di masa mendatang, kami mungkin ingin mengubah implementasi fitur bagan "platform" itu menjadi sesuatu yang lain.

Nilai templat mungkin ingin ditempatkan di tempat selain values.yaml tingkat atas (mungkin templates/_values.yaml ) sehingga nilai tersebut tidak tampak sebagai bagian dari API eksternal bagan induk. Itu juga bisa mengatasi masalah referensi siklik.

@johngmyers Nilai bagan induk juga harus tersedia di bagan anak. Saya yakin metode yang saya usulkan sebelumnya juga akan menyelesaikan masalah Anda. Anda bisa membuat nilai templat di bagan induk seperti yang Anda jelaskan sebelumnya dan membiarkannya diteruskan ke bagan anak.

FYI, PR saya yang sudah terkait (mis. #3252) mengimplementasikan fitur ini dan saya pikir mungkin memenuhi berbagai kasus penggunaan ini. Kami telah menggunakannya secara internal untuk sementara waktu, dan meneruskan nilai induk ke bagan anak adalah salah satu masalah yang kami selesaikan dengannya.

PR belum membuat banyak kemajuan sejauh ini. Umpan balik apa pun, baik pada PR itu sendiri atau dari mencoba fitur dalam build, jelas sangat diterima.

@eicnix Dokumentasi Helm menyatakan:

Tetapi bagan tingkat yang lebih rendah tidak dapat mengakses hal-hal di bagan induk, jadi MySQL tidak akan dapat mengakses properti judul. Juga, dalam hal ini, tidak dapat mengakses Apache.port.

jadi sepertinya tidak mungkin.

@johngmyers Bagan anak tidak dapat mengakses nilai induk tetapi bagan induk dapat meneruskan nilai ke bagan anak. Dengan asumsi Anda memiliki bagan anak bernama mychild, Anda dapat meneruskan nilai dari parent values.yaml dengan cara ini:

mychild:
  overridenValue: true

@eicnix Tetapi nilai-nilai seperti itu harus diketahui pada waktu paket helm. Apakah Anda bahkan membaca kasus penggunaan saya?

Apakah Tim Helm mengetahui isu/usulan ini? Itu dibuat pada 25 Mei 2017, 10 bulan yang lalu. Ada banyak diskusi di sini, dan beberapa masalah duplikat/serupa dibuat.
Masalah ini belum ditetapkan kepada siapa pun.

Kami melihat komentar 'itu akan mengasapi helm'. Jadi solusi mana yang tidak membengkak? Bisakah Tim Helm memberikan rencana dan ETA untuk proposal ini dan setidaknya memberikan solusi/solusi yang masuk akal?

Tampaknya PR https://github.com/kubernetes/helm/pull/3252 dapat mendukung templating di values.yml. Jika Tim Helm berpikir demikian, tolong percepat penggabungannya.
Terima kasih.

Solusi @mparry di https://github.com/kubernetes/helm/pull/3252 tampaknya menangani kasus penggunaan saya dengan elegan. Akan luar biasa jika itu bisa digabungkan!

Sepertinya permintaan tarik yang terkait dengan masalah ini belum diterima, tetapi saya baru saja menerbitkan sebuah paket yang menghilangkan masalah yang saya lihat yang membawa saya ke masalah ini. Ini disebut Mercator dan dapat ditemukan di sini . Saya tahu itu tidak cocok dengan semua kasus penggunaan ini, tetapi semoga seseorang mungkin menganggapnya berguna!

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

@johngmyers Apakah Anda pernah menemukan solusi yang baik untuk https://github.com/helm/helm/issues/2492#issuecomment -370895073? Saya mengalami masalah enkapsulasi yang sama. Saya benar-benar ingin menghindari penulisan pembungkus untuk helm untuk secara rekursif melakukan pra-render nilai template saya ke dalam file values.yaml.

Saya tidak punya solusi yang baik. Saya memiliki solusi yang menggunakan pembuatan Helm pribadi dengan #3471 yang diterapkan, memungkinkan saya untuk (secara berlebihan) meneruskan nama dan versi bagan induk ke subbagan pada waktu paket.

Ini dan dukungan penggabungan yang buruk pada dasarnya menghalangi saya untuk melakukan enkapsulasi yang masuk akal. Saya berharap penggunaan LUA Helm 3 akan membantu masalah ini.

Untuk berbagai alasan teknis dan desain di balik cara kerja mesin rendering template Tiller, kami tidak bermaksud untuk mendukung nilai pra-pemrosesan.yaml sebagai template Go untuk Helm 2 atau Helm 3. Namun, kami sangat menganjurkan komunitas untuk menulis pembungkus atau Helm plugin yang mendukung fitur ini untuk kasus penggunaannya! Salah satu contoh yang kami dengar dari pengguna adalah gomplate , tetapi kami ingin melihat pra-prosesor lain yang dapat menyediakan fungsionalitas ini sebelum menjalankan helm install .

Untuk mengulangi komentar sebelumnya di utas ini: menambahkan dukungan untuk memperluas variabel lingkungan di values.yaml akan menjadi masalah yang mudah untuk diatasi tanpa menimbulkan banyak kerumitan pada mesin rendering, tetapi menggunakan templat yang lengkap akan menjadi tugas besar.

Bahkan jika kami dapat mendukung fitur ini, itu akan menghasilkan peningkatan yang cukup besar dari laporan bug yang diajukan ketika orang-orang akhirnya mencapai kasus edge. Mengingat ukuran volume antrian masalah saat ini dan terbatasnya jumlah pengelola dan anggota komunitas yang ikut serta untuk membantu mempertimbangkan masalah, kami tidak memiliki sumber daya manusia untuk mendukung upaya ini.

Kami mohon maaf atas ketidaknyamanan ini, dan terima kasih atas pengertiannya!

@bacongobbler - Saya awalnya membuka masalah ini sebelum saya pikir saya benar-benar memahami cara menggunakan helm secara efektif dalam alur kerja saya. Saya sepenuhnya setuju dengan keputusan untuk menutup tiket. Saya membiarkannya terbuka terutama karena akhirnya ada banyak diskusi komunitas tentang masalah ini. Sejak saya membuka tiket ini dan saya mempelajari lebih banyak alur kerja "standar", saya sebenarnya tidak berpikir saya pernah menginginkan fitur khusus ini. Jadi, bagaimanapun juga, 👍

@benjigoldberg Bisakah Anda menjelaskan bagaimana Anda berhasil menyelesaikan masalah ini? Apa yang Anda maksud dengan alur kerja "standar"? Masalah kami adalah salah satu dari sekadar dapat mengatur kata sandi yang sama di sejumlah subchart, namun hanya mengekspos satu nilai kata sandi di bagan payung tingkat atas. Untuk memperjelas, kami memiliki bagan tingkat atas untuk aplikasi kami, yang mencakup subbagan untuk prometheus dan grafana. Kami ingin kata sandi untuk ketiganya sama. Saat ini, kita harus mengekspos bagian dalam grafik, dan mengatur kata sandi tiga kali, satu per satu, yang sangat merusak enkapsulasi.

@nuwang dalam skenario jenis itu, kami biasanya akan menggunakan bagan payung tingkat atas seperti yang telah Anda jelaskan, membuat rahasia di tingkat atas, dan kemudian masing-masing bagan anak menggunakan rahasia itu untuk mengakses kredensial. Semoga membantu -- mungkin juga saya salah memahami deskripsi Anda. Biarkan aku tahu!

@benjigoldberg Bagaimana jika Anda tidak mengontrol subchart? grafana adalah pihak ke-3 misalnya. Kami tidak dapat dengan mudah mengubah templatnya untuk menggunakan rahasia yang ditentukan dalam bagan payung.

@dtshepherd kami pasti mengalami masalah itu -- dalam skenario tersebut kami telah membuat repo bagan kemudi dan menyumbangkan opsi kembali ke hulu dan kemudian menggunakan bagan bercabang kami sendiri hingga perubahan digabungkan (kemudian kami bermigrasi kembali ke repo utama bagan). Ada bagian-bagian yang bergerak, tetapi hari-hari ini hal itu tidak banyak terjadi lagi. Repo grafik utama telah cukup matang dan banyak grafik memiliki fleksibilitas ini di luar kotak.

Ya, sebagian besar templat bagan pihak ke-3 baik-baik saja. Namun, jika saya memiliki bagan pembungkus untuk merangkum bagan pihak ke-3 tersebut, saya tidak dapat menormalkan beberapa variabel umum tanpa meletakkan tpl di bagan pihak ke-3.

@dtshepherd Anda dapat mengontrol nama variabel/rahasia dari file nilai tingkat atas dan kemudian mendorongnya ke subchart, bukan?

Dalam kasus Elasticsearch/Kibana, nama layanan diturunkan dari nama rilis. Tapi itu tidak _sama_ dengan nama rilis. Adakah yang bisa menyarankan cara meneruskan nama layanan yang dihasilkan ke Kibana hanya menggunakan penggantian nama variabel?

@benjigoldberg Ya, tapi itu merusak enkapsulasi karena bagan tingkat atas perlu mengetahui nama variabel di bagan pihak ke-3. Bagan di tengah harus berupa lapisan abstraksi, tetapi tidak boleh tanpa file template values.yaml.

@benjigoldberg Terima kasih atas balasannya. Alasan mengapa kita tidak bisa menggunakan secret, adalah karena nama secret harus diteruskan ke subchart sebagai variabel tunggal. Namun, karena file nilai tidak mendukung templating, Anda harus memberikan nama konstan yang dikodekan secara keras, tanpa nama rilis yang diawali dengannya (karena nama rilis adalah variabel, tentu saja, yang perlu ditemplat). Ini berarti bahwa Anda hanya dapat memiliki satu contoh bagan yang dipasang per namespace, yang merupakan batasan yang tidak dapat diterima bagi kami. Itu cukup banyak menghilangkan penggunaan rahasia sebagai opsi, dan kami jatuh kembali ke dalam perangkap karena harus memodifikasi bagan pihak ketiga yang tidak kami kendalikan, atau secara individual memasukkan kata sandi tiga kali dalam kasus kami, sepenuhnya mengekspos detail implementasi dari grafik payung.

Jadi dengan satu atau lain cara, ini merusak enkapsulasi, merusak rilis unik, merusak KERING, dan seringkali, kombinasi dari semua hal di atas.

Beberapa lagi yang kami temui yang muncul di pikiran saya:

• Klaim volume persisten yang perlu dibagikan di antara beberapa subchart, tetapi juga harus mendukung beberapa rilis.
• Variabel bersama yang disediakan pengguna, yang perlu didorong ke beberapa subchart.

Ketidakmampuan Helm untuk merangkum ini adalah titik sakit utama bagi kami. Beberapa minggu yang lalu saya memperingatkan perusahaan layanan cloud besar dari Helm atas masalah ini.

Tiket ini agak terlalu dibatasi. Persyaratannya adalah mengizinkan bagan induk untuk meneruskan nilai ke sub bagan yang nilainya tidak diketahui pada waktu paket, tetapi diturunkan dari bagan induk sendiri .Value , .Chart , dan/atau .Release . Saya percaya templating diperlukan, tetapi tidak harus di values.yaml.

Proposal saya di atas dari templates/_values.yaml mungkin menjadi salah satu cara untuk mencapai ini tanpa kondisi tepi dan kompleksitas #2133. Pengelola telah menyatakan bahwa mereka tidak akan mendukung templating values.yaml, tetapi tidak jelas apakah mereka akan mempertimbangkan proposal templating nilai alternatif semacam itu.

Ada banyak komentar bagus seputar masalah ini. Saya ingin memberikan lebih banyak kejelasan seputar keputusan ini dan mencoba menggabungkan semua informasi yang tersebar di berbagai isu dan PR. Pertama, saya benar-benar mengerti bahwa ini akan menyelesaikan beberapa kasus penggunaan yang menyakitkan. Saya bukan hanya pengelola Helm, tetapi saya menulis _banyak_ grafik dan pernah mengalami masalah ini sebelumnya. Namun, ada beberapa alasan besar mengapa kami tidak ingin menerapkan ini:

tl; dr
Paling sederhana, alasan di balik tidak ingin melakukan ini adalah Anda tidak membuat template file yang menyediakan nilai yang Anda gunakan untuk template. Selanjutnya, fitur ini akan dibuat usang oleh Helm 3

Membuat urutan dan logika
Jika Anda membuat template file yang Anda berikan nilai, itu menimbulkan sejumlah besar kerumitan dalam urutan rendering, dependensi nilai melingkar, dan bug/kegagalan logika. Saat Anda mulai menambahkan blok logika penuh ke nilai, itu adalah titik kegagalan lain saat mencoba merender manifes. Ini membuat segalanya lebih sulit untuk di-debug dan didiagnosis (karenanya komentar tentang jumlah bug yang akan dihasilkannya). Itu juga membuat templat lebih sulit untuk ditulis karena Anda harus memperhitungkan variabilitas yang diperkenalkan oleh file nilai templat

Kompatibilitas mundur
File nilai templating memperkenalkan sintaks non-YAML ke dalam file YAML. Ini kemungkinan akan merusak solusi templating yang ada yang menghasilkan values.yaml. Berbicara dari pengalaman, saya telah menggunakan file nilai yang dihasilkan di mana memiliki non-YAML dalam file akan merusak alur kerja kami. Mengingat bahwa banyak orang sudah memiliki perkakas di sekitar nilai Helm, ini akan membuat file nilai yang ditemplat menjadi pemutus kompatibilitas mundur. Saya akui kami belum sempurna dalam mempertahankan kompatibilitas mundur, tetapi sebagian besar kami telah melakukan pekerjaan yang layak dalam mempertahankannya, dan fitur seperti ini pasti akan merusak alur kerja yang ada.

Kompleksitas bahasa
File nilai template akan memerlukan dialek kustom go-template karena YAML itu sendiri tidak dapat menjadi template saat diteruskan sebagai bagian dari rilis. Ini juga memperkenalkan kerumitan pembuatan konteks khusus untuk mengevaluasi template sebelum langkah lainnya.

Usang oleh Helm 3
Di Helm 3 sebagai bagian dari sistem eventing/hook, kami akan mengizinkan modifikasi nilai berbasis Lua dengan cara yang jauh lebih mudah daripada harus membuat template keluar. Mengingat kami sedang mengembangkan Helm 3 dengan baik, menambahkan fitur dengan semua kekurangan yang disebutkan di atas akan menyebabkan lebih banyak churn daripada nilai tambah. Jadi kami tidak menolak ini secara langsung, tetapi menerapkannya (walaupun dengan cara yang berbeda) untuk Helm 3

Semoga ini memperjelasnya lagi untuk semua orang!

Terima kasih telah meluangkan waktu untuk memberikan klarifikasi terperinci ini @thomastaylor312 , yang membuat keputusan ini jauh lebih baik.

Saya pikir masalah intinya adalah memisahkan antarmuka eksternal bagan, dari detail implementasi internalnya. Itu tampaknya memerlukan beberapa mekanisme sederhana untuk memisahkan apa yang diperlihatkan bagan sebagai file nilai eksternal, dari bagaimana nilai-nilai itu diubah dan didistribusikan ke subbagan pihak ketiga, bahkan di Helm 3. Kait peristiwa Lua mungkin menjadi jawabannya, atau mungkin itu akan terlalu rumit untuk apa yang seharusnya menjadi fitur bawaan, tetapi sulit untuk mengevaluasinya dari posisi ketidaktahuan saya. Jadi harap pertimbangkan ini sebagai permintaan fitur untuk Helm 3 dan terima kasih atas semua kerja keras yang dilakukan Helm - senang menggunakannya!

xref: https://github.com/helm/community/blob/master/helm-v3/002-events.md

Terima kasih atas umpan balik yang bagus @nuwang! Kami akan memastikan untuk mempertimbangkannya dengan semua pekerjaan Helm 3

Berikut ini adalah solusi untuk ini.

Hanya menulis beberapa ekspresi template di values.yaml sebagai string yaml biasa.
Suka.

helloworld: Hello World!!
sometemplate: '{{ .Values.helloworld }}'

Dan menggunakan tpl untuk mengevaluasi sometemplate dalam file template.

{{ $global := . }}
{{ tpl (trimAll "\"'" .Values.sometemplate) $global }}

Outputnya akan menjadi

Halo Dunia!

@wpc009 ya, itu berhasil, satu-satunya ketidaknyamanan adalah tpl mengevaluasi string hanya sekali yang bukan hal yang buruk tetapi sesuatu yang harus Anda ingat:

publicHost: "{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}"
callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}/validate" # this will work
# callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ paymentgw.publicHost }}/validate" # this will not

@wpc009 ya, itu berhasil, satu-satunya ketidaknyamanan adalah tpl mengevaluasi string hanya sekali yang bukan hal yang buruk tetapi sesuatu yang harus Anda ingat:

publicHost: "{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}"
callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}/validate" # this will work
# callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ paymentgw.publicHost }}/validate" # this will not

Itu benar. nilai yang direferensikan harus konstan.
Atau Anda perlu menulis tpl bersarang.

@eicnix Mencoba {{ .Values.labels | quote | tpl | toYaml | indent 4 }} , tetapi mendapat kesalahan ini: executing "financial-accounting/templates/worker-deployment.yaml" at <tpl>: wrong number of args for tpl: want 2 got 0 .

nilai.yaml

labels:
  revision: revision-{{ .Release.Revision }}-{{ .Release.Revision | quote | b64enc }}

development.yaml

metadata:
  labels:
{{ .Values.labels | quote | tpl | toYaml | indent 4 }}

Saya membuatnya bekerja dengan:

nilai.yaml

dbName: test_{{ .Release.Namespace }}

penyebaran.yaml

env:
  - name: DB_NAME
    value: {{ tpl .Values.dbName . | quote }}

Saya menggunakan pengontrol ekspos fabric8.io, yang memberikan URL default ke layanan yang terbuka. Sekarang saya ingin membuat URL khusus berdasarkan namespace, Sesuatu seperti
fabric8.io/exposeUrl: https://{{ tpl .Release.Namespace }}.jx.org.co , sesuatu yang akan dipilih oleh pengontrol eksposur, jadi saya tidak memiliki opsi untuk menggunakan {{ tpl ... }}. Apakah ada cara agar resolusi nama dapat dilakukan di values.yaml itu sendiri?

Beberapa solusi yang telah ditunjukkan orang lain di berbagai sub-utas:

1. gunakan nilai global Helm untuk meneruskan variabel dari induk ke anak ( ref ).
2. gunakan jangkar YAML untuk meningkatkan KEKERINGAN dalam file values.yaml Anda ( ref , terima kasih @szwed).

Ini tidak mencakup semua kasus penggunaan, namun mereka bagus untuk ada di sabuk alat Anda.

Saya juga ingin membuat template di values.yml saya Sebagian besar untuk menumpuk kompleksitas dan konfigurasi spesifik menggunakan grafik. Jadi saya mulai dengan bagan umum, buat bagan saya sendiri di atas yang memiliki sebagian besar konfigurasi dan meninggalkan beberapa detail akhir untuk ditentukan saat penggelaran. Jangkar YAML tidak cukup: mereka tidak dapat mengganti nilai YAML di dalam (seperti string file konfigurasi multiline), dan tidak memiliki logika ketergantungan Helm seperti nilai subchart.

Saya yakin kita memerlukan fitur yang lebih canggih untuk membuat diagram layer tanpa mengubah diagram yang mendasarinya untuk membangun komunitas diagram Helm. Bagan komunitas hulu sekarang diperlukan untuk mengaktifkan semua berbagai kasus penggunaan dalam logika yang kompleks, bukan dalam lapisan. Dan logika ini membutuhkan perubahan upstream untuk mengaktifkan banyak fitur, dimana layering akan membutuhkan perubahan upstream yang jauh lebih sedikit. Lihat saja semua properti yang terekspos di sebagian besar bagan komunitas, inkonsistensi dalam properti dan cara kerja ini, dan duplikasi dalam file _helpers.tpl. Dan yang terburuk, setiap bagan komunitas diharuskan untuk secara eksplisit mengaktifkan pengaturan ini sendiri. Usaha yang sia-sia.

@nicorikken Sry untuk plug tak tahu malu tapi saya sarankan mencoba helmfile untuk nilai template dan layering templated helm releases dan helm-x untuk memodifikasi grafik tanpa forking, dan bahkan kombinasi helmfile + helm-x.

Saya setuju bahwa kami membutuhkan sesuatu untuk menangani masalah yang Anda sebutkan. Di sisi lain saya tidak ingin scope-creep helm. Itu sebabnya saya mulai memelihara dua proyek out-of-tree sendiri.

@mumoshu Terima kasih untuk stekernya. Saya melihatnya disebutkan sebelumnya sebagai solusi potensial. Aku akan melihatnya. Ini akan membawa biaya perkakas tambahan, yang mungkin harus kita integrasikan dengan Argo-CD juga (apakah itu mungkin?). Untuk saat ini saya telah melakukan fork repo dan membuat parameter namespace, dan membuat PR ke repo grafik stabil hulu. Mari kita lihat apa yang dibuat oleh pengelolanya.

@nicorikken Terima kasih telah membalas!

Saya pikir saya mengerti biaya perkakas tambahan. Tetapi di sisi lain saya mempertanyakan diri saya sendiri - jika ada alat besar yang mencakup semua kasus penggunaan helm + helm + helm-x, apakah akan mudah dipelajari/digunakan?

IMHO ini hampir masalah dokumentasi. Jika alat tambahan memiliki dokumentasi yang cukup baik untuk mengintegrasikannya dengan alat upstream dan alat pihak ketiga (helm dan argo cd dalam kasus khusus ini), itu sebanding dengan solusi in-tree.

apakah itu mungkin?

Yap :) helmfile template bermain dengan baik dengan fitur "plugin manajemen konfigurasi" argo-cd.

Untuk kasus penggunaan khusus dalam menentukan namespace, saya telah membuat PR hulu ke bagan Jenkins Helm https://github.com/helm/charts/pull/15202 Ini menambahkan parameter namespaceOverride . Saya berharap pola ini akan diadopsi secara lebih luas, untuk memungkinkan penerapan diagram Helm di seluruh kluster.
Saya harus meluangkan waktu untuk melihat lebih jauh ke dalam Helmfile. Tampaknya memenuhi persyaratan kami dengan mengaktifkan templating tingkat klaster lanjutan di atas bagan upstream, dan berintegrasi dengan Argo-CD.

Adakah yang tahu bagaimana melakukan ini ketika mengatur sesuatu untuk aturan affinity ? Misalnya, pada bagan Ingress NGINX di stable/nginx-ingress , saya ingin menetapkan nilai controller.affinity menjadi sebagai berikut:

nilai.yaml

controller:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 5
        podAffinityTerm:
          topologyKey: "kubernetes.io/hostname"
          labelSelector:
            matchLabels:
              app: {{ template "nginx-ingress.name" . }}
              component: "{{ .Values.controller.name }}"
              release: {{ .Release.Name }}

Menggunakan {{ tpl .Values.controller.name }} untuk kunci component berfungsi, tetapi saya juga membutuhkan bagian app dan release , yang tidak berfungsi seperti yang muncul di atas.

Apakah ada orang lain yang perlu memanggil fungsi downstream template dan nilai Release.Name ?

@sc250024 Hei! Di mana Anda mendefinisikan template nginx-ingress.name di template values.yaml Anda?

Itu perlu didefinisikan sebelumnya dengan {{define ... seperti yang dijelaskan di https://golang.org/pkg/text/template/#hdr -Actions

Juga - {{.Release.Name}} hanya berfungsi dalam string di bawah releases[].values di helmfile.yaml .

Ini harus bekerja:

releases:
- ...
  values:
  - {{`{{.Release.Name}}`}}/values.yaml

Ini tidak berfungsi:

releases:
- ...
  values:
  - foo: {{`{{.Release.Name}}`}}/values.yaml

Saya pikir itu layak permintaan fitur khusus jika Anda memerlukan salah satunya.

@mumoshu itu tidak didefinisikan dalam file nilai saya, itu adalah sesuatu yang termasuk dalam bagan Helm NGINX yang terletak di stable/nginx-ingress . Itu maksud saya sebenarnya, saya mencoba menggunakan template yang sudah ada di bagan itu.

Sebagai catatan, saya tidak menggunakan stable/nginx-ingress sebagai subchart dalam bagan yang saya kembangkan; Saya hanya menggunakannya secara langsung untuk menyebarkan masuknya NGINX.

itu tidak didefinisikan dalam file nilai saya, itu adalah sesuatu yang termasuk dalam bagan Helm NGINX yang terletak di stable/nginx-ingress. Itu maksud saya sebenarnya, saya mencoba menggunakan template yang sudah ada di bagan itu.

Sayangnya Ini tidak mungkin karena templat Helmfile (nilai) bekerja secara independen dari templat Helm (bagan), dan nginx-ingress.name adalah templat yang ditentukan dalam bagan Helm untuk digunakan dalam templat bagan.

Mungkin satu-satunya cara adalah menyalin blok {{define "nginx-ingress.name"}} yang ditentukan dalam bagan nginx ke dalam templat nilai helmfile Anda values.yaml ?

Saya telah memikirkan solusi tentang masalah ini dan saya berhasil. Ini mungkin praktik yang buruk tetapi saya akan membagikannya untuk berjaga-jaga. Anda bisa meletakkan placeholder di teks yang ingin Anda template dan kemudian mengganti placeholder itu dengan template yang ingin Anda gunakan di file yaml di template. Jadi ini contohnya:

Di values.yaml:

keys:
  - name: key_for_test
    value: CHANGEFORRELEASE-my-value

Dan saya akan menggunakan ini dalam rahasia yaml:

rahasia_kv.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-test-kv
  annotations:
    description: Key/Value pairs to save in test datastore
  labels:
    app: test
    tier: backend
    vendor: test
    support: {{ template "supportMethod" . }}
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
type: Opaque
data:
  {{- $var := .Release.Name }}
  kv.yaml: {{ toYaml .Values.keys | replace "CHANGEFORRELEASE" $var | b64enc | quote }}

Saya berharap bahwa itu akan membantu seseorang.

Ini adalah utas pertama yang saya temui, daripada juga berkomentar di sini ...
Lihat juga #2514

:) Untungnya, manual Helm terbaru mengatakan bagaimana mencapai ini.
https://helm.sh/docs/howto/charts_tips_and_tricks/#using -the-tpl-function

Triknya adalah melampirkan variabel dalam " atau di blok yaml |- , dan kemudian mereferensikannya dalam template sebagai {{ tpl .Values.variable . }}
Hal ini rupanya membuat Helm senang.

Contoh:

$ cat Chart.yaml | grep appVersion
appVersion: 0.0.1-SNAPSHOT-d2e2f42


$ cat platform/shared/t/values.yaml | grep -A2 image:
image: 
  tag: |-
    {{ .Chart.AppVersion }}


$ cat templates/deployment.yaml | grep image:
          image: "{{ .Values.image.repository }}:{{ tpl .Values.image.tag . }}"


$ helm template . --values platform/shared/t/values.betradar.yaml | grep image
          image: "docker-registry.default.svc:5000/namespace/service:0.0.1-SNAPSHOT-d2e2f42"
          imagePullPolicy: Always
      image: busybox

Kalau tidak, ada kesalahan yang dilemparkan..

$ cat platform/shared/t/values.yaml | grep -A1 image:
image: 
  tag: {{ .Chart.AppVersion }}

1 $ helm template . --values platform/shared/t/values.yaml | grep image
Error: failed to parse platform/shared/t/values.yaml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Chart.AppVersion":interface {}(nil)}

Untuk saat ini, apa yang telah saya lakukan dalam pekerjaan CI adalah menjalankan helm template pada file values.yaml. Ini bekerja cukup baik atm.

cp values.yaml templates/
helm template $CI_BUILD_REF_NAME ./ | sed -ne '/^# Source: templates\/values.yaml/,/^---/p' > values.yaml
rm templates/values.yaml

helm upgrade --install ...

Ini rusak jika Anda memiliki beberapa file -f values.yml , tetapi saya berpikir untuk menulis pembungkus helm kecil yang pada dasarnya menjalankan skrip bash untuk setiap file values.yaml .

Ada kasus penggunaan di mana Anda harus meneruskan nama penerapan ke bagan ketergantungan di mana Anda tidak memiliki kendali.

Misalnya saya mencoba mengatur podAffinity untuk penjaga kebun binatang. Dan saya memiliki bagan kemudi aplikasi yang menetapkan penjaga kebun binatang sebagai ketergantungan. Dalam hal ini, saya meneruskan antiafinitas pod ke penjaga kebun binatang melalui nilai. Jadi dalam file values.yaml aplikasi saya, saya memiliki bagian zookeeper.affinity. Jika saya memiliki kemampuan untuk mendapatkan nama rilis di dalam nilai yaml, saya hanya akan menetapkan ini sebagai default dan menyelesaikannya.

Tetapi sekarang untuk setiap penerapan saya harus mengganti nilai ini, yang merupakan masalah besar.

@thomastaylor312 dan lainnya:

Saya telah membaca banyak masalah terkait tentang topik umum ini, dan tampaknya gagasan templating values.yaml tidak praktis, tidak sepele, dll.

Apakah masuk akal untuk mendukung beberapa fase perantara tambahan selama pembuatan grafik/penerapan/dll. di mana beberapa skrip arbitrer (yaitu disediakan pengguna) (yaitu Python, BASH, Lua, dll.) menerima salinan statis values.input.yaml (alias values.yaml ) dan memiliki akses ke berbagai variabel (mis. .Release.* ), dan skrip dapat bertanggung jawab untuk secara dinamis membuat file values.output.yaml "final" (yang sebenarnya langsung digunakan oleh templat bagan lainnya)? Jika Helm dapat menyediakan "pengait" untuk ini, sepertinya itu mungkin kompromi yang layak, yaitu "ini semua data dan kait untuk memicu skrip Anda untuk membuat values.output.yaml , selamat bersenang-senang!".

Satu hal yang menjadi perhatian adalah jika pendekatan ini dapat menangani sub-bagan dengan benar dan cakupan/arti dari . berubah, jadi saya harus tunduk pada pengelola Helm untuk memutuskan apakah itu dapat dipecahkan atau hanya sekaleng worm lainnya (yaitu apakah fase ini perlu dipicu secara rekursif untuk sub-grafik).

Saat ini saya melakukan sesuatu seperti ini sekarang, tetapi itu mengharuskan saya untuk menyediakan skrip "peluncur" untuk bagan saya, jadi konsumen hilir tidak bisa begitu saja "memasang helm" bagan saya (kasus penggunaan yang agak mirip dengan helmfile ) . Ini muncul dari kebutuhan untuk membuat template nilai untuk bagan/wadah pihak ketiga (yang tidak dapat saya ubah karena alasan teknis dan hukum). Dalam bagan ini, saya memiliki nilai hard-code yang setara dengan .Release.Namespace yang muncul secara harfiah di mana-mana (di dalam string URI/URL untuk FQDN dalam kluster untuk layanan K8S, larik nama host, env vars, dll.). Setiap kali saya perlu menyebarkan bagan tingkat atas ke namespace yang berbeda, jika bukan karena skrip pembantu saya, saya harus memodifikasi sekitar 30 entri di values.yaml . Jika ada beberapa cara untuk menstandarisasi ini (bahkan jika tidak melalui implementasi yang saya jelaskan di atas), itu akan sangat membantu.

@IAXES Apakah hal-hal pasca-render baru mungkin membantu menyelesaikan ini?

@thomastaylor312 Dalam kasus penggunaan khusus saya sendiri, pasti ya. Dalam kasus penggunaan yang telah dijelaskan orang lain (yaitu yang non-sepele dan memerlukan beberapa tingkat pembuatan dinamis dari file values.yaml , serta akses ke variabel waktu penerapan seperti .Release.Namespace , dll .), Saya sangat curiga itu bisa menyelesaikan masalah itu juga (akan memerlukan beberapa umpan balik tambahan dari orang lain yang menginginkan/membutuhkan fitur asli yang dijelaskan di bagian atas utas/masalah ini).

Meskipun saya tidak berpengalaman dalam basis kode Helm, saya berpotensi ikut serta atau memberikan dukungan desain/pengujian (atau memotong ini sebagai bukti konsep jika saya dapat melakukan ping ke kolaborator/pengelola untuk mendapatkan saran di mana harus menyuntikkan potongan kode saya untuk membuat sistem "kait").

Jika ini adalah sesuatu yang dianggap layak untuk ditelusuri, mungkin juga ide yang baik untuk +CC helmfile pengelola/pemilik (konsultasi/opini/umpan balik/dll), karena dimungkinkan untuk menghubungkan solusi yang ada untuk bukti dari konsep. Jika seseorang dapat mengatur kait ini dan memiliki solusi sewenang-wenang untuk "mengisi yang kosong", dan konsumen/pengguna akhir masih harus menjalankan helm install (ditambah mungkin apt/yum/apk menginstal beberapa dependensi) , itu akan luar biasa!

@benjigoldberg @fsniper Apakah kasus penggunaan yang saya jelaskan di atas berpotensi mengatasi kasus penggunaan Anda dengan cara yang wajar?

@IAXES Jika saya mengerti benar Anda menyarankan, helm menyediakan kait ke aplikasi eksternal dan kemudian menggunakan output dari mereka sebagai statika.

Ini adalah ide yang menarik untuk dijelajahi, sekaligus sudah mungkin tanpa bantuan helm sama sekali. Anda sudah mengakui bahwa Anda telah menggunakan proses ini. Dan saya yakin semua pihak yang berkepentingan bisa menerapkan ini sendiri.

Mengingat helm termasuk mesin templating yang lebih dari cukup mampu untuk melakukan ini, saya tidak terlalu senang dengan pendekatan ini. Pertama, ini membutuhkan pengaturan aplikasi eksternal dan diintegrasikan ke dalam proses yang mungkin sudah berjalan, seperti CI/CD, dan kedua yang lebih penting membutuhkan templating di luar proses, yang tidak didefinisikan dengan baik. Seperti yang saya nyatakan sebelum definisi ini, dan standarisasi sudah ada dengan kemudi. Jadi mengapa tidak menggunakan ini sebagai kemudi dan menyediakan sarana untuk fitur yang sudah diminta?

Atau mengimplementasikan skrip lua yang sudah dibahas dan didokumentasikan dapat digunakan untuk ini. Tentu saja tidak tersedia juga.

Saat ini pendekatan saya menggunakan substitusi nilai lingkungan file nilai juru mudi. Ini terbatas, tetapi dapat digunakan dengan beberapa lompatan.

Masalah ini membuatnya lebih menantang untuk menggunakan penerapan biru-hijau dengan diagram kemudi induk untuk semua aplikasi Anda, setidaknya jika salah satu nilai Anda adalah URL khusus lingkungan atau koneksi database. Untuk saat ini saya akan mencoba solusi @ leox-phq.

Saya juga bertanya-tanya apakah membuat file templates/values.yaml alih-alih file values.yaml dapat digunakan sebagai konvensi untuk memberi tahu Helm agar melakukan penggantian nilai...tidak yakin apakah ini akan membantu mengatasi beberapa masalah dengan menerapkan ini secara asli di Helm yang disebutkan ...

Pembaruan: Solusi @ leox-phq dapat ditingkatkan untuk menghindari kebutuhan penggantian menggunakan sed dengan menggunakan opsi --show-only dari helm template :

helm template . --show-only templates/values.yaml > values.yaml

Saya mencari cara untuk menggunakan Chart.yaml appVersion dalam file values.yaml. Tidak yakin apakah sudah ada solusi, atau masalah ini diperlukan.

@nodesocket Sudah ada di .Chart ! https://docs.helm.sh/docs/chart_template_guide/builtin_objects/

@thomastaylor312 Saya pikir Anda hanya dapat menggunakan .Chart.AppVersion di dalam template bukan di file values.yaml?

Ah maaf, saya melewatkan bagian itu. Ya, tidak ada templating file nilai karena alasan yang disebutkan di sini.

Setelah membaca tentang templating di values.yaml dan mencoba berbagai solusi, tampaknya ini adalah solusi terbersih untuk saat ini (dalam hal yang paling mudah dibaca dengan tidak harus melihat terlalu banyak tempat):

• Deploy grafik Helm melalui Terraform, sediakan file eksternal values.yaml.tmpl , dan gunakan templatefile("values.yaml.tmpl",..) untuk merender variabel Terraform.
• Terapkan bagan Helm melalui Helmfile, berikan semua nilai sebaris, dan gunakan {{ requiredEnv "..." }} untuk merender variabel lingkungan.

Ada juga #6876 yang merupakan pendekatan baru untuk masalah ini, menyelesaikan masalah yang diangkat oleh https://github.com/helm/helm/issues/2492#issuecomment -413635332. Namun, itu besar, dan butuh waktu lama untuk ditinjau.