Saya baru saja mengalami ini juga. Saya biasanya ingin tag gambar ditentukan pada saat mengemas bagan, tetapi untuk men-debug aplikasi ingin melakukan penginstalan dengan tag yang berbeda.

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

Mengangkat ini lagi seperti yang diangkat di https://github.com/kubernetes/charts/pull/5919

Menyalin sebagian dari komentar saya baru-baru ini:

Kami secara khusus memilih untuk menjaga agar versi minor bagan kami selaras dengan versi aplikasi minor (walaupun nomor versi tambalan dapat, dan memang terpisah).

Ini karena kami dapat menambahkan flag baru ke rilis baru cert-manager, dan dengan menambahkan dukungan untuk itu ke dalam bagan Helm akan merusak kompatibilitas dengan rilis cert-manager yang lebih lama, karena mereka tidak mendukung flag. Ini adalah pertanyaan yang cukup mendasar seputar pembuatan versi bagan Helm di IMO secara umum, dan kami tidak memiliki cerita yang bagus untuk itu.

Saya tahu tidak disarankan untuk mencoba dan menyelaraskan appVersion dengan versi bagan, tetapi dengan cara ini, pengguna tahu bahwa mereka dapat menggunakan bagan Helm versi 0.3.x dengan manajer cert 0.3.x, dan bagan versi 0.4.x dengan cert -manajer 0.4.x. Kompatibilitas didefinisikan dalam versi minor.

/hapus siklus hidup basi

Saya ingin membawa ini kembali untuk diskusi.

Secara keseluruhan, kami belum melihat banyak hal menarik yang mendukung pembuatan versi bagan untuk aplikasi internal kami ketika semua yang berubah adalah tag gambar yang digunakan oleh beberapa komponen. Saat memutakhirkan rilis, bidang appVersion sepertinya tempat yang tepat untuk informasi ini.

Menyalin proposal asli saya yang dirujuk di atas:

Alur kerja kami saat ini untuk menerapkan bagan helm melibatkan tugas-tugas yang memungkinkan yang memanggil perintah CLI upgrade helm dan akan menyenangkan untuk dapat melewati tanda untuk mengatur appVersion saat merevisi rilis untuk versi bagan yang sama.

Mungkin sedikit aneh secara konseptual karena appVersion dikaitkan dengan bagan daripada rilis, tetapi dalam kasus kami, kami hanya memperbarui tag gambar yang digunakan untuk beberapa wadah dan alur kerja kami belum menyertakan versi bagan dan/atau repositori bagan belum. Ini mungkin berubah di masa mendatang, tetapi untuk saat ini saya tidak melihat masalah apa pun dengan menambahkan tanda untuk --app-version saat menginstal dan memutakhirkan karena bidang ini murni informasi.

ketika mengembangkan aplikasi internal kita sendiri, aplikasi itu sendiri berubah lebih banyak daripada bagan yang menyebarkannya. Biasanya perintah Continuous Deployment kami adalah helm upgrade dengan tidak lebih dari --set imageTag=<new_version> (jelas, digunakan di tempat lain dalam bagan untuk mengatur versi penampung) Jika kami menggantinya dengan --app-version itu akan memberikan kami titik visual lain di helm ls untuk melihat versi kode apa yang digunakan bersama dengan versi bagan yang digunakan.

Untuk membuat ini lebih terlihat jika tidak, saya telah membuat standar dalam menyetel tag metadata imageTag yang disetel ke imageTag yang diteruskan saat install/upgrade. Ini memungkinkan saya untuk menggunakan dasbor K8s atau dengan mudah membuat dasbor Graphana dengan imageTag ditampilkan, tetapi mengharuskan saya untuk meninggalkan baris perintah dan menggunakan mousey clicky.

Ada berita tentang ini?

Terima kasih

Setiap pembaruan tentang ini. Tampaknya PR dari @Eraac melakukan apa yang diminta. Seperti yang disebutkan @TD-4242, kami juga menjalankan helm upgrade --set imageTag=<imagetag> , namun ini tidak memperbarui VERSI APLIKASI yang tercantum dalam output helm ls . Mampu --set app-version atau --set version akan memungkinkan kita untuk menjalankan helm upgrade sedemikian rupa sehingga helm ls dengan benar menunjukkan versi yang digunakan.

Ada pembaruan?

Aaaaan segera akan menyenangkan!

itu akan sangat berguna

Juga menyukai kemampuan untuk mengatur versi aplikasi pada waktu penginstalan karena kami menggunakan bagan umum untuk menyebarkan aplikasi

+1

+1

Ini akan sangat membantu

Meminta hal yang sama

Harap hentikan spam dengan +1. Sudah ada PR (https://github.com/helm/helm/pull/4961) dan orang-orang sedang mendiskusikan proposal tersebut. Balasan terakhir bahkan 2 hari yang lalu.

Hai @filipre

Sudah ada PR (#4961) dan orang-orang sedang mendiskusikan proposalnya.

Menurut PR itu, ini dipindahkan ke sini:
https://github.com/helm/helm/pull/5492
Ini PR terbaru ke #4961 dan sepertinya kalau kita tunggu reviewnya digabung...

@filipre Bisakah Anda mengatakan: apa yang terjadi dengan PR? Sepertinya PR tidak bergerak setengah bulan

Ini akan sangat berguna. Saya mengalami sesuatu di mana saya perlu menyematkan aplikasi ke versi 0.6.0, dan versi bagan tidak ada hubungannya dengan versi aplikasi.

Saya setuju, saya juga berpikir ini akan sangat berguna. Ada pembaruan?

Lihat https://github.com/helm/helm/pull/5492#issuecomment -509662190.

Baru saja mencapai masalah ini sekarang ketika saya menyadari ini akan menjadi masalah saat menulis bagan Helm yang kami rencanakan untuk digunakan kembali untuk banyak aplikasi. Mengingat kurangnya kemajuan dalam memecahkan masalah ini dengan cara yang sederhana (yaitu dengan tanda untuk menyetel versi aplikasi saat penginstalan), saya telah menemukan alternatif yang seharusnya berfungsi untuk saat ini. Ini sangat sederhana - lakukan saja helm fetch terlebih dahulu dengan opsi untar, dan kemudian helm package dengan flag --app-version yang memang ada di sana, lalu lanjutkan untuk menginstal bagan lokal itu.

Ini tidak ideal, tetapi hasil akhirnya di helm list benar, dan sangat mudah untuk melakukannya di server CI. Akan senang jika --app-version tersedia di helm install dan helm upgrade .

Ringkasan diskusi di #5492 adalah bahwa perintah yang membungkus logika helm package dan helm install akan menyelesaikan kasus penggunaan yang awalnya dijelaskan dalam masalah ini.

Dengan kata lain, Anda dapat menyiasatinya dengan menjalankan yang berikut ini:

$ helm package myapp --app-version 1.0.0
$ helm install myapp-1.0.0.tgz

(Komentar bergerak dari PR yang baru saja ditutup di sini - jadi tidak berakhir di Nirvana)

Inilah 2 sen saya untuk ini:
Dengan asumsi kita memiliki kendali chart version X menyebarkan layanan dengan appVersion Y .

Diagram helm digunakan untuk menggambarkan infrastruktur di dalam Kubernetes pada chart version X yang digunakan untuk meng-host layanan appVersion Y .

Selama pengembangan awal, X dan Y akan berubah secara teratur. Namun, di beberapa titik X akan lebih atau kurang stabil dan Y akan terus berubah (kecuali Y memiliki beberapa persyaratan baru untuk infrastruktur, yang kemungkinan besar terjadi jauh lebih jarang dalam siklus pengembangan Y ).

Dengan pendekatan yang diusulkan dalam tiket ini, seseorang dapat mengambil paket bagan kemudi yang stabil pada versi X untuk menerapkan appVersion Y , Y+1 , Y+N , dll.

Namun, tidak mengizinkan flag ini ditimpa selama pemasangan atau peningkatan helm dan sebagai gantinya hanya di mis paket akan secara efektif mengikat X dan Y bersama-sama memaksa saya untuk selalu membuat X+1 untuk Y+1 . Ini tampaknya tidak perlu bagi saya dan akan menghasilkan satu ton paket helm yang secara efektif tidak berubah selain dari itu mereka mereferensikan appVersion . Dari sudut pandang saya, versi aplikasi dan versi infrastruktur yang menghosting aplikasi tersebut memiliki hubungan, tetapi harus atau masih dapat diversi secara independen. Bagaimana hal itu dilakukan harus diserahkan kepada tim pengembangan masing-masing.

Ringkasan:

Pendekatan ini pasti berhasil, tetapi juga menghasilkan banyak paket Helm yang tidak perlu di mana hanya AppVersion berubah:
$ helm package myapp --app-version 1.0.0 $ helm install myapp-1.0.0.tgz

Ya, tapi saya kira itu tidak masalah jika Anda mengambil pendekatan yang saya sebutkan di atas. Dorong bagan Anda ke repo bagan tanpa set versi aplikasi (atau 0.0.0 atau sesuatu), lalu ketika Anda ingin menggunakannya, gunakan helm fetch , lalu kemas dengan versi aplikasi yang tepat, lalu gunakan lokal .tgz file dan jangan mendorong grafik itu. Dengan begitu repo bagan Anda tetap bersih dan Anda hanya memiliki perubahan bagan aktual yang terwakili di sana.

Ya, itu akan berhasil. Dalam hal ini, seseorang tidak akan pernah dapat secara langsung menggunakan artefak penyebaran (misalnya dengan menginstal langsung dari repositori Helm), tetapi selalu harus mengirimkannya melalui langkah tambahan yang memutasikan artefak tersebut.

Di mana dikatakan bahwa Charts.yaml tidak dapat diubah, saya berpendapat bahwa artefak penyebaran harus demikian.

_Merangkum pemikiran saya dari https://github.com/helm/helm/pull/5492#issuecomment -520029902_

Ada masalah dalam cara komunitas menafsirkan paket, bagan, dan versi. @BenjaminSchiborr , saya harap ini masuk akal bagi Anda.

Bagan - adalah kode sumber rilis Anda. Seperti kode sumber aplikasi Anda. Terdiri dari template, file kode.
Package - adalah build dari rilis Anda, artefak. Seperti biner, dibangun dari kode sumber Anda. Terdiri dari versi produksi tetap: versi grafik dan versi aplikasi.
Rilis - adalah build, dikerahkan dengan konfigurasi yang ditentukan.

Tidak mungkin Anda bisa membuat Rilis dari Bagan . Ini tidak bekerja dengan cara ini!

Sebelum menerapkan aplikasi Anda di atas panggung, Anda harus memiliki bagan. Kemudian, Anda perlu mengemas aplikasi Anda dengan bagan, memperbaiki kedua versi, menggunakan helm package . Ini akan menghasilkan sebuah paket, yang dapat digunakan pada tahap apa pun. Kemudian, Anda menginstal paket ini pada, misalnya, tahap QA, mempromosikannya di UA dan kemudian di Produksi, menggunakan helm install .

Ini adalah cara kerja perangkat lunak berorientasi paket.

Kebingungan

helm install membutuhkan sumber, yang harus diinstal. Sumber bisa berupa:

1. Nama paket, tersedia dari registri
2. Jalur file paket, jika paket sudah diunduh atau dibuat
3. URL paket, jika tersedia menggunakan HTTP
4. Jalur direktori bagan

Pendekatan ke-4 terasa seperti kambing hitam di sini, bukan begitu? Inilah sebabnya mengapa ppl membingungkan Paket dan Bagan. Dan ini adalah akar masalahnya.

Pemikiran

Ada dua jenis aplikasi di alam liar:

Besar/sedang - di sinilah kami memiliki waktu, uang, dan sumber daya untuk menyiapkan alur terperinci dan terperinci untuk introspeksi dan jaminan kualitas yang lebih baik.
Kecil - layanan mikro, proyek hewan peliharaan, PoC, proyek berbiaya rendah, proyek tanpa pengetahuan DevOps atau bahkan memimpin pengujian proses pengembangan.

Dengan proyek kecil, Anda tidak memiliki waktu atau kebutuhan untuk membuat atau menangani pengemasan. Anda ingin menulis beberapa file template dan menyebarkannya dengan satu perintah !

Inilah mengapa helm install mengizinkan penggunaan seperti itu, seperti helm package & helm install . Tapi itu tidak memberikan kemampuan penuh helm package , seperti --app-version .

helm install bisa menjadi helm package & helm install , tetapi itu akan membuat helm install berantakan, neraka untuk dukungan, pengujian dan membuat praktik yang baik.

Usulan 1

Sederhanakan helm install . Seharusnya hanya mengizinkan paket yang disediakan, untuk menyederhanakan basis kode, menguji dan membuatnya beropini, untuk menyederhanakan pemahaman tentang helm .

Usulan 2 - helm run

Perkenalkan perintah baru: helm run . Perintah, yang seharusnya berfungsi . Ideal untuk aplikasi kecil. Atau mungkin sedang dan besar.

Itu harus menggabungkan helm package dan helm install , memberikan kemampuan dari kedua perintah, tidak termasuk yang tidak masuk akal dalam usecase tersebut.

helm package membuat build, seperti yang dilakukan go build . go run memungkinkan untuk memulai aplikasi tanpa proses pembangunan, jadi helm run terlihat seperti nama yang solid di sini.

Hal-hal tambahan yang perlu dipertimbangkan:

• Haruskah itu menggunakan upgrade --install sebagai gantinya?
• Haruskah --atomic diaktifkan secara default?

@iorlas ,
komentar Anda masuk akal. Namun, Anda berasumsi bahwa hanya ada satu paket akhir yang secara bawaan mengikat versi infrastruktur dan versi perangkat lunak, sedangkan saya berasumsi saya memiliki paket untuk versi perangkat lunak saya dan paket untuk infrastruktur saya dan ingin mengikatnya dalam rilis (misalnya melalui konfigurasi status yang diinginkan yang merujuk pada versi perangkat lunak dan versi infrastruktur).

Saya tidak mengerti mengapa proses pengembangan harus dipaksakan ke dalam pola itu di mana itu juga dapat diserahkan kepada kelompok pengembangan yang bertanggung jawab untuk memutuskan apakah mereka ingin menyatukan infrastruktur dan versi perangkat lunak di tingkat paket kemudi atau lebih baru. Saat ini proses penyebaran harus selalu menggunakan paket helm baru, sedangkan hanya versi perangkat lunak yang berubah. Ini menghasilkan ribuan paket yang tidak berguna dalam repositori untuk saya.

Saya baik-baik saja jika ada beberapa keuntungan jangka panjang untuk ini. Aku hanya tidak melihatnya.

@BenjaminSchiborr Oke, izinkan saya menguraikannya sedikit.

Anda dapat memiliki Chart(== infrastruktur), yang memiliki versi X .
Anda dapat memiliki aplikasi Anda, versi Y .

Cara kerja helm sekarang, ini menyatukan versi infrastruktur dan aplikasi pada langkah helm package . Kemudian, Anda perlu mengikatnya dengan namespace k8s, menghasilkan Release.

Jadi rumusnya adalah: package(infra + app) + k8s = Release

Yang benar-benar Anda inginkan, adalah melewati langkah tengah ini dan mengikat ketiga komponen menjadi satu dalam satu langkah - Lepaskan. Seperti ini: infra + app + k8s = Release . Apakah saya benar?

Inilah yang akan dilakukan helm run , di permukaan. Di bawah tenda, itu akan sama.

Tapi... Saya merasa Anda mungkin kehilangan inti dari Helm . Meskipun alat apapun bisa digunakan sesuka hati pengguna, selalu ada ide yang mempengaruhi masyarakat, menciptakan "jalan", sehingga teleskop tidak akan berakhir sebagai hummer dengan kemampuan untuk menyeduh bir.

Biarkan saya mencoba menjelaskan bagaimana itu harus digunakan dan akan luar biasa untuk melihatnya dari sudut pandang Anda.

Helm sendiri dibuat untuk mengabstraksi template dan penerapan k8s, menyatukan aplikasi dan infrastruktur, dengan dependensinya: alih-alih menulis ulang template secara manual, menerapkannya pada K8s dan kemudian menyediakan tag gambar baru, Anda hanya memerlukan satu perintah - helm upgrade . Seperti paket MSI atau deb.

Saat Anda perlu menginstal versi aplikasi baru atau menurunkan versinya, Anda harus menggunakan helm untuk itu. Alih-alih mengelola aplikasi, Anda mengelola seluruh paket. Akan sulit untuk mengembalikan versi aplikasi dan infrastruktur secara terpisah ketika terjadi kesalahan - saya pernah ke sana, tidak akan menyarankan siapa pun.

Jadi itu adalah hal yang benar untuk memiliki banyak paket di registri Anda, karena paket tersebut bukan infrastruktur, paket adalah aplikasinya, karena aplikasi tidak berarti apa-apa di K8s tanpa infrastruktur.

Jika masalah Anda karena Anda memiliki terlalu banyak paket dalam repo, saya sarankan untuk menggunakan artefak daripada repositori. Saya melakukannya seperti itu di CI: buat aplikasi, kirim ke registri buruh pelabuhan, buat paket, simpan sebagai artefak untuk dirilis. CircleCI, Travis, Azure Pipelines mendukung pembuatan file yang dilampirkan untuk dibuat sebagai artefak. Bisakah Anda melakukan hal yang sama?

Mungkin saya tidak mengerti maksud Helm. Mungkin Helm melewatkan satu poin di sini. Saya pikir tiket ini adalah tentang mengevaluasi hal itu. Dan secara pribadi - juga tentang memperluas cakrawala saya :)

Tapi ya, secara abstrak apa yang Anda katakan itu benar. Saya tidak ingin versi perangkat lunak digabungkan ke paket/rilis helm, jadi pada dasarnya itu adalah infra + app + k8s = Release . Sama seperti saya tidak ingin properti versi perangkat lunak saya terikat dengan paket/rilis helm saya (terlepas dari mungkin default waras yang dapat saya timpa).

Mengenai contoh yang Anda berikan lebih jauh ke bawah. Saya tidak melihat bagaimana ini menunjukkan bagaimana pendekatan ini bermasalah. Anda masih akan menggunakan helm untuk roll-back atau roll-maju. Jika infrastruktur berubah, Anda menggunakan versi bagan helm yang diubah. Jika versi perangkat lunak berubah, Anda menggunakan versi aplikasi yang berbeda. Jika parameter berubah, Anda menggunakan parameter yang berbeda. Itu akan selalu menjadi panggilan helm (tunggal) per layanan.

Bisakah Anda menguraikannya?

Jika masalah Anda karena Anda memiliki terlalu banyak paket dalam repo, saya sarankan untuk menggunakan artefak daripada repositori.

Yang saya maksud adalah terlalu banyak bagan helm yang dikemas (yang sudah menyertakan appVersion). Anggap saja sebagai satu versi bagan kemudi yang stabil dan versi aplikasi yang berubah ratusan kali sehari. Jadi setiap hari beberapa ratus bagan helm yang dikemas per layanan dalam repositori yang kemudian dikonsumsi oleh otomatisasi.

(Pipa saya umumnya terlihat sama dengan Anda: Bangun Aplikasi -> Gambar Docker (menghasilkan appVersion) -> bagan paket (dengan appVersion yang diperbarui) -> mendorong ke repositori?

Saya pikir tiket ini adalah tentang mengevaluasi hal itu.

Tentunya! Menurut pendapat saya, kita sudah memiliki terlalu banyak level abstraksi, jadi memiliki helm di sini sedikit membebani Juga, ada operator k8s di sini, yang dibuat untuk beberapa (mungkin sebagian besar?) dari masalah yang dipecahkan Helm. Tapi itu topik untuk lain waktu, hehe.

Anggap saja sebagai satu versi bagan kemudi yang stabil dan versi aplikasi yang berubah ratusan kali sehari. Jadi setiap hari beberapa ratus bagan helm yang dikemas per layanan dalam repositori yang kemudian dikonsumsi oleh otomatisasi.

Yup, pasti terasa berlebihan, tapi memang disengaja. Seperti, Anda menjalankan build, itu harus menghasilkan beberapa artefak, lalu menyimpannya untuk digunakan untuk disebarkan di atas panggung. Seperti... bagaimana kita bisa menjalankan build yang tidak memiliki hasil build? Haruskah kita membuat build saat kita men-deploy? Ini akan benar-benar salah. Meskipun beberapa pipa CI melakukan itu untuk JS build.

Masalah yang sama yang kita miliki dengan buruh pelabuhan: setiap build menghasilkan gambar buruh pelabuhan baru, yang masuk ke registri buruh pelabuhan. Kita perlu menyimpannya, bagaimana kita harus menyebarkannya, jika kita tidak memilikinya?

Tentu saja kita bisa docker save untuk menghemat ruang pada registri dan menyapu kemudian dalam membangun kebijakan retensi artefak. Tapi jadi kita bisa helm package dan menyimpannya sebagai file.

Tapi saya pasti mengerti maksud Anda, kita dapat memiliki satu "pemasang", yang dapat menerima versi aplikasi. Karena penginstal tersebut memiliki infrastruktur, Anda dapat membuatnya tetap sama, hanya dengan mengubah versi aplikasi. Terlihat rapi dan sederhana, tetapi ada masalah.

Aplikasi itu sendiri tidak masuk akal di lingkungan k8s tanpa infrastruktur .

Bagaimana jika aplikasi Anda bergantung pada beberapa infrastruktur? Contoh dasar - configmap.

Bagaimana jika Anda perlu mengembalikan aplikasi?
Anda perlu menurunkan versi aplikasi, tetapi kemudian Anda juga perlu menurunkan versi infrastruktur.

Bagaimana jika Anda perlu mengembalikan infrastruktur?
Infrastruktur sebelumnya tidak memiliki petunjuk versi aplikasi mana yang perlu Anda instal, karena tidak terikat padanya. Jadi, Anda perlu mengingat aplikasi mana yang mendukung infrastruktur mana dan mengaturnya secara manual.

Sungguh, itu akan menjadi neraka. Dan itu adalah neraka sekarang, ketika Anda tidak memiliki helm. Dan itu tidak salah. Tetapi dalam hal ini, Anda memiliki sedikit alasan untuk menggunakan helm.

kita sudah memiliki terlalu banyak level abstraksi
Semua kedipan yang bagus dan sederhana

Saya pikir poin terakhir Anda sangat meyakinkan:

Infrastruktur sebelumnya tidak memiliki petunjuk versi aplikasi mana yang perlu Anda instal, karena tidak terikat padanya
Ini jelas merupakan masalah jika Anda memisahkan hal-hal ini dan memiliki paket/rilis Helm sebagai sumber kebenaran.

Namun, bagi banyak orang hal ini mungkin tidak terjadi. Ada orkestrasi di atas Helm (yay, lapisan abstraksi lain) yang mengikat beberapa bagan helm (dan AppVersions) bersama-sama (Pikirkan juru mudi, harness, atau sejenisnya). Dan lapisan itu sendiri juga berversi. Dalam hal ini, apa yang Anda gambarkan tidak lagi menjadi masalah, karena Anda tidak akan kembali ke versi yang lebih lama dari bagan kemudi, tetapi ke versi lapisan orkestrasi yang lebih lama (yang masuk akal untuk aplikasi dan infrastruktur).

Tapi helmnya saja ya, 100% masalah . Saya pikir itulah alasan mengapa idenya adalah secara eksplisit mengizinkan untuk menimpa appVersion dan, secara default, tidak mengizinkannya.

Satu hal yang saya suka tentang menggabungkan versi bagan dan versi aplikasi adalah menjadi jelas versi aplikasi mana yang termasuk dalam bagan mana. Jika Anda perlu menerapkan ulang satu versi tertentu, Anda tidak perlu mengingat versi aplikasi mana yang kompatibel dengan versi bagan mana. Karena mereka terhubung bersama, Anda cukup merujuk ke versi bagan yang tepat dan Anda akan yakin, aplikasi dan bagan itu cocok. Saya pikir ini pada dasarnya apa yang dijelaskan @iorlas , bukan?

Pada akhirnya, versi bagan akan bertindak sebagai versi "super":

• perubahan apa pun (terlepas dari apakah itu mengubah aplikasi atau infrastruktur, yaitu bagan) akan menghasilkan versi bagan baru, yaitu versi aplikasi baru akan menyiratkan bahwa versi bagan juga berubah
• versi bagan baru tidak menyiratkan bahwa versi aplikasi berubah

Untuk tujuan dokumentasi (dan mungkin ide bagus lainnya), Anda dapat memperkenalkan versi "hanya-grafik" lain yang hanya akan merujuk pada definisi bagan itu sendiri.

@filipre
Yup-yup! Begitulah seharusnya Helm bekerja, berdasarkan keputusan desain arsitektur saat ini. Seperti yang saya lihat.

Masalahnya adalah kadang-kadang terasa aneh - terlalu banyak untuk pengaturan dan gagasan yang meragukan untuk memiliki aplikasi dan infra yang diikat bersama. Jadi, apakah ini pendekatan yang tepat - itu sebuah pertanyaan.

@BenjaminSchiborr

Namun, bagi banyak orang hal ini mungkin tidak terjadi

Tentunya! Bahkan seluruh k8s, containerising bisa terlalu banyak.

Biarkan saya mencoba memecahnya dari sedikit perspektif lain, mencoba menemukan masalah helm dibuat untuk:

• Instance infrastruktur adalah cara kerja keseluruhan produk: Instans SaaS, kumpulan VM, penyiapan k8s, versi aplikasi (termasuk database, alat observabilitas, router, sidecars, dan instans aplikasi produk)
• Instance infrastruktur membutuhkan satu sumber kebenaran. Sekarang kami memiliki utilitas seperti Terraform.
• Terlalu banyak hal dalam satu folder = keras. Kita perlu menguraikannya. Halo modul Terraform.
• Baik platform maupun aplikasi dalam satu folder = hard. Kita perlu terurai. Halo platform dan wadah. K8 masuk.
  
  
  
  1. Jadi, modul Terraform dapat mengelola platform, termasuk pembuatan lapisan wadah kosong yang siap digunakan
  
  
  2. K8 mengelola wadah, memungkinkan untuk membuat sumber daya dasar menggunakan YAML
  
  
• Banyak file YAML untuk banyak aplikasi K8 (termasuk database dan lainnya) = hard. Pisahkan ke dalam folder per aplikasi.
  
  
  
  1. Jadi di sana kami memiliki beberapa folder seperti PostgreSQL, Redis, MyPetShop. Masing-masing memiliki file YAML untuk sumber daya yang kami miliki. Dan versi aplikasinya perlu disetel agar dapat diterapkan ke K8.
  
  
• Hello Helm - instrumen, yang memungkinkan untuk mengatur folder-folder ini (disebut Bagan), tetapi lebih banyak lagi: terapkan bersama-sama, kembalikan.
• Bagan terlihat kokoh. Mari kita gunakan kembali dengan mendukung variabel. Sekarang Bagan bukan Infrastruktur, tetapi template Infrastruktur.
• Bagan terlihat mengagumkan. Mari berbagi dengan teman-teman. Setiap kali kita memperbarui grafik, kita perlu mendorongnya ke file repo dengan index.

Jadi, rasanya luar biasa dan semuanya, tanpa paket sama sekali. Jadi, Anda perlu menerapkan Bagan ini, lalu berikan versi aplikasi. Dan itu seharusnya.

Tetapi masalah muncul: tidak ada yang mau mengingat Bagan mana yang diperlukan untuk versi aplikasi mana. Bagan mana yang diperbarui untuk memberikan nilai konfigurasi baru untuk versi aplikasi mana.

Pada akhirnya, yang kami inginkan hanyalah "Atur myApp versi 1.4.2 sebagai aplikasi K8s" , yang merangkum semua risiko, ketergantungan, perubahan menjadi satu artefak - penginstal aplikasi, yaitu apps versions + hooks + setup logic + infrastructure to connect it all . Inilah mengapa kami memiliki hal-hal seperti MSI, Deb, RPM, bahkan NPM, Go mod, Pip, Gem.

Di sinilah Paket muncul. Dan Paket, menurut definisi, perlu dibuat sebagai rilis yang dapat diinstal, dalam aliran CI/CD. Jadi kami dapat mengirimkannya ke registry dan/atau setup di sistem kami (k8s cluster).

Dan tidak ada proyek lain yang berbeda. Ketika kita helm install Chart secara langsung, tanpa paket, kita melakukan hal yang sama. Tetapi alih-alih pembuatan paket, kami membuatnya pada langkah yang berbeda. Alih-alih membangunnya pada proses pembuatan aplikasi, kami membangunnya pada langkah rilis. Kami masih menyatukan versi infrastruktur dan aplikasi . Secara implisit .

Hal yang lucu adalah:

• Ketergantungan diperbarui = perbarui versi templat Infrastruktur (Bagan)
• Aplikasi diperbarui = menghasilkan garpu, subset dari templat Infrastruktur (Bagan) - Paket, dengan versinya sendiri

Namun, operator k8s harus diproyeksikan pada masalah saat ini, jadi seharusnya hanya ada satu instrumen, yang seharusnya bekerja seperti operator, tetapi menyediakan proses pelepasan yang mudah, seperti halnya helm.

Ada pikiran? Kami mungkin membuat sesuatu yang baru di sini, tetapi lebih baik

Apa yang Anda gambarkan sangat masuk akal untuk aplikasi yang dimaksudkan untuk digunakan oleh orang lain di infra yang tidak dapat Anda kendalikan. Namun, dalam skenario perusahaan, membuat paket menjadi pekerjaan yang sibuk: kami mungkin memiliki lusinan layanan mikro pemotong kue, yang disebarkan ke lingkungan bersama atau pemotong kue, dan berdasarkan definisi pipa CI/CD yang hidup di repo itu sendiri (pikirkan azure-pipelines.yaml), "versi paket" hanyalah build yang dihasilkan dari versi tertentu dari cabang master. Artinya, saya tidak benar-benar perlu menyimpan "paket" di mana pun - build saya akan menghasilkan paket yang sama, dengan bit yang sama dan variabel yang sama yang digunakan dalam configmaps, dll. Dalam skenario seperti ini, saya akan mengubah bagan helm hanya ketika perubahan infra layanan, yang jarang terjadi. Helm dalam gambar ini adalah karena 1) Saya sudah harus menggunakannya untuk menyebarkan beberapa bagian infra (misalnya, nginx), 2) Saya tidak perlu menemukan kembali roda dengan templating k8s yaml.

@wasker

Mari kita memproyeksikannya, misalnya, buruh pelabuhan. Gambar Docker juga merupakan paket. Ini mengikat binari bersama dengan gambar OS = infrastruktur. Saya percaya, alasan untuk membuat gambar buruh pelabuhan setiap kali kita membuat build, sama dengan membuat paket helm.

Jika seseorang tidak perlu mengabstraksikan semuanya ke gambar buruh pelabuhan, seseorang tidak perlu buruh pelabuhan dan dapat hidup dengan VM biasa.

Jadi, jika kita mencoba untuk memproyeksikan penggunaan buruh pelabuhan ke helm, menggunakan helm sebagai instrumen infrastruktur saja akan seperti menggunakan buruh pelabuhan hanya untuk membuat gambar awal, kemudian memperbarui gambar tersebut pada host k8s itu sendiri, dengan mengirimkan binari baru. Itu buruk, sama buruknya dengan menggunakan helm dan tidak mengemasnya setiap kali.

Bagaimanapun, saya pikir, kami salah jalan. Apakah ada yang menggunakan helm dan kemudian memperbarui gambar secara manual? Saya percaya, kami memiliki 3 kasus penggunaan umum:

1. helm package chart -> helm install package
2. helm install chart
3. helm install -> kubectl set image

@wasker Yang mana milikmu? Saya percaya, bukan yang ke-3. Meskipun ini adalah pemisahan nyata dari konfigurasi infrastruktur dan pembuatan versi aplikasi, akan sangat tidak menyenangkan untuk digunakan. Karena, itu berarti, ketika Anda perlu memperbarui infrastruktur, Anda akan kehilangan semua versi. Anda perlu memperbaruinya di Bagan, secara manual, atau kubectl set image untuk setiap penerapan.

Jadi, kita berbicara tentang yang kedua, helm install chart , "tanpa kemasan". Jadi, helm selalu ada di gambar . Masalahnya adalah, paket sedang dibuat, tetapi dalam waktu proses - ketika kami menerapkan aplikasi kami. Jadi CI build bertanggung jawab atas pembuatan paket, secara implisit, saat kita perlu menerapkannya.

Dan jika memproyeksikannya di golang, praktik seperti itu terlihat seperti mengirim kode sumber dan menjalankannya sebagai go run di buruh pelabuhan, alih-alih membangunnya dan menggunakan biner.

Jadi, alasan sebenarnya untuk melewatkan langkah pengemasan adalah untuk menyederhanakan keseluruhan gambar untuk insinyur. Apakah itu ?

Di sinilah kita bisa mulai berbicara. Di sini https://github.com/helm/helm/issues/3555#issuecomment -529022699 adalah proposal saya. Tambahkan helm run dan modelkan sebagai go run .

Jika kita benar-benar perlu membagi infrastruktur dan pembuatan versi aplikasi , itu berarti menggunakan helm hanya untuk memperbarui/menanam infrastruktur. Meskipun saya ingin melihat cara melakukan ini, saya dapat melihatnya, yang tidak akan menambah pusing pada pembaruan. Kita dapat mengabaikan versi dan hal-hal penerapan saat ini... tapi menurut saya itu sangat salah, akan membuang-buang waktu untuk membuatnya.

Mari kita memproyeksikannya, misalnya, buruh pelabuhan. Gambar Docker juga merupakan paket. Ini mengikat binari bersama dengan gambar OS = infrastruktur. Saya percaya, alasan untuk membuat gambar buruh pelabuhan setiap kali kita membuat build, sama dengan membuat paket helm.

Saya kira masalahnya adalah jika Anda membuat Gambar Docker baru, itu karena sesuatu di dalam gambar itu telah berubah. Dalam skenario yang dijelaskan di sini, isi dari Bagan Helm yang dikemas tidak berubah selain dari satu baris - versi aplikasi. Ini memang mempengaruhi hasil akhir, tetapi itu tidak mengubah bagaimana grafik Helm itu sendiri berperilaku. Ini akan melakukan hal yang sama, dengan cara yang sama, hanya dengan nilai yang berbeda - Bagan Helm sebagai entitas itu sendiri tidak berubah sedikit pun sebagai akibat dari perubahan versi aplikasi; hanya apa yang dirilis pada akhirnya memiliki.

Anda dapat menggambar paralel di sini dengan kemampuan untuk melakukan hal-hal seperti menggunakan konfigurasi untuk Gambar Docker. Anda meneruskan variabel lingkungan ke Gambar Docker, ini memengaruhi cara menjalankannya saat runtime, dan Anda tidak membangun kembali gambar untuk mengubah variabel tersebut. Isi gambar tidak berubah, tetapi hasil akhirnya memiliki - situasi yang sangat mirip di sana, tetapi dalam hal itu perilakunya diinginkan dan normal.

Dan jika memproyeksikannya di golang, praktik seperti itu terlihat seperti mengirim kode sumber dan menjalankannya sebagai go run di docker, alih-alih membangunnya dan menggunakan biner. [...] Jadi, alasan sebenarnya untuk melewatkan langkah pengemasan adalah untuk menyederhanakan keseluruhan gambar untuk insinyur. Apakah itu?

Tidak dalam pandangan saya. Secara realistis argumen di sini adalah apakah orang mempertimbangkan versi aplikasi "bagian dari bagan", dan juga apakah mereka menganggap Bagan Helm berbeda dari Gambar Docker yang disebarkan sebagai hasil bagan. Pandangan saya tentang ini adalah apa yang telah saya sebutkan di atas. Ini seperti mengambil biner Go yang dikompilasi, dalam gambar Docker, dan menjalankannya dengan beberapa variabel lingkungan yang berbeda.

Meskipun demikian, argumen yang telah dibuat untuk mengemas ulang Bagan Helm dengan versi aplikasi baru dan menggunakan Versi Bagan sebagai semacam "versi super" sangat menarik (yaitu untuk keuntungan selalu memiliki versi aplikasi yang kompatibel yang digunakan dengan bagan - asalkan versi aplikasi tidak dapat disesuaikan melalui nilai).

Pertanyaan saya adalah - _mengapa tidak mendukung kedua pendekatan?_ Ada pro dan kontra untuk setiap pendekatan. Pada dasarnya, tidak mendukung ini hanya membuat beberapa alur kerja yang benar-benar valid menjadi lebih sulit. Misalnya menggunakan CD Flux dan Operator Helmnya. Jika Anda memiliki Bagan Helm bersama (yaitu karena Anda memiliki jenis layanan tertentu yang banyak Anda terapkan dan memiliki banyak karakteristik yang sama), maka untuk mendapatkan keluaran helm list berguna, Anda harus memiliki Helm baru Bagan untuk setiap aplikasi, dan setiap rilis juga membutuhkan Bagan Helmnya sendiri. Ini saja memperumit saluran pipa, karena jika Bagan dapat dibagikan, itu bisa memiliki salurannya sendiri yang hanya berjalan ketika Bagan diperbarui, dan saluran aplikasi bahkan tidak perlu menjalankan satu perintah Helm (asalkan Flux CD menambahkan dukungan untuk bendera versi aplikasi baru saat menginstal/memutakhirkan).

Pertanyaan saya adalah - mengapa tidak mendukung kedua pendekatan?

Itulah yang saya pikirkan.

Dalam kasus saya, "versi super" bukanlah bagan helm tetapi lapisan lain yang hanya menggunakan sejumlah besar bagan helm. Bagi saya satu bagan Helm tidak ada artinya karena hanya menggambarkan layanan kecil di antara banyak lainnya. Hanya bersama-sama mereka membentuk pelepasan yang berarti.
Jadi dalam kasus saya "versi super" adalah ringkasan dari semua rilis tersebut bersama-sama (begitulah sebenarnya versinya).

Namun, ada argumen untuk memiliki bagan Helm itu sendiri sebagai "versi super" deskriptif.

Kembali ke poin @seeruk : Mengapa tidak mendukung keduanya?

Mungkin akan membantu untuk debat saat ini untuk mendapatkan suara dari luar. Untuk sedikit konteks, saya telah menggunakan helm untuk total _11 hari._ Saya pikir ini memberi saya perspektif unik untuk ditambahkan karena saya belum terlibat dalam pembelajaran lanjutan apa pun. Semua yang saya kumpulkan berasal dari dokumentasi dan eksperimen.

Bagaimana Saya Melihat Helm

Sampai dengan membaca perdebatan saat ini tentang helm menginstal paket daripada grafik, saya percaya bahwa Helm terutama merupakan antarmuka untuk menggambarkan sumber daya Kubernetes terkait. Keyakinan ini terutama berasal dari dokumentasi Helm yang mengatakan ini:

Helm menginstal grafik ke Kubernetes, membuat rilis baru untuk setiap instalasi. Dan untuk menemukan grafik baru, Anda dapat mencari repositori grafik Helm.

Untuk konteksnya, dokumen helm stabil saat ini juga menyatakan:

Bagan adalah paket Helm. Ini berisi semua definisi sumber daya yang diperlukan untuk menjalankan aplikasi, alat, atau layanan di dalam cluster Kubernetes. Anggap saja seperti Kubernetes yang setara dengan formula Homebrew, file Apt dpkg, atau Yum RPM.

Jadi sekarang ada beberapa kebingungan! Dokumen Helm mengatakan dengan jelas bahwa "bagan adalah paket helm," tetapi jika itu masalahnya, lalu mengapa helm install menerima repo Bagan yang tidak dikemas?

Perilaku inilah yang memengaruhi pandangan saya saat ini tentang apa itu helm dan bagaimana cara kerjanya:

Helm bertindak sebagai mapper antara struktur _what_ yang akan masuk ke cluster dan _what properties_ hal-hal itu miliki.

Jadi sekarang pertanyaannya adalah: "Apa yang dikerahkan Helm?"

Apa itu Pemasangan Helm?

Ketika saya menjalankan helm install release-name ./local_chart saya mengharapkan helm untuk merender semua template bagan secara lokal dengan nilai yang ditentukan (baik melalui default atau override) dan mendorong versi yang dirender ke Kubernetes. Saya juga mengharapkan Helm untuk menyimpan objek Kubernetes yang sebelumnya digunakan jika saya melakukan rollback. Konsep "kumpulan templat yang dirender" ini (yang berisi beberapa metadata) adalah rilis dan merupakan paket. Semua definisi sumber daya tersebut (bahkan jika tidak berubah) harus dalam _statusnya yang dijelaskan dalam bundel_ agar rilis ada (atau dikembalikan).

Dari sini, saya menduga bahwa helm hanya benar-benar menyebarkan paket . Tampaknya menjadi satu-satunya hal yang benar secara semantik yang dapat Anda katakan; namun, argumen tentang bagaimana paket-paket ini didistribusikan tampaknya menjadi akar penyebab perdebatan ini dalam praktiknya. Secara khusus, "apakah memutakhirkan atau mengubah versi aplikasi merupakan paket baru?"

Dengan _semantik pribadi saya_ jawaban untuk pertanyaan ini adalah ya . Dengan argumen bahwa Anda tidak akan menabrak nomor versi kecuali ada sesuatu yang berubah, Anda hanya perlu menyesuaikan nomor versi aplikasi Anda jika beberapa properti yang mendasarinya berubah. Ini mungkin melibatkan menarik gambar buruh pelabuhan yang berbeda dari registri, atau mengatur tanda fitur melalui variabel lingkungan, atau sejumlah praktik berbeda yang dapat digunakan untuk mengubah perilaku beberapa artefak kode.

Karena itulah saya mulai membersihkan registry kami dan tidak pernah menyebarkan dari :latest kecuali dalam pengembangan. Menggunakan "meta-tag" alih-alih tag rilis dari gambar buruh pelabuhan membuat pengikatan penerapan yang diberikan ke basis kode yang diberikan menjadi tidak mungkin. Kami mempelajari ini dengan cara yang sulit (tapi untungnya dalam ujian, dan bukan dalam prod).

Pola Mana yang Harus Digunakan?

Ini sudah dikomentari oleh Helm: package .

Mengingat bahwa pola ini adalah pola --appVersion disediakan. Menjawab "mengapa" ini mungkin lebih penting daripada apa pun, jadi izinkan saya mengakhiri kontribusi saya dengan jawaban itu.

Mengapa mendukung --appVersion?

Mari kita lihat kasus penerapan khusus:

Sebuah perusahaan memiliki aplikasi dengan dua versi utama. Beberapa klien perusahaan ini belum berkomitmen untuk meningkatkan ke versi utama terbaru dari aplikasi ini dan menggunakan yang lebih lama dari keduanya. Karena kontrak pengembangan berbayar, pengembangan langsung masih dilakukan pada versi mayor lama... tetapi produknya "sama". Infrastruktur yang akan digunakan untuk kedua versi aplikasi ini adalah sama; namun, versi aplikasi akan sangat berbeda antara penerapan ini.

Apa yang harus dilakukan perusahaan ini?

1. Buat dua bagan kemudi yang terpisah, hampir identik, yang hanya berbeda di appVersion ?
2. Gunakan satu bagan kemudi tetapi terus perbarui appVersion bolak-balik di antara versi aplikasi utama?
3. Ganti appVersion dengan tanda (saat ini tidak didukung) yang menyebabkan potensi kesalahan pengembang pada baris perintah?
4. Rescope appVersion dari Chart.yaml dan ke values.yaml ?

Proposal 1 memperkenalkan sedikit lebih banyak overhead daripada proposal lainnya, tetapi juga memiliki manfaat untuk menjaga bagan untuk versi aplikasi ini terpisah jika berbeda. Ini memiliki kasus penggunaan yang jelas dan mungkin akan diadopsi dalam banyak kasus masalah ini.

Proposal 2 memiliki overhead yang lebih sedikit daripada proposal 1 tetapi memperkenalkan variabilitas tinggi ke dalam bagan. Apa yang terjadi jika Anda menjalankan helm install release-name https://remote-repo.com/chart dan versi grafik terbaru adalah versi aplikasi yang salah? Ups. Mungkin bukan pendekatan terbaik.

Proposal 3 adalah apa yang sedang kita diskusikan. Saya pribadi tidak menyukai opsi itu tetapi hanya karena saya merasa itu adalah solusi yang salah untuk masalah tersebut. Apakah itu membuat appVersion dapat dikonfigurasi? Tentu. Tetapi juga memiliki masalah yang sama yang Anda hadapi ketika Anda menjalankan helm install release-name https://remote-repo/chart : Metadata bersifat sementara dan HANYA dikelola oleh Helm.

Saya sebenarnya cukup terkejut karena belum ada yang menawarkan Proposal 4 atau semacamnya. Itu menempatkan appVersion ke dalam keadaan di mana ia dapat ditimpa (mengaktifkan sesuatu yang menyerupai helm run ), dapat dimuat dalam paket yang dihasilkan oleh helm package , dan benar-benar menguraikan konsep versi aplikasi dari versi bagan sambil menjaga konsep appVersion digabungkan ke penerapan helm (appVersion harus ada di suatu tempat kan?).

Saya harap ini bermanfaat. PR ini.

@jrkarnes : Dalam arti 4) telah diusulkan dan digunakan sebagai solusi oleh banyak orang (lihat di sini https://github.com/helm/helm/pull/5492#issuecomment-517255692 ). Anda dapat menggunakan sesuatu seperti ini di templat Bagan Anda:

{{ default .Values.appVersion .Chart.AppVersion }}

Ini akan memungkinkan Anda untuk menggunakan appVersion di Charts.yaml sebagai default dan menimpanya dengan sesuatu di Values.yaml (yang dapat diganti selama panggilan instalasi/upgrade). Kelemahannya adalah ketika melakukan misalnya helm ls itu akan menunjukkan kepada Anda tidak atau salah appVersion .

@BenjaminSchiborr Terima kasih telah memberi tahu saya tentang ini. Seperti yang saya katakan, saya telah berada di dalam ruang kerja helm untuk waktu yang sangat terbatas sehingga pengetahuan apa pun adalah pengetahuan yang baik untuk saya saat ini.

Saya pikir proposal keempat saya sedikit disalahpahami. Daripada memiliki sesuatu seperti {{ default .Values.appVersion .Chart.AppVersion}} Anda akan menggunakan {{ .Values.Helm.AppVersion}} dan values.yaml memegang appVersion alih-alih Chart.yaml

@jrkarnes
Itulah yang saya pikirkan sekarang. Seperti, mengapa versi aplikasi harus diperlakukan sebagai kepingan salju yang unik. Ini adalah nilai grafik.

Alasan di balik ini mudah: semuanya adalah bagian dari infrastruktur. Jadi, infra memiliki versi. Mengapa dua versi?

Tapi saya terlalu sibuk untuk membungkus kepala saya di sekitar kasus samping dan proyeksi. Tetapi secara umum, itulah pertanyaannya: Mengapa kita membutuhkan versi aplikasi, padahal singkatnya itu semua infrastruktur? atau Bisakah kita menggunakan versi Bagan sebagai versi infrastruktur ketika Bagan hanya infra template, dan sebagai versi aplikasi ketika infra menyertakan versi aplikasi?

Saya akan memikirkannya sedikit lagi

@jrkarnes
Itulah yang saya pikirkan sekarang. Seperti, mengapa versi aplikasi harus diperlakukan sebagai kepingan salju yang unik. Ini adalah nilai grafik.

Alasan di balik ini mudah: semuanya adalah bagian dari infrastruktur. Jadi, infra memiliki versi. Mengapa dua versi?

Pada dasarnya masuk akal untuk menjaga versi grafik terpisah dari versi aplikasi . Contoh cepat mungkin adalah cara terbaik untuk membuktikan bahwa ini masalahnya.

Katakanlah Anda memiliki aplikasi yang digunakan yaitu ver 4.0.0 berjalan pada bagan Anda yang berversi ver 1.1.0 . Selama operasi Anda, Anda menyadari bahwa Anda harus mulai menjalankan tugas cron untuk aplikasi ini. Daripada menulis objek cronJob dan menerapkannya ke cluster, Anda menyadari bahwa orang lain yang menjalankan bagan ini mungkin akan membutuhkan tugas cron juga... jadi Anda menambahkannya ke bagan Anda. Bagan Anda sekarang telah berkembang menjadi ver 1.2.0 tetapi tidak ada perubahan pada aplikasi yang dikelola bagan, masih di ver 4.0.0 .

Kebalikan dari itu juga berlaku dan sudah menjadi bahan perdebatan dalam PR ini.

Tapi saya terlalu sibuk untuk membungkus kepala saya di sekitar kasus samping dan proyeksi. Tetapi secara umum, itulah pertanyaannya: Mengapa kita membutuhkan versi aplikasi, padahal singkatnya itu semua infrastruktur? atau Bisakah kita menggunakan versi Bagan sebagai versi infrastruktur ketika Bagan hanya infra template, dan sebagai versi aplikasi ketika infra menyertakan versi aplikasi?

Saya akan memikirkannya sedikit lagi

Daripada memikirkan kasus sampingan atau proyeksi, pikirkan hal-hal seperti MySql yang memiliki tiga versi mesin yang banyak digunakan dan didukung di luar sana: [5.6, 5.7, 8.0] . Untuk men-deploy instance mysql ke dalam cluster, Anda akan selalu memiliki:

• Pod yang menjalankan instance MySql dari versi yang dipilih
• Layanan yang memungkinkan resolusi kube-dns ke pod (atau pod jika berjalan di HA)
• Sebuah PV untuk pod untuk menulis datanya dengan PVC yang menyertainya

Bagan untuk menerapkan MySql 5.6, 5.7, atau 8.0 harus relatif sama untuk semua versi Engine (aplikasi). Satu-satunya perbedaan nyata adalah versi aplikasi dan gambar buruh pelabuhan (yang mungkin ditandai secara semantik menurut versi mesin).

Saya mengerti maksud Anda tentang bertanya-tanya tentang "kebutuhan" versi aplikasi. Saya pikir itu tergantung pada kenyamanan pengembang atau operasi saat menjalankan helm ls atau helm inspect .

+1 ke @jrkarnes posting terakhir. Ada banyak nilai dalam menjaga versi bagan dan aplikasi sebagai konsep terpisah justru karena versi bagan adalah "versi infrastruktur".

Jika saya menerbitkan bagan untuk dikonsumsi orang lain, itu menjadi bagian dari infrastruktur untuk proyek yang bergantung padanya. Namun, jika saya tidak pernah bermaksud agar aplikasi saya dikonsumsi oleh orang lain, yang saya pedulikan hanyalah mengubah versi bagan saya sendiri dari waktu ke waktu, helm install last-known-good-chart-version , saya cukup menjalankan kembali pipa CD saya dengan pointer ke ID komit baik yang terakhir diketahui.

@iorlas Saya sudah membaca proposal Anda untuk helm run dan saya tidak punya masalah dengan itu. Meskipun saya pikir tidak perlu memiliki dikotomi instal/jalankan, jika itu membuat pikiran pengelola helm tenang tentang membuat versi aplikasi bisa berubah, saya setuju dengan itu. :)

@iorlas Apakah Anda memiliki kesempatan untuk memikirkan apa yang ingin Anda lakukan dengan proposal ini?

Saya rasa saya tidak mengerti bagaimana fungsi penyelesaian yang melibatkan {{ default .Values.appVersion .Chart.AppVersion}} . Saya mendapatkan kesalahan ini:

Kesalahan: kesalahan saat mengonversi YAML ke JSON: yaml: kunci peta tidak valid: map[interface {}]interface {}{".Values.appVersion | default \"0.0.1\"":interface {}(nil)}[

Ini Chart.yaml saya:

name: demo-helm
version: 0.0.1
appVersion: {{ .Values.appVersion | default "0.0.1" }}
home: http://example.com
description: Demo Helm

@IRobL Anda harus memasukkan cuplikan ini ke templates/deployment.yaml , di mana versi digunakan. File seperti values.yaml tidak diperlakukan sebagai template.

@jrkarnes Saya bukan pengelola, jadi kata terakhir akan ada di orang lain, saya kira. Tapi bagaimanapun, saya cukup sibuk selama beberapa minggu terakhir. Pada minggu mendatang saya akan mengevaluasi kembali pendekatan kami saat ini untuk mengelola helm dan packages .

Kami menggunakan pendekatan yang saya jelaskan:

• Helm Chart adalah bagian dari repositori aplikasi
• Pembuatan aplikasi menghasilkan:
  
  
  
  • Gambar buruh pelabuhan -> registri buruh pelabuhan
  
  
  • File statis -> layanan CDN
  
  
  • Paket helm -> penyimpanan CI
  
  
• Jadi, paket Helm adalah artefak utama, mengikat semua artefak aplikasi bersama-sama
• Saat penerapan, install mengatakan paket

Kekhawatiran saat ini:

• Kompleksitas proses pembuatan.
  
  
  
  • Alih-alih gambar buruh pelabuhan dan file statis, file tambahan( helm package ) dihasilkan
  
  
  • Apa alasan utama kita membutuhkan sesuatu selain file yang dihasilkan go build / make install ?
  
  
  • Berapa biayanya?
  
  
  • Mengapa untuk melamar?
  
  
  • Kapan melamar?
  
  
• Durasi pembuatan
  
  
  
  • Bahkan jika kami tidak perlu menerapkannya, kami masih membuang waktu dan uang. 2-5 detik. Tidak banyak, tetapi pekerjaan yang tidak berarti tidak ada artinya.
  
  
• Kompleksitas pembaruan template infrastruktur
  
  
  
  • Saat Bagan diperbarui, nilainya juga harus diperbarui
  
  
  • Bagan adalah satu repo, nilai adalah yang lain, setiap pembaruan ke nilai berarti sedikit sakit kepala
  
  

Evaluasi ulang semacam itu dapat mengarah pada penyederhanaan dan gagasan tambahan. Kita lihat saja nanti :)
Saya akan mengirim pembaruan lebih dekat ke Jumat depan.

Ah, saya mengerti mengapa trik itu tidak berhasil sekarang setelah Anda menunjukkan ini untuk saya, terima kasih. Berikut adalah trik yang menurut saya berfungsi dengan baik untuk banyak orang yang menggunakan Helm 2.x dengan asumsi Anda merasa nyaman membungkus alat helm Anda dengan potongan-potongan overhead semacam ini:

APP_VERSION=0.0.7
sed -i.bak "s/^appVersion:.*\\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
helm install --name helm_demo helm/

@IRobL

Secara umum, jika Anda membungkus penerapan dengan sed, itu berarti mesin templating tidak melakukan apa yang Anda perlukan, yang merupakan inti dari diskusi ini.

Ketika gitlab masih dalam masa pertumbuhan dan tidak memiliki dukungan helm, kami benar-benar memasukkan nilai pada target pengganti pada file manifes buatan tangan.

Ini adalah praktik yang buruk untuk hal seperti ini dan saya akan mendorong Anda untuk menjauh darinya jika memungkinkan.

Pada 7 Oktober 2019, pukul 15.33, IRobL [email protected] menulis:

Ah, saya mengerti mengapa trik itu tidak berhasil sekarang setelah Anda menunjukkan ini untuk saya, terima kasih. Berikut adalah trik yang menurut saya berfungsi dengan baik untuk banyak orang yang menggunakan Helm 2.x dengan asumsi Anda merasa nyaman membungkus alat helm Anda dengan potongan-potongan overhead semacam ini:

APP_VERSION=0,0.7
sed -i.bak "s/^a ppVersion:. *\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
pemasangan helm --nama helm_demo helm/
—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

@jrkarnes , ketika Anda mengatakan praktik buruk, apakah Anda mengatakan bahwa perlu membungkus perintah helm dengan skrip tidak diinginkan? Jika demikian maka saya setuju sepenuhnya. Saya tidak mengatakan saya menentang penambahan flag --app-version sama sekali; sebaliknya saya pikir itu akan menjadi tambahan yang sangat nyaman untuk helm. Jelas berdasarkan PR ini, saya bukan satu-satunya orang yang menggunakan helm yang ingin menjaga variabel appVersion konsisten dengan build sebenarnya yang digunakan. Saya kebetulan sedang mengembangkan library pipeline build yang dapat digunakan kembali yang menggabungkan berbagai alat build untuk menghasilkan build yang dapat direproduksi -- ini adalah praktik umum untuk organisasi teknologi besar. Dalam kasus penggunaan saya, library pipeline membuat container docker, menerbitkannya, dan akhirnya menyebarkannya melalui helm dari pipeline build aplikasi (misalnya, pertimbangkan versi aplikasi 1.0.1-pr-3.1 untuk build pertama dari PR ketiga dari sebuah aplikasi, yang berpotensi sebagai pra-rilis ke versi 1.0.1).

Bahkan setelah masalah ini diselesaikan di perpustakaan pipa build perusahaan saya, saya pasti akan merasa lebih nyaman memiliki sakelar --app-version terpasang di Helm; itu hanya terasa seperti cara yang lebih fleksibel dalam menangani penerapan. Maksud saya, mengapa sistem eksternal atau insinyur harus masuk ke file Bagan dan memperbarui yaml sebelum setiap penerapan jika itu dapat diotomatisasi oleh platform build yang tidak dapat mengacaukan angka secara tidak sengaja? Dari sudut pandang saya, fungsionalitas appVersion perlu ditinggalkan sepenuhnya oleh organisasi saya, atau pekerjaan sed "ceroboh" perlu ditambahkan ke kode pustaka pipa kami, jadi saya pikir saya akan membagikannya untuk orang lain yang sedang memecahkan masalah ini.

@IRobL
Secara umum, utilitas apa pun harus mandiri pada tingkat abstraksinya sendiri: ia harus mengabstraksikan masalah yang dipecahkannya dengan menyediakan API yang memadai. Helm tidak terkecuali. Jadi jika Anda perlu menyesuaikan bagaimana perilakunya, Anda perlu bertanya terlebih dahulu: apakah itu sejalan dengan arsitektur, prinsip desain atau mungkin saya melewatkan sesuatu?

Inilah sebabnya mengapa PR ini tidak mudah diselesaikan. Karena, perbaikannya sudah jelas, tetapi tidak sesuai dengan desain Helm. Itu sebabnya beberapa solusi sementara disediakan.

Dan Anda benar tentang bendera app-version . Anda harus menyediakannya, lalu Helm harus menangani semuanya sendiri.

Bisakah saya mengajukan pertanyaan? Bagaimana Anda memanfaatkan Helm dalam produk Anda? Ketika Anda menggunakan helm install ? Bagaimana tepatnya Anda menggunakannya? Sudahkah Anda mempertimbangkan untuk menggunakan helm package ?

Saya melihat lagi helm package tadi malam. Aku tidak benar-benar dijual di atasnya. sed telah ada sejak lama dan sangat stabil. Semua sub-perintah tiller / package / install ini relatif baru, dan kurang stabil. Untuk membantu mengartikulasikan poin saya, beberapa bulan yang lalu, saya memutuskan "yakin anakan bisa berhasil" meskipun saya telah melihat plugin seseorang yang mengabaikan kebutuhan akan Tiller. Saya melihat plugin sebagai sesuatu yang pasti kurang mainstream, tetapi saya telah menendang diri saya sendiri sejak itu. Seandainya saya memercayai plugin, saya akan berada dalam posisi yang jauh lebih baik daripada saya sekarang. Pengelola di Helm bahkan telah mengkonfirmasi bahwa mereka setuju bahwa itu adalah desain yang tidak dapat dipertahankan dan akan dihapus pada rilis mendatang.

Saya pikir itu akan menjadi kesalahan di pihak saya untuk menggunakan helm package untuk melakukan operasi sed sederhana ini. Apa kasus penggunaan Anda untuk package ? Saya merasa seolah-olah seluruh konsep helm package kehilangan poin dari rilis kontrol versi web 2.0/ dengan mengemas ke dalam zip biner di tempat pertama ketika kelompok teknologi modern telah memanfaatkan kekuatan penandaan untuk mencapai proses yang sama tetapi dengan cara yang lebih ramping dan lebih dapat diaudit.

Untuk kasus penggunaan saya, saya memungkinkan pengembang aplikasi untuk mengkodifikasi aplikasi dalam container mereka dan menerapkannya dengan cara yang dapat dipelihara, jadi meminimalkan overhead (admin sistem ops/ tiller, manajemen artefak rilis yang berlebihan, dll.) adalah sangat penting. Saya pikir penggunaan saya lebih dekat mengikuti filosofi Unix untuk diputuskan tentang penggunaan alat untuk apa yang terbaik, dan kemudian beralih ke alat lain (dll. sed) jika sesuai. Saya tidak berpikir Anda akan pernah menemukan satu alat untuk melakukan segalanya dengan sempurna untuk Anda, tetapi jika Anda senang dengan alur kerja Anda saat ini, jangan biarkan saya menghalangi Anda untuk mengikuti filosofi Anda sendiri.

@IRobL

ketika Anda mengatakan praktik buruk, apakah Anda mengatakan bahwa perlu membungkus perintah helm dengan skrip tidak diinginkan?

Ya. Ini tepatnya.

Dalam kasus penggunaan saya, perpustakaan pipa membangun wadah buruh pelabuhan, menerbitkannya, dan akhirnya menyebarkannya melalui helm dari pipa pembangunan aplikasi

Ini adalah persis apa yang kita lakukan juga.

Bahkan setelah masalah ini diselesaikan di perpustakaan pipa build perusahaan saya, saya pasti akan merasa lebih nyaman memiliki --app-version switch bawaan Helm

Saya akan mengambil langkah ini lebih jauh dan mengatakan bahwa memiliki appVersion menjadi properti dari file Chart.yaml mungkin salah. Jika nilainya dapat diubah dengan cepat, itu tidak boleh dalam apa yang dianggap sebagai "set nilai yang tidak dapat diubah." Saya percaya saya menganjurkan hal yang sama dalam komentar sebelumnya.

Semua sub-perintah tiller/ package/ install ini relatif baru, dan kurang stabil.

FWIW, Tiller tidak akan menjadi apa-apa di Helm 3. Anda menyinggung hal ini nanti di posting Anda; namun, saya hanya mengulangi ini karena ini menunjukkan bahwa sintaks helm package untuk membuat "biner kubernetes" dan mengirimkannya ke Tiller mungkin merupakan praktik yang buruk.

Saya pikir itu akan menjadi kesalahan di pihak saya untuk menggunakan paket helm untuk melakukan operasi sed sederhana ini. Apa kasus penggunaan Anda untuk paket?

Saya mungkin bisa mengadvokasi tim Helm yang satu ini. Perasaan yang saya dapatkan di balik kemudi adalah metode agar pengembang aplikasi menentukan cara menjalankan aplikasi mereka dengan benar dari dalam Kubernetes. Itu sebabnya penyedia aplikasi menjalankan repo Helm mereka sendiri yang dapat Anda tambahkan untuk mengunduh versi penerapan yang diberikan. Tim Helm mungkin melihat kode aplikasi & kode infrastruktur saling terkait karena tim target produksi yang mereka tuju tidak akan menggunakan Helm dalam alur kerja harian seperti yang kami lakukan di CI/CD. Contoh: kita rata-rata menggunakan helm upgrade 130 kali sehari. Saya tidak berpikir itu pernah menjadi tujuan penggunaan.

Mungkin jauh lebih umum bagi orang untuk mengatakan, "Saya hanya ingin menginstal mysql ke dalam kubernetes" dan helm adalah cara (yang relatif) mudah untuk melakukan itu bagi orang-orang yang hanya tahu sedikit tentang kubernet dan hanya bermain-main dengannya.

Jadi, helm package pada akhirnya dimaksudkan untuk dikonsumsi oleh _pemirsa itu_. Alat ini pasti melihat lebih banyak digunakan di bidang yang tim (saya pikir) tidak percaya akan mengambil alat, atau tidak pernah bermaksud menggunakannya seperti apa adanya.

Saya pikir penggunaan saya lebih dekat mengikuti filosofi Unix untuk diputuskan tentang penggunaan alat untuk apa yang terbaik, dan kemudian beralih ke alat lain (dll. sed) jika sesuai.

Saya pada dasarnya memperlakukan Helm seperti awk dengan sekelompok kubectl apply -f setelahnya. Jauh lebih bersih untuk memiliki alat otomatis yang menangani nilai untuk menghindari kesalahan manusia.

Kedengarannya seperti Anda dan saya memiliki banyak nilai yang sama dan mungkin melakukan banyak hal serupa.

@IRobL

petani

Bagi saya, tiller tidak dapat diterima. Karena itu menambahkan satu titik eksposur lagi, risiko keamanan tambahan dan, yang paling penting, tidak melakukan apa pun selain menciptakan satu cara lagi untuk menerapkan file yaml, tetapi dengan API yang berbeda. Tiller dirancang untuk mengamankan, menyelaraskan proses penerapan paket Helm, tetapi memiliki begitu banyak risiko, perangkat lunak tambahan (dan versi!). Itu sebabnya Helm the 3rd tidak menggunakannya.

Saya pikir itu akan menjadi kesalahan di pihak saya untuk menggunakan paket helm untuk melakukan operasi sed sederhana ini.

Saya pikir Anda kehilangan poin saya. Biarkan saya mencoba lagi. Untuk apa sed dibuat? Untuk mengubah aliran data. Itu harus mengabstraksikan masalah transformasi, memberi Anda API dan hasil untuk setiap input yang diberikan.

Bagaimana jika Anda membuat skrip, di mana perintah sed Anda tidak berfungsi (yaitu Anda memiliki kesalahan dalam regex Anda)? Jadi Anda membuat kesimpulan, itu tidak berhasil. Maukah Anda mencoba memahami mengapa sed tidak bekerja sendiri, atau Anda akan menambahkan satu pipa tambahan dengan skrip Perl?

Hal yang sama berlaku dengan setiap solusi: itu harus menyediakan API, mengambil input dan memberikan output, mengabstraksi satu masalah. Anda tahu, gaya Unix.

Memproyeksikan ke Helm, ini dirancang untuk membuat versi rilis Anda dan mendorongnya ke K8. Hal ini memungkinkan untuk menyesuaikan konfigurasi menggunakan template. Jadi, Anda mengamati suatu masalah, Anda perlu menyediakan versi. Helm menyediakan mekanisme sederhana untuk mengelola versi dan menyediakan cara mudah untuk menyesuaikan cara kerja build Anda. Jadi, mengapa tidak mencoba memahami cara kerjanya, daripada menambahkan solusi dengan perangkat lunak tambahan?

@jrkarnes

Ya, kami berdua mendekati kemudi dengan minat yang sama. Saya tidak benar-benar menyadari bahwa akar dari perintah package terkait dengan kesalahan yang dibuat oleh tiller, terima kasih telah berbagi wawasan ini dengan saya!

Saya sebenarnya meninjau sejarah mengapa fitur ini tidak hanya ditambahkan dan melihat dua argumen mengapa mereka tidak dapat menambahkan fitur ini, salah satunya adalah karena sudah didefinisikan dalam package mereka juga tidak boleh menambahkannya. harus mendefinisikannya di install / upgrade juga. Saya bersimpati untuk itu, ini terdengar seperti masalah utang teknologi. Tidak ada perangkat lunak yang digunakan secara publik yang tidak memiliki hutang teknologi. Alasan lainnya adalah bahwa file Chart.yml adalah metadata dan tidak boleh diperbarui. Itu menurut saya aneh... ketika orang mengembangkan bagan kemudi, pasti mereka memperbarui file itu secara manual ketika banyak hal berubah dan itu tidak dapat diubah dengan sendirinya. Lebih mudah bagi saya untuk melihat file Chart.yml sebagai cara memasukkan parameter ke dalam biner helm karena ia membangun objek penerapan yang kontras sebenarnya tidak dapat diubah.

Apa platform build Anda btw? Kode pipa yang saya tulis ditulis untuk Jenkins sebagai Perpustakaan Pipa Global.

@IRobL Masalah utamanya adalah: Anda melihat Helm sebagai skrip penerapan. Tapi Helm tidak seperti itu. Helm adalah lapisan abstraksi. Helm mengambil semua artefak Anda dan menerapkannya sebagai satu unit kerja ke K8 sebagai platform.

Helm adalah seorang pembuat paket. Helm dirancang untuk memudahkan penyebaran. Ini menciptakan "penginstal" dari artefak Anda, sehingga Anda dapat "menginstal" ke OS Anda - K8s.

app-version dalam install tidak ada hubungannya dengan utang teknologi. Itu tidak diperlukan sama sekali ketika Anda ingin install atau upgrade itu. Sama adalah Chart.yml . Seharusnya tidak diubah sama sekali, karena ini adalah file konfigurasi default, yang berisi versi Bagan yang sebenarnya, tetapi bagan bukanlah perangkat lunak Anda. Anda hanya salah menggunakannya.

Dari sudut pandang itu, mengapa Anda tidak mempertimbangkan untuk menggunakan package ? Ini terlihat terlalu rumit untuk Anda atau apa?

Telah keluar dari lingkaran tentang masalah ini untuk sementara waktu, tetapi saya telah melihat poin semacam ini muncul beberapa kali:

Helm adalah seorang pembuat paket. Helm dirancang untuk memudahkan penyebaran. Ini menciptakan "penginstal" dari artefak Anda, sehingga Anda dapat "menginstal" ke OS Anda - K8s.

Pada dasarnya, Helm _tidak sama sekali_ membuat installer. Itu tidak membuat "biner". Itu tidak membuat sesuatu yang mirip dengan file ".deb" atau serupa. Ini membuat arsip beberapa template manifes Kubernetes, dengan beberapa nilai default dan/atau preset. Perangkat lunak Anda yang sebenarnya tidak ada di Bagan Helm itu. Itu tidak dikemas dengan itu. Itu tidak dijamin tidak berubah.

Saya pikir adil untuk mengatakan bahwa dalam banyak kasus, Bagan Helm Anda akan berubah _lot_ lebih sedikit daripada perangkat lunak yang Anda gunakan melalui Bagan Anda.

Ini adalah alasan mendasar (setidaknya IMO) --app-version tersedia di helm install dan helm upgrade . Mengapa Anda harus mengemas bagan Anda lagi jika secara harfiah tidak ada yang berubah?

Saya melihat Helm Chart sebagai deskripsi versi manifes Kubernetes, yang menjelaskan sekumpulan komponen Kubernetes yang akan berhasil menjalankan aplikasi, dan hanya itu yang saya lihat. Jika instruksi itu perlu diubah, saat itulah saya ingin memperbarui bagan saya - tidak setiap kali aplikasi saya berubah dan saya hanya perlu memperbarui versi gambar (yang sering Anda tetapkan melalui nilai).

Lihatlah Flux misalnya, dan cara kerja Operator Helm mereka. Anda dapat membuatnya secara otomatis memperbarui nilai tag gambar - yang tidak memperbarui Bagan, hanya tag gambar yang diterapkan.

Ini membuat arsip beberapa template manifes Kubernetes, dengan beberapa nilai default dan/atau preset.

Tetapi file deb adalah kumpulan file konfigurasi, perintah, manifes, dan/atau nilai preset yang sama. Sama seperti installer MSI atau bahkan yang lebih dekat, ebuild di sistem paket emerge gento. Juga, sama seperti paket Brew.

Jadi apa itu Helm jika bukan manajer paket untuk K8? Apa perbedaan yang Anda lihat?

Itu tidak dijamin tidak berubah.

Kenapa tidak? Jika Anda mengubah paket setelah pembuatan paket, itu salah. Jika Anda memberikan opsi tambahan selama proses install/upgrade , ini dimaksudkan, seperti di semua sistem pengemasan.

Saya melihat Bagan Helm sebagai deskripsi versi manifes Kubernetes

Anda sudah memilikinya - GIT. Jadi, mengapa Anda membutuhkan Helm?

Saya pikir itu adil untuk mengatakan bahwa dalam banyak kasus, Bagan Helm Anda akan berubah jauh lebih sedikit daripada perangkat lunak yang Anda gunakan melalui Bagan Anda.
Ini adalah alasan mendasar (setidaknya IMO) untuk --app-version tersedia pada pemasangan helm dan peningkatan helm. Mengapa Anda harus mengemas bagan Anda lagi jika secara harfiah tidak ada yang berubah?

Dalam desain ini, appVersion tidak boleh diperlakukan sebagai atribut dari pembuatan Paket Helm. Itu harus diperlakukan sebagai parameter konfigurasi, dalam nilai.

Lihatlah Flux misalnya, dan cara kerja Operator Helm mereka. Anda dapat membuatnya secara otomatis memperbarui nilai tag gambar - yang tidak memperbarui Bagan, hanya tag gambar yang diterapkan.

Dalam hal ini Anda akan kehilangan sambungan manifes infrastruktur aplikasi dan versi aplikasi. Karena, mengubah tag gambar tidak akan memicu peningkatan helm baru (koreksi saya jika orang-orang Flux melakukannya dengan cara lain). Dalam hal ini, Anda akan memiliki Helm sebagai template konfigurasi. Dalam hal ini, Anda tidak perlu --app-version sama sekali.

Tetapi file deb adalah kumpulan file konfigurasi, perintah, manifes, dan/atau nilai preset yang sama. Sama seperti installer MSI atau bahkan yang lebih dekat, ebuild di sistem paket emerge gento. Juga, sama seperti paket Brew.

Deskripsi Anda di sini untuk paket .deb dan .msi tidak memiliki satu komponen kunci - hal yang sebenarnya sedang diinstal. Jika Anda melihat isi file .deb , Anda akan menemukan perangkat lunak yang dibangun - perangkat lunak _THE_ yang akan diinstal. Secara umum (selalu dalam kasus .deb ?) aplikasi yang digunakan secara intrinsik terkait, dan bagian dari paket itu (tidak demikian dengan minuman).

Paket minuman berbeda, dan tidak benar-benar sebanding dengan cara yang sama. Brew sebenarnya jauh lebih mirip dengan Helm saat ini, karena itu hanya instruksi tentang bagaimana itu harus diinstal, dan dari mana sumber / paket harus diunduh.

Untuk menjadi sangat jelas di sini; sebuah Bagan Helm _tidak terikat secara intrinsik dengan versi aplikasi tertentu_, dan tidak berisi artefak yang sedang digunakan (yaitu gambar Docker). Itu hanya berisi referensi untuk itu, dan nilai di balik referensi itu bahkan dapat berubah (yaitu Anda dapat mendorong ke tag Docker yang sama, jika Anda menginginkannya). Jadi, apa pun yang terjadi, Bagan Helm bukanlah versi paket aplikasi, dan juga tidak terkait secara ketat dengan versi aplikasi tertentu.

Anda hanya perlu melihat repo grafik stabil sebagai contoh. Berapa banyak aplikasi yang memungkinkan Anda mengganti gambar yang digunakan melalui nilai? (Banyak_)

Jadi apa itu Helm jika bukan manajer paket untuk K8? Apa perbedaan yang Anda lihat?

Ini adalah alat yang memfasilitasi pembuatan template Kubernetes, dan dengan mudah mendistribusikan dan menginstalnya. Kuncinya di sini adalah, itu saja yang ditangani Helm - manifes Kubernetes.

Ini semua kembali ke poin utama saya - jika manifes itu berubah, atau templating perlu diubah untuk manifes itu karena alasan apa pun, maka _that_ adalah saat Bagan Helm perlu benar-benar diubah.

Komplikasi utama yang saya lihat adalah ada 2 kasus penggunaan:

• Menyebarkan aplikasi pihak ketiga.
• Menyebarkan aplikasi pihak pertama.

Dalam hal aplikasi pihak ketiga, sebagai konsumen Helm, sebaiknya Helm Chart dirilis dengan setiap versi aplikasi baru. Satu perbedaan utama di sini adalah dengan frekuensi rilis. Sepertinya Bagan Helm pihak ketiga untuk sesuatu seperti MySQL atau apa pun tidak akan berubah beberapa kali sehari. Dalam hal ini Anda juga tidak ingin secara tidak sengaja menggunakan versi lama bagan dengan perangkat lunak versi baru - kesalahan yang jauh lebih mudah dilakukan dengan perangkat lunak dan bagan yang belum Anda tulis sendiri.

Dalam kasus aplikasi pihak pertama, Anda mungkin memiliki cara standar untuk menerapkan kelas aplikasi. Di Icelolly misalnya, kami menulis dan menerapkan layanan Go kami dengan cara yang hampir sama. Untuk itu, kami sebenarnya dapat menggunakan satu bagan sekarang untuk semua layanan Go kami yang diterapkan di Kubernetes (kami menggunakan solusi helm package sekarang). Jika pendekatan yang kami ambil untuk menerapkan aplikasi kami sendiri berubah, kami akan memperbarui bagan. Kami membuat versi grafik kami dengan SemVer, sehingga aplikasi yang tidak diperbarui tidak akan terpengaruh sampai kami ingin memperbaruinya.

Hanya pada catatan ini; bagan go-service kami terakhir diperbarui sekitar sebulan yang lalu. Selama waktu itu, kami mungkin memiliki puluhan hingga ratusan penerapan - semuanya tanpa perubahan bagan itu.

Dalam satu kasus, Anda hanya menginginkan kesederhanaan. Dalam kasus lain Anda ingin kontrol, dan kemudahan manajemen.

Dalam hal ini Anda akan kehilangan sambungan manifes infrastruktur aplikasi dan versi aplikasi. Karena, mengubah tag gambar tidak akan memicu peningkatan helm baru (koreksi saya jika orang-orang Flux melakukannya dengan cara lain). Dalam hal ini, Anda akan memiliki Helm sebagai template konfigurasi. Dalam hal ini, Anda tidak memerlukan --app-version sama sekali.

Flux benar-benar akan mengubah nilai yang digunakannya untuk memutakhirkan bagan, dan kemudian menjalankan pemutakhiran dengan nilai gambar baru. Maksud Anda tentang kehilangan kopling manifes infrastruktur dan versi aplikasi masih berlaku. Poin yang saya perdebatkan adalah bahwa itu sebenarnya diinginkan untuk menjadi kasus dalam beberapa kasus penggunaan. Anda benar, dalam kasus penggunaan ini, saya tidak perlu --app-version , itu tidak akan digunakan karena tidak ada sekarang. Jika ya, mungkin Flux bisa menggunakannya. Dalam hal ini, itu akan sangat membantu.

helm list adalah perintah yang berguna. Mampu melihat versi aplikasi mana yang di-deploy memang masih berguna. Untuk aplikasi kami yang saat ini diinstal melalui Helm dengan pendekatan helm package kami hanya mengatur versi aplikasi (via --app-version pada helm package ) sehingga output dari helm list adalah berguna. Itu sebabnya jika kita bisa mengaturnya pada helm install|upgrade itu akan lebih mudah bagi kita. Kami tidak perlu mengambil bagan dan mengemasnya kembali hanya untuk mengubah versi.

Faktanya, helm list dan penanganan rollback mungkin adalah satu-satunya alasan kami menggunakan Helm untuk perangkat lunak pihak pertama.

Deskripsi Anda di sini untuk paket .deb dan .msi tidak memiliki satu komponen kunci - hal yang sebenarnya sedang diinstal.

"Instal" adalah proses menyiapkan fasilitas yang diperlukan (folder, konfigurasi, biner, pengambilan db, penyegaran/migrasi data) pada platform target.

deb menangani semua itu. Begitu juga dengan paket Helm. Apa maksud Anda paket Helm tidak "benar-benar diinstal"?

Jika Anda melihat isi file .deb, Anda akan menemukan perangkat lunak yang dibangun - perangkat lunak yang akan diinstal.

Palsu. Terkadang Anda akan menemukan perangkat lunak itu sendiri. Terkadang Anda akan menemukan beberapa perangkat lunak. Terkadang Anda tidak akan menemukan apa pun kecuali sekumpulan skrip untuk mengambil perangkat lunak tersebut. Jadi, poin kuncinya di sini - tidak masalah , karena Linux dan K8 adalah platform untuk menampung aplikasi yang diberikan, menerima satu format aplikasi universal. Dan nama gambar, parameter konfigurasi - adalah bagian dari paket.

Brew sebenarnya jauh lebih mirip dengan Helm saat ini, karena itu hanya instruksi tentang bagaimana itu harus diinstal, dan dari mana sumber / paket harus diunduh.

Tepat. Apakah Anda mencoba meyakinkan saya bahwa Brew bukan manajer paket?

Untuk menjadi sangat jelas di sini; a Helm Chart _tidak terikat secara intrinsik dengan versi aplikasi tertentu ...
Berapa banyak aplikasi yang memungkinkan Anda mengganti gambar yang digunakan melalui nilai? (Banyak)

Anda benar sekali. Helm tidak lebih dari mesin templating yang berguna untuk templat k8s. Saya tidak memiliki masalah dengan keberadaan perangkat lunak seperti itu: ini sedikit membantu, tidak akan mengubah praktik pengiriman modern.

Masalahnya, Helm lebih dari sekadar mesin template. Ini adalah manajer pengemasan, dengan segala kelebihan dan kekurangannya. Dan dalam ekosistem di mana pengelola paket ada, adalah praktik yang buruk untuk memiliki pengelola sesuatu oleh pengelola paket lain. Lebih buruk - bekerja tanpa manajer paket.

Saya melihat alasan di balik pembuatan versi aplikasi sebagai argumen paket untuk paket-paket ini. Dan saya melihat alasan Anda dan Anda semua tidak perlu membuat paket. Masalahnya adalah, pendekatan itu sudah ketinggalan zaman, kompleks dan lebih sulit untuk dikelola. Lucunya, biayanya kecil, tapi untungnya luar biasa.

Poin yang saya perdebatkan adalah bahwa itu sebenarnya diinginkan untuk menjadi kasus dalam beberapa kasus penggunaan.

Yup, ini poin utamanya: Apakah produk itu diinginkan?

Argumen Anda adalah bahwa Helm Chart jarang berubah, jadi mengapa kita harus mengemasnya bersama setiap rilis. Saya setuju dengan Anda, rasanya berlebihan. Tapi bagaimanapun, kami masih mengemas beberapa file sumber lama, mobil sampingan lama (jika Helm terdiri dari beberapa aplikasi), konfigurasi lama, Dockerfile lama.

Jadi pertanyaannya adalah, jika kita mengemas seluruh Bagan sebagai artefak, pada setiap build, apa keuntungannya? Untuk Dockerfile sudah jelas (tapi tentu saja tidak jelas ketika containerisation muncul di pasar). Untuk file sumber juga.

Kembali pada hari-hari kami memiliki mekanisme pengiriman yang paling jelas: hanya mengunggah file yang diubah melalui FTP. Sekarang kita memiliki begitu banyak hal. Kita perlu memutuskan apa yang baik, mengapa itu baik, siapa yang harus menggunakannya. Saya tidak yakin saya akan senang dengan Helm yang menangani kedua pendekatan secara bersamaan - terlalu rumit.

Menyebarkan aplikasi pihak ketiga.

Saya akan sangat senang jika saya dapat menginstal versi PSQL/MySQL menggunakan diagram Helm saja. Akan jauh lebih mudah untuk mempertahankan proyek lama, memperkenalkan infrastruktur kepada pemula. Bahkan lebih mudah untuk diberitahu tentang pembaruan Bagan. Mengapa kami memiliki begitu banyak file tar.gz untuk setiap rilis untuk binari, tetapi tidak dapat memiliki kumpulan file tar.gz yang sama untuk Paket Helm?

@iorlas Saya baru saja membaca ini dan PR yang ditolak dan Anda membuat beberapa poin yang sangat bagus. Anda telah meyakinkan saya bahwa saya harus mulai mengemas bagan helm saya sebagai artefak lain dari build/rilis saya.

Tetapi saya ingin menyebutkan bahwa saya bahkan tidak tahu bahwa helm memiliki perintah paket dan saya rasa saya tidak sendirian. Itu mungkin karena begitu mudahnya memasang bagan dari direktori sumber, tetapi juga dokumentasinya tidak benar-benar menjual konsep atau bahkan menjelaskannya secara mendetail.

Perintah paket jelas didokumentasikan tetapi hanya ada beberapa penyebutan paket yang panduan mulai cepat , pada kenyataannya, paket kata banyak muncul di mulai cepat tetapi sebagian besar berbicara tentang cara menginstal Helm dan paket OS yang berbeda . Pengemasan juga tidak disebutkan dalam praktik terbaik dan saya pikir menangkap apa itu pengemasan dan mengapa itu membantu harus disertakan di sana. Saya juga telah memeriksa dokumen v3 yang memiliki struktur yang sedikit berbeda tetapi tampaknya juga tipis dalam menyarankan pengguna mengemas bagan mereka.

Biasanya saya ingin mengirimkan PR dan tidak hanya terdengar seperti mengeluh tentang sesuatu, tapi saya tidak yakin apa yang terjadi dengan perubahan dokumentasi 3.0.

@jonstelly Pasti ada celah dalam dokumentasi. Bahkan saya berpikir pada awalnya bahwa --app-version baik untuk digunakan, tetapi kemudian meskipun itu tidak dapat dibiarkan hilang tanpa alasan.

Dokumen pasti membutuhkan klarifikasi dan pengenalan masalah umum. Kemudian, pengenalan siklus pengembangan Helm. Tapi saya yakin tim sedang sibuk pada versi ke-3. Dan aku terlalu sibuk sekarang :(

"Instal" adalah proses menyiapkan fasilitas yang diperlukan (folder, konfigurasi, biner, pengambilan db, penyegaran/migrasi data) pada platform target.

deb menangani semua itu. Begitu juga dengan paket Helm. Apa maksud Anda paket Helm tidak "benar-benar diinstal"?

Saya tidak bermaksud bahwa Bagan Helm itu sendiri tidak diinstal - yang saya katakan adalah, Bagan Helm tidak berisi aplikasi sebenarnya yang Anda gunakan. Gambar Docker tidak dikemas ke dalam Bagan Helm. Itu ditarik oleh Kubernetes dari beberapa sumber eksternal.

Palsu. Terkadang Anda akan menemukan perangkat lunak itu sendiri. Terkadang Anda akan menemukan beberapa perangkat lunak. Terkadang Anda tidak akan menemukan apa pun kecuali sekumpulan skrip untuk mengambil perangkat lunak tersebut. Jadi, poin kuncinya di sini - tidak masalah, karena Linux dan K8 adalah platform untuk meng-host aplikasi yang diberikan, menerima satu format aplikasi universal. Dan nama gambar, parameter konfigurasi - adalah bagian dari paket.

Sejauh yang saya ketahui, sebenarnya Anda salah di sini. File .deb adalah arsip AR. Anda dapat mengekstraknya dan melihat isinya, dan pada akhirnya itu adalah beberapa metadata, dan beberapa file. File .deb secara teori dapat berisi tambalan, tetapi seringkali tidak. Jika file .deb berisi skrip untuk mengambil perangkat lunak, maka itu berarti skrip yang diinstal oleh file .deb , bukan perangkat lunak itu sendiri. Itu seperti menginstal installer.

Jika Anda memiliki contoh perangkat lunak Linux yang dikemas dalam .deb tempat .deb pergi dan mengunduh perangkat lunak untuk diinstal sebagai bagian dari proses penginstalan file .deb , maka saya sangat ingin melihatnya - karena ini adalah sesuatu yang belum pernah saya temui sebelumnya selama bertahun-tahun menggunakan Linux.

Tepat. Apakah Anda mencoba meyakinkan saya bahwa Brew bukan manajer paket?

Tidak. Yang saya katakan adalah seperti Helm, skrip yang disediakan untuk menginstal perangkat lunak melalui Brew hanyalah skrip. Aplikasi dibangun, dikemas, dan didistribusikan secara terpisah dan ditarik oleh skrip tersebut. Itu tidak membuat Brew kurang menjadi manajer paket, seperti yang saya katakan tidak membuat Helm menjadi manajer paket Kubernetes. Bukan itu inti dari masalah ini, kami tidak memperdebatkan apakah Helm adalah manajer paket atau bukan, kami mencoba memutuskan apakah flag --app-version harus ditambahkan ke helm install|upgrade untuk memfasilitasi kasus penggunaan umum.

Saya melihat alasan di balik pembuatan versi aplikasi sebagai argumen paket untuk paket-paket ini. Dan saya melihat alasan Anda dan Anda semua tidak perlu membuat paket. Masalahnya adalah, pendekatan itu sudah ketinggalan zaman, kompleks dan lebih sulit untuk dikelola. Lucunya, biayanya kecil, tapi untungnya luar biasa.

Maaf, saya tidak jelas apa yang Anda maksud dengan ini. Apa yang ketinggalan zaman/kompleks/sulit untuk dikelola?

Jadi pertanyaannya adalah, jika kita mengemas seluruh Bagan sebagai artefak, pada setiap build, apa keuntungannya? Untuk Dockerfile sudah jelas (tapi tentu saja tidak jelas ketika containerisation muncul di pasar). Untuk file sumber juga.

Sekali lagi, perbedaannya pada dasarnya adalah bahwa semua hal yang Anda sebutkan itu terkait secara intrinsik. Anda memerlukan semua kode sumber untuk menjalankan aplikasi - bukan hanya apa yang berubah. Anda tidak mengemas Dockerfile, jadi tidak yakin apa maksudnya - tetapi Anda akan sering menggunakan Dockerfile yang sama tanpa mengubahnya untuk membuat versi gambar baru (maksud saya, mengapa repot-repot dengan otomatisasi jika Anda harus mengubah sesuatu secara manual setiap waktu, kan?). Dengan semua hal semacam itu, Anda membuat sesuatu yang merangkum semua yang Anda butuhkan, sehingga dapat digunakan secara terpisah. Jadi Anda dapat melakukan hal-hal seperti memutar simpul baru, dan menyebarkannya dengan cara yang sama seperti yang Anda lakukan ke simpul yang ada, dll.

Ada _banyak_ keuntungan, karena saya yakin Anda sudah mengetahuinya, lebih dari menggunakan unggahan lama melalui FTP.

Bagaimanapun, ini semua oleh. Saya pikir pada akhirnya seperti yang telah saya sebutkan, menurut pendapat saya, semua ini adalah; apakah pengelola Helm ingin mengaktifkan kasus penggunaan lain ini, atau mempersulit orang untuk menggunakannya dengan cara ini? Pada akhirnya, ini bukan _benar-benar_ perbedaan besar. Bagi saya, alangkah baiknya jika saya tidak harus mengemas bagan internal kami, yang jarang berubah, pada setiap build hanya untuk mengatur versi aplikasi, yang lagi-lagi hanya digunakan untuk menampilkan versi saat ini dalam daftar. Untuk aplikasi pihak pertama, saya akan jujur, saya mempertanyakan apakah Helm adalah pendekatan yang tepat.

Gambar Docker tidak dikemas ke dalam Bagan Helm

Sebenarnya, saya berharap akan seperti itu. Tapi itu tidak sekarang. Visi saya adalah, K8 akan/harus menjadi platform, yang akan menggabungkan Helm (sehingga tidak akan ada Helm) sebagai API untuk menginstal paket: Anda perlu mengemas barang-barang Anda ke dalam arsip dan menginstalnya. Kembali ke kesederhanaan file deb, tetapi dengan isolasi yang tepat dan sumber daya k8s sebagai warga kelas satu.

File .deb adalah arsip AR
Anda dapat mengekstraknya dan melihat isinya
dan pada akhirnya itu adalah beberapa metadata
dan beberapa file

Seperti.... paket Helm!

Jika Anda memiliki ... .deb tempat .deb pergi dan mengunduh perangkat lunak untuk diinstal sebagai bagian dari proses menginstal file .deb ...
Itu seperti menginstal installer. ...

Ya, itu akan seperti penginstal yang memiliki penginstal di dalamnya. Lucu kan? Saya akan menggunakan satu artefak jika memungkinkan , jika itu cukup untuk menyiapkan instance aplikasi. Tetapi kami memiliki perangkat lunak yang berbeda, sumber kebenaran yang berbeda, kadang-kadang bahkan berguna untuk memiliki banyak sumber.

• Brew memiliki YAML sebagai paket, tetapi mengambil binari dari penyimpanan jarak jauh
• Emerge(gentoo) memiliki ebuild sebagai definisi, yang mengunduh bahkan klon git

Debian mencoba mengemas semua yang ada di dalamnya. Dan itu adalah hal yang benar untuk dilakukan, jika memungkinkan. Tetapi untuk membuktikan maksud saya, metapackages akan berhasil. Pernahkah Anda mendengarnya? Ini adalah paket, yang menginstal beberapa paket lain. Bukan paket?

Tapi tolong, jangan lewatkan poin utamanya: Tidak masalah ! Bahkan paket kosong, yang hanya memiliki referensi di dalamnya, adalah sebuah paket. Mungkin Anda akan menerima istilah lain, installer?

Saya katakan adalah seperti Helm, skrip yang disediakan untuk menginstal perangkat lunak melalui Brew hanya itu - skrip
Aplikasi dibangun, dikemas, dan didistribusikan secara terpisah dan ditarik oleh skrip tersebut

Dan kita semua memiliki saluran yang sama - untuk membangun citra buruh pelabuhan.

kami mencoba memutuskan apakah flag --app-version harus ditambahkan ke helm install|upgrade untuk memfasilitasi kasus penggunaan umum.

Itu kunci. Tapi bagaimana kita bisa memutuskan? Kita harus mengajukan dua pertanyaan:

• Apa itu mungkin? Ya
• Apakah itu hal yang benar untuk dilakukan? Ya? Tidak?

Jika ada ppl melakukan sesuatu, apakah itu berarti itu adalah hal yang baik? Untuk membuat kemajuan, kita perlu mempertanyakan segalanya.

Maaf, saya tidak jelas apa yang Anda maksud dengan ini. Apa yang ketinggalan zaman/kompleks/sulit untuk dikelola?

biarkan proyek ke Brew, karena Brew sangat dekat dengan Helm dan sudah banyak digunakan, berhasil. Anda dapat memproyeksikan ke Gentroo Ebuild atau deb, gambar tidak akan berubah.

• usang. Kapan terakhir kali Anda harus menginstal MySQL/PSQL secara manual? Mengapa kita pindah darinya? Alasan ini, bung.
• Kompleks. Ini adalah salah satu dari "mengapa": Anda perlu mengatur infrastruktur secara mandiri, Anda perlu tahu mana yang paling cocok dengan versi perangkat lunak mana. Terkadang Anda perlu menyesuaikan infrastruktur untuk menjalankan versi perangkat lunak tertentu. Kenapa mengganggu? Mengapa Anda tidak mendelegasikan seluruh pertanyaan?
• Lebih sulit untuk dikelola. Anda perlu mengelola versi infrastruktur dan aplikasi saat Anda hanya dapat memiliki satu artefak. Mengapa membuat hidup Anda lebih sulit?

Maaf, agak malas sekarang untuk menjelaskan semua kasus penggunaan, seperti rollback bersih, peningkatan yang anggun, bagaimanapun ini adalah bonus utama.

Sekali lagi, perbedaannya pada dasarnya adalah bahwa semua hal yang Anda sebutkan itu terkait secara intrinsik.

Tidak selalu. Misalnya, gambar buruh pelabuhan dapat memiliki SSR BE dan referensi ke CDN.

Dockerfile, jadi tidak yakin tentang apa itu - tetapi Anda akan sering menggunakan Dockerfile yang sama tanpa mengubahnya untuk membuat versi gambar baru (maksud saya, mengapa repot dengan otomatisasi jika Anda harus mengubah sesuatu secara manual setiap saat, bukan?).

Itulah intinya. Bahkan ketika Dockerfile tidak diubah, Anda membuat image baru. Jika kode sumber Anda tidak diubah, tetapi Dockerfile, Anda membuat gambar baru. Jadi, singkatnya, Dockerfile juga merupakan sebuah paket. Hal yang sama berlaku untuk Helmi. Tidakkah menurutmu begitu?

Dengan semua hal semacam itu, Anda membuat sesuatu yang merangkum semua yang Anda butuhkan, sehingga dapat digunakan secara terpisah. Jadi Anda dapat melakukan hal-hal seperti memutar simpul baru, dan menyebarkannya dengan cara yang sama seperti yang Anda lakukan ke simpul yang ada, dll.

Namun ternyata gambar buruh pelabuhan tidak cukup untuk menjalankan sebuah aplikasi. Kami membutuhkan contoh konfigurasi, kami membutuhkan definisi layanan. Mengapa tidak mengemas semuanya?

Pada akhirnya, perbedaannya tidak terlalu besar.

Saya percaya, itu. Mungkin ini bukan masalah besar dalam basis kode, tetapi evolusi containerisasi akan mandek.

Gambar Docker tidak dikemas ke dalam Bagan Helm

Gambar itu sendiri tidak dikemas, tetapi referensi (baca: pin) adalah. Tentu, kita bisa bertele-tele dan terjebak pada apakah gambar literal dengan berbagai ukuran (dari MB hingga GB) termasuk dalam artefak helm package (spoiler: tidak), tetapi intinya pernyataan "Versi tertentu dari kode aplikasi disertakan dalam paket helm" pada dasarnya masih benar. Apakah Anda ingin terjebak dalam bagaimana tidak relevan.

Kembali ke contoh, katakanlah Anda memiliki aplikasi yang secara internal Anda versikan sebagai 1.9.9 berjalan pada bagan berversi 1.2.5 . Agar tidak bingung, image Docker sha untuk container aplikasi adalah fakeshaA .

Tim Anda memutuskan bahwa dalam versi 2.0.0 aplikasi Anda akan ada versi sistem file lokal dari file yang sebelumnya harus Anda rujuk melalui HTTP. Alasan untuk ini tidak penting tetapi konsekuensinya bagi Anda cukup parah. Sekarang Anda memerlukan pv dan pvc untuk penerapan Anda sehingga file sekarang-lokal ini tidak hilang di antara pemutakhiran. Melihat kebutuhan, Anda melanjutkan dan memperbarui bagan Helm Anda untuk memiliki pv dan pvc sehingga perpindahan ke 2.0.0 tidak terlalu mengganggu.

Sebelum Anda mengubah bagan, Anda memiliki Artifact A menautkan versi aplikasi 1.9.9 ke versi infrastruktur 1.2.5 . Sekarang Anda mengubah bagan... _Bagan Helm Anda sekarang v. 1.3.0 _ dan Anda akan menghasilkan artefak yang menghubungkan 1.9.9 ke versi infrastruktur 1.3.0 . Kami akan menyebutnya Artifact B

Ketika penerapan kode untuk 2.0.0 ditayangkan dengan gambar Docker sha fakeShaB , Anda akan membuat artefak lain yang menghubungkan 2.0.0 ke versi infra 1.3.0 . Ini Artifact C

Sekarang misalkan ternyata ada masalah yang belum kamu pahami sepenuhnya dengan rilis 2.0.0 dan kamu harus melakukan roll back. Anda mengembalikan menggunakan Artifact B ... tetapi ini tidak menyelesaikan masalah sehingga Anda mengembalikan lagi ke Artifact A dan masalahnya selesai.

Satu-satunya masalah yang Anda hadapi adalah apakah Docker Registry yang menjadi referensi artefak Anda masih memiliki gambar yang direferensikan dalam artefak tersebut.

Apa pun yang terjadi, Anda masih memiliki hubungan antara versi aplikasi dan versi infrastruktur . Ini adalah tujuan dari Helm. Berdebat sebaliknya adalah kebodohan.

@iorlas :

Mari kita kesampingkan perbandingan .deb . Saya pikir hanya kita yang teralihkan.

Tidak selalu. Misalnya, gambar buruh pelabuhan dapat memiliki SSR BE dan referensi ke CDN.

Itu sangat benar. Lebih lanjut tentang itu nanti.

Itulah intinya. Bahkan ketika Dockerfile tidak diubah, Anda membuat image baru. Jika kode sumber Anda tidak diubah, tetapi Dockerfile, Anda membuat gambar baru. Jadi, singkatnya, Dockerfile juga merupakan sebuah paket. Hal yang sama berlaku untuk Helmi. Tidakkah menurutmu begitu?

Anda dapat melakukannya, tetapi itu karena produk di akhir proses pembuatan itu (yaitu Gambar Docker) bergantung pada _keduanya_ file Docker, dan hal yang Anda masukkan ke dalamnya. Sebuah gambar tidak dapat eksis tanpa kedua komponen tersebut.

Di sisi lain, Bagan Helm bisa ada bahkan sebelum aplikasi dibangun - secara harfiah sebelum satu baris kode ditulis. Anda dapat membuat yang imajiner yang akan gagal untuk diinstal - tetapi bagaimanapun, Bagan Helm bisa ada sepenuhnya tanpa hal lain. Seperti yang saya katakan, ini tidak akan berguna, tetapi saya hanya mencoba untuk mengilustrasikan poin saya bahwa mereka sama sekali tidak terkait.

Maksud saya di sini, dan bagaimana hal itu terkait dengan masalah khusus ini hanyalah bahwa Diagram Helm tidak selalu secara intrinsik terkait dengan aplikasi yang digunakan oleh Bagan. Saya tidak berpikir itu klaim yang berani, itu terjadi - itu sudah fakta. Saya sedang melakukannya sekarang dengan aplikasi produksi, begitu juga orang lain yang telah mengomentari masalah ini. Jadi seperti yang saya katakan sebelumnya, semua ini bermuara pada; apakah pengelola Helm ingin mengaktifkan kasus penggunaan ini, atau tidak - tidak ada yang lain untuk itu.

Namun ternyata gambar buruh pelabuhan tidak cukup untuk menjalankan sebuah aplikasi. Kami membutuhkan contoh konfigurasi, kami membutuhkan definisi layanan. Mengapa tidak mengemas semuanya?

Sebenarnya, saya berharap akan seperti itu. Tapi itu tidak sekarang.

Jika ini masalahnya, dan Bagan Helm benar-benar mengemas semua yang dikerahkannya (Anda menyebutkan CDN sebelumnya, tetapi Anda tidak menyebarkannya ke Kubernetes, jadi itu tidak akan masuk ke Bagan Anda), maka saya pikir itu percakapan ini tidak akan terjadi. Bagan Helm Anda _akan_ secara intrinsik ditautkan ke versi aplikasi yang sedang digunakan - sama seperti membangun gambar Docker. Untuk membangun Bagan Helm dalam skenario itu, Anda akan diminta untuk membangunnya kembali ketika aplikasi Anda berubah, di mana tidak ada pertanyaan. Anda tidak dapat menggunakan Helm seperti yang saya gunakan hari ini - akan jauh lebih jelas seperti itu.

Padahal kenyataannya tidak demikian. Ini bukan cara kerja Helm, dan saya tidak tahu apakah itu akan benar-benar berakhir. Tapi jangan pernah bilang tidak, kan?

@jrkarnes :

Gambar itu sendiri tidak dikemas, tetapi referensi (baca: pin) adalah.

Tentu, tetapi kasus penggunaan umum menggunakan nilai untuk mengganti nilai ini. Saya telah menggunakannya dengan grafik pihak ketiga dan pihak pertama. Itu tidak akan menjadi pilihan jika itu bukan sesuatu yang digunakan orang.

Tentu, kita bisa bertele-tele dan terjebak pada apakah gambar literal dengan berbagai ukuran (dari MB hingga GB) termasuk dalam artefak paket helm (spoiler: tidak),

Saya tidak berpikir kita sedang bertele-tele tentang apa pun - seperti yang telah Anda tunjukkan, akan salah secara faktual untuk mengatakan bahwa Gambar Docker dikemas di dalam Bagan Helm "buatan".

"Versi tertentu dari kode aplikasi yang disertakan dalam paket helm" pada dasarnya masih benar.

Tapi tidak juga, karena poin pertama saya di sana akan ditentang. Anda dapat mengubah apa yang sedang digunakan. Neraka, Anda dapat mengubah sebagian besar grafik untuk menjalankan gambar hello-world jika Anda mau. Itu tidak akan berguna, tetapi itu membuktikan maksud saya dengan baik - Bagan Helm tidak ditautkan ke aplikasi Anda. Ada _harapan_ bahwa Anda akan menggunakannya dengan gambar yang tepat, dan mungkin secara default akan melakukannya, tetapi tentu saja tidak _harus_ - dan dalam _tidak mungkin_ adalah kode aplikasi yang disertakan dalam Bagan Helm, dikemas lain sebaliknya.

Kembali ke negeri contoh, [...] dan masalahnya terpecahkan.

Anda telah membuatnya terdengar seperti ini tidak mungkin tanpa menggunakan Helm dengan cara yang tampaknya saat ini dimaksudkan. Namun pada kenyataannya, Anda hanya dapat memiliki 2 versi bagan (yaitu dua versi infrastruktur Anda), dan 3 versi aplikasi Anda. Jika Anda ingin melakukan rollback, lakukanlah, Anda dapat memilih dengan mudah Bagan dan gambar mana yang ingin Anda gunakan. Jalankan Helm dengan Bagan Anda, atur nilai Anda sesuai untuk gambar, dan Anda sudah siap.

Apa pun yang terjadi, Anda masih memiliki hubungan antara versi aplikasi dan versi infrastruktur. Ini adalah tujuan dari Helm. Berdebat sebaliknya adalah kebodohan.

Saya pikir untuk berdebat (idealnya membahas) bagaimana hal-hal dapat berubah sering mengarah pada perbaikan. Saya tidak berpikir "tujuan" Helm adalah untuk menautkan Bagan dan versi aplikasi. Saya pikir tujuannya adalah untuk membuatnya lebih mudah dan lebih aman untuk menyebarkan aplikasi ke dalam cluster Kubernetes, sambil menjaga agar Kubernetes Anda KERING dan dapat digunakan kembali. Tidak ada tempat di sana Anda memerlukan Bagan dan versi aplikasi untuk ditautkan secara ketat (seperti pada kenyataannya saat ini, Anda tidak memerlukannya).

Jadi sekali lagi, seperti yang saya katakan kepada @iorlas , pertanyaannya adalah, haruskah Helm beradaptasi? Apa alasan untuk tidak mengaktifkan kasus penggunaan ini? Jika alasannya hanya "karena saat ini tidak" maka itu alasan yang sangat buruk jika Anda bertanya kepada saya. Tak satu pun dari diskusi ini sejauh ini tampaknya telah menjawab pertanyaan ini.

... produk di akhir proses pembuatan itu (yaitu Gambar Docker) bergantung pada Dockerfile, dan benda yang Anda masukkan ke dalamnya. ... Sebuah gambar tidak dapat eksis tanpa kedua komponen tersebut.

Jadi... Paket Helm membutuhkan Bagan dan versi aplikasi (= Gambar Docker) dan tidak dapat ada tanpanya.

Bagan Helm bisa ada bahkan sebelum aplikasi dibangun - secara harfiah sebelum satu baris kode ditulis. ... Bagan Helm bisa ada sepenuhnya tanpa hal lain. Seperti yang saya katakan, ini tidak akan berguna

Lucunya, pada satu proyek kami menggunakan gambar stub docker untuk membuat arsitektur prototipe. Kami benar-benar menggunakan Bagan tanpa menulis satu baris kode. Juga, selalu layak untuk memiliki Bagan yang hanya terdiri dari subbagan.

Jadi, hipotesis saya adalah : Paket helm hampir tidak berguna tanpa gambar Docker. Gambar Docker hampir tidak berguna tanpa kode sumber. Perbedaannya adalah tingkat abstraksi. Kedua hal tersebut adalah objek seperti paket .

tapi saya hanya mencoba untuk mengilustrasikan poin saya bahwa mereka sama sekali tidak terhubung.

Ya, ya! Itu sangat bagus, kami memiliki ppl yang siap untuk mendiskusikan semuanya hingga detail. Tanpa Anda, tanpa proyeksi dan pernyataan, kami tidak akan membuat kehidupan yang layak di masa depan

Saya tidak berpikir itu klaim yang berani, itu terjadi - itu sudah fakta. ... Jadi seperti yang saya katakan sebelumnya, semua ini bermuara pada; apakah pengelola Helm ingin mengaktifkan kasus penggunaan ini, atau tidak - tidak ada yang lain untuk itu.

Fakta. Untuk membuat dan menerima perubahan seperti itu, harus dievaluasi: apakah itu hal yang benar untuk dilakukan ?

Biarkan saya menceritakan sebuah cerita. Martini adalah kerangka kerja web yang hebat dan banyak digunakan. Alasannya bukan karena kurangnya waktu untuk berinvestasi, alasannya bukan karena masalah perizinan. Jadi satu-satunya cara untuk membuat masa depan lebih cerah adalah dengan mencela seluruh kerangka kerja, membuat marah beberapa orang, meninggalkan beberapa proyek menjadi yatim piatu, memaksa beberapa orang untuk mengevaluasi kembali hal-hal yang mereka lakukan.

Jadi, saya tidak menentang pendekatan ini. Saya melihat bagaimana itu bisa hidup (lihat proposal saya dengan helm run ). Tetapi sementara kami memiliki kesempatan untuk melakukan intervensi dan, mungkin, memperbaiki seluruh industri selagi belum terlambat, saya akan mengevaluasi setiap penggunaan, mendiskusikan kekurangan dan masalah.

Untuk membangun Bagan Helm dalam skenario itu, Anda akan diminta untuk membangunnya kembali ketika aplikasi Anda berubah

Ya. Bahkan sekarang bisa jadi kasus. Kami memiliki satu saluran di mana alih-alih push kami melakukan save / load dari gambar buruh pelabuhan. Dan itu bekerja dengan cukup baik. Saya tidak merasa seperti itu sekarang, tetapi pada dasarnya ini adalah cara yang jauh lebih bersih. Masalahnya adalah, K8 masih membutuhkan registri buruh pelabuhan jarak jauh sebagai bus untuk mentransfer "pemula" - gambar buruh pelabuhan.

Mari kita persempit fokus kita guys

Bagan Helm Anda akan secara intrinsik ditautkan ke versi aplikasi yang sedang digunakan - seperti membangun gambar Docker.

Ini adalah perbedaan utama di sini. Dan @seeruk berhasil. Dan kita bisa fokus ke sana. Biarkan saya memparafrasekannya menjadi fakta:

1. Gambar Docker tidak terikat dengan paket Helm. Hanya referensi untuk itu.
2. Ini memberi kesempatan untuk melepaskan jalur ini secara mandiri.

Pertanyaan kunci:

1. Apa risiko dari pendekatan independen? (yaitu bagaimana jika beberapa devops akan menggunakannya, argumen apa yang akan kami katakan untuk menentangnya)
2. Bagaimana pendekatan pengemasan menyelesaikannya?
3. Berapa biayanya?
4. Bagaimana kita melihat masa depan containerisasi dalam pertanyaan khusus ini?

@seruk :

Jadi sekali lagi, seperti yang saya katakan kepada @iorlas , pertanyaannya adalah, haruskah Helm beradaptasi? Apa alasan untuk tidak mengaktifkan kasus penggunaan ini? Jika alasannya hanya "karena saat ini tidak" maka itu alasan yang sangat buruk jika Anda bertanya kepada saya. Tak satu pun dari diskusi ini sejauh ini tampaknya telah menjawab pertanyaan ini.

Anda membuat banyak klarifikasi dan poin yang bagus. Secara pribadi saya pikir Helm harus beradaptasi. CI/CD adalah masa depan bagaimana perangkat lunak akan dibangun, dan jujur ​​dengan perlakuan seperti --atomic helm sudah menjadi lebih fleksibel sebagai alat penyebaran yang andal. Padahal, masalah ini sudah cukup lama jadi saya pikir menggabungkan PR bukanlah "langkah selanjutnya" dalam prosesnya.

Apakah membuat plugin, katakanlah helm-ci-cd layak untuk fitur --app-version ini ( @jrkarnes mungkin dapat berbicara dengan yang ini sebagai kontributor PR)? Saya pikir kebutuhan komunitas untuk mengeluarkan Tiller benar-benar baru diketahui setelah plugin itu diluncurkan. Ada berbagai masalah lain dengan Helm yang mudah dilewati yang mungkin merupakan kandidat bagus lainnya untuk helm-ci-cd lihat dualitas install/ upgrade yang telah disatukan oleh CI/ CD ppl kita melalui pembungkusan.

Bahkan jika sakelar --app-version bukan nilai tambah langsung bagi pengguna akhir yang mencoba memasang aplikasi k8s tanpa harus melihat file templat (yang, btw, tidak pernah benar-benar berhasil saya karena perlu menambahkan kebijakan jaringan agar sesuai dengan infrastruktur k8s pekerjaan saya) pengguna akhir masih mendapatkan nilai lebih karena orang yang membuat bagan itu lebih mudah melakukannya karena fitur helm ci/ cd yang membuat bangunan stabil dan perangkat lunak yang dapat diandalkan lebih mudah.

Kami baru saja membaca di Chart.yaml dengan groovy kemudian mengatur versi aplikasi dan menimpa file selama waktu penerapan. Kemudian lakukan upgrade helm. Akan lebih baik jika itu adalah bagian dari helm tetapi saya tidak akan mengandalkannya.

Menemukan ini melalui Google'ing. Perahu yang sama, sebenarnya.

Jika verison: adalah versi Bagan, itu berarti versi ini berubah ketika YAML Bagan berubah. Karena bagan adalah templat dengan nilai yang dapat dikonfigurasi, aman untuk mengasumsikan Anda dapat menggunakan Bagan 1.3 untuk menerapkan aplikasi dari beberapa versi, 1.2, 1.3, 1.6, 1.8, dll, tanpa harus memodifikasi file YAML Bagan.

Sekarang hadir dalam appVersion: hard-coded di dalam Chart.yaml -- memaksa Anda untuk mengedit file grafik untuk memperbarui (dan mencerminkan) versi aplikasi yang digunakan.

Pasti ada kebutuhan untuk opsi CLI --app-version dapat kita gunakan dalam template Bagan untuk merujuk versi _application_ untuk menyebarkan versi yang berbeda dengan Bagan version: 1.3.0 .

@seruk

Saya tidak berpikir "tujuan" Helm adalah untuk menautkan Bagan dan versi aplikasi. Saya pikir tujuannya adalah untuk membuatnya lebih mudah dan lebih aman untuk menyebarkan aplikasi ke dalam cluster Kubernetes, sambil menjaga agar Kubernetes Anda KERING dan dapat digunakan kembali.

Ini adalah titik pertikaian kami dan saya tidak berpikir salah satu dari kami akan meyakinkan yang lain. Terkadang dalam lingkungan profesional, tidak apa-apa untuk memiliki perbedaan yang tidak dapat didamaikan ketika menyangkut masalah pendapat. Saya tentu saja tidak setuju dengan semua yang dikatakan Stallman dan jika kami masuk ke parit tentang semua yang dia dan saya tidak setujui, kami akan mati sebelum mencapai konsensus.

Saya mengatakannya lebih jauh dalam diskusi dan saya pikir perlu diulang:

[...] Saya menduga bahwa helm hanya pernah benar-benar menyebarkan paket. Tampaknya menjadi satu-satunya hal yang benar secara semantik yang dapat Anda katakan; namun, argumen tentang bagaimana paket-paket ini didistribusikan tampaknya menjadi akar penyebab perdebatan ini dalam praktiknya. Secara khusus, "apakah memutakhirkan atau mengubah versi aplikasi merupakan paket baru?"

Bagan kemudi pihak pertama (saya suka menggunakan MySQL jadi saya akan terus menggunakannya) tanpa konfigurasi harus menginstal sumber daya ke dalam kluster seperti yang dijelaskan dan dimaksudkan oleh pembuat bagan . Melihat bagan aktual untuk mysql ada dua properti yang dapat dikonfigurasi yang melibatkan mesin mysql yang sebenarnya:

• image (default mysql )
• imageTag (default 5.7.14 )

Kemudian, dalam file Chart.yaml :

apiVersion: v1
name: mysql
version: 1.4.0
appVersion: 5.7.27

Perhatikan bahwa appVersion dan default imageTag tidak cocok . Jika saya menjalankan helm list saya akan mendapatkan laporan bahwa "versi aplikasi" (baca; versi mesin) adalah status _yang tidak mencerminkan versi aplikasi sebenarnya yang diinstal ke dalam cluster_.

Tidak ada tempat di sana Anda memerlukan Bagan dan versi aplikasi untuk ditautkan secara ketat (seperti pada kenyataannya saat ini, Anda tidak memerlukannya).

Ini benar; dan menurut saya, cacat desain.

Jadi sekali lagi, seperti yang saya katakan kepada @iorlas , pertanyaannya adalah, haruskah Helm beradaptasi?

Ya. Saya akan membahas beberapa saran sebentar lagi.

@IRobL

Apakah membuat plugin, katakanlah helm-ci-cd layak untuk fitur --app-version khusus ini ( @jrkarnes mungkin dapat berbicara dengan yang ini sebagai kontributor PR)?

Anda menjawab pertanyaan Anda sendiri dengan:

Bahkan jika --app-version switch bukan nilai tambah langsung untuk pengguna akhir yang mencoba menginstal aplikasi k8s tanpa harus melihat file template, pengguna akhir masih mendapatkan nilai lebih karena orang yang membuat bagan itu lebih mudah melakukannya karena fitur helm ci/ cd yang membuat pembuatan perangkat lunak yang stabil dan andal menjadi lebih mudah.

Jika kita harus melakukannya sebagai plugin untuk mendapatkan fungsi yang benar, maka saya akan menganjurkan pendekatan itu; Namun, saya pikir itu mengatasi masalah yang salah. Seperti yang saya katakan sebelumnya kepada @seeruk , saya pikir memiliki appVersion menjadi properti intrinsik dalam file Chart.yaml tidak dapat diubah adalah cacat desain. appVersion adalah properti dari image yang sedang diinstal ke dalam cluster melalui bagan, dan dalam beberapa cara diturunkan dari gambar yang dirujuk dengan tag .

Saat memikirkan tentang plugin helm-ci , fitur atau add-in apa lagi yang Anda harapkan ada di sana? Saya tidak berpikir bahwa hanya dengan mengalihkan appVersion dari properti Chart.yaml tidak dapat diubah sudah cukup sebagai nilai tambah untuk menjamin menjadi sebuah plugin.

@IRobL dan @seeruk bersama-sama:

Saya pikir pendapat kami yang berbeda berasal dari siapa yang kami lihat sebagai pengguna akhir helm yang lebih umum. Jika pengguna akhir seharusnya seseorang yang tidak akan melakukan banyak konfigurasi atau menggali template, maka helm ls mungkin tidak terlalu berguna dan intinya bisa diperdebatkan.

Namun... jika Anda menggunakan helm sebagai alat administratif dan asisten untuk mengelola klaster ATAU jika Anda menggunakan Helm lebih banyak dalam konteks CI/CD, maka sakelar --appVersion menjadi jauh lebih lebih berguna dan dengan demikian menjadi perhatian (dan konfigurasi),

Di dunia yang sempurna, saya berpendapat bahwa appVersion harus menjadi properti turunan dan berasal dari metadata gambar buruh pelabuhan; ini tidak layak untuk dilakukan, ergo, kurangnya pertengkaran.

Untuk apa yang saya katakan tentang

Ya. Saya akan membahas beberapa saran sebentar lagi...
... dalam memikirkan plugin helm-ci , fitur atau add-in apa lagi yang Anda harapkan ada di sana?

Saya memiliki daftar pribadi yang mungkin menjadi titik awal yang baik:

• Menjalankan helm dalam mode CICD tidak akan membandingkan _only_ status paket yang dirilis sebelumnya dengan apa yang sedang diterapkan. . Sebaliknya, setiap penerapan rilis akan sepenuhnya menerapkan setiap template manifes saat upgrade dijalankan.
• helm-cicd harus membungkus perintah kubernetes dasar. Saya tidak dapat menghitung berapa kali saya mencoba menjalankan helm describe atau helm logs .
• helm-cicd seharusnya memungkinkan saya untuk melihat apa hasil dari perintah ketika dijalankan oleh pengguna yang berbeda. Jika kita menggunakan RBAC, saya ingin melihat apa yang terjadi ketika pengguna yang tidak diautentikasi mencoba melakukan sesuatu.
• helm-cicd harus dapat menguraikan namespace menjadi kumpulan manifes untuk diedit nanti.
• helm-cicd harus dapat _transplant_ rilis ke namespace.

Itu adalah yang besar... tetapi membahas plugin helm-ci berada di luar cakupan PR/Masalah ini (saat ini).

Saya membaca semua yang kalian ketik dan saya menghargai wacana. Saya menunggu respon Anda.

Cukup sibuk pada waktu saya sekarang, tetapi ingin mengoreksi Anda pada beberapa poin. @jrkarnes

Saya pikir menjadikan appVersion sebagai properti intrinsik dalam file Chart.yaml yang tidak dapat diubah adalah cacat desain

Bukan itu. Ketika sesuatu dibuat dengan cara ini dan bukan yang lain, selalu ada alasan, bahkan alasan yang liar . Dalam hal ini, ideologi yang saya pegang: satu paket = satu build, chart = template untuk build, package = app + infra.

Helm dirancang berdasarkan ideologi ini, untuk memperlakukan K8 sebagai OS dan paket sebagai penginstal/pembaru untuk aplikasi Anda. Ini memiliki beberapa masalah, kadang-kadang terasa seperti terlalu banyak, tetapi itu pasti masa depan.

_Mengapa saya pikir itu dirancang seperti itu? helm list sama diatur untuk menampilkan versi paket saat ini yang diinstal._

Oke, kami memiliki banyak Bagan (publik seperti mysql dan lokal, seperti yang mungkin Anda miliki) yang tidak dibuat untuk membuat paket setiap kali rilis baru muncul. Dan saya mengagumi kebutuhan ini, karena migrasi ke solusi tingkat tinggi membutuhkan waktu. Juga, seseorang perlu membuat paket dan akan sulit untuk meyakinkan pengelola mysql untuk membuat paket Helm untuk setiap build.

Dengan grafik MySQL ada masalah tambahan. Anda benar, itu akan lebih baik untuk melihat versi MySQL diinstal di helm list , tetapi itu hanya bagian dari versi, karena ada juga tag Gambar, yang mungkin merupakan bagian dari versi di sini.

Jadi sekali lagi, seperti yang saya katakan kepada @iorlas , pertanyaannya adalah, haruskah Helm beradaptasi?
Ya. Saya akan membahas beberapa saran sebentar lagi.

Sekali lagi, ada proposal untuk menambahkan helm run , yang Anda semua cari. Apakah dimaksudkan untuk menggunakan Bagan sebagai paket secara instan, memungkinkan untuk menyediakan versi aplikasi dan semuanya.

Di dunia yang sempurna, saya berpendapat bahwa appVersion harus menjadi properti turunan dan berasal dari metadata gambar buruh pelabuhan; ini tidak layak untuk dilakukan, ergo, kurangnya pertengkaran.

Anda melihat gambar Docker sebagai produk akhir, sebagai paket terakhir, yang merupakan sumber kebenaran terakhir. Bukan itu. Ketika Anda tidak memiliki apa-apa selain gambar Docker, Anda dapat ditipu untuk percaya bahwa itu adalah perangkat lunak Anda. Saat Anda menulis modul dalam kode Anda, Anda tertipu untuk percaya bahwa modul ini adalah perangkat lunak Anda.

Masalahnya, tidak. Itu hanya sebagian, artefak. Dari produk kecil hingga besar, Anda akan memiliki banyak artefak yang diikat menjadi satu. Terkadang Anda akan melewati versi dalam file buruh pelabuhan dalam proses pembuatan, terkadang Anda akan memiliki ConfigMap, yang mengikat beberapa artefak. Dan Anda tidak akan memiliki satu file buruh pelabuhan yang akan memiliki semuanya.

Saya memiliki daftar pribadi yang mungkin menjadi titik awal yang baik

Saya yakin Anda memiliki banyak saran, tetapi rasanya lebih hidup sebagai garpu Helm , bukan beberapa plugin liar. Saya akan mengatakan itu tidak ada hubungannya dengan CI CD secara eksklusif. Saya berpendapat untuk tidak membuat garpu/plugin seperti itu, tetapi diskusikan dan temukan solusi yang tepat. Tidak ada yang membutuhkan 3 garpu Helm, mengingat komunitas saat ini tidak sebesar sekarang.

Mohon perhatiannya!

Oke, kita punya banyak pemikiran sana-sini. Saya percaya skenario kasus terbaik adalah memiliki:

• Kemampuan untuk mengubah versi aplikasi, tanpa perlu membuat paket terlebih dahulu
• Kemampuan untuk melihat versi aplikasi yang tepat di helm ls
• Izinkan API apa pun (seperti operator Helm) untuk menentukan/meningkatkan versi aplikasi tanpa status tengah

Kami memiliki dua pendekatan yang disediakan:

1. helm install dibuat untuk menginstal sebuah paket. Ini mendukung pemasangan Bagan juga, tetapi terbatas. Mari kita sederhanakan helm install dan biarkan untuk melayani tujuannya - instal paket. Kedua, mari tambahkan helm run , yang tujuannya adalah untuk memberikan aliran yang disederhanakan: gabungkan helm package dan helm run , berikan kedua argumen perintah, tetapi filter yang tidak masuk akal dalam kasus seperti itu .
2. Tambahkan app-version ke helm install cmd. Ini akan mengasapi API ini dan menyembunyikan ide menggunakan paket, itu akan menyembunyikan (seperti yang terjadi sekarang) ideologi menggunakan paket sebagai penginstal, yang masuk akal setidaknya untuk beberapa, jika tidak sebagian besar, proyek.

Bisakah kita setuju bahwa kedua pendekatan ini akan menyelesaikan semua perjuangan yang kita miliki saat ini?

Plugin adalah solusi untuk fitur yang hilang yang tidak ingin didukung oleh pengembang inti atau tidak punya waktu, jadi saya tidak peduli apakah itu plugin.

Helm dirancang berdasarkan ideologi ini, untuk memperlakukan K8 sebagai OS dan paket sebagai penginstal/pembaru untuk aplikasi Anda.

Oooh. Saya mengerti. Bagan kemudi [paket] dimaksudkan sebagai "rpm" [per-katakan] untuk Kubernetes. Sama sekali bukan kesan yang saya dapatkan: helm menggunakan Bagan untuk menyebarkan Aplikasi. Bagan/paket adalah aplikasi "diformat untuk k8s."

Aku baik-baik saja dengan itu. Masuk akal - kami baru saja perlu memperbarui server build kami ke appVersion saat kami membangun wadah baru:

• Bangun Penampung - beri tag "v1.2"
• Perbarui Chart.yaml - appVersion: "v1.2" --- Saya melihat bahkan sudah ada perintah helm package --app-version .
• Bagan paket: helm package --app-version v1.2 => package[chart]-v1.2.tgz (yaitu "package[chart]-v1.2.rpm")
• Terapkan paket menggunakan server penerapan, paket instal helm[bagan]-v1.2 (mis. apt install [email protected])

Sekarang, apakah saya salah dalam memahami semua ini? Jika package-v1.2 bukan appVersion v1.2, mengapa tidak? Bukankah itu niatnya? misalnya rpm adalah versi aplikasi, bukan paket (Bagan).

Sunting:

Jika package-v1.2 bukan appVersion v1.2, mengapa tidak? Bukankah itu niatnya?

Sekarang saya mengerti mengapa orang-orang mengomentari Chart.version dan Chart.appVersion secara bersamaan. Argumen dapat berjalan dua arah di sini... sebuah aplikasi dengan build "bagan" yang stabil, Anda akan mengharapkan package-v1.2 untuk mengubah nomor versinya. Tetapi Anda juga dapat berargumen bahwa package-v1.2 akan menjadi nomor versi Bagan - ketika file yaml berubah.

Bagaimana Anda mengelola versi Bagan yang stabil (1.2), yang membedakan dari versi aplikasi yang meningkat (1.6)? Akankah package-[version] menjadi 1,2? atau 1.6? Katakanlah Anda menggunakan Bagan versi 1.2 tetapi appVersion berubah pada pengemasan: helm package --app-version 1.6 ?

➜  chart git:(master) ✗ helm package --app-version 1.5 nginx
Successfully packaged chart and saved it to: /Users/Documents/source/docker/nginx/chart/nginx-0.1.0.tgz

:(

.... Jadi membingungkan.

Bagan helm [paket] dimaksudkan sebagai "rpm" [per-katakan] untuk Kubernetes

Tepat! Namun terkadang terasa terlalu ketat atau terlalu merepotkan, disinilah dibutuhkan jalan pintas.

Sekarang, apakah saya salah dalam memahami semua ini? Jika package-v1.2 bukan appVersion v1.2, mengapa tidak? Bukankah itu niatnya? misalnya rpm adalah versi aplikasi, bukan paket (Bagan).

Ini adalah masalah untuk diskusi lain, tetapi saat ini paket akan dinamai menurut versi bagan, bukan versi aplikasi. Saya tidak tahu alasannya, saya merasa seharusnya sebaliknya. Saya pikir, ini adalah masalah bersejarah, tetapi dalam pikiran saya, seperti milik Anda, seharusnya package-{app-version}.tgz .

Sesuai pesan saya sebelumnya, ada 4 komponen untuk versi:

• Bagan
• Aplikasi
• Kemasan
• Melepaskan

Ini adalah sakit kepala untuk versi semua hal ini secara mandiri, tetapi cara kerjanya sekarang. Dengan satu pengecualian: paket diversi setelah versi bagan.

Jika kita akan memilih ideologi pengemasan aplikasi, versi aplikasi akan sangat masuk akal, karena proses yang sama menghasilkan aplikasi, gambar, dan paket. Jadi, ketika kita akan masuk ke langkah pengiriman, akan terlihat jelas bagaimana file dipanggil, file mana yang akan diinstal. Saat ini kita harus meng-hardcode nama paket di pipeline >_<

@iorlas

Anda melihat gambar Docker sebagai produk akhir, sebagai paket terakhir, yang merupakan sumber kebenaran terakhir. Bukan itu. Ketika Anda tidak memiliki apa-apa selain gambar Docker, Anda dapat ditipu untuk percaya bahwa itu adalah perangkat lunak Anda. Saat Anda menulis modul dalam kode Anda, Anda tertipu untuk percaya bahwa modul ini adalah perangkat lunak Anda.

Saya mengambil beberapa minggu untuk memikirkan pernyataan ini dan saya 100% setuju dengan Anda. Selain itu, saya sekarang mengerti dari mana perbedaan pendapat kita berasal...

Saya mengikuti filosofi pengembangan dan penerapan bahwa Anda harus membangun sistem dari komponen kecil yang melakukan serangkaian hal dengan sangat baik (pikirkan UNIX); namun, sistem modern mungkin memperlakukan "aplikasi" sebagai pengelompokan alat-alat kecil ini. Bagaimana Anda seharusnya menandai "versi" aplikasi ketika itu tidak hanya bergantung pada artefak buruh pelabuhan, tetapi juga sub-komponen lain (yang mungkin juga merupakan artefak buruh pelabuhan)? Ini bukan jawaban yang mudah ketika Anda mulai menggunakan jenis kopling ini.

Menjawab pertanyaan ini jauh di luar cakupan masalah/permintaan ini. Untuk kembali ke akar masalah, saya ingin membuat perbedaan antara install dan run . Berdasarkan semantik, install seharusnya hanya beroperasi pada paket, dan run harus "menjalankan" melalui proses pembuatan template dan menerapkannya _tanpa mempertahankan status_.

Meskipun seringkali kita harus menggunakan helm template untuk melihat bagaimana grafik prospektif akan disebarkan, ada banyak kegunaan dalam melihat hal itu terjadi vi-ca-vi run yang memiliki tujuan ganda menjadi bintang dalam jalur pengembangan (di mana kami tidak perlu menyimpan paket karena tidak memiliki nilai jika kecepatannya sangat tinggi).

Dengan grafik MySQL ada masalah tambahan. Anda benar, itu akan lebih baik untuk melihat versi MySQL terinstal di daftar helm, tetapi itu hanya bagian dari versi, karena ada juga tag Gambar, yang mungkin merupakan bagian dari versi di sini.

Seperti yang saya katakan, di alam semesta yang sempurna, versi objek yang diinstal akan diintrospeksi. Namun ini memberi saya ide.

Jika kita mengingat apa yang saya katakan di awal tentang bagaimana grafik dikerahkan, bagaimana jika kita memiliki kemampuan untuk menyebarkan semua sub-komponen dengan tanda pada helm describe ? Itu tidak memperbaiki kebutuhan untuk menentukan aplikasi-versi, tapi itu tidak membuatnya lebih jelas apa yang diinstal (yang merupakan bagian dari kekuatan pendorong di belakang yang ingin menyesuaikan aplikasi-versi dengan bendera).

Saya membaca semua komentar dan tidak memiliki pendapat yang sepenuhnya memenuhi syarat tentang masalah ini.

Saya tiba di sini karena perusahaan saya mengelola repositori Helm pribadi dan 90% bagan kami sebagian besar adalah satu penerapan yang memiliki satu spesifikasi wadah. Dalam kasus ini, jika kita dapat menggunakan appVersion untuk mencantumkan tag gambar, kita akan menghindari duplikasi variabel dan kita akan dapat melihat versi ini berjalan helm version .

Setelah membaca utas ini, menurut saya ini akan menjadi kemudahan, meskipun sangat bagus yang akan saya gunakan jika itu pernah digabungkan.

Seperti yang diminta, saya akan menyertakan balasan terakhir saya dari utas sebelumnya untuk dilihat orang lain

Hmm. Di sinilah hal-hal mulai bertentangan satu sama lain ketika Anda mulai mengikat appVersion ke tag Docker (asosiasi logis). Di sinilah kami mengalami masalah, yaitu skenario dev yang saya sebutkan di atas. Karena version harus SemVer, kami tidak dapat menggunakan tag Docker sebagai Bagan version .

Bagaimana cara membuat perbedaan versi visual bagi pengembang ketika appVersion tidak terlihat di tangga lagu?

Karena cara kerja k8s dengan aplikasinya: di dunia dev, ada beberapa cara untuk mengizinkan versi tag di seluruh papan.

Itu tidak dapat melakukan hal-hal seperti SemVer dalam hal operator ~ atau ^, karena versinya murni dipesan, tanpa semantik.

Kenapa tidak? Kami melakukan ini sepanjang waktu dengan php composer . Kita dapat menggunakan SemVer atau kita dapat menggunakan versi string yang hanya diuraikan atau diabaikan dalam skema versi, yaitu jika version bukan nomor SemVer, jangan sertakan dalam ~ dan ^ Pencocokan pola

Karena Anda mengutip komentar saya di #7299 , saya akan mengklarifikasi "Tidak bisa" sebagai "Tidak" (dan mungkin masih tidak).

Untuk paket .deb dan .rpm, string versi dibagi dengan cara tertentu (dengan tanda hubung), tetapi mereka tidak memiliki arti semantik seperti "Ini kompatibel dengan API" sehingga Anda tidak dapat membuat ekspresi seperti "Berikan saya versi terbaru yang kompatibel dengan API" atau "Beri saya versi terbaru dengan API yang tidak berubah", seperti yang Anda bisa dengan SemVer.

Saya ingat bahwa Debian dan RedHat menggunakan alias paket untuk mencapai kasus penggunaan tersebut (dan kompatibilitas ABI) umumnya berdasarkan nomor soversion. Ini memungkinkan perilaku yang cukup konsisten hanya menggunakan nama paket dan perbandingan hanya pemesanan.

Pada topik umum, cara kami menggunakan grafik Helm untuk produk kami adalah untuk mengemas berbagai layanan kami. Namun, gambar Docker hanyalah artefak, dan penamaannya didorong oleh versi layanan, yang kami adopsi SemVer karena mereka menawarkan API.

Pipeline CI kami mengubah git repo kode dan skrip terkait, dan menghasilkan bagan Helm yang dapat diinstal, dan kebetulan merujuk pada gambar Docker. Tag pada gambar Docker tidak menarik bagi pengguna kami. Kami memberi tag kemudian dengan git SHA asalnya, dan kemudian memberi tag ulang pada gambar yang digunakan dalam rilis. Manfaat utama dari pemberian tag ulang adalah kita tahu untuk tidak pernah menghapus tag tersebut, sementara kita dapat menghapus tag versi git-SHA setelah beberapa saat.

Jadi saya cukup senang dengan cara Helm bekerja untuk kami, karena version berisi versi persis perangkat lunak kami, dan appVersion berisi hal yang sama tetapi sebagai string, dan tidak ada yang pernah melihat di repo Docker kami.

Saya sedikit kurang senang dengan cara bagan diversi di https://github.com/helm/charts/ , karena di sana bagan diversi, bukan perangkat lunak, yang mengarah ke bagan minor (stabil) sesekali version bagan dari versi hal-hal yang dikandungnya.

Kami memiliki masalah serupa dengan bagan operator stabil/prometheus , di halaman internal "Perpustakaan dan artefak yang dikonsumsi secara eksternal". Itu berisi banyak perangkat lunak yang berbeda, jadi pertanyaannya "Kita menggunakan versi apa?" dan khususnya "Apakah aman untuk ditingkatkan?" jauh lebih sulit untuk dijawab daripada untuk Agnes, yang versinya sama seperti kita.

@jrkarnes

Jika kita mengingat apa yang saya katakan di awal tentang bagaimana grafik dikerahkan, bagaimana jika kita memiliki kemampuan untuk merentangkan semua sub-komponen dengan flag on helm yang dijelaskan? Itu tidak memperbaiki kebutuhan untuk menentukan versi aplikasi, tetapi itu membuat lebih jelas apa yang diinstal (yang merupakan bagian dari kekuatan pendorong di balik keinginan untuk menyesuaikan versi aplikasi dengan tanda).

Saya sangat ingin melihatnya. Ada permintaan fitur terkait di #6932 misalnya.

Baru saja membuka kembali diskusi, gagasan bahwa appVersion terkait dengan metadata gambar Docker jelas tidak sesuai dengan kasus penggunaan kami, karena setidaknya beberapa bagan kami (yang terutama ditangani oleh pengguna kami) melakukannya tidak berisi gambar Docker, sebagian besar menjadi host untuk sumber daya bersama (misalnya, kunci publik JWT, values.yaml ) ditambah requirements.yaml untuk menarik grafik lain.

gagasan bahwa appVersion terkait dengan metadata gambar Docker jelas tidak sesuai dengan kasus penggunaan kami, karena setidaknya beberapa bagan kami

Saya tidak mengatakan itu adalah _the_ yang dimaksudkan untuk digunakan. Saya hanya menyatakan itu asosiasi logis. Anda masih menggunakan appVersion sebagai "wadah logis" dari yaml internal Anda.

Saya masih tidak tahu bagaimana mengunci version ke SemVer memiliki manfaat. Bisakah helm hanya parse-test version (dan appVersion ) dan melanjutkan dari sana?

Saya kira maksud saya adalah kami tidak menggunakan appVersion sama sekali, biasanya tidak ada di Chart.yaml kami, dan ketika ada, itu identik dengan version .

Manfaat mengunci version ke SemVer adalah Anda dapat menggunakan berbagai operator SemVer di dalamnya, dan menguraikannya dengan andal untuk menghasilkan urutan dan kecocokan dengan menginstal.

Sistem pengemasan RPM dan DEB memiliki hal yang sama, kecuali bahwa sistem versi mereka menggunakan sintaks yang berbeda, tetapi masih merupakan sintaks terbatas karena alasan penguraian semantik. Mereka juga memiliki semantik berbeda yang mereka pedulikan.

Mengingat bagaimana repo helm/bagan dijalankan, saya merasa satu bidang version dengan versi gaya DEB atau RPM akan menjadi pilihan yang lebih baik daripada SemVer plus string appVersion . Namun, itu benar-benar berbeda, sudah berlayar, kapal. Dan karena telah menjadi vendor upstream dan pembuat paket Debian di masa muda saya, saya menghargai tidak harus menyulap "Manakah dari nomor versi yang perlu dibenturkan di sini?" dalam paket " version adalah satu-satunya kebenaran" kami.

Masalah dengan "kadang-kadang SemVer" adalah bahwa SemVer sangat mirip dengan parser yang tidak dapat dibedakan dari sesuatu yang mungkin Anda tulis dengan tangan, atau temui di tempat lain, seperti versi paket Debian yang tidak memiliki zaman, dengan hasil yang sangat membingungkan .

Hai. Tidak ada berita tentang fitur ini.

Setelah membaca semua komentar, saya dapat melihat bahwa itu akan sangat membantu.

Memang, di perusahaan kami karena kami mendapatkan beberapa aplikasi yang menggunakan teknologi yang sama dan diterapkan dengan cara yang sama, kami memiliki satu bagan untuk aplikasi yang berbeda untuk menghindari duplikasi.
Kami mengemas grafik baru hanya ketika ada perubahan infra, struktural.
Dan hanya ketika kami meningkatkan atau menginstal rilis, kami menerapkan nilai tertentu sebagai tag, variabel env...

Kami menganggap bahwa bagan helm yang dikemas adalah lapisan abstraksi yang mewakili sumber daya dan struktur kubernetes yang diharapkan untuk satu jenis aplikasi dan hanya selama penerapan yang kami katakan "ok saya ingin aplikasi semacam ini digunakan pada env itu dengan nilai-nilai spesifik ini"

Karena daftar helm harus menampilkan informasi rilis, kami harus dapat melihat versi aplikasi yang digunakan dalam rilis ini.

Saya meninggalkan komentar dalam masalah serupa https://github.com/helm/helm/issues/7517
Bisakah kita menambahkan kemampuan untuk menimpa ini di values.yaml ?
Kemudian kita mendapatkan opsi baris perintah gratis --set

Jika kami mencoba menggunakan helm untuk aplikasi apa pun, ini benar-benar menyebalkan. Tidak ada yang menggunakan versi semantik untuk aplikasi produksi.

Saya setuju. Saat ini kami diblokir karena menggunakan Museum Bagan untuk bagan berbasis _aplikasi_ yang tidak dapat diubah. Chart version != versi aplikasi, sehingga tidak memungkinkan untuk kami rilis melalui Chart Museum.

Saya membaca banyak (tidak semua) diskusi di atas, jadi maaf jika saya mengulangi beberapa poin / pandangan. Saya mencoba mengajukan tanggapan yang lebih dipertimbangkan.

Saya suka melihat appVersion ketika saya melakukan helm ls dan secara konseptual pindah dari .Values.image.tag itu bagus TAPI tidak dapat mengaturnya pada waktu penerapan adalah penghenti pertunjukan nyata dan merupakan sesuatu yang saya miliki untuk kembali ke.

Saya yakin bahwa (bagan) version adalah versi bagan dan appVersion adalah tag buruh pelabuhan. Dalam proses CI kami, tag buruh pelabuhan juga merupakan tag git.
Kami juga memiliki beberapa layanan mikro dan memiliki keinginan untuk menjaga segala sesuatunya sekering mungkin. Kami memiliki bagan generik dalam repo bagan lokal karena sebagian besar aplikasi java-springboot adalah sama. Sebagian besar aplikasi Tomcat adalah sama (tetapi berbeda dari yang springboot). Bilas dan ulangi untuk teknologi lainnya. Kami kemudian memiliki nilai-nilai lingkungan saat penerapan berjalan melalui berbagai lingkungan
Masing-masing layanan mikro ini kemudian menggunakan bagan generik melalui CI/CD
misalnya helm upgrade release-name private-repo/generic-chart --values <environment>.yaml --set image.tag=<docker tag from build step> --namespace <environment> --install Saya lebih suka menggunakan .Chart.AppVersion daripada .Values.image.tag tetapi saya HARUS dapat menerapkan dengan cara yang efisien untuk Organisasi kami.

Jika saya melakukan helm ls saya memiliki keduanya CHART dan APP VERSION jadi seluruh versi bagan harus cocok dengan versi aplikasi jatuh datar di wajahnya di sana. Melanjutkan rute itu hanya akan mengasingkan orang dan pada titik tertentu proyek akan bercabang karena mentalitas itu terlalu ketat dan bukan yang diinginkan banyak orang. Itu juga mulai mengarah ke "Lets remove image.* , nameOverride & fullnameOverride . image.* dapat dikodekan secara keras di deployment.yaml dll." untuk alasan yang SANGAT mirip.

Poin terakhir adalah bahwa banyak bagan publik tidak akan sama persis dengan versi wadah buruh pelabuhan yang mereka gunakan. Lihatlah kontainer buruh pelabuhan yang paling terkenal misalnya alpine atau nginx di mana versi mayor dan minor adalah tag bergulir dengan hanya versi patch yang tidak bergulir. Memiliki pemetaan 1:1 untuk setiap versi tambalan memperkenalkan overhead yang cukup signifikan dengan sedikit atau tanpa manfaat.
Bukan hal yang aneh jika lingkungan produksi tidak dapat meningkatkan ke versi terbaru karena berbagai alasan. Bahkan tidak berbicara ke sebagian besar tempat tentang versi bergulir dalam produksi.

Hasil dari semua hal di atas kemudian menimbulkan pertanyaan "Mengapa helm bisa menggunakan chart repo sama sekali?".
Tidak dapat menimpa appVersion pada waktu pemasangan / peningkatan berarti Anda sudah perlu mengunduh dan membongkar bagan, mengedit appVersion per pemasangan/peningkatan, atau Anda mungkin juga mengemas wadah buruh pelabuhan yang diperlukan ke grafik.
Pengecualian adalah di mana instalasi yang sepenuhnya standar terjadi, dan sudah ada banyak perdebatan seputar pembuatan kata sandi otomatis dan sejenisnya.
Saya tahu paragraf terakhir sepertinya saya akan masuk ke lubang kelinci dan mengecat diri saya ke sudut, tetapi di situlah "appVersion adalah tag buruh pelabuhan DAN tidak dapat mengatur appVersion melalui baris perintah atau nilai" membawa kita.

@timothyclarke : Apa yang mungkin ingin Anda lakukan, untuk kasus penggunaan helm upgrade Anda jelaskan di sini, adalah helm package terlebih dahulu, yang memungkinkan Anda mengatur --version dan --app-version , dan kemudian Anda dapat helm install tarball, dan menyimpannya sebagai artefak CI, yang meningkatkan reproduktifitas Anda untuk penginstalan, karena tidak memerlukan parameter --set ditambahkan. Itulah yang kami pindahkan, meskipun tanpa aspek "bagan generik", karena bagan kami tidak umum.

Ini juga merupakan peluang bagus untuk menambahkan metadata build ke Version , dengan sesuatu seperti +g<shortCommitSHA> .

Per #7517, yang memungkinkan saya menghapus sekelompok panggilan sed yang menulis ulang image.tag sebelum menginstal ke klaster pengujian CI kami, dan kemudian lagi saat pengemasan nanti.

Pendekatan ini mungkin benar-benar menyelesaikan masalah yang dihadapi kebanyakan orang di sini, jika mereka membuat bagan mereka sendiri, dan terutama jika mereka memasang dari sumber bagan di checkout mereka. Tidak terlalu membantu jika mereka membutuhkan fungsionalitas ini untuk bagan yang berasal dari repo, tetapi saya pikir itu masalah yang berbeda dari yang dialami kebanyakan orang di sini?

Bagi saya, risiko dari mengganti versi aplikasi (atau versi) pada waktu penginstalan adalah bahwa itu tidak terlihat jelas oleh orang lain yang mencoba membuat ulang bagan, bahwa ini sudah selesai. Kecuali jika entah bagaimana diretas ke dalam dukungan nilai, itu tidak akan ada ketika seseorang mengekstrak konfigurasi bagan saat ini menggunakan helm get values -o yaml , sehingga menjadi _satu hal lagi_ yang membuat penerapan bagan langsung Anda berbeda dari yang Anda dapatkan helm install <some way to specify a particular package> --values <values from helm get values> , misalnya, ketika mencoba mereproduksi masalah yang terlihat dalam produksi pada pengaturan pengujian.

Bagi saya, risiko dari mengganti versi aplikasi (atau versi) pada waktu penginstalan adalah bahwa itu tidak terlihat jelas oleh orang lain yang mencoba membuat ulang bagan, bahwa ini sudah selesai. Kecuali jika entah bagaimana diretas ke dalam dukungan nilai, itu tidak akan ada ketika seseorang mengekstrak konfigurasi bagan saat ini menggunakan helm get values -o yaml

Anda memukul paku di kepala. Ini seharusnya sudah ada di values.yml sejak hari pertama.

Meskipun saya memahami argumen filosofis yang menentang fitur ini, praktik lapangan menunjukkan bahwa fitur ini akan banyak membantu orang -- termasuk kita.

Ada banyak bagan di alam liar yang memungkinkan Anda mengatur versi aplikasi melalui values.yml , khususnya karena tidak dapat disetel di sini.

Saya tidak yakin apakah itu telah dibahas (melakukan CTRL+F cepat dan tidak dapat menemukan jejak apa pun), tetapi bagaimana dengan menghapus appVersion bersama-sama sebagai solusi alternatif? Tampaknya bagi saya, bahwa itu akan menghindari seluruh kebingungan.

Saat ini appVersion diperlakukan sebagai semacam nilai "khusus". Saya berasumsi, bahwa itu ada untuk memberikan visibilitas misalnya saya dapat memiliki grafik versi 123.5.6 dari Prometheus, tetapi akan memiliki appVersion: 2.17.1, jadi saya tahu versi patch keamanan apa yang dimilikinya dan fitur Prometheus apa yang diharapkan dan saya dapat mencarinya menggunakan helm ls .

Saya kira itu bisa diberikan dengan cara yang berbeda. Mungkin melalui label rilis? Atau mungkin kueri jsonPath atas semua rilis, mirip dengan apa yang mungkin dilakukan dengan kubectl misalnya:

kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

Kemudian, dukungan itu akan dialihkan ke praktik terbaik, alih-alih dipaksakan oleh helm itu sendiri. Itu juga bisa dilapisi.

Di sisi lain, mungkin banyak orang yang mengandalkan implementasi appVersion , yang juga perlu dipertimbangkan.

Mungkin mengambil langkah mundur dan memahami mengapa tepatnya appVersion telah ditambahkan akan membantu menyelesaikan masalah ini?

@bokysan Itu sebelumnya di values.yaml itu dipindahkan ke Chart.yaml Saya menduga untuk keseluruhan helm ls menunjukkan bagan dan tag buruh pelabuhan daripada harus menjalankan perintah seperti itu sebagai
kubectl get deployment <release name> -o jsonpath='{.spec.template.spec.containers[0].image}'

@TBBle Saya akan membahas setiap poin Anda, tetapi itu akan membuat posting ini sepanjang yang sebelumnya. Saya pikir seluruh masalah ini sampai pada seseorang yang memutuskan bahwa bagan umum bukan kasus penggunaan yang valid hanya dengan melihat bagan di repo publik.

Seluruh premis appVersion gagal total begitu Anda perlu mulai menggunakan initContainers dan sidecars. Untuk memberikan contoh dunia nyata, salah satu proyek yang saat ini perlu saya kelola memiliki nginx dengan sidecar php. Tag nginx dan php tidak sering berubah. Wadah / versi php sangat penting bagi pengembang yang menulis kode. Wadah yang paling sering berubah adalah initContainer yang menyediakan konten.
Apakah saya menetapkan appVersion ke initContainer , ke php container atau nginx , dan dengan memilih hanya satu dari ini informasi apa yang telah hilang ?

Jika itu penting bagi pengguna Anda, maka itu harus versi PHP, bukan? Itulah yang Anda iklankan. Anda juga bisa menempelkan ketiganya di appVersion Anda, bagaimanapun juga ini adalah bidang teks bebas.

Jika Anda ingin memaksa appVersion == tag gambar wadah, maka Anda akan menemukan tantangan itu dengan bagan non-sepele, yaitu bagan dengan lebih dari satu wadah, atau tanpa wadah. Sebenarnya bukan itu intinya, atau itu akan menjadi imageVersion . Jika Anda mengemas satu aplikasi upstream, gunakan versinya. Jika Anda membuat paket dari beberapa aplikasi upstream, pilih salah satu, misalnya bagan operator prometheus, atau abaikan appVersion, karena ini adalah bidang opsional.

Jika sumber bagan Anda adalah _bagian dari_ aplikasi, misalnya Agnes, biarkan appVersion kosong, atau salin dari version jika Anda memiliki perkakas yang bergantung padanya.

Tak satu pun dari hal-hal ini perlu menjadi helm install -keputusan waktu. Seperti yang saya sebutkan sebelumnya, helm package sudah cukup terlambat untuk semua alur kerja kecuali "ganti versi upstream yang berbeda pada waktu penginstalan untuk bagan pihak ketiga" dan itu harus di --values atau --set seperti semua tindakan "ubah X pada waktu pemasangan" lainnya.

Sejujurnya, fitur yang sebenarnya hilang mungkin adalah "pass appVersion melalui tpl ", sehingga Anda dapat membacanya dari .Values.image.tag atau apa pun yang sesuai untuk Anda.

Jika Anda ingin memaksa appVersion == tag gambar kontainer

Maka kita mungkin berada di https://github.com/helm/helm/issues/7517 Itu mungkin dari mana semua ini berasal.

Saya tidak mengerti sama sekali pembahasan ini. Mengapa tidak memberi orang pilihan untuk menggunakan versi aplikasi dengan cara yang menurut mereka paling cocok untuk mereka adalah masalah besar?

Dalam bentuk saat ini bagi saya yang terbaik adalah tidak memiliki APP VERSION sama sekali. Ini hanya membawa kebingungan bagi orang-orang dalam proyek kami. Kami memiliki >80 layanan yang menggunakan diagram kemudi yang sama dan karena tidak mungkin mengubah APP VERSION di helm upgrade -i ... Saya melihat bahwa semua aplikasi kami akan selamanya tetap dengan 1.0 sini. Dan saya tidak berencana untuk mengemas ulang bagan yang sudah dikemas untuk hanya mengubah versi aplikasi. Mengapa saya harus memperumit CI saya agar sesuai dengan desain Anda???

Saya juga melihat bahwa saya hanya perlu mengatakan kepada semua orang untuk tidak menggunakan helm list karena itu akan menjadi sesuatu yang tidak berguna bagi mereka. Untuk memeriksa versi aplikasi mana yang mereka miliki, mereka perlu menggunakan sesuatu yang lain.

Saya optimis pada awal membaca percakapan ini tetapi setelah sampai akhir melihat bagaimana Anda membahas ini dan bagaimana Anda berjuang untuk memaksa pengguna untuk memiliki cara berpikir Anda, saya kehilangan harapan sekarang :(.

Memiliki dua output berbeda "CHART(version)" dan "APP VERSION" di helm list , helm history dan sejenisnya sangat membantu dan menghindari kebutuhan untuk menggali lebih dalam opsi baris perintah dan parsing output untuk mendapatkan fakta yang paling penting.

Jika "CHART(version)" dan "APP VERSION" terikat pada waktu pembuatan ("helm package"), seluruh manfaat dari memiliki dua nilai yang berbeda agak hilang. Membangun bagan dan memperbarui VERSI APLIKASI tanpa menambah/memperbarui VERSI BAGAN akan menghasilkan masalah besar karena VERSI BAGAN yang sama akan memberi Anda hasil yang sangat berbeda. :-<

Jadi untuk saat ini kami dipaksa untuk membangun paket dengan setiap rilis dan peningkatan "GRAFIK (versi)" dan "VERSI APLIKASI" secara sinkron agar tidak mengalami situasi yang gila/tidak jelas.

Seperti yang baru saja saya pelajari, kita dapat menghapus "VERSI APLIKASI", karena ini opsional dan menggunakan beberapa nilai khusus dan menggunakannya sebagai ganti {{ Chart.appVersion }} untuk gambar kita.... tetapi kemudian helm list akan menjadi kurang informatif. :-<

Dari Perspektif Pengguna (Pengembang):

• kemampuan untuk mengatur beberapa properti versi/bendera/nilai pada waktu penginstalan
• kemampuan untuk melihat properti versi/bendera/nilai itu dalam daftar helm/output riwayat dengan label "versi XX"

Adakah kemungkinan kita bisa menyelesaikannya?

Jika "CHART(version)" dan "APP VERSION" terikat pada waktu pembuatan ("helm package"), seluruh manfaat dari memiliki dua nilai yang berbeda agak hilang.

Saya pikir ini adalah inti dari disalignment. Manfaat Versi Aplikasi saat saya menggunakannya, dan seperti yang tampaknya dimaksudkan oleh pengaturan saat ini, adalah Anda mengetahui versi Aplikasi yang dibungkus _untuk versi bagan itu_, karena Versi Bagan adalah versi keseluruhan bagan, bukan versi versi template dalam bagan. Saya tidak suka setiap pernyataan seperti "Kami membutuhkan Versi ~XY dari bagan Helm" untuk meminta "Oh, dan jangan main-main dengan AppVersion" ditambahkan di akhir.

Manfaat ini hilang dari Versi Aplikasi (dan versi aplikasi yang sebenarnya) berubah pada waktu penginstalan, karena sekarang Versi Bagan tidak memberi tahu Anda Aplikasi apa yang Anda gunakan, dan Anda kehilangan kemampuan untuk menggunakan SemVer untuk memastikan, misalnya, Anda memiliki rilis terbaru yang kompatibel dengan API.

Untuk kasus penggunaan yang dijelaskan oleh @pniederlag , dapat membuat appVersion menjadi templat yang menunjuk pada entri Nilai akan membuat helm list melakukan apa yang diinginkan, selama Bagan mendukung memilikinya versi aplikasi (mungkin tag penampung) diubah pada waktu penginstalan, melalui --set atau --values seperti setiap opsi konfigurasi "berubah pada waktu penginstalan".

Di sini saya mendapat masalah dengan AppVersion .

Kami menggunakan versi Rilis dan AppVersions.

Untuk mengaturnya sekarang - saya harus memanggil helm package secara eksplisit sebelumnya dari helm upgrade --install untuk membuat arsip tar lokal dengan kedua versi sedang disetel.

Sekarang saya menambahkan dukungan helm-secrets , dan...
Dan pembungkusnya tidak dapat berfungsi dengan helm package !

Jadi bagaimana sekarang?
Jatuhkan semua dukungan dan aliran versi kami?
Jatuhkan menggunakan Rahasia?
Ada ide?

Sebenarnya ini lebih merupakan masalah untuk helm-secrets , tetapi ini terkait dengan kemampuan --set app-version dibahas di sini juga, karena jika saya dapat menggunakannya dengan cara ini - saya tidak perlu memanggil helm package sama sekali.

UPD Oh, tunggu... Saya masih bisa menggunakan helm secrets upgrade chart.tgz -f secrets.yaml ...
Oke.
Tapi tetap saja, +1 untuk menambahkan --set app-version .

Jadi bagaimana sekarang?
Jatuhkan semua dukungan dan aliran versi kami?
Jatuhkan menggunakan Rahasia?
Ada ide?

Kami membangun dua paket: paket helm hanya dengan bagan, tanpa nilai env dan file rahasia. Kami mengganti nama paket ini menjadi chart-{app-version}.tgz karena versi grafik tidak berarti apa-apa bagi kami, versi grafik juga tidak mendukung sintaks versi aplikasi kami. Pembaruan aplikasi kami mencakup pembaruan grafik potensial (repo yang sama, menggunakan penandaan git).

Kemudian kita memiliki tgz kedua yang spesifik untuk lingkungan, chart-{app-version}-{env}.tgz yang menyertakan bagan tgz, nilai yaml, dan file rahasia terenkripsi. File ini juga menyertakan "package.yaml" yang berisi nilai seperti tag, aplikasi, dan nama lingkungan untuk skrip otomatis kami untuk diterapkan menggunakan helm-secrets .

Kami terbiasa mengidentifikasi versi aplikasi kami, atau sebagian besar, dengan nomor versi semantik. Kemudian gunakan gunakan nomor ini di VERSI APLIKASI untuk mengidentifikasinya dengan mudah di daftar helm history untuk rollback atau operasi lainnya.
Karena sistem tidak mengizinkan untuk menginjeksinya secara otomatis dalam waktu penerapan, kami menjalankan perintah sederhana ini secara otomatis pada saluran CI/CD kami sebelum perintah penerapan:

sed -i -E "s/^appVersion: (.*)/appVersion: ${deploy.project.version}/" ${chartPath}/Chart.yaml

Ini rumit, tetapi berfungsi seperti yang diharapkan.

@bvis
Masalah dengan solusi Anda adalah Anda harus mengedit bagan di saluran CI/CD Anda.
Jika Anda menggunakan repo bagan terpusat, maka Anda dipaksa ke helm pull repo/chart --untar

Adakah kemajuan lebih lanjut dengan menyuntikkan Chart.yaml/appVersion secara terprogram? Apakah ada solusi? Ini akan memberikan dorongan luar biasa di CI/CD Helm .

@jakovistuk sejauh yang saya tahu, bagan yang menggunakan appVersion untuk menampilkan versi wadah melakukan ini secara langsung melalui Chart.yaml, seperti yang terlihat di nginx-ingress/Chart.yaml misalnya...

Saya belum terlalu memikirkan masalah ini selama beberapa waktu, jadi ini mungkin pertanyaan yang sangat bodoh, tetapi apakah ada cara untuk menggunakan Helm CLI untuk mengesampingkan appVersion?

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

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 ketika memperhitungkan perubahan OCI yang menurut saya akan membuat ini lebih sulit untuk diterapkan.

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.

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}" \
       --set-string ingress.enabled="${INGRESS}" \
       --set service.port="${CONTAINER_PORT}" \
       --set service.targetPort="${CONTAINER_PORT}" \
       --set dc="${CI_ENVIRONMENT_NAME}" \
       --set project="${CI_PROJECT_NAME}" \
       --namespace ${NAMESPACE}
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

Jika Anda default image.tag ke {{ .Chart.AppVersion }} maka Anda tidak perlu --set selama instalasi, itu sudah benar. Ini juga berfungsi dengan baik untuk pembuatan otomatis, ketika gambar Docker Anda ditandai dengan SHA1 sehingga AppVersion cocok dengan tag gambar Docker, dan Versinya adalah SemVer pembuatan otomatis.

Tidak ada masalah dengan Versi yang sama dengan AppVersion jika AppVersion Anda adalah SemVer.

Untuk paket yang diproduksi oleh tim saya, kami bergerak menuju hal-hal yang mencari AppVersion, misalnya image.tag, default ke Versi jika AppVersion tidak disetel. Ini bukan perbedaan besar, hanya satu argumen lebih sedikit ke helm package untuk rilis yang diberi tag, tetapi hanya masuk akal jika bagan Anda dibuat dari SCM yang sama dengan yang Anda kemas.

@TBBle itu tidak akan berfungsi jika Anda menggunakan sub-bagan untuk mengatur tag gambar Anda

Maksud Anda image.tag ada di dalam subbagan, tetapi Anda mencoba menggunakan versi bagan induk? Jika demikian, ya, itu sangat canggung, dan tidak akan mudah diatur. Saya baru saja memantulkan tata letak ini di https://github.com/googleforgames/open-match/ 's Helm charts. Saya sarankan menggulirkan sub-grafik yang dimaksud kembali ke dalam bagan utama dalam kasus ini.

Bagan harus diisolasi secara independen/unit yang dapat digunakan, tidak bergantung pada perilaku bagan induk untuk berfungsi. Subchart memiliki versinya sendiri, _that_ yang harus digunakan oleh gambarnya, jika tidak, mengapa subchart?

Dalam kasus Open Match, subchart tampaknya digunakan sehingga XXX.enable dapat digunakan sebagai jalan pintas di values.yaml untuk menonaktifkan banyak hal sekaligus, tetapi kemudian memunculkan banyak masalah struktural seperti ini . Semua subbagan Open Match menggunakan bagan induk bernama templat, dan juga memiliki versi lokal 0.0.0-dev , jadi sudah ada dua kode-bau bahwa ada sesuatu yang tidak terstruktur dengan baik.

Atau mungkin saya salah memahami pengamatan yang Anda buat.

@haimari Sayangnya, ini tidak berfungsi (terkait dengan https://github.com/helm/helm/issues/6921 ?):

> helm package $DIR/deployment/chart --app-version="1111e8" --version="3454e5" --namespace stage
Error: Invalid Semantic Version

Tapi, ini berfungsi:

> helm package $DIR/deployment/chart --app-version="0.0.0-1111e8" --version="0.0.0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0.0.0-3454e5.tgz

dan bahkan ini (tetapi tampaknya kotor):

> helm package $DIR/deployment/chart --app-version="0-1111e8" --version="0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0-3454e5.tgz

versi helm versi.BuildInfo{Version:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"dirty", GoVersion:"go1.15.3"}

Saya pikir solusi @haimari apa adanya hanya berfungsi karena mereka menggunakan tag yang kompatibel dengan semver dalam pipa CI mereka (yaitu ini akan menjadi contoh untuk menjalankan pekerjaan untuk rilis yang ditandai, tidak dijalankan pada setiap komit)

@a0s : Saya biasanya menyarankan:

helm package $DIR/deployment/chart --app-version="<container image tag>" --version="<semver version>"

Dan kemudian buat nilai tag gambar wadah Anda menjadi seperti {{ Values.image.tag | default .Chart.AppVersion | default .Chart.Version , sehingga Anda tidak perlu mengubahnya saat itu juga, seperti yang dilakukan @haimari .

Dalam contoh Anda, Anda memiliki apa yang tampak seperti dua versi git yang berbeda, apakah itu benar? Apakah satu untuk gambar wadah, dan satu untuk bagan?

Dengan SemVer, Anda tidak dapat benar-benar memasukkan git commit SHA ke dalam bagian semver yang bermakna, karena semver menyiratkan pemesanan, dan git commit SHA tidak dapat diurutkan.

Jadi, Anda akan ingin menggunakan versi seperti 0.0.1-alpha.<build-id>+g<gitcommitsha> mana <build-id> mirip seperti pipeline atau ID pekerjaan dari sistem CI Anda, jadi Anda selalu berkomitmen pada proyek Anda. Dengan begitu Anda selalu mendapatkan build terbaru saat Anda memintanya.

Di SemVer, menggunakan - berarti ini adalah pra-rilis untuk versi tersebut, jadi 0.0.1-<anything> berada di antara rilis 0.0.0 dan 0.0.1. Bagian setelah + adalah build-info, dan diabaikan untuk pengurutan, oleh karena itu tempat yang baik untuk meletakkan git SHA atau nama cabang atau informasi pelacakan lain yang tidak dapat diurutkan.

Jadi dengan apa yang telah Anda gunakan di sini, 0-3454e5 akan tampak lebih baru daripada komit berikutnya, jika SHA-nya dimulai dengan 2 , misalnya 0-2764e1 .

Dalam contoh Anda, Anda memiliki apa yang tampak seperti dua versi git yang berbeda, apakah itu benar? Apakah satu untuk gambar wadah, dan satu untuk bagan?

Ya, aplikasi dan bagan - ada dua perangkat lunak independen.

Dengan begitu Anda selalu mendapatkan build terbaru saat Anda memintanya.

Bagaimana jika saya tidak ingin (dan bahkan tidak bisa membayangkan) meminta yang terbaru.

0.0.1-alpha.<build-id>+g<gitcommitsha>

String ini (setelah interpolasi) tampaknya terlalu panjang untuk dimasukkan ke dalam satu kolom output standar helm list :)

Saya selalu tahu versi (sha hash) aplikasi yang ingin saya instal (teruskan dengan --set args). Dan saya selalu tahu versi grafik apa yang saya gunakan (seperti yang dijelaskan @haimari , saya akan selalu menggunakan git checkout chart && helm pack && helm upgrade .tar.gz secara lokal di ci/cd saya)

Apa yang bisa salah?
1) Kesalahan selama helm upgrade reguler. Oke, saya akan memperbaiki kesalahan dan mencoba lagi (dengan komit aplikasi lain - 99%) (atau menggunakan --atomic sebagai gantinya)
2) Penggulungan kembali manual: helm rollback <RELEASE_NAME> atau penerapan sebelumnya harus dilakukan melalui CI/CD.

Apa yang saya lewatkan?

PS Sejujurnya, saya ingin menggunakan bagian sha pendek dalam versi dan versi aplikasi hanya untuk tujuan informasi (selama helm list )

Jika hanya untuk tujuan informasi, maka ia akan mengikuti + dalam SemVer, bukan - . Jika Anda _tidak pernah_ peduli tentang pemesanan rilis, atau mendistribusikan bagan Helm kepada siapa pun, dan bagan atau aplikasi Anda belum SemVer, maka 0+g<commitsha> adalah SemVer yang valid (setara dengan 0,00).

Inilah yang dilakukan oleh bagan yang dibuat secara otomatis oleh Open Match, misalnya; mereka semua saat ini 0.0.0-dev , dan kami telah mulai melihat pembuatan 0.0.0-dev+g<commitsha> sehingga jika Anda melihat apa yang telah Anda instal, Anda setidaknya dapat memberi tahu _yang_ master build yang Anda miliki.