Helm: Izinkan helm untuk menambahkan file eksternal ke bagan penyebaran

Hai Lena,

Cara saat ini:
Cara saat ini untuk mengimplementasikan penambahan file-content adalah dengan menggunakan parameter n-dimensi "--values" saat memanggil helm install. Menempatkan setiap file (nilai konfigurasi normal, hal-hal SSL, lisensi) dalam file YML terpisah akan memberikan keterbacaan yang lebih baik.

Mari kita asumsikan kita menggunakan "semangat pertama" sebagai nama repositori bagan, yang kemudian memberikan bagan kepada pelanggan. Kemudian pelanggan dapat menerapkan bagan Anda melalui panggilan:

helm install firstspirit/caas --values myvalues.yml,ssl.yml,foobar-license.yml

Dalam bagan Anda, Anda sekarang dapat memvalidasi jika semua kunci yang diperlukan memiliki nilai yang ditetapkan (sertifikat ssl, lisensi, ..).
File lisensi dapat disimpan secara lokal, dan saat mengirim ke cluster kubernetes file tersebut harus disimpan sebagai rahasia kubernets. Untuk peningkatan pengembangan yang lebih cepat, Anda dapat memberikan ssl zert yang telah dibuat sebelumnya sebagai nilai default.

Sebagai kelebihan lainnya, pelanggan dapat mengotomatiskan pembuatan sertifikat SSL oleh alat pihak ketiga dan membuat sendiri file .yml untuk menyetel nilai rahasia kubernetes Anda di luar Helm dan meneruskan file yang dihasilkan ke Helm untuk perintah "helm install".

Salam,
Markus

Hai Markus,
tidak yakin apakah kita saling memahami dengan benar. Untuk menguraikan sedikit tentang kasus penggunaan saya, inilah isi bagan saya saat ini:

...
{{ if .Files.Get "config/fs-license.conf" }}
file.fs-license.conf:               {{ .Files.Get "config/fs-license.conf"                                | b64enc }}
{{ else }}
{{ fail "you need to supply your license file! add 'fs-license.conf' to your chart 'config' directory." }}
{{ end }}
...

Saya ingin tidak memaksa pengguna untuk memberikan string yang disandikan base64 dalam file yaml, tetapi memberikan file secara langsung. Namun, file harus menjadi bagian dari grafik itu sendiri dan tidak dapat diberikan dari luar, oleh karena itu tiket ini.

Saya memiliki kebutuhan yang tepat ini. Bagan saya menerbitkan pembacaan rahasia dari file di /keybase . File ini sengaja tidak ada di chart.

Saya percaya file untuk .Files.Get tidak boleh dianggap berada di dalam bagan:

https://github.com/kubernetes/helm/blob/master/pkg/chartutil/files.go#L32

Saya cukup yakin .Files.Get tidak dapat mengakses sistem file secara sewenang-wenang adalah fitur keamanan, jadi saya tidak berpikir perilaku saat ini salah - itu tidak memenuhi semua kasus penggunaan.

Salah satu solusi alternatif adalah mendistribusikan sertifikat dan lisensi Anda sebagai rilis helm terpisah. Di mana Anda memasukkannya ke dalam peta konfigurasi dengan nama yang diketahui oleh penerapan layanan Anda, gunakan pemasangan volume configmap/secrets dalam penerapan layanan Anda.

Mungkin itu yang sudah disarankan @cr4igo :)

Kami mengalami masalah yang sama dengan kasus penggunaan yang sangat mirip:

Kami memiliki sertifikat untuk layanan pemberitahuan push Apple dan Google; kami memiliki sertifikat yang berbeda untuk lingkungan pengujian dan produksi kami sehingga kami tidak bisa hanya menggabungkan sertifikat ke dalam Bagan (mengabaikan masalah keamanan saat melakukannya); kami idealnya ingin dapat menempatkan jalur file ke dalam file nilai dan meminta Helm memuat file itu.

Saya tidak punya saran bagus tentang cara memberi tahu Helm bahwa string dalam file nilai adalah jalur file relatif - mungkin membungkusnya dengan semacam konstruksi $file("path/goes/here") tetapi tampaknya berantakan.

misalnya
nilai.yaml

apns:
  certificatePath: "./mycert.p12"

rahasia.yaml

...
data:
  apnsCertificate.p12: |-
    {{ Files.Get .Values.apns.certificatePath | b64enc }}

Saya pikir, ini adalah duplikat #1754

Saya tidak berpikir ini duplikat, ini tentang mengizinkan helm untuk mengakses file di jalur absolut di luar "root" bagan helm.

Contoh:

data:$
  dynamicvalues.json: |-$
{{- if .Files.Get (required "Helm Error: .Values.valuesfile is required" .Values.valuesfile) }}$
    {{ .Files.Get (.Values.valuesfile) }}$
{{- else }}$
{{ fail "Helm Error: specified .Values.valuesfile could not be read" }}$
{{- end }}$

Ini gagal dirender jika menunjuk ke file di dalam repo helm, yaitu:
helm --set valuesfile=/tmp/my-dynamic-file [...]

Jika file yang sama disalin ke root helm dan menunjuk dengan jalur relatif, perintah yang sama berfungsi.
Contoh di bawah ini hanya berfungsi jika menunjuk ke file di dalam repo helm, apa pun di luar gagal,

Hai,

Saya ingin menyarankan pendekatan yang mirip dengan C-preprocessor... secara default memiliki jalur pencarian di dalam bagan, namun tambahkan parameter --search-directories= untuk memungkinkan direktori tambahan. Ini akan memenuhi persyaratan keamanan karena sysadmin harus menentukan di mana file tambahan berada, itu akan membuat Files::glob berfungsi dengan baik.

Bagaimana menurutmu?

GUNAKAN KASUS

sertakan kumpulan file tambahan ke configmap/secrets menggunakan .Files.Glob dari direktori di luar paket bagan, tanpa mengekstrak paket.

MASALAH

paket tidak boleh keluar dari direktori pencarian resmi.

LARUTAN

tambahkan parameter --search-directories untuk mencari file di direktori tambahan yang ditentukan oleh sysadmin, file akan dimuat ke dalam kumpulan file bagan, tersedia untuk objek Files.

Mohon maaf atas keterlambatan respon. Tim inti (termasuk saya sendiri) telah berfokus hanya untuk mendapatkan rilis alfa Helm 3, jadi setiap pengembangan pada kontribusi signifikan untuk Helm 2 jauh lebih sulit untuk mendedikasikan sumber daya untuk tinjauan sejawat dan pekerjaan desain saat ini.

Proposal di OP ( --include-file=foobar-license.conf ) terdengar seperti solusi yang masuk akal jika seseorang ingin menangani fitur tersebut! Saya sangat menyarankan menunggu sampai kami memiliki rilis alfa Helm 3 yang tersedia sebelum mengerjakan pekerjaan fitur baru; Pengembangan Helm 2 dan Helm 3 telah menyimpang ke titik di mana kami tidak akan dapat mem-porting fitur Helm 2 baru ke Helm 3, itulah sebabnya kami ragu untuk menggabungkan fitur baru ke dalam rilis terbaru dan hanya mengerjakan perbaikan bug. Semoga ini membantu!

Halo,

Adakah pembaruan tentang status masalah ini? Bagaimana dengan Helm 3?

Saya bertanya juga .. akan sangat menyukainya untuk barang traefik ssl f.ex. :)

AFAIK tidak ada seorang pun dari komunitas yang mulai menangani pekerjaan ini untuk Helm 2.

Hai, Apa yang terbaru tentang topik ini? Kami juga mencari perilaku yang diminta. Terima kasih

Sama seperti sebelumnya. Tidak ada pembaruan.

Masih menunggu pembaruan tentang ini

Seharusnya juga bagus jika Anda memberikan opsi seperti --include-folder=<path to folder> dan Helm berperilaku seperti folder itu berada di akar bagan Helm. menyertakan satu file tidak menyelesaikan masalah dalam kasus kami. mungkin ada ratusan file dan sub direktori di folder itu.

Saya menandai fitur ini sebagai "Dicari Bantuan". Akan sangat bagus untuk memiliki fitur ini, tetapi kami sibuk mengerjakan kembali arsitektur untuk Helm 3 sehingga kami tidak punya waktu untuk fokus pada penerapan fitur baru seperti ini.

Jika Anda tertarik untuk menyumbangkan fitur ini untuk Helm 3, beri tahu kami agar kami dapat mencoba mengoordinasikan upaya/menggabungkan konflik dengan anggota tim lainnya.

Masih menunggu pembaruan tentang ini

Jika ada pembaruan lebih lanjut, kami akan membagikannya di sini.

Terima kasih!

Jika itu membantu siapa pun, saya telah berhasil mengatasi batasan ini untuk kebutuhan saya.
Saya agak baru untuk memimpin, jadi itu mungkin pendekatan yang terkenal

Struktur folder saya:

├───mainfests
│   └───[app_name]
│       ├───charts
├───[app_name]
│   └───resources
│       ├───config-prod.json
│       ├───config-staging.json

Masalahku:

Saya mencoba menyalin konten file konfigurasi ke k8s configMap, tetapi saya telah mencapai batasan di mana saya tidak dapat mereferensikan file konfigurasi, karena berada di luar bagan helm.

Solusi saya:

Saya telah menggunakan set-file untuk menyalin konten file konfigurasi

helm install --set-file ``configValues=./[app-name]/config/config_prod.json

Dan dalam penyebaran helm saya yaml direferensikan seperti ini:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <config-name>
data:
  {{ printf "config_%s.json" .Values.envType }}: |-
  {{ .Values.configValues }}`

(diedit beberapa kali untuk memperbaiki jeda baris tanpa hasil)

Fitur yang sangat dibutuhkan untuk sertifikat terutama .. Jika tidak, itu menjadi terlalu rumit untuk pekerjaan itu

Anda dapat membuat bagan dengan sumber daya tambahan dan kemudian menggunakan bagan yang sebenarnya sebagai subbagan melalui requirements.yaml

Jika itu membantu siapa pun, saya telah berhasil mengatasi batasan ini untuk kebutuhan saya.
Saya agak baru untuk memimpin, jadi itu mungkin pendekatan yang terkenal

Struktur folder saya:

├───mainfests
│   └───[app_name]
│       ├───charts
├───[app_name]
│   └───resources
│       ├───config-prod.json
│       ├───config-staging.json

Masalahku:

Saya mencoba menyalin konten file konfigurasi ke k8s configMap, tetapi saya telah mencapai batasan di mana saya tidak dapat mereferensikan file konfigurasi, karena berada di luar bagan helm.

Solusi saya:

Saya telah menggunakan set-file untuk menyalin konten file konfigurasi

helm install --set-file configValues=./[nama-aplikasi]/config/config_prod.json ``

Dan dalam penyebaran helm saya yaml direferensikan seperti ini:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <config-name>
data:
  {{ printf "config_%s.json" .Values.envType }}: |-
  {{ .Values.configValues }}`

(diedit beberapa kali untuk memperbaiki jeda baris tanpa hasil)

file sumber daya apa yang bukan format teks atau json, dalam kasus saya, saya memiliki file sumber daya sebagai file perang yang digunakan untuk konfigurasi aplikasi saya

Saat ini saya melakukannya dengan configmap:

 data:                                                                                                                                                                                                                              
   my-configuration.php: |-                                                                                                                                                                                                      
     {{- .Files.Get "admin-configs/my-configuration.php" | nindent 4 }}  
   other-configuration.yaml: |-                                                                                                                                                                                                    
     {{- .Files.Get "admin-configs/other-configuration.yaml" | nindent 4 }} 

dan saya hanya menempatkan file konfigurasi di folder admin-configs (di bawah grafik) - sebelum menjalankan helm, dan itu menambahkan konten file-file itu ke configmap - yang kemudian dapat dipasang di dalam pod, dan mendarat sebagai file.

Saya bertujuan untuk mencoba ini sebagai kontribusi pertama saya, karena di permukaan sepertinya permintaan fitur yang layak dan berguna. Tapi sekarang, saya merasa ini bisa diatasi dengan fungsionalitas yang ada.

Saya telah membaca komentar dan orang-orang berbicara tentang dua kasus penggunaan: Sertifikat dan Penggantian Bagan.

1. Sertifikat.
Ini masuk Rahasia atau ConfigMaps. Saya yakin bahwa Anda harus menetapkan ini sebagai string ketika Anda memanggil helm , misalnya dari skrip bash. Lebih dari itu, Anda dapat menulis skrip yang mengambil rahasia dari penyimpanan, misalnya HashiCorp's Vault, dan mengisi melalui nilai saat runtime.

Untuk contoh apa yang dapat dilakukan, lihat proyek Helmfile yang mengagumkan. Saya telah menggunakan ini untuk mengambil rahasia dari vault ke file secret.yaml , yang kemudian diteruskan ke helm melalui helmfile , satu per Bagan, dan dihapus di akhir.

Jadi, solusi ini cukup fleksibel dan scriptable. Dalam pikiran saya, Helm seharusnya tidak mencoba mengelola rahasia dari luar lingkup langsungnya, yaitu Bagan; ini termasuk harus mengambil rahasia dari mana saja, bahkan file.

2. Penimpaan Bagan.
Fitur bagan perpustakaan baru Helm harus menyelesaikan kasus penggunaan ini. Bagan pustaka, bersama dengan contoh bagan "instal", seharusnya cukup untuk membuat orang mulai menggunakan bagan yang memerlukan penyesuaian di luar apa yang dapat dilakukan dengan nilai sederhana. Saya percaya ini akan menjadi solusi elegan untuk masalah OP.

@bacongobbler , Anda menetapkan masalah ini sebagai Dicari Bantuan, jadi saya menandai Anda. Ada pikiran?

Hei @vladfr - Saya sebagian setuju, tetapi tidak 100% :). Saya berbicara tentang kasus penggunaan sertifikat sekarang, dan ini murni berdasarkan pengalaman pribadi, yang berarti itu mungkin tidak dapat diterapkan secara luas. Untuk proyek internal, saya setuju. Anda ingin menyimpan sertifikat Anda di sesuatu seperti vault. Menulis skrip yang mengambil data dari sana dan hanya menambahkan nilai kode base64 melalui parameter tidak masalah. Anda memiliki kendali, tidak ada masalah.

Untuk perangkat lunak kami, distribusi bekerja melalui diagram kemudi. Orang-orang membeli produk kami dan menginstalnya secara lokal di kluster kubernetes mereka. Bukannya orang yang menginstal perangkat lunak biasanya memiliki banyak pengalaman dengan kubernetes, dan mereka menggunakan berbagai sistem operasi (telah melihat semua linux, mac, windows) saat memanggil helm. Kami tidak menyediakan sertifikat sendiri, pelanggan membelinya di tempat lain; kami menyediakan bagan kemudi dan mereka menambahkan sertifikat. Kami juga tidak memiliki kendali atas saluran pipa CI/CD mereka. Ini sudah merupakan masalah kompleksitas-bijaksana dengan k8s dan helm itu sendiri.

Saya memiliki kasus penggunaan dukungan di mana orang tidak berhasil mengonversi sertifikat mereka ke base64 dengan benar - mungkin itu masalah umpan baris atau serupa. Kami memiliki lebih sedikit masalah untuk memberi tahu orang-orang untuk membuka ritsleting bagan, menempatkan sertifikat di lokasi tertentu dan kemudian memasang bagan dari direktori. Saya tahu ini sangat jauh dari ideal, tetapi berhasil - sejauh ini - lebih baik daripada mengatakan "pastikan Anda menambahkan sertifikat yang disandikan base64 di sini". Tapi itu rumit.

Untuk menambahkan kasus penggunaan lain yang kami miliki, selain sertifikat: lisensi (misalnya file kunci lisensi) yang membatasi penggunaan perangkat lunak. Kasus itu lebih mudah karena kami dapat memberikan lisensi dalam format yang disandikan base64 untuk memungkinkan untuk mengaturnya melalui --set , atau sebagai values.yaml yang telah dikonfigurasi sebelumnya yang dapat Anda terapkan.

Jadi, saya masih berpikir fitur ini akan sangat berguna.

@lenalebt terima kasih telah menjelaskan kasus penggunaan ini dengan sangat rinci. Saya setuju, dalam hal ini rumit. Saya masih merasa ini harus ditangani di luar kemudi, tetapi jika pengelola merasa sebaliknya, saya akan dengan senang hati mencoba menerapkan ini.

Terima kasih @vladfr.

Saya berpihak pada @lenalebt dalam hal ini. Dimungkinkan untuk mengatasi ini, tetapi jika Anda benar-benar menjual produk berdasarkan k8s/helm, kompleksitas tambahan pada solusi akhir dapat memberikan poin negatif pada etalase Anda. Anda juga meminta pelanggan untuk menangani beberapa detail teknis secara manual, atau menyembunyikannya di balik skrip pembungkus atau antarmuka GUI yang menyebabkan biaya pemeliharaan lembur.

Saya yakin ada beberapa cara untuk menerapkan ini, dan umpan balik komunitas dapat membantu menentukan cara yang paling elegan untuk dilakukan.

Secara pribadi, saya akan memberikan fungsi baru pada baris .Files.GetExternal , yang dapat didokumentasikan dengan baik sebagai alternatif yang tidak aman untuk .Files.Get .

Harap pertimbangkan untuk menerapkannya. Bahkan kustomize menyediakan flag baris perintah untuk mengizinkan file eksternal diakses.

Sepertinya ada lebih dari cukup konsensus untuk fitur ini. Kami mencari relawan yang bersedia meluangkan waktu untuk melaksanakan ini. Kami tidak punya waktu untuk menulis ini sendiri tetapi kami bersedia membantu orang lain melalui proses pembelajaran. @solacens apakah Anda bersedia meluangkan waktu untuk mengimplementasikan ini?

@bacongobbler Saya ingin mencobanya. Saya telah mencari masalah pertama yang bagus untuk mulai berkontribusi.

Besar!

Saya akan menghubungi @ankul untuk memastikan tidak ada yang menginjak kaki satu sama lain. Dia mengirimi saya pesan di Slack sebelumnya hari ini yang menyatakan minatnya untuk mengimplementasikan fitur tersebut juga.

Untuk flag --include-file=foobar-license.conf diusulkan:

• Apakah kami mengharapkan pengguna untuk mengumpulkan semua file dalam satu direktori dan menamainya dengan tepat? Jika demikian, bagaimana nama yang sesuai dikomunikasikan kepada pengguna?
  Mengutip dari https://github.com/helm/helm/issues/1754#issuecomment -271381902

  Saya melihat values.yml (dan --set) sebagai semacam "antarmuka" di mana input diteruskan ke helm.

  Dalam pendekatan ini, nama file sekarang akan menjadi input arbitrer ke bagan.

• Haruskah kita memiliki konstruk files mirip dengan values untuk mencantumkan nama file apa yang diharapkan grafik? Pengguna dapat meneruskan file-file itu sebagai --include-file key1=path1 key2=path2 mana kunci yang diharapkan terdaftar di helm show files bersumber dari files.yml .

  .. Atau hanya meminta pengguna menentukan nama file sebagai nilai?

@juliohm1978 Saya tidak yakin bagaimana Files.GetExternal tidak aman (atau mengapa itu diperlukan sama sekali). File-file ini dapat tersedia melalui metode yang sama yang ada pada objek Files ( Get , GetBytes , Glob , Lines dll) .

Saya harap saya tidak melewatkan sesuatu yang telah dibahas sejauh ini.

@anukul Anda membuat poin bagus tentang menemukan nama file apa yang diharapkan. Dokumentasi adalah salah satu cara tetapi tidak ideal.

Saya ingin menyarankan pendekatan yang berbeda.

Kasus penggunaan adalah untuk mendapatkan konten file menjadi nilai. Bagaimana dengan membaca file langsung ke variabel nilai? Sesuatu seperti: --set certificate={{file://path/to/your/file}} . Helm perlu mengurai setiap nilai dan melihat apakah itu cocok dengan skema file:// , lalu cukup baca file sebagai string dan atur kuncinya. Ini akan bekerja melalui yaml juga.

Dengan cara ini, nama file tidak lagi relevan. Penulis bagan akan memiliki kendali atas tempat menerima konten file, dan pengguna dapat dengan mudah meneruskan file arbitrer sebagai nilai, di mana pun mereka suka. Files.Get tidak akan digunakan lagi.

Apakah itu masuk akal?

kedengarannya lebih seperti --set-file , yang sudah ada saat ini. Dalam contoh Anda, Anda akan menggunakan --set-file certificate=/path/to/your/file , lalu memanggil .Values.certificate di template Anda untuk mengakses data file.

https://github.com/helm/helm/blob/07a3d7299c7fa9e0e36953623b6a4917f06bbe53/cmd/helm/flags.go#L37

Hai,
Apa yang saya pikirkan adalah seperti -I beralih untuk cc atau -L beralih ke ld , tambahkan direktori tambahan ke jalur pencarian file.
Saat ini, hanya direktori bagan yang mencari file saat mengulangi/membaca file generik , sedangkan persyaratannya adalah mencari file di luar pohon dengan cara yang sama.
Misalnya, bagan mungkin memiliki direktori tempat menyimpan file konfigurasi *.yaml , bagan mengulangi semua file dalam direktori ini untuk membuat peta konfigurasi dengan entri untuk setiap file.
Persyaratannya adalah mengizinkan chart untuk mencari file tambahan di luar root chart atau tarball, sehingga dalam hal ini sysadmin dapat menambahkan file *.yaml untuk diinjeksikan ke dalam configmap.
Ini dapat dengan mudah dibuat dengan -I<directory> (dengan opsi ke beberapa lokasi) untuk mencari direktori bayangan tambahan, tanpa mengubah logika bagan.
Terima kasih!

Apakah mungkin untuk menentukan jalur untuk file konfigurasi di values.yaml saya dan menggunakan jalur itu untuk membaca konten untuk membuat beberapa peta konfigurasi?
Saya pada dasarnya ingin menghasilkan yaml berikut
Katakanlah saya memiliki repo git lain tempat file konfigurasi saya disimpan dan saya ingin menariknya ke bawah di direktori di luar bagan helm. Saya ingin dapat mereferensikan direktori itu dan mengambil semua file di dalamnya. Kita mungkin bisa melakukan satu lapisan terlebih dahulu. belum perlu rekursif.

apiVersion: v1
kind: ConfigMap
metadata:
  name: conf
data:
  boot.properties: |
    <paste file content here>
  jndi.properties: |
    <paste file content here>

Saya mengerti ini adalah fitur keamanan, tetapi beberapa dari kita sebenarnya adalah penulis bagan kemudi dan kita percaya diri bahwa kita tidak mencoba menyerang atau menggunakan diri kita sendiri. Jadi saya sarankan menambahkan kemungkinan untuk menonaktifkan fitur keamanan ini (--allow-all-files)

FWIW jika seseorang mencari pembuatan ConfigMap: https://helm.sh/docs/chart_template_guide/accessing_files/

@ravindranathakila

Dokumentasi Helm tidak berfungsi.

Sedih melihat fitur penting seperti itu masih belum diterapkan. Saya berharap ini menjadi salah satu dari hal-hal dasar ini.

@theAkito , seperti yang telah saya sebutkan beberapa kali sebelumnya di utas ini , kami mencari sukarelawan yang bersedia meluangkan waktu untuk menerapkan ini. Sebagai pengelola inti, sebagian besar waktu kami dihabiskan untuk membantu orang lain melalui proses kontribusi perbaikan dan fitur ke Helm. Kami tidak punya waktu untuk menulis fitur baru sendiri, tetapi kami lebih dari bersedia untuk membantu orang lain melalui proses pembelajaran.

Sejauh ini, saya belum melihat permintaan tarik yang mengimplementasikan fitur ini seperti yang disarankan . Kami masih mencari relawan.

Saya melihat bahwa Anda merasa cukup bersemangat tentang fitur ini. Bagaimana perasaan Anda tentang bekerja menerapkan ini?

Bahkan sekarang Anda dapat menambahkan file eksternal apa pun ke instalasi sejak Post-Render Hooks diperkenalkan

https://github.com/helm/helm/issues/7260

Saya melihat bahwa Anda merasa cukup bersemangat tentang fitur ini. Bagaimana perasaan Anda tentang bekerja menerapkan ini?

Tentu, jika tidak ditulis di Go. Rasanya seperti setiap pengguna Github lainnya tahu cara Go, jadi seharusnya tidak menjadi masalah untuk menemukan seseorang yang tertarik. Sebenarnya, saya sudah memiliki beberapa orang di sini di Github di pikiran saya yang bisa saya tanyakan, karena mereka terlibat dalam pekerjaan terkait Kubernetes dan semuanya banyak melakukan Go. Menemukan programmer Go seperti mencari sebutir pasir di pantai.

Berikut adalah contoh cara menggunakan kustomisasi melalui Post-Render Hooks
https://github.com/helm/helm/issues/7260

Berikut adalah contoh cara membuat konfigurasi dari file eksternal:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#configmapgenerator

Saya percaya masalah ini bisa ditutup.

Berikut adalah contoh yang lebih sederhana:

sh.sh

#!/bin/bash

sed "s/TOKEN_TO_REPLACE/$(cat file.txt)/"

file.txt

some content

Nikmati:
helm install --post-renderer ./sh.sh stable/some_helm_chart

Anda hanya perlu membuat peta konfigurasi dengan konten palsu TOKEN_TO_REPLACE

_tetapi bisa menjadi masalah dengan indentasi baris di yaml_

@R-omk, seperti yang dikatakan dalam dokumen:
"_Sumber daya yang dibuat oleh hook saat ini tidak dilacak atau dikelola sebagai bagian dari rilis._"

IMHO, solusinya adalah yang disarankan sebelumnya, yaitu memiliki tanda untuk menambahkan direktori ke jalur pencarian fungsi ".File".
IMHO tidak ada masalah keamanan karena pengguna bagan dengan sengaja menentukan tempat di mana bagan dapat diputar dengan file, dan ini bukan bagan yang dapat mengelola file di tempat yang sewenang-wenang

Bagaimana dengan flag " --search-folder " baru yang dapat disetel beberapa kali? Dan untuk masalah pemfilteran file, itu bisa menerapkan aturan yang persis sama seperti yang saat ini diterapkan oleh .File.Glob dll, jadi tidak ada kerumitan atau decripencies baru di sini

@titou10titou10

"Sumber daya yang dibuat oleh hook saat ini tidak dilacak atau dikelola sebagai bagian dari rilis."

Ini tentang kait: pre/post - install/delete/upgrade/rollback

post-renderer adalah jenis pengait yang sama sekali berbeda

@R-omk, cukup adil. Dok ketinggalan dalam hal ini
Tapi saya masih tidak bisa melihat bagaimana saya bisa menyelesaikan masalah kami dengan post-renderer hook.
Salah satu kasus penggunaan kami:

• kami menggunakan pipa jenkins untuk membangun aplikasi java dan menyebarkannya ke OpenShift
• kami menggunakan "templat" OpenShift untuk ini dan mencoba pindah ke Helm karena ini jauh lebih fleksibel dan kami membuat Bagan khusus untuk penyebaran
• proses penyebaran termasuk membuat satu ConfigMap dengan berbagai file properti klasik yang dibuat secara dinamis oleh build, semuanya berada di direktori yang sama (build dapat meletakkannya di mana saja..)
• ini adalah kandidat yang sempurna untuk fungsi " Files.Glob(<ext dir>) / AsConfig() ", sayangnya karena file properti dibuat di luar Bagan, saat ini tidak memungkinkan
• komentar: nama-nama file properti dinamis, jumlah file juga dinamis, build mengelompokkannya dalam satu direktori

Mungkin menggunakan post-renderer hook dapat membantu kami tetapi saya tidak melihat caranya, dan IMHO itu hanya akan menjadi solusi tetapi semua "solusi" diterima pada tahap ini
Dan menambahkan bendera " --search-folder " atau menambahkan fungsi .Files.GlobExternal() / .Files.GetExternal() seperti yang disarankan seseorang tampaknya merupakan solusi yang valid tetapi yang pertama lebih aman IMHO karena ini bukan Bagan yang memungkinkan akses ke lokal folder

Pengingat cepat: kami tidak akan menerima PR yang memperkenalkan .Files.GetExternal atau flag folder pencarian. Itu dapat menimbulkan masalah keamanan di sisi penginstal. Seseorang berpotensi dapat menulis bagan berbahaya yang menyalin file sensitif dan mengirimkannya ke tempat lain dengan kait bagan.

Namun, eksplisit —include-file atau —include-dir akan diterima, seperti yang disebutkan dalam komentar sebelumnya: https://github.com/helm/helm/issues/3276#issuecomment -412942372

Ada kasus di mana Anda ingin menyertakan file sebagai bagian dari tahap rendering untuk template tersebut. Post-render mungkin tidak menangani semua kasus.

@bacongobbler cukup baik.
Mari kita berharap flag baru --include-dir akan memungkinkan untuk menggunakan .Files.Glob(<dir>).AsConfig() atau fitur yang setara untuk memenuhi kasus penggunaan ini, yang menurut saya, sangat umum dalam pipeline

Atau mungkin Helm in bukan alat yang tepat dalam skenario pipa CICD di mana banyak "data" tidak dapat diekspresikan dengan cara "nilai" murni (via -f , --set atau --set-file ) dan diadakan di luar grafik

Untuk saat ini satu-satunya solusi yang saya lihat adalah mengambil dan membuka tar bagan di suatu tempat, menyalin file eksternal di bawah pohon bagan, menjalankan helm dari salinan lokal itu

Saya tidak mengerti mengapa file mentah di dalam rilis?

helm v3 tidak lagi menjalankan rendering template sisi server. Oleh karena itu, Anda tidak dapat menggunakan Files.Glob.
Masalah ini sebenarnya hanya untuk helm v2.

@bacongobbler Saya 100% turun untuk menambahkan fitur ini. Implementasi yang saya usulkan (terinspirasi oleh kubectl create secret generic --from-file=... ) adalah:

helm install --include-file [<key>=]<path>[,[<key2>=]<path2>...] --include-dir [<prefix>=]<dirpath>

di mana <key> adalah jalur yang akan diterima sebagai argumen ke .Files.Get , dan default ke nama dasar <path> . Misalnya, --include-file foo.txt=../dir/bar.txt akan membuat konten ../dir/bar.txt dapat diakses melalui .Files.Get "foo.txt" .

Untuk direktori, semua konten dirpath akan tersedia di bawah jalurnya relatif terhadap <dirpath> , dengan tambahan prefix opsional. Misalnya, jika mydir/ berisi foo.txt dan bar.txt , dan saya memanggil ini sebagai --include-dir mydir/ , file foo.txt dan bar.txt menjadi terlihat; ketika dipanggil sebagai --include-dir baz/qux=mydir/ , file-file itu terlihat sebagai baz/qux/foo.txt dan baz/qux/bar.txt .

Jika itu terdengar masuk akal, saya bisa memulai akhir pekan ini.

(Kelemahan utama adalah bahwa kami/majikan saya tidak akan dapat menggunakan ini untuk sementara waktu, karena kami juga harus mendukung versi helm yang lebih lama, tapi saya rasa lebih baik terlambat daripada tidak sama sekali)

Kedengarannya bagus, terima kasih! Saya tunggu PRnya.

@misberner dapatkah Anda mengonfirmasi bahwa menggunakan --include-dir <prefix>=<dirpath> akan memungkinkan kami menggunakan .Files.Glob(<prefix>).AsConfig() , jadi buat ConfigMap dengan satu entri di CM per file di <dirpath> ?

Ya itu idenya. Pertanyaan terbuka dari sudut pandang saya adalah apakah --include-dir dengan <prefix> ditentukan memperkenalkan overlay, atau membayangi semuanya di bawah <prefix>/ dari argumen sebelumnya dan dari bundel itu sendiri. Saya tidak terlalu berpendirian tentang yang satu itu tetapi lebih suka yang pertama.

ping ke @misberner. Adakah peningkatan?

Hai! Saya baru saja menemukan kasus lain di mana fitur ini akan berguna.
@bacongobbler Saya melihat ini masih terbuka - apakah masalah ini belum ditetapkan? Saya mungkin punya waktu minggu depan untuk melihatnya.

Merasa bebas

Menghabiskan beberapa waktu, saya memiliki flag file yang berfungsi, dan berencana untuk menambahkan flag cemara juga.

Saya telah mengatasi ini dengan menggunakan inkubator bagan

PR sekarang terbuka untuk ditinjau.

@vladfr tampaknya PR ditempatkan untuk rilis 3.4.0.

Kami membicarakannya minggu lalu di dev call. @vladfr hadir dan mengajukan pertanyaan apakah kami bisa mendapatkan ini untuk 3.3.0.

Dengan beban kerja kami saat ini untuk 3.3.0 kami tidak memiliki cukup waktu untuk berinvestasi meninjau PR ini. Saat ini kami menjangkau anggota komunitas yang telah menulis PR untuk 3.3.0 dan meminta mereka untuk memperbaiki PR mereka sebelum jendela penggabungan ditutup dan kami menghentikan rilisnya. E_TOO_MANY_PRS_TO_REVIEW

Setelah 3.3.0 keluar, kita dapat meninjau kembali percakapan ini.

mengikuti

mengikuti juga

bekerja di sekitar adalah:
{{- range $datakey, $dataval := $cm.fileList }}
{{- $datakey | nindent 2 }}: |-
{{- $fullPath := printf "configFiles/%s" $dataval }}
{{- $.Files.Dapatkan $fullPath | titik 4 }}
{{- akhir }}

setiap pembaruan tentang ini, mengingat kami memposting 3.3.1

Menggunakan --include-dir sepertinya merupakan pendekatan yang baik. Menantikan v3.4.0

Hai. Bagaimana fitur ini datang? Saya melihat ada PR tertutup dan terbuka, referensi terakhir sekitar sebulan yang lalu?

fungsi ini akan sangat berguna - dapatkah kami segera memilikinya?

Tolong tambahkan +1 saya ke ini saja. Saya baru saja menghabiskan 4 jam mencoba mencari tahu bagaimana sintaks saya salah; padahal sebenarnya itu diam-diam mengabaikan fakta bahwa saya melewati jalur absolut di luar folder penyebaran grafik. Tidak berhasil sampai saya menemukan masalah ini!

Dalam sistem unix, akses ke file dalam direktori di luar pohon direktori bagan helm dapat dicapai dengan menggunakan tautan simbolik (setidaknya menggunakan Helm 3.3.4)

Tolong tambahkan +1 saya ke ini saja. Saya baru saja menghabiskan 4 jam mencoba mencari tahu bagaimana sintaks saya salah; padahal sebenarnya itu diam-diam mengabaikan fakta bahwa saya melewati jalur absolut di luar folder penyebaran grafik. Tidak berhasil sampai saya menemukan masalah ini!

@catdevnull --