También me encontré con esto. Normalmente quiero que la etiqueta de la imagen se especifique en el momento de empaquetar el gráfico, pero para depurar la aplicación quería hacer una instalación con una etiqueta diferente.

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Traer esto a colación de nuevo como se planteó en https://github.com/kubernetes/charts/pull/5919

Copiando partes de mi comentario reciente:

Elegimos específicamente mantener la versión secundaria de nuestro gráfico alineada con la versión secundaria de la aplicación (aunque los números de la versión del parche pueden, y se desvían).

Esto se debe a que podemos agregar una nueva bandera a una nueva versión de cert-manager, y al agregar soporte para ella en el gráfico de Helm rompería la compatibilidad con versiones anteriores de cert-manager, ya que no admiten la bandera. Esta es una pregunta bastante fundamental sobre las versiones de gráficos de Helm en general, en mi opinión, y para la que no tenemos una buena historia.

Sé que no se recomienda intentar alinear appVersion con la versión del gráfico, pero de esta manera, un usuario sabe que puede usar la versión 0.3.x del gráfico Helm con cualquiera de cert-manager 0.3.xy la versión 0.4.x del gráfico con cert -gestor 0.4.x. La compatibilidad se define dentro de la versión secundaria.

/ remove-lifecycle stale

Me gustaría volver a traer esto para discutirlo.

En general, no hemos visto mucho a favor de la creación de versiones de los gráficos para nuestras aplicaciones internas cuando todo lo que está cambiando es la etiqueta de imagen utilizada por algunos componentes. Al actualizar una versión, el campo appVersion parece el lugar adecuado para esta información.

Copiando mi propuesta original mencionada anteriormente:

Nuestro flujo de trabajo actual para implementar gráficos de helm implica tareas ansibles que llaman al comando de la CLI de actualización de helm y sería bueno poder pasar una bandera para configurar la appVersion al revisar una versión para la misma versión de gráfico.

Puede ser un poco extraño conceptualmente porque una appVersion está asociada con un gráfico en lugar de un lanzamiento, pero en nuestro caso solo estamos actualizando la etiqueta de imagen utilizada para algunos contenedores y nuestro flujo de trabajo no ha llegado a incorporar la versión del gráfico y / o los repositorios de gráficos. aún. Esto puede cambiar en el futuro, pero por ahora no veo ningún problema al agregar una marca para --app-version en la instalación y actualización, ya que el campo es meramente informativo.

al desarrollar nuestras propias aplicaciones internas, la aplicación en sí cambia mucho más que el gráfico que la implementa. Normalmente, nuestro comando de Despliegue Continuo es un helm upgrade con nada más que --set imageTag=<new_version> (obviamente, usado en otra parte del gráfico para configurar la versión del contenedor) Si lo reemplazamos con --app-version daría usamos otro punto visual en helm ls para ver qué versiones de código se implementan junto con la versión del gráfico que se implementa.

Para hacer esto más visible, de lo contrario, he estandarizado la configuración de una etiqueta de metadatos de imageTag que se establece en el imageTag pasado en la instalación / actualización. Esto me permite usar el tablero de K8s o crear fácilmente tableros de Graphana con imageTag mostrado, pero requiere que deje la línea de comando y haga clic con el mouse.

¿Alguna noticia sobre esto?

Gracias

Algún avance en esto. Parece que las relaciones públicas de @Eraac hacen lo que se solicita. Como mencionó @ TD-4242, también ejecutamos helm upgrade --set imageTag=<imagetag> , sin embargo, esto no actualiza la VERSIÓN DE LA APLICACIÓN listada en la salida de helm ls . Ser capaz de --set app-version o --set version nos permitirá ejecutar helm upgrade manera que helm ls muestre correctamente la versión implementada.

¿Alguna actualización?

¡Aaaa cualquier momento pronto sería maravilloso!

será muy útil

También me encantaría poder configurar la versión de la aplicación en el momento de la instalación, ya que usamos gráficos comunes para implementar aplicaciones.

+1

+1

Sería muy útil

Solicitando lo mismo

Detenga el spam con el +1. Ya existe un PR (https://github.com/helm/helm/pull/4961) y la gente está discutiendo la propuesta. La última respuesta fue incluso hace 2 días.

Hola @filipre

Ya hay un PR (# 4961) y la gente está discutiendo la propuesta.

Según ese PR, esto se movió aquí:
https://github.com/helm/helm/pull/5492
Este es el último PR para # 4961 y parece que si estamos esperando una revisión para fusionar ...

@filipre ¿Podría decirnos qué pasa con las relaciones públicas? Parece que las relaciones públicas no se mueven la mitad del mes

Sería muy útil. Me encontré con algo que necesito anclar a la versión 0.6.0 de una aplicación, y la versión del gráfico no tiene relación con la versión de la aplicación.

Estoy de acuerdo, también creo que esto sería muy útil. ¿Alguna actualización?

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

Simplemente golpeé este problema ahora cuando me di cuenta de que esto sería un problema mientras escribía un gráfico de Helm que planeamos reutilizar para muchas aplicaciones. Dada la falta de progreso en la resolución de este problema de una manera simple (es decir, con la marca para configurar la versión de la aplicación en la instalación), se me ocurrió una alternativa que debería funcionar por ahora. Realmente es súper simple: simplemente haga un helm fetch primero con la opción untar, y luego helm package con la bandera --app-version que existe allí, luego proceda a instalar ese gráfico local.

No es ideal, pero el resultado final en helm list es correcto y es muy sencillo hacer esto en un servidor CI. Sin embargo, me encantaría tener --app-version disponible en helm install y helm upgrade .

El resumen de la discusión en # 5492 fue que un comando que envuelve la lógica de helm package y helm install resolvería el caso de uso descrito originalmente en este número.

En otras palabras, puede solucionar este problema ejecutando lo siguiente:

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

(Moviendo el comentario de relaciones públicas cerradas recientemente aquí, para que no termine en Nirvana)

Aquí están mis 2 centavos en esto:
Suponiendo que tenemos un timón chart version X implementando un servicio con appVersion Y .

El gráfico de timón se usa para describir la infraestructura dentro de Kubernetes en chart version X que se usa para alojar un servicio de appVersion Y .

Durante el desarrollo inicial, tanto X como Y cambiarán regularmente. Sin embargo, en algún momento X será más o menos estable y Y continuará cambiando (a menos que Y tenga algunos requisitos nuevos para la infraestructura, lo que probablemente suceda con mucha menos frecuencia en el ciclo de desarrollo de Y ).

Con el enfoque propuesto en este ticket, uno podría tomar un paquete de gráficos de timón estable en la versión X para implementar una aplicaciónVersion Y , Y+1 , Y+N , etc.

Sin embargo, no permitir que esta bandera se anule durante la instalación o actualización de helm y, en su lugar, solo en, por ejemplo, el paquete, vincularía efectivamente tanto X como Y obligándome a crear siempre un nuevo X+1 por Y+1 . Esto me parece innecesario y daría como resultado una tonelada de paquetes de timón que efectivamente no han cambiado, aparte de que hacen referencia a un nuevo appVersion . Desde mi perspectiva, una versión de una aplicación y una versión de la infraestructura que aloja esa aplicación tienen una relación, pero deberían o podrían tener una versión independiente. La forma en que se hace debe dejarse en manos de los respectivos equipos de desarrollo.

Resumen:

Este enfoque definitivamente funciona, pero también da como resultado una gran cantidad de paquetes Helm innecesarios donde solo ha cambiado AppVersion :
$ helm package myapp --app-version 1.0.0 $ helm install myapp-1.0.0.tgz

Sí, pero supongo que no es un gran problema si adoptas el enfoque que mencioné anteriormente. Empuje su gráfico a un repositorio de gráficos sin una versión de la aplicación configurada (o 0.0.0 o algo así), luego, cuando quiera usarlo, use helm fetch , luego empaquételo con la versión de la aplicación correcta, luego use el local .tgz file y no empuje ese gráfico. De esa manera, su repositorio de gráficos se mantiene limpio y solo tiene los cambios de gráficos reales representados allí.

Sí, funcionaría. En este caso, uno nunca podría consumir directamente el artefacto de implementación (por ejemplo, instalando directamente desde el repositorio de Helm), pero siempre tiene que enviarlo a través de un paso adicional que muta el artefacto.

Donde se argumentó que Charts.yaml debería ser inmutable, yo sostengo que el artefacto de implementación debería serlo.

_Resumen mis pensamientos de https://github.com/helm/helm/pull/5492#issuecomment -520029902_

Existe un problema en cómo la comunidad interpreta el paquete, el gráfico y las versiones. @BenjaminSchiborr , espero que esto tenga sentido para ti.

Chart : es un código fuente de su lanzamiento. Como un código fuente de su aplicación. Consta de plantillas, archivos de código.
Paquete : es una compilación de su lanzamiento, artefacto. Como un binario, construido a partir de su código fuente. Consta de versiones de producción fijas: versión de gráfico y versión de aplicación.
Versión : es una compilación, implementada con una configuración especificada.

No hay forma de que puedas hacer un lanzamiento de Chart . ¡Simplemente no funciona de esta manera!

Antes de implementar su aplicación en el escenario, necesita tener un gráfico. Luego, debe empaquetar su aplicación con un gráfico, arreglando ambas versiones, usando helm package . Dará como resultado un paquete, que se puede implementar en cualquier escenario. Luego, instala este paquete, por ejemplo, en la etapa QA, promocionándolo en UA y luego en Producción, usando helm install .

Es la forma en que funciona cualquier software orientado a paquetes.

La confusión

helm install necesita una fuente, que debe estar instalada. La fuente podría ser:

1. Nombre del paquete, disponible en el registro
2. Ruta del archivo del paquete, si el paquete ya está descargado o creado
3. URL del paquete, si está disponible mediante HTTP
4. Ruta del directorio de gráficos

El cuarto enfoque se siente como una oveja negra aquí, ¿no crees? Es por eso que las personas confunden Paquete y Gráfico. Y esta es la raíz de los problemas.

Razonamiento

Hay dos tipos de aplicaciones en la naturaleza:

Grande / mediano : aquí es donde tenemos tiempo, dinero y recursos para configurar flujos detallados y granulares para una mejor introspección y garantías de calidad.
Pequeño : un microservicio, proyecto mascota, PoC, proyectos de bajo costo, proyectos sin conocimiento de DevOps o incluso pruebas de procesos de desarrollo de timón.

Con proyectos pequeños, no tienes tiempo ni necesitas crear o lidiar con empaques. ¡Quiere escribir algunos archivos de plantilla e implementarlos con un comando !

Es por eso que helm install permite tal uso, como helm package & helm install . Pero no proporciona capacidades helm package , como --app-version .

helm install puede ser helm package & helm install , pero haría helm install un desastre, un infierno para el soporte, las pruebas y las buenas prácticas.

Propuesta 1

Simplifica helm install . Debería permitir que solo se proporcionen paquetes, para simplificar la base de código, las pruebas y hacerla obstinada, para simplificar la comprensión de helm .

Propuesta 2 - helm run

Introduzca un nuevo comando: helm run . Un comando, que debería funcionar . Ideal para aplicaciones pequeñas. O tal vez incluso mediano y grande.

Debería combinar helm package y helm install , proporcionando capacidades de ambos comandos, excluyendo los que no tienen sentido en tal caso de uso.

helm package crea una compilación, como lo hace go build . go run permite iniciar la aplicación sin el proceso de construcción, por lo que helm run parece un nombre sólido aquí.

Cosas adicionales a considerar:

• ¿Debería usar upgrade --install lugar?
• ¿Debería tener --atomic habilitado de forma predeterminada?

@iorlas ,
sus comentarios tienen sentido. Sin embargo, está asumiendo que solo puede haber un paquete final que vincula de manera heredada tanto la versión de infraestructura como la versión de software, mientras que supongo que tengo un paquete para mi versión de software y un paquete para mi infraestructura y quiero atarlos en una versión (por ejemplo, a través de una configuración de estado deseada que hace referencia a la versión del software y la versión de la infraestructura).

No veo por qué un proceso de desarrollo debería forzarse en ese patrón donde también podría dejarse a los grupos de desarrollo responsables decidir si quieren unir la infraestructura y la versión de software en el nivel del paquete del timón o más tarde. Actualmente, un proceso de implementación siempre debe utilizar nuevos paquetes de timón, mientras que solo cambia la versión del software. Esto da como resultado miles de paquetes inútiles en un repositorio para mí.

Estoy bien si esto tiene alguna ventaja a largo plazo. Simplemente no lo veo.

@BenjaminSchiborr Está bien, déjame desglosarlo un poco.

Puede tener su Chart (== infraestructura), que tiene la versión X .
Puede tener su aplicación, versión Y .

Cómo funciona helm este momento, une la infraestructura y las versiones de la aplicación en el paso helm package . Luego, debe vincularlo con el espacio de nombres k8s, produciendo Release.

Entonces la fórmula es: package(infra + app) + k8s = Release

Lo que realmente desea es omitir este paso intermedio y unir los 3 componentes en un solo paso: Liberar. Así: infra + app + k8s = Release . ¿Estoy en lo correcto?

Esto es lo que hará helm run , en la superficie. Debajo del capó, será lo mismo.

Pero ... siento que puede estar perdiendo el sentido de Helm . Aunque cualquier herramienta puede usarse como le plazca al usuario, siempre hay una idea que influye en la comunidad, crea un "camino", por lo que un telescopio no terminará como un tarareador con capacidad para elaborar una cerveza.

Permítanme tratar de describir cómo se debe usar y sería increíble verlo desde su perspectiva.

Helm en sí se creó para abstraer las plantillas y la implementación de k8s, unir la aplicación y la infraestructura, con sus dependencias: en lugar de reescribir manualmente las plantillas, aplicarlas en K8 y luego proporcionar una nueva etiqueta de imagen, solo necesita un comando: helm upgrade . Como un paquete MSI o deb.

Cuando necesite instalar una nueva versión de la aplicación o degradarla, se supone que debe usar helm para ello. En lugar de administrar la aplicación, administra el paquete completo. Sería una molestia revertir la versión de la aplicación y la infraestructura por separado cuando algo sale mal; he estado allí, no se lo recomendaría a nadie.

Entonces, es lo correcto tener muchos paquetes en su registro, ya que el paquete no es la infraestructura, el paquete es la aplicación, porque la aplicación no significa nada en K8s sin infraestructura.

Si su problema es que tiene demasiados paquetes en el repositorio, le sugiero que use artefactos en lugar de repositorios. Lo hago así en CI: compile la aplicación, envíela al registro de Docker, cree el paquete, guárdelo como artefacto para su lanzamiento. CircleCI, Travis, Azure Pipelines admiten la creación de archivos adjuntos para compilar como artefactos. ¿Puedes hacer lo mismo?

Quizás me estoy perdiendo el punto de Helm. Quizás Helm ha perdido un punto aquí. Creo que este boleto se trata de evaluar precisamente eso. Y personalmente, también sobre expandir mi horizonte :)

Pero sí, de manera abstracta lo que dices es correcto. No quiero que la versión del software esté acoplada al paquete / lanzamiento de helm, por lo que esencialmente es infra + app + k8s = Release . Igual que no quiero que las propiedades de mi versión de software estén vinculadas a mi versión / paquete de timón (aparte de tal vez un valor predeterminado que pueda anular).

Respecto al ejemplo que proporcionas más abajo. No veo cómo esto muestra cómo este enfoque es problemático. Seguiría usando el timón para retroceder o avanzar. Si cambia la infraestructura, usa una versión de carta de timón modificada. Si cambia la versión del software, usa una versión de aplicación diferente. Si un parámetro cambia, usa un parámetro diferente. Siempre sería una llamada de timón (única) por servicio.

¿Puedes dar más detalles?

Si su problema es que tiene demasiados paquetes en el repositorio, le sugiero que use artefactos en lugar de repositorios.

A lo que me refería era a demasiados gráficos de timón empaquetados (que ya incluyen appVersion). Piense en ello como una versión de gráfico de timón que es estable y una versión de aplicación que cambia cientos de veces al día. Así que, diariamente, unos cientos de gráficos de timón empaquetados por servicio en un repositorio que luego es consumido por una automatización.

(Mis canalizaciones generalmente se ven iguales a las suyas: Build App -> Imagen de Docker (resultados en appVersion) -> gráfico de paquetes (con appVersion actualizada) -> ¿empuja al repositorio?

Creo que este boleto se trata de evaluar precisamente eso.

¡Con seguridad! En mi opinión, ya tenemos demasiados niveles de abstracción, por lo que tener un timón aquí abruma un poco 😄Además, hay operadores k8s aquí, que se crean para algunos (¿quizás la mayoría?) De los problemas que resuelve Helm. Pero ese es un tema para otro momento, jeje.

Piense en ello como una versión de gráfico de timón que es estable y una versión de aplicación que cambia cientos de veces al día. Así que, diariamente, unos cientos de gráficos de timón empaquetados por servicio en un repositorio que luego es consumido por una automatización.

Sí, definitivamente se siente demasiado, pero está intencionado. Por ejemplo, tiene una ejecución de compilación, debería producir algunos artefactos, luego guárdelo para usarlo para implementarlo en el escenario. Como ... ¿cómo podemos ejecutar una compilación que no tiene un resultado de compilación? ¿Debemos generar la compilación cuando la implementemos? Realmente estaría mal. Aunque algunas canalizaciones de CI hacen eso para las compilaciones JS.

El mismo problema que tenemos con la ventana acoplable: cada compilación genera una nueva imagen de la ventana acoplable, que entra en el registro de la ventana acoplable. Necesitamos guardarlo, ¿cómo se supone que lo desplegaríamos entonces, si no lo tuviéramos?

Por supuesto, podemos docker save para ahorrar espacio en el registro y barrer más tarde en la política de retención de los artefactos de compilación. Pero entonces podemos helm package y mantenerlo como un archivo.

Pero definitivamente veo su punto, podemos tener un "instalador", que puede aceptar una versión de la aplicación. Dado que dicho instalador tiene infraestructura, puede mantenerlo igual, simplemente cambiando la versión de la aplicación. Parece ordenado y simple, pero hay un problema.

La aplicación en sí no tiene sentido en el entorno k8s sin infraestructura .

¿Qué pasa si su aplicación se basa en alguna infraestructura? Ejemplo básico: configmap.

¿Qué pasa si necesita revertir la aplicación entonces?
Debería degradar la aplicación, pero luego también deberá degradar la infraestructura.

¿Qué sucede si entonces necesita revertir la infraestructura?
La infraestructura anterior no tiene ni idea de qué versión de la aplicación necesita instalar, ya que no está vinculada a ella. Por lo tanto, debe recordar qué aplicación admite qué infraestructura y configurarla manualmente.

Realmente, eso sería un infierno. Y es un infierno ahora mismo, cuando no tienes el timón. Y no está mal. Pero en ese caso, tienes pocas razones para usar Helm.

ya tenemos demasiados niveles de abstracción
Todo lindo y simple guiño.

Creo que tu último punto es muy convincente:

La infraestructura anterior no tiene ni idea de qué versión de la aplicación necesita instalar, ya que no está vinculada a ella
Definitivamente, esto es un problema si desacopla estas cosas y tiene el paquete / lanzamiento de Helm como la fuente de la verdad.

Sin embargo, para muchas personas probablemente este no sea el caso. Hay una orquestación en la parte superior de Helm (sí, otra capa de abstracción) que une varios gráficos de timón (y appVersions) (Piense en timonel, arnés o similares). Y esa capa en sí también está versionada. En ese caso, lo que describa ya no es un problema, porque no volvería a una versión anterior de un gráfico de timón, sino a una versión anterior de la capa de orquestación (que tiene sentido para la aplicación y la infraestructura).

Pero el timón solo, sí, 100% un problema 💣. Creo que esa es la razón por la que la idea era permitir explícitamente anular la versión de la aplicación y, de forma predeterminada, no permitirlo.

Una cosa que me gusta de acoplar la versión del gráfico y la versión de la aplicación es que queda claro qué versión de la aplicación pertenece a qué gráfico. Si necesita volver a implementar una versión específica, no es necesario que recuerde qué versión de la aplicación era compatible con qué versión del gráfico. Debido a que están vinculados entre sí, simplemente consulte la versión correcta del gráfico y estará seguro de que la aplicación y el gráfico coinciden. Creo que esto es básicamente lo que describió @iorlas , ¿verdad?

Al final, la versión del gráfico actuará como una "super" -versión:

• cualquier cambio (independientemente de si cambió la aplicación o la infraestructura, es decir, el gráfico) dará como resultado una nueva versión del gráfico, es decir, la nueva versión de la aplicación implicará que la versión del gráfico también cambió
• una nueva versión del gráfico no implica que la versión de la aplicación haya cambiado

Para fines de documentación (y tal vez otras ideas sofisticadas), podría introducir usted mismo otra versión de "solo gráfico" que solo se referirá a la definición del gráfico en sí.

@filipre
¡Sí, sí! Así es como se supone que funciona Helm, según las decisiones de diseño de arquitectura actuales. Como yo lo veo.

El problema es que a veces se siente extraño: demasiado para la configuración y la idea cuestionable de tener una aplicación y una infraestructura unidas. Entonces, ¿es el enfoque correcto? Esa es una pregunta.

@BenjaminSchiborr

Sin embargo, para muchas personas probablemente este no sea el caso.

¡Con seguridad! Incluso los k8 enteros, los contenedores podrían ser demasiado.

Permítanme tratar de desglosarlo desde una perspectiva un poco diferente, tratando de encontrar el problema para el que se creó el timón:

• La instancia de infraestructura es cómo funciona todo el producto: instancias de SaaS, grupos de VM, configuraciones de k8s, versiones de aplicaciones (incluidas bases de datos, herramientas de observabilidad, enrutadores, sidecars e instancias de aplicaciones de productos)
• La instancia de infraestructura necesita una fuente de verdad. Ahora tenemos utilidades como Terraform.
• Demasiadas cosas en una carpeta = difícil. Necesitamos descomponerlo. Hola módulos Terraform.
• Tanto la plataforma como la aplicación en una carpeta = difícil. Necesitamos descomponernos. Hola plataforma y contenedores. K8s interviene.
  
  
  
  1. Por lo tanto, los módulos de Terraform pueden administrar la plataforma, incluida la creación de una capa de contenedores vacía y lista para usar.
  
  
  2. K8s administra los contenedores, lo que permite crear recursos básicos usando YAML
  
  
• Muchos archivos YAML para muchas aplicaciones de K8 (incluidas bases de datos y demás) = difícil. Divídalo en carpetas por aplicación.
  
  
  
  1. Ahí tenemos algunas carpetas como PostgreSQL, Redis, MyPetShop. Cada uno de los cuales tiene archivos YAML para los recursos que tenemos. Y necesita que se configuren las versiones de su aplicación para poder aplicarla en los K8.
  
  
• Hola Helm - instrumento, que permite configurar estas carpetas (llamadas Gráficas), pero más: aplicarlas juntas, deshacer.
• El gráfico parece sólido. Reutilicémoslo apoyando variables. Ahora Chart no es una infraestructura, sino una plantilla de infraestructura.
• El gráfico se ve increíble. Compartámoslo con amigos. Cada vez que actualizamos el gráfico, debemos enviarlo al repositorio de archivos con index.

Entonces, se siente increíble y todo, sin paquetes en absoluto. Por lo tanto, debe aplicar este Cuadro y luego proporcionar la versión de la aplicación. Y debería serlo.

Pero surge el problema: nadie quiere recordar qué Chart se necesita para qué versión de la aplicación. Qué gráfico se actualiza para proporcionar un nuevo valor de configuración para qué versión de la aplicación.

Al final del día, todo lo que queremos es "Configurar myApp versión 1.4.2 como aplicación K8s" , que encapsula todos los riesgos, dependencias y cambios en un artefacto: el instalador de la aplicación, que es apps versions + hooks + setup logic + infrastructure to connect it all . Es por eso que tenemos cosas como MSI, Deb, RPM, incluso NPM, Go mod, Pip, Gem.

Aquí es donde Package entra en escena. Y el paquete, por definición, debe crearse como versión instalable, dentro del flujo de CI / CD. Entonces podemos enviarlo al registro y / o configurarlo en nuestro sistema (clúster k8s).

Y ningún otro proyecto es diferente. Cuando helm install Chart directamente, sin paquete, hacemos lo mismo. Pero en lugar de crear un paquete, lo creamos en un paso diferente. En lugar de construirlo en el proceso de construcción de la aplicación, lo construimos en el paso de lanzamiento. Todavía unimos la infraestructura y las versiones de la aplicación . Implícitamente .

Lo gracioso es:

• Dependencia actualizada = actualizar la versión de la plantilla de infraestructura (gráfico)
• Aplicación actualizada = generar una bifurcación, subconjunto de la plantilla de infraestructura (gráfico) - Paquete, con su propia versión

Aún así, los operadores de k8s deben proyectarse sobre los problemas actuales, por lo que debería haber solo un instrumento, que debería funcionar como operadores, pero proporcionar un proceso de liberación fácil, como lo hace Helm.

¿Alguna idea? Puede que estemos creando algo nuevo aquí, pero mejor

Lo que está describiendo tiene mucho sentido para las aplicaciones que están destinadas a ser utilizadas por otras personas en infra sobre las que no tiene control. Sin embargo, en escenarios empresariales, la creación de paquetes se convierte en una tarea complicada: es posible que tengamos docenas de microservicios estándar, que se implementan en los entornos compartidos o cortadores de galletas, y en virtud de la definición de canalización CI / CD que vive en el repositorio mismo (piense azure-pipelines.yaml), la "versión del paquete" es solo una compilación producida a partir de una versión particular de la rama maestra. Es decir, realmente no necesito almacenar el "paquete" en ningún lugar; mi compilación producirá el mismo paquete, con los mismos bits y las mismas variables que se usan en los mapas de configuración, etc. En escenarios como este, estaré acelerando el gráfico de timón solo cuando cambios en la infraestructura del servicio, lo que ocurre muy raramente. Helm está en esta imagen porque 1) ya tengo que usarlo para implementar algunas piezas de infra (por ejemplo, nginx), 2) no tengo que reinventar la rueda con plantillas k8s yaml.

@wasker

Proyectémoslo, por ejemplo, en docker. La imagen de Docker también es un paquete. Vincula los archivos binarios con la imagen = infraestructura del sistema operativo. Creo que la razón para hacer una imagen de la ventana acoplable cada vez que hacemos una compilación es la misma que para hacer un paquete helm.

Si uno no tiene la necesidad de abstraer todo a las imágenes de la ventana acoplable, no necesita la ventana acoplable y puede vivir con una máquina virtual simple.

Por lo tanto, si intentamos proyectar el uso de la ventana acoplable en helm, usar helm solo como instrumento de infraestructura sería como usar la ventana acoplable solo para crear una imagen inicial y luego actualizar dicha imagen en el host k8s mediante el envío de nuevos binarios. Es malo, el mismo tipo de daño que usar Helm y no volver a empaquetarlo cada vez.

De todos modos, creo, fuimos por el camino equivocado. ¿Alguien usa helm y luego actualiza la imagen manualmente? Creo que tenemos 3 casos de uso generales:

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

@wasker ¿Cuál es el tuyo? Yo creo, no el tercero. Incluso si se trata de una separación real de la configuración de la infraestructura y el control de versiones de la aplicación, sería desagradable trabajar con él. Dado que, significaría que cuando necesite actualizar la infraestructura, perderá todas las versiones. Deberá actualizarlo en Chart, manualmente o kubectl set image para cada implementación.

Entonces, estamos hablando del segundo, helm install chart , "sin el empaque". Entonces, el timón siempre está en la imagen . El problema es que el paquete está compilado, pero en el tiempo de ejecución, cuando implementamos nuestra aplicación. Entonces, la compilación de CI está a cargo de la creación de paquetes, implícitamente, cuando necesitamos implementarlo.

Y si lo proyecta en golang, tal práctica parece enviar código fuente y ejecutarlo como go run en la ventana acoplable, en lugar de construirlo y usar el binario.

Por lo tanto, la verdadera razón para omitir el paso de empaquetado es simplificar el panorama completo para el ingeniero. Lo es

Aquí es donde podemos empezar a hablar. Aquí https://github.com/helm/helm/issues/3555#issuecomment -529022699 está mi propuesta. Agregue helm run y modele como go run .

Si realmente necesitamos dividir la infraestructura y el control de versiones de la aplicación , eso significaría usar helm solo para actualizar / inicializar la infraestructura. Incluso aunque me gustaría ver una forma de hacer esto, puedo ver la que no agregará dolor de cabeza a las actualizaciones. Podemos ignorar las versiones de implementación actuales y esas cosas ... pero creo que está tan mal que sería una pérdida de tiempo crearlo.

Proyectémoslo, por ejemplo, en docker. La imagen de Docker también es un paquete. Vincula los archivos binarios con la imagen = infraestructura del sistema operativo. Creo que la razón para hacer una imagen de la ventana acoplable cada vez que hacemos una compilación es la misma que para hacer un paquete helm.

Supongo que el problema es que si está creando una nueva imagen de Docker, es porque algo dentro de esa imagen ha cambiado. En el escenario que se describe aquí, el contenido del gráfico de timón empaquetado no ha cambiado más que una sola línea: la versión de la aplicación. Esto afecta el resultado final, pero no cambia cómo se comporta el gráfico de Helm por sí solo. Hará lo mismo, de la misma manera, solo que con valores diferentes: el Helm Chart como entidad por sí misma no ha cambiado en lo más mínimo como resultado del cambio de la versión de la aplicación; solo lo que se libera al final tiene.

Puede establecer paralelismos aquí con la capacidad de hacer cosas como usar la configuración para Docker Images. Pasas variables de entorno a una imagen de Docker, esto afecta cómo se ejecuta en tiempo de ejecución y no reconstruyes una imagen para cambiar esas variables. El contenido de la imagen no ha cambiado, pero el resultado final sí: una situación muy similar allí, pero en ese caso el comportamiento es deseable y normal.

Y si lo proyecta en golang, tal práctica parece enviar código fuente y ejecutarlo como se ejecuta en la ventana acoplable, en lugar de compilarlo y usar el binario. [...] Entonces, la verdadera razón para omitir el paso del empaquetado es simplificar el panorama completo para el ingeniero. ¿Lo es?

No desde mi punto de vista. Siendo realistas, el argumento aquí es si las personas consideran o no la versión de la aplicación "parte del gráfico", y también si consideran que un gráfico de Helm es distinto de las imágenes de Docker que se implementan como resultado del gráfico. Mi opinión sobre esto es la que he mencionado anteriormente. Es como tomar un binario Go compilado, en una imagen de Docker, y ejecutarlo con algunas variables de entorno diferentes.

Dicho esto, los argumentos que se han hecho para volver a empaquetar un Helm Chart con una nueva versión de la aplicación y usar la versión Chart como una especie de "superversión" son convincentes (es decir, por la ventaja de tener siempre una versión de la aplicación compatible implementada con un gráfico, siempre que la versión de la aplicación no se pueda personalizar mediante valores).

Mi pregunta es: ¿por qué no apoyar ambos enfoques? Hay pros y contras en cada enfoque. Básicamente, no admitir esto solo dificulta algunos flujos de trabajo perfectamente válidos. Por ejemplo, usando Flux CD y su Helm Operator. Si tiene un gráfico de Helm compartido (es decir, porque tiene un cierto tipo de servicio del que implementa muchos y comparten muchas de las mismas características), para obtener una salida útil de helm list , debe tener un nuevo Helm Chart para cada aplicación, y cada versión también necesita su propio Helm Chart. Esto por sí solo complica las canalizaciones, porque si se pudiera compartir el gráfico, podría tener su propia canalización que solo se ejecutara cuando se actualizara el gráfico, y las canalizaciones de la aplicación ni siquiera necesitarían ejecutar un solo comando de Helm (siempre que Flux CD agregara soporte para una nueva marca de versión de la aplicación en la instalación / actualización).

Mi pregunta es: ¿por qué no apoyar ambos enfoques?

Eso es exactamente lo que estoy pensando.

En mi caso, la "superversión" no es el gráfico de timón sino otra capa que solo usa una plétora de gráficos de timón. Para mí, un solo gráfico de Helm no tiene sentido, ya que describe solo un pequeño servicio entre muchos otros. Solo juntos forman una liberación significativa.
Por lo tanto, en mi caso, la "superversión" es el resumen de todas esas versiones juntas (que es la forma en que realmente se versiona).

Aún así, existe un argumento a favor de tener un gráfico de Helm en sí mismo como la "súper versión" descriptiva.

Volviendo al punto de

Puede ser útil para el debate actual tener una voz externa. Para un poco de contexto, he estado usando helm para una suma total de _11 días. Creo que esto me da una perspectiva única para agregar porque no he estado involucrado en ningún aprendizaje avanzado. Todo lo que he obtenido proviene de la documentación y la experimentación.

Cómo veo Helm

Hasta que leí este debate actual sobre la instalación de paquetes de helm en lugar de gráficos, creía que Helm es principalmente una interfaz para describir los recursos de Kubernetes relacionados. Esta creencia proviene principalmente de la documentación de Helm que dice esto:

Helm instala gráficos en Kubernetes, creando una nueva versión para cada instalación. Y para encontrar nuevos gráficos, puede buscar en los repositorios de gráficos de Helm.

Para el contexto, los documentos actuales de timón estable también establecen:

Un gráfico es un paquete de Helm. Contiene todas las definiciones de recursos necesarias para ejecutar una aplicación, herramienta o servicio dentro de un clúster de Kubernetes. Piense en ello como el equivalente de Kubernetes de una fórmula Homebrew, un Apt dpkg o un archivo Yum RPM.

¡Así que ahora hay algo de confusión! Los documentos de Helm dicen claramente que "un gráfico es un paquete de helm", pero si ese es el caso, ¿por qué diablos helm install acepta repositorios de Chart no empaquetados?

Es este comportamiento el que ha influido en mi visión actual de qué es el timón y cómo se supone que funciona:

Helm actúa como un mapeador entre la estructura de _lo_ que entra en el clúster y _qué propiedades_ tienen esas cosas.

Así que ahora la pregunta es: "¿Qué está implementando Helm?"

¿Qué es Helm Deploying?

Cuando ejecuto helm install release-name ./local_chart espero que helm renderice todas las plantillas de gráficos localmente con los valores especificados (ya sea a través de valores predeterminados o anulaciones) y envíe las versiones renderizadas a Kubernetes. También espero que Helm mantenga los objetos de Kubernetes implementados anteriormente en caso de que retroceda. Este concepto de "una colección de plantillas renderizadas" (que contiene algunos metadatos) es una versión y es un paquete. Todas esas definiciones de recursos (incluso si no cambiaron) deben estar en _su estado descrito en el paquete_ para que exista la versión (o se revierta).

A partir de esto, supongo que helm solo implementa realmente paquetes . Parece ser la única cosa semánticamente correcta que puede decir; sin embargo, el argumento sobre cómo se distribuyen estos paquetes parece ser la causa fundamental de este debate en la práctica. Específicamente, "¿actualizar o cambiar la versión de la aplicación constituye un nuevo paquete?"

Según mi semántica personal, la respuesta a esta pregunta es sí . Siguiendo el argumento de que no aumentaría el número de versión a menos que algo cambiara, solo necesitaría ajustar el número de versión de su aplicación si cambiaran algunas propiedades subyacentes. Esto probablemente implicaría extraer una imagen de la ventana acoplable diferente de un registro, o establecer una marca de característica a través de una variable de entorno, o cualquier cantidad de prácticas diferentes que se pueden usar para cambiar el comportamiento de algún artefacto de código.

Es por esto que comencé a limpiar nuestros registros y nunca implementar desde :latest excepto en desarrollo. El uso de una "metaetiqueta" en lugar de una etiqueta de lanzamiento de una imagen de la ventana acoplable hace que sea imposible vincular una implementación determinada a una base de código determinada. Aprendimos este de la manera difícil (pero afortunadamente en la prueba y no en la producción).

¿Qué patrón se debe utilizar?

Esto ya lo opina Helm: packages .

Dado que este patrón es el patrón obligatorio incluso si no es 100% evidente, parece lógicamente coherente que se proporcione una bandera --appVersion . Responder el "por qué" de esto es probablemente más importante que cualquier otra cosa, así que permítanme concluir mi contribución con esa respuesta.

¿Por qué apoyar --appVersion?

Echemos un vistazo a un caso especial de implementación:

Una empresa tiene una aplicación con dos versiones principales. Algunos de los clientes de esta empresa no se han comprometido a actualizar a la versión principal más reciente de esta aplicación y están utilizando la más antigua de las dos. Debido a los contratos de desarrollo pagados, el desarrollo en vivo todavía se lleva a cabo en la versión principal anterior ... pero el producto es "el mismo". La infraestructura a implementar para ambas versiones de esta aplicación es la misma; sin embargo, la versión de la aplicación será drásticamente diferente entre estas implementaciones.

¿Qué va a hacer esta empresa?

1. Haga dos gráficos de timón separados, casi idénticos, que solo difieran en appVersion ?
2. ¿Utiliza un gráfico de timón pero actualiza constantemente appVersion alternando entre las principales versiones de la aplicación?
3. ¿Reemplazar appVersion con una marca (actualmente no admitida) que conduzca a un posible error del desarrollador en la línea de comando?
4. Alcance appVersion de Chart.yaml y dentro de values.yaml ?

La propuesta 1 introduce un poco más de gastos generales que las otras propuestas, pero también tiene la ventaja de mantener los gráficos para estas versiones de la aplicación separados si divergen. Tiene un caso de uso claro y probablemente se adopte en muchos casos de este problema.

La propuesta 2 tiene menos gastos generales que la propuesta 1, pero presenta una gran variabilidad en un gráfico. ¿Qué sucede si va a ejecutar helm install release-name https://remote-repo.com/chart y la versión más actualizada del gráfico es la versión incorrecta de la aplicación? ¡Ups! Probablemente no sea el mejor enfoque.

La propuesta 3 es lo que estamos discutiendo actualmente. Personalmente, no me gusta la opción, pero solo porque siento que es la solución incorrecta al problema. ¿Hace que appVersion sea configurable? Seguro. Pero también tiene el mismo problema con el que se encuentra cuando ejecuta helm install release-name https://remote-repo/chart : los metadatos son efímeros y SOLO los mantiene Helm.

De hecho, estoy bastante sorprendido de que nadie haya ofrecido la Propuesta 4 o algo así todavía. Pone la appVersion en un estado en el que se puede anular (habilitando algo parecido a helm run ), se puede incluir en el paquete generado por helm package y realmente desenreda el concepto de una versión de la aplicación. desde una versión de gráfico manteniendo el concepto de appVersion acoplado a una implementación de timón (la appVersion tiene que estar en algún lugar, ¿no?).

Espero que esto haya sido de ayuda. 👀 este PR.

@jrkarnes : En cierto sentido 4) ya se ha propuesto y muchas personas lo utilizan como solución alternativa (consulte aquí https://github.com/helm/helm/pull/5492#issuecomment-517255692). Puede usar algo como esto en sus plantillas de gráficos:

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

Esto le permitiría usar appVersion en Charts.yaml como valor predeterminado y anularlo con algo en Values.yaml (que puede anularse durante las llamadas de instalación / actualización). La desventaja es que al hacer, por ejemplo, un helm ls , le mostraría no o un appVersion incorrecto.

@BenjaminSchiborr Gracias por helm durante un tiempo muy limitado, por lo que cualquier conocimiento es un buen conocimiento en este momento para mí.

Creo que mi cuarta propuesta fue un poco malentendida. En lugar de tener algo como {{ default .Values.appVersion .Chart.AppVersion}} , usaría {{ .Values.Helm.AppVersion}} y el values.yaml contiene appVersion lugar de Chart.yaml

@jrkarnes
Eso es lo que estoy pensando ahora mismo. Me gusta, por qué la versión de la aplicación debe tratarse como un copo de nieve único. Es el valor del gráfico.

Razonar detrás de esto es fácil: todo es parte de la infraestructura. Entonces, infra tiene versión. ¿Por qué dos versiones?

Pero estoy demasiado ocupado para pensar en casos secundarios y proyecciones. Pero en general, esa es la pregunta: ¿Por qué necesitamos la versión de la aplicación, cuando en pocas palabras es toda la infraestructura? o ¿Podemos usar la versión de Chart como versión de infraestructura cuando Chart es solo una plantilla de infra, y como versión de aplicación cuando infra incluye la versión de la aplicación?

Lo pensaré un poco más

@jrkarnes
Eso es lo que estoy pensando ahora mismo. Me gusta, por qué la versión de la aplicación debe tratarse como un copo de nieve único. Es el valor del gráfico.

Razonar detrás de esto es fácil: todo es parte de la infraestructura. Entonces, infra tiene versión. ¿Por qué dos versiones?

Fundamentalmente, tiene sentido mantener la versión del gráfico separada de la versión de la aplicación . Un ejemplo rápido es probablemente la mejor manera de demostrar que este es el caso.

Digamos que tiene una aplicación implementada que es ver 4.0.0 ejecutándose en su gráfico con versión ver 1.1.0 . Durante sus operaciones, se da cuenta de que necesitará comenzar a ejecutar una tarea cron para esta aplicación. En lugar de escribir el objeto cronJob y aplicarlo al clúster, se da cuenta de que otras personas que ejecutan este gráfico probablemente también necesitarán la tarea cron ... por lo que la agrega a su gráfico. Su gráfico ahora ha progresado a ver 1.2.0 pero no se ha realizado ningún cambio en la aplicación que administra el gráfico, todavía está en ver 4.0.0 .

Lo inverso de eso también es aplicable y ya es tema de debate en este PR.

Pero estoy demasiado ocupado para pensar en casos secundarios y proyecciones. Pero en general, esa es la pregunta: ¿Por qué necesitamos la versión de la aplicación, cuando en pocas palabras es toda la infraestructura? o ¿Podemos usar la versión de Chart como versión de infraestructura cuando Chart es solo una plantilla de infra, y como versión de aplicación cuando infra incluye la versión de la aplicación?

Lo pensaré un poco más

En lugar de pensar en un caso lateral o una proyección, piense en cosas como MySql, que tiene tres versiones de motor ampliamente utilizadas y compatibles: [5.6, 5.7, 8.0] . Para implementar una instancia mysql en un clúster, siempre tendrá:

• Un pod (s) que ejecutan una instancia de MySql de la versión elegida
• Un servicio que permite la resolución de kube-dns al pod (o pods si se ejecuta en HA)
• Un PV para que los pods escriban sus datos con los PVC adjuntos

El cuadro para implementar MySql 5.6, 5.7 u 8.0 debería ser relativamente el mismo para todas las versiones de Engine (aplicación). La única diferencia real es la versión de la aplicación y la imagen de la ventana acoplable (que probablemente esté etiquetada semánticamente según la versión del motor).

Entiendo lo que quieres decir con preguntarte sobre la "necesidad" de una versión de la aplicación. Creo que eso se reduce a la conveniencia del desarrollador o de las operaciones cuando se ejecuta helm ls o helm inspect .

+1 al último mensaje de @jrkarnes . Es muy valioso mantener las versiones de gráficos y aplicaciones como conceptos separados precisamente porque la versión de gráficos es la "versión de infraestructura".

Si publico el gráfico para que otros lo consuman, se convierte en parte de la infraestructura de los proyectos que dependen de él. Sin embargo, si nunca tengo la intención de que mi aplicación sea consumida por otros, todo lo que me importa es acelerar mi propia versión de gráfico de vez en cuando, cuando el gráfico en sí cambia , pero de lo contrario, solo necesito que la versión de mi aplicación esté en línea con CI / Salida de CD. En este tipo de gráfico de uso, las revoluciones son relativamente raras, pero la versión de la aplicación aumenta con cada ocurrencia de IC. Mi repositorio de código mantiene la relación entre el código y la versión infra que es aplicable para que se ejecute esta versión del código. En otras palabras, en lugar de revertir mi implementación con helm install last-known-good-chart-version , simplemente vuelvo a ejecutar mi canalización de CD con un puntero a un último ID de confirmación válido conocido.

@iorlas He leído tu propuesta por helm run y no tengo problemas con eso. Si bien creo que no es necesario tener la dicotomía instalar / ejecutar, si eso tranquiliza a los encargados del mantenimiento del timón acerca de hacer que la versión de la aplicación sea mutable, estoy de acuerdo con eso. :)

@iorlas ¿Has tenido la oportunidad de pensar qué te gustaría hacer con esta propuesta?

No creo que esté entendiendo cómo funciona la solución alternativa que involucra {{ default .Values.appVersion .Chart.AppVersion}} . Recibo este error:

Error: error al convertir YAML a JSON: yaml: clave de mapa no válida: mapa [interfaz {}] interfaz {} {". Values.appVersion | default \" 0.0.1 \ "": interfaz {} (nil)} [

Aquí está mi Chart.yaml:

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

@IRobL Debe poner este fragmento en templates/deployment.yaml , donde se usa la versión. Los archivos como values.yaml no se tratan como plantillas.

@jrkarnes No soy un mantenedor, así que la última palabra será sobre otros chicos, supongo. Pero de todos modos, estuve bastante ocupado durante las últimas semanas. La próxima semana estaré reevaluando nuestro enfoque actual para administrar helm y su packages .

Usamos el enfoque que describí:

• Helm Chart es parte del repositorio de aplicaciones
• La compilación de la aplicación produce:
  
  
  
  • Imagen de Docker -> registro de Docker
  
  
  • Archivos estáticos -> servicio CDN
  
  
  • Paquete de timón -> Almacenamiento de CI
  
  
• Entonces, el paquete Helm es el artefacto principal, que une todos los artefactos de la aplicación
• En la implementación, install dicho paquete

Preocupaciones actuales:

• Complejidad del proceso de construcción.
  
  
  
  • En lugar de la imagen de la ventana acoplable y los archivos estáticos, se genera un archivo adicional ( helm package )
  
  
  • ¿Cuáles son las razones clave por las que necesitamos algo además del archivo resultante go build / make install ?
  
  
  • ¿Cuánto cuesta?
  
  
  • ¿Por qué aplicar?
  
  
  • ¿Cuándo aplicar?
  
  
• Duración de la construcción
  
  
  
  • Incluso si no necesitamos implementarlo, aún perdemos algo de tiempo y dinero. 2-5 segundos. No mucho, pero el trabajo sin sentido no tiene sentido.
  
  
• Complejidad de las actualizaciones de la plantilla de infraestructura
  
  
  
  • Cuando se actualiza el gráfico, los valores también deben actualizarse
  
  
  • El gráfico es un repositorio, los valores son otro, cada actualización de los valores significa un pequeño dolor de cabeza
  
  

Tal reevaluación podría conducir a simplificaciones e ideas adicionales. Ya veremos :)
Enviaré una actualización más cerca del próximo viernes.

Ah, veo por qué ese truco no funcionaría ahora que me lo indicaste, gracias. Aquí hay un truco que creo que funciona bien para muchas personas que usan Helm 2.x, suponiendo que se sienta cómodo envolviendo su herramienta de timón con este tipo de piezas superiores:

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

@IRobL

En general, si está cerrando una implementación con sed, significa que un motor de plantillas no está haciendo lo que necesita, que es el punto principal de esta discusión.

Cuando gitlab estaba en su infancia y no tenía soporte de helm, literalmente incorporamos valores en los objetivos de reemplazo en un archivo de manifiesto hecho a mano.

Es una mala práctica para algo como esto y le insto a que se aleje de él si es posible.

El 7 de octubre de 2019, a las 3:33 p.m., IRobL [email protected] escribió:

Ah, veo por qué ese truco no funcionaría ahora que me lo indicaste, gracias. Aquí hay un truco que creo que funciona bien para muchas personas que usan Helm 2.x, suponiendo que se sienta cómodo envolviendo su herramienta de timón con este tipo de piezas superiores:

APP_VERSION = 0.0.7
sed -i.bak "s / ^ a ppVersion :. * \\ $ / appVersion: $ APP_VERSION /" helm / Chart.yaml
helm install --nombre helm_demo helm /
-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

@jrkarnes , cuando dices mala práctica, ¿estás diciendo que es indeseable tener que envolver el comando helm con scripting? Si es así, estoy completamente de acuerdo. No estoy diciendo que esté en contra de agregar una bandera --app-version en absoluto; al contrario, creo que sería una adición muy conveniente al timón. Claramente basado en este PR, no soy la única persona que usa helm que quiere mantener la variable appVersion consistente con la compilación real que se está implementando. Sucede que estoy desarrollando una biblioteca de canalización de compilación reutilizable que reúne varias herramientas de compilación para producir compilaciones reproducibles; esta es una práctica común para las grandes organizaciones tecnológicas. En mi caso de uso, la biblioteca de canalización crea los contenedores de la ventana acoplable, los publica y, en última instancia, los implementa a través del timón desde la canalización de compilación de la aplicación (por ejemplo, considere la versión de la aplicación 1.0.1-pr-3.1 para la primera compilación del tercer RP de una aplicación, que es potencialmente una versión preliminar de la versión 1.0.1).

Incluso después de solucionar este problema en la biblioteca de procesos de compilación de mi empresa, definitivamente me sentiría más cómodo si tuviera un conmutador --app-version integrado en Helm; simplemente se siente como una forma más flexible de manejar las implementaciones. Quiero decir, ¿por qué debería un sistema externo o un ingeniero tener que ir al archivo Chart y actualizar un yaml antes de cada implementación si puede ser automatizado por una plataforma de compilación que no pueda estropear los números accidentalmente? Desde mi perspectiva, la funcionalidad appVersion tendría que ser abandonada por completo por mi organización, o el "descuidado" sed tendría que agregarse al código de nuestra biblioteca de canalización, así que pensé en compartirlo por cualquier otra persona que estuviera solucionando este problema.

@IRobL
En general, cualquier utilidad debería ser autosuficiente en su propio nivel de abstracción: debería abstraer el problema que resuelve proporcionando suficiente API. Helm no es una excepción. Entonces, si necesita personalizar cómo se comporta, primero debe preguntarse: ¿va en línea con la arquitectura, los principios de diseño o tal vez me pierdo algo?

Es por eso que este RP no fue tan fácil de resolver. Dado que, la corrección es obvia, pero no está en línea con el diseño de Helm. Es por eso que se proporcionan pocas soluciones temporales.

Y tienes razón sobre la bandera app-version . Debe proporcionarlo, luego Helm debe manejar todo por su cuenta.

¿Puedo hacerte una pregunta? ¿Cómo utiliza Helm en su producto? Cuando usa helm install ? ¿Cómo lo usas exactamente? ¿Ha considerado usar helm package ?

Le di otro vistazo a helm package anoche. Realmente no estaba convencido de eso. sed ha existido durante mucho tiempo y es muy estable. Todos estos subcomandos tiller / package / install son relativamente nuevos y menos estables. Para ayudar a articular mi punto, hace meses, decidí "seguro que Tiller podría funcionar" a pesar de que había visto el complemento de alguien que pasaba por alto la necesidad de Tiller. Vi el complemento como algo que debe haber sido menos convencional, pero me he estado pateando desde entonces. Si hubiera confiado en el complemento, estaría en una posición mucho mejor de la que estoy ahora. Los mantenedores de Helm incluso han confirmado que están de acuerdo en que era un diseño que no se podía mantener y que desaparecerá en futuras versiones.

Creo que sería un error de mi parte usar helm package para realizar estas simples operaciones sed. ¿Cuál es su caso de uso para package todos modos? Siento que todo el concepto de helm package pierde el sentido de las versiones de control de versiones / web 2.0 al empaquetar en un zip binario en primer lugar cuando los grupos de tecnología moderna han estado aprovechando el poder del etiquetado para lograr el mismo proceso pero de una manera más ágil y audible.

Para mi caso de uso, estoy permitiendo que los desarrolladores de aplicaciones codifiquen sus aplicaciones en contenedores y las implementen de una manera que se pueda mantener, por lo que minimizar los gastos generales (administradores de sistemas de operaciones / tiller, administración de artefactos de liberación redundantes, etc.) es de suma importancia. Creo que mi uso sigue más de cerca la filosofía de Unix de decidir usar una herramienta para lo que hace mejor y luego cambiar a otras herramientas (etc. sed) cuando sea apropiado. No creo que nunca encuentre una herramienta que lo haga todo a la perfección, pero si está satisfecho con su flujo de trabajo actual, no permita que lo disuada de seguir su propia filosofía.

@IRobL

cuando dices mala práctica, ¿estás diciendo que no es deseable tener que envolver el comando helm con secuencias de comandos?

Si. Esto precisamente.

En mi caso de uso, la biblioteca de canalizaciones crea los contenedores de la ventana acoplable, los publica y, en última instancia, los implementa a través de helm desde la canalización de compilación de la aplicación.

Esto es exactamente lo que estamos haciendo también.

Incluso después de que este problema se solucione en la biblioteca de canalización de compilación de mi empresa, definitivamente me sentiría más cómodo si tuviera un conmutador --app-version integrado en Helm

Yo llevaría esto un paso más allá y diría que tener appVersion como propiedad del archivo Chart.yaml probablemente sea incorrecto. Si el valor se puede cambiar sobre la marcha, no debería estar en lo que se considera un "conjunto de valores inmutables". Creo que defendí lo mismo en un comentario anterior.

Todos estos subcomandos de tiller / package / install son relativamente nuevos y menos estables.

FWIW, Tiller no va a ser una cosa en Helm 3. Mencionaste esto más adelante en tu publicación; sin embargo, solo estoy reiterando esto porque muestra que la sintaxis helm package de crear un "binario de kubernetes" y enviarlo a Tiller probablemente sea una mala práctica.

Creo que sería un error de mi parte usar el paquete helm para realizar estas simples operaciones sed. ¿Cuál es su caso de uso para el paquete de todos modos?

Probablemente pueda defender al equipo de Helm en este caso. El sentido que tengo detrás de helm fue un método para que los desarrolladores de aplicaciones especifiquen cómo ejecutar su aplicación correctamente desde dentro de Kubernetes. Es por eso que los proveedores de aplicaciones ejecutan sus propios repositorios de Helm que puede agregar para descargar una versión determinada de su implementación. El equipo de Helm probablemente vio el código de la aplicación y el código de la infraestructura como entrelazados porque sus equipos de producción objetivo previstos no iban a utilizar Helm en los flujos de trabajo diarios como lo hacemos nosotros en CI / CD. Ejemplo: usamos helm upgrade 130 veces al día en promedio. No creo que ese haya sido nunca el uso previsto.

Probablemente era mucho más común que la gente dijera: "Solo quiero instalar mysql en kubernetes" y helm era una forma (relativamente) fácil de hacerlo para las personas que sabían poco sobre kubernetes y simplemente estaban jugando con él.

Por lo tanto, en última instancia, helm package estaba destinado a ser consumido por _ esa audiencia_. Definitivamente, la herramienta se está utilizando mucho más en ámbitos que el equipo (creo) o no creía que la utilizaría, o nunca tuvo la intención de usarla de la manera en que lo hace.

Creo que mi uso sigue más de cerca la filosofía de Unix de decidir usar una herramienta para lo que hace mejor y luego cambiar a otras herramientas (etc. sed) cuando sea apropiado.

Básicamente estoy tratando a Helm como awk con un montón de kubectl apply -f s después. Es mucho más limpio tener una herramienta automatizada que se encargue de los valores para evitar errores humanos.

Parece que tú y yo tenemos muchos de los mismos valores y podemos estar haciendo muchas cosas similares.

@IRobL

caña del timón

Para mí, tiller no es aceptable. Dado que agrega un punto de exposición más, riesgos de seguridad adicionales y, lo más importante, no hace nada más que crea una forma más de aplicar archivos yaml, pero con una API diferente. Tiller fue diseñado para asegurar, alinear el proceso de aplicación de paquetes de Helm, pero con tantos riesgos, software adicional (¡y control de versiones!). Es por eso que Helm the 3rd no lo usa.

Creo que sería un error de mi parte usar el paquete helm para realizar estas simples operaciones sed.

Creo que estás perdiendo mi punto. Déjame intentar de nuevo. ¿Para qué está hecho sed ? Transformar un flujo de datos. Debería abstraerse del problema de las transformaciones, brindándole API y resultado para cualquier entrada dada.

¿Qué pasa si crea un script, donde su comando sed no funciona (es decir, tiene un error en su expresión regular)? Así que llegó a una conclusión, no funciona. ¿Intentará entender por qué sed no funciona por sí solo, o agregaría una tubería adicional con el script perl?

Lo mismo ocurre con todas las soluciones: debe proporcionar API, tomar entradas y proporcionar resultados, abstrayendo un problema. Ya sabes, estilo Unix.

Proyectado en Helm, está diseñado para versionar su lanzamiento y empujarlo hacia los K8. Permite personalizar la configuración mediante plantillas. Entonces, si está observando un problema, debe proporcionar una versión. Helm proporciona un mecanismo simple para administrar versiones y proporciona una manera fácil de personalizar la forma en que funciona su compilación. Entonces, ¿por qué no intentar comprender cómo funciona, en lugar de agregar una solución con software adicional?

@jrkarnes

Sí, ambos nos acercamos al timón con intereses similares en mente. Realmente no me había dado cuenta de que la raíz del comando package estaba entrelazada con los errores pavimentados por tiller, ¡gracias por compartir estas ideas conmigo!

De hecho, estaba revisando el historial de por qué esta función no se acaba de agregar y vi dos argumentos sobre por qué no podían agregar esta función, el primero era que, dado que ya está definida en package tampoco deberían hacerlo. también tienes que definirlo en install / upgrade . Siento simpatía por eso, esto suena como un problema de deuda tecnológica. No existe un software de uso público que no tenga deuda tecnológica. La otra razón fue que el archivo Chart.yml era metadato y no debería actualizarse. Eso me pareció extraño ... a medida que las personas desarrollan gráficos de timón, seguramente actualizan ese archivo manualmente a medida que las cosas cambian y, por lo tanto, no es inmutable en sí mismo. Es más fácil para mí ver el archivo Chart.yml como una forma de introducir parámetros en el binario del timón, ya que crea los objetos de implementación que, en contraste, son realmente inmutables.

¿Cuál es tu plataforma de construcción por cierto? El código de canalización que estoy escribiendo está escrito para Jenkins como una biblioteca de canalización global.

@IRobL El problema clave es: está viendo Helm como un script de implementación. Pero Helm no es así. Helm es una capa de abstracción. Helm toma todos sus artefactos y los aplica como una unidad de trabajo a los K8 como plataforma.

Helm es un empaquetador. Helm está diseñado para facilitar la implementación. Crea un "instalador" a partir de sus artefactos, para que pueda "instalarlo" en su sistema operativo - K8.

app-version en install no tiene nada que ver con la deuda tecnológica. No es necesario en absoluto cuando desea install o upgrade . Lo mismo es el Chart.yml . No debe cambiarse en absoluto, ya que es un archivo de configuración predeterminado, que contiene la versión del gráfico real, pero el gráfico no es su software. Lo estás usando mal.

Desde ese punto de vista, ¿por qué no considerará usar package ? ¿Te parece demasiado complejo o qué?

He estado fuera del circuito sobre este tema por un tiempo, pero he visto este tipo de punto surgir varias veces:

Helm es un empaquetador. Helm está diseñado para facilitar la implementación. Crea un "instalador" a partir de sus artefactos, para que pueda "instalarlo" en su sistema operativo - K8.

Básicamente, Helm _no crea de ninguna manera un instalador. No crea un "binario". No crea algo similar a un archivo ".deb" o similar. Crea un archivo de algunas plantillas de manifiestos de Kubernetes, con algunos valores predeterminados y / o preestablecidos. Su software real no vive en ese Helm Chart. No está empaquetado con él. No se garantiza que sea inmutable.

Creo que es justo decir que en la mayoría de los casos, su Helm Chart cambiará un _mucho_ menos que el software que está implementando a través de su Chart.

Esta es la razón fundamental (al menos en mi opinión) por la que --app-version esté disponible en helm install y helm upgrade . ¿Por qué debería volver a empaquetar su gráfico si literalmente nada ha cambiado?

Veo un Helm Chart como una descripción versionada de los manifiestos de Kubernetes, que describe un conjunto de componentes de Kubernetes que ejecutarán correctamente una aplicación, y eso es todo lo que veo. Si esas instrucciones necesitan cambiar, ahí es cuando me gustaría actualizar mi gráfico, no cada vez que cambia mi aplicación y solo necesito actualizar una versión de imagen (que a menudo se establece mediante valores de todos modos).

Eche un vistazo a Flux, por ejemplo, y cómo funciona su operador de timón. Puede hacer que actualice automáticamente un valor de etiqueta de imagen; eso no actualiza el gráfico, solo la etiqueta de imagen que se está implementando.

Crea un archivo de algunas plantillas de manifiestos de Kubernetes, con algunos valores predeterminados y / o preestablecidos.

Pero el archivo deb es el mismo conjunto de archivos de configuración, comandos, manifiestos y / o valores preestablecidos. Igual que el instalador de MSI o incluso, que es el más cercano, ebuild en el sistema de paquetes gento emerge. Además, lo mismo que los paquetes Brew.

Entonces, ¿qué es Helm si no es un administrador de paquetes para K8? ¿Cuál es la diferencia que ves?

No se garantiza que sea inmutable.

¿Por qué no? Si modifica un paquete después de la generación del paquete, es incorrecto. Si proporciona opciones adicionales durante el proceso install/upgrade , está previsto, como en todos los sistemas de empaquetado.

Veo un gráfico de Helm como una descripción versionada de los manifiestos de Kubernetes

Ya tienes uno: GIT. Entonces, ¿por qué necesitarías un Helm?

Creo que es justo decir que en la mayoría de los casos, su Helm Chart cambiará mucho menos que el software que está implementando a través de su Chart.
Esta es la razón fundamental (al menos en mi opinión) para que --app-version esté disponible en la instalación y actualización de helm. ¿Por qué debería volver a empaquetar su gráfico si literalmente nada ha cambiado?

En este diseño, appVersion no debe tratarse como un atributo de la compilación del paquete Helm. Debe tratarse como un parámetro de configuración, en valores.

Eche un vistazo a Flux, por ejemplo, y cómo funciona su operador de timón. Puede hacer que actualice automáticamente un valor de etiqueta de imagen; eso no actualiza el gráfico, solo la etiqueta de imagen que se está implementando.

En este caso, perderá el acoplamiento de los manifiestos de infraestructura de la aplicación y la versión de la aplicación. Desde entonces, cambiar la etiqueta de la imagen no activará una nueva actualización del timón (corríjame si los chicos de Flux lo están haciendo de otra manera). En ese caso, tendrá Helm como plantilla de configuración. En ese caso, no necesita --app-version en absoluto.

Pero el archivo deb es el mismo conjunto de archivos de configuración, comandos, manifiestos y / o valores preestablecidos. Igual que el instalador de MSI o incluso, que es el más cercano, ebuild en el sistema de paquetes gento emerge. Además, lo mismo que los paquetes Brew.

A su descripción aquí para los paquetes .deb y .msi le falta un componente clave: el elemento real que se está instalando. Si observa el contenido de un archivo .deb , encontrará el software integrado: el software _THE_ que se instalará. En términos generales (siempre en el caso de .deb ?), La aplicación que se implementa está intrínsecamente vinculada y es parte de ese paquete (no es el caso de brew).

Los paquetes de infusión son diferentes y no son realmente comparables de la misma manera. Sin embargo, Brew es en realidad mucho más similar a Helm en la actualidad, ya que son solo las instrucciones sobre cómo debe instalarse y de dónde debe descargarse la fuente / paquete.

Para ser absolutamente claro aquí; un gráfico de Helm _no está vinculado intrínsecamente a una versión de aplicación específica_ y no contiene el artefacto que se está implementando (es decir, la imagen de Docker). Solo contiene una referencia a él, y el valor detrás de esa referencia puede incluso cambiar (es decir, puede enviar a la misma etiqueta de Docker, si así lo desea). Entonces, pase lo que pase, un Helm Chart no es una versión empaquetada de una aplicación, y tampoco está estrictamente vinculado a una versión específica de la aplicación.

Solo necesita ver el repositorio de gráficos estables para ver un ejemplo. ¿Cuántas aplicaciones le permiten anular la imagen que se utiliza mediante valores? (Mucho_)

Entonces, ¿qué es Helm si no es un administrador de paquetes para K8? ¿Cuál es la diferencia que ves?

Es una herramienta que permite crear plantillas de manifiestos de Kubernetes y distribuirlos e instalarlos fácilmente. La clave aquí es que, eso es todo lo que trata Helm: los manifiestos de Kubernetes.

Todo esto vuelve a mi punto principal: si esos manifiestos cambian, o si las plantillas deben cambiar para esos manifiestos por cualquier motivo, entonces es cuando un gráfico de Helm realmente debe cambiarse.

La principal complicación que veo es que hay 2 casos de uso:

• Implementación de aplicaciones de terceros.
• Implementación de aplicaciones propias.

En el caso de aplicaciones de terceros, como consumidor de Helm es deseable que se publique un gráfico de Helm con cada nueva versión de la aplicación. Una diferencia clave aquí es con la frecuencia de lanzamientos. Es probable que un gráfico de Helm de terceros para algo como MySQL o lo que sea no cambie varias veces al día. En este caso, tampoco querrá utilizar accidentalmente una versión antigua de un gráfico con una nueva versión de software, un error que es mucho más fácil de cometer con software y gráficos que no ha escrito usted mismo.

En el caso de las aplicaciones de origen, es posible que tenga una forma estándar de implementar una clase de aplicaciones. En Icelolly, por ejemplo, escribimos e implementamos nuestros servicios Go prácticamente de la misma manera. Con ese fin, en realidad podemos usar un solo gráfico en este momento para todos nuestros servicios Go implementados en Kubernetes (usamos la solución alternativa helm package este momento). Si cambia el enfoque que adoptamos para implementar nuestras propias aplicaciones, actualizaremos el gráfico. Actualizamos nuestro gráfico con SemVer, por lo que las aplicaciones que no se actualizan no se verán afectadas hasta que queramos actualizarlas.

Solo en esta nota; Nuestro gráfico go-service se actualizó por última vez hace aproximadamente un mes. Durante ese tiempo, probablemente hemos tenido decenas a cientos de implementaciones, todo sin que cambie el gráfico.

En un caso, solo desea simplicidad. En el otro caso, desea control y facilidad de gestión.

En este caso, perderá el acoplamiento de los manifiestos de infraestructura de la aplicación y la versión de la aplicación. Desde entonces, cambiar la etiqueta de la imagen no activará una nueva actualización del timón (corríjame si los chicos de Flux lo están haciendo de otra manera). En ese caso, tendrá Helm como plantilla de configuración. En ese caso, no necesita --app-version en absoluto.

Flux realmente cambiará los valores que usa para actualizar el gráfico y luego ejecutará la actualización con el nuevo valor de imagen. Su punto sobre perder el acoplamiento de los manifiestos de infraestructura y la versión de la aplicación sigue en pie. El punto que estoy argumentando es que en realidad es deseable que ese sea el caso en algunos casos de uso. Sin embargo, tiene razón, en este caso de uso, no necesito --app-version , no se usaría porque no existe en este momento. Sin embargo, si lo hiciera, tal vez Flux podría usarlo. En ese caso, sería útil.

helm list es un comando útil. Ser capaz de ver qué versiones de la aplicación están implementadas sigue siendo útil. Para nuestras aplicaciones instaladas actualmente a través de Helm con el enfoque helm package , solo configuramos la versión de la aplicación (a través de --app-version en helm package ) para que la salida de helm list sea útil. Por eso, si pudiéramos configurarlo en helm install|upgrade , sería más sencillo para nosotros. No tendríamos que buscar el gráfico y volver a empaquetarlo solo para cambiar la versión.

De hecho, helm list y el manejo de reversiones son probablemente las únicas razones por las que estamos usando Helm para software de primera mano.

A su descripción aquí para los paquetes .deb y .msi le falta un componente clave: lo que realmente se está instalando.

"Instalar" es un proceso de configuración de las instalaciones necesarias (carpetas, configuraciones, binarios, búsqueda de bases de datos, actualización / migración de datos) en la plataforma de destino.

deb maneja todo eso. También lo hace el paquete Helm. ¿Qué quiere decir que el paquete Helm no está "realmente instalado"?

Si observa el contenido de un archivo .deb, encontrará el software integrado: EL software que se instalará.

Falso. A veces encontrará el software en sí. A veces encontrará algunas piezas de software. A veces, no encontrará nada más que un conjunto de scripts para obtener dicho software. Entonces, el punto clave aquí: no importa , ya que Linux y K8 son plataformas para alojar una aplicación determinada, aceptando un formato de aplicación universal. Y los nombres de las imágenes, los parámetros de configuración, son las piezas del paquete.

Sin embargo, Brew es en realidad mucho más similar a Helm en la actualidad, ya que son solo las instrucciones sobre cómo debe instalarse y de dónde debe descargarse la fuente / paquete.

Exactamente. ¿Estás tratando de convencerme de que Brew no es un administrador de paquetes?

Para ser absolutamente claro aquí; un gráfico de Helm _no está vinculado intrínsecamente a una versión específica de la aplicación ...
¿Cuántas aplicaciones le permiten anular la imagen que se utiliza mediante valores? (Mucho)

Tienes toda la razón. Helm no podría ser más que un útil motor de creación de plantillas para las plantillas de k8s. No tengo problemas con la existencia de este tipo de software: ayuda un poco, no cambiará la práctica de entrega moderna.

El problema es que Helm es más que un motor de plantillas. Es un gestor de envases, con todas sus ventajas y desventajas. Y en el ecosistema donde existe el administrador de paquetes, es una mala práctica tener un administrador de algo a través de otro paquete. Peor aún, trabajando sin administrador de paquetes.

Veo las razones detrás de hacer que la versión de la aplicación sea un argumento de paquete para estos paquetes. Y veo razones por las que usted y todos ustedes no tienen que hacer paquetes. El problema es que es un enfoque obsoleto, complejo y más difícil de administrar. Es curioso, el costo es pequeño, pero gámelo increíble.

El punto que estoy argumentando es que en realidad es deseable que ese sea el caso en algunos casos de uso.

Sí, este es el punto central: ¿Es deseable para algún producto?

Su argumento es que Helm Chart rara vez cambia, entonces, ¿por qué deberíamos empaquetarlo en cada versión? Estoy de acuerdo contigo, se siente redundante. Pero de todos modos, todavía empaquetamos algunos archivos fuente antiguos, sidecar antiguos (si Helm consta de varias aplicaciones), configuraciones antiguas, Dockerfile antiguo.

Entonces, la pregunta es, si empaquetamos todo el gráfico como artefacto, en cada compilación, ¿cuál es la ganancia? Para Dockerfile es obvio (pero seguro que no fue obvio cuando la contenedorización apareció en el mercado). También para archivos fuente.

En los días en que teníamos el mecanismo de entrega más claro posible: cargar solo archivos modificados a través de FTP. Ahora tenemos tantas cosas. Necesitamos decidir qué es bueno, por qué es bueno, quién debería usarlo. No estoy seguro de estar contento con que Helm maneje ambos enfoques al mismo tiempo, demasiado complejo.

Implementación de aplicaciones de terceros.

Estaría muuuy feliz si pudiera instalar cualquier versión de PSQL / MySQL usando únicamente el gráfico Helm. Sería mucho más fácil mantener proyectos heredados, presentar infraestructura a los novatos. Incluso será más fácil recibir notificaciones sobre actualizaciones de Chart. ¿Por qué tenemos tantos archivos tar.gz para cada versión de los binarios, pero no podemos tener el mismo conjunto de archivos tar.gz para los paquetes Helm?

@iorlas Acabo de leer esto y las relaciones públicas rechazadas y haces algunos puntos muy buenos. Me has convencido de que necesito comenzar a empaquetar mis gráficos de timón como otro artefacto de mi construcción / lanzamiento.

Pero me gustaría mencionar que ni siquiera sabía que helm tenía un comando de paquete y supongo que no estoy solo. Probablemente se deba a que es muy fácil instalar un gráfico desde el directorio de origen, pero tampoco la documentación realmente vende el concepto o ni siquiera lo explica en detalle.

El comando del paquete está obviamente documentado, pero solo hay un par de menciones muy generales de paquetes en la guía de inicio rápido ; de hecho, la palabra paquete se muestra mucho en el inicio rápido, pero principalmente se refiere a cómo instalar Helm y los diferentes paquetes del sistema operativo. . El empaque tampoco se menciona en las mejores prácticas y creo que debería incluirse capturar qué es el empaque y por qué es útil. También verifiqué los documentos v3 que tienen una estructura ligeramente diferente, pero parecen ser escasos al sugerir a los usuarios que empaqueten sus gráficos.

Normalmente me gustaría enviar un PR y no solo suena como si me quejara de algo, sino que no estoy seguro de qué está pasando con los cambios en la documentación 3.0.

@jonstelly Definitivamente hay un vacío en la documentación. Incluso yo estaba pensando al principio que --app-version está listo para comenzar, pero luego, aunque no podía faltar sin una razón.

Los documentos definitivamente necesitan una aclaración y la introducción de problemas comunes. Luego, introducción al ciclo de desarrollo de Helm. Pero creo que el equipo está ocupado con la tercera versión. Y estoy demasiado ocupado ahora también :(

"Instalar" es un proceso de configuración de las instalaciones necesarias (carpetas, configuraciones, binarios, búsqueda de bases de datos, actualización / migración de datos) en la plataforma de destino.

deb maneja todo eso. También lo hace el paquete Helm. ¿Qué quiere decir que el paquete Helm no está "realmente instalado"?

No me refiero a que un gráfico de Helm no esté instalado; todo lo que digo es que el gráfico de Helm no contiene la aplicación real que está implementando. Una imagen de Docker no está empaquetada en un gráfico de Helm. Kubernetes lo extrae de alguna fuente externa.

Falso. A veces encontrará el software en sí. A veces encontrará algunas piezas de software. A veces, no encontrará nada más que un conjunto de scripts para obtener dicho software. Entonces, el punto clave aquí: no importa, ya que Linux y K8s son plataformas para alojar una aplicación determinada, aceptando un formato de aplicación universal. Y los nombres de las imágenes, los parámetros de configuración, son las piezas del paquete.

Hasta donde yo sé, en realidad estás equivocado aquí. Un archivo .deb es un archivo AR. Puede extraerlo y mirar el contenido y, en última instancia, son algunos metadatos y algunos archivos. .deb archivos .deb contiene una secuencia de comandos para ir a buscar el software, entonces significaría que es la secuencia de comandos la que está siendo instalada por el archivo .deb , no el software en sí. Eso es como instalar un instalador.

Si tiene un ejemplo de una pieza de software de Linux empaquetada en un .deb donde .deb va y descarga el software para instalar como parte del proceso de instalación del archivo .deb , entonces realmente me gustaría verlo, ya que es algo con lo que literalmente nunca me he encontrado antes en muchos años de uso de Linux.

Exactamente. ¿Estás tratando de convencerme de que Brew no es un administrador de paquetes?

No. Todo lo que digo es que, al igual que Helm, los scripts proporcionados para instalar software a través de Brew son solo eso: scripts. Las aplicaciones se crean, empaquetan y distribuyen por separado y se extraen mediante esos scripts. Eso no hace que Brew sea menos un administrador de paquetes, al igual que lo que he estado diciendo no hace que Helm sea menos un administrador de paquetes de Kubernetes. Sin embargo, ese no es el punto de este problema, no estamos debatiendo si Helm es o no un administrador de paquetes, estamos tratando de decidir si se debe agregar o no una bandera --app-version a helm install|upgrade para facilitar un caso de uso común.

Veo las razones detrás de hacer que la versión de la aplicación sea un argumento de paquete para estos paquetes. Y veo razones por las que usted y todos ustedes no tienen que hacer paquetes. El problema es que es un enfoque obsoleto, complejo y más difícil de administrar. Es curioso, el costo es pequeño, pero gámelo increíble.

Disculpas, no tengo claro qué quieres decir con esto. ¿Qué es desactualizado / complejo / más difícil de administrar?

Entonces, la pregunta es, si empaquetamos todo el gráfico como artefacto, en cada compilación, ¿cuál es la ganancia? Para Dockerfile es obvio (pero seguro que no fue obvio cuando la contenedorización apareció en el mercado). También para archivos fuente.

Bueno, de nuevo, la diferencia es básicamente que todas esas cosas que mencionaste están intrínsecamente vinculadas. Necesita todo el código fuente para ejecutar la aplicación, no solo lo que cambió. No empaqueta el Dockerfile, por lo que no estoy seguro de qué se trata ese punto, pero a menudo usará el mismo Dockerfile sin cambiarlo para crear nuevas versiones de imágenes (quiero decir, ¿por qué molestarse con la automatización si tuviera que cambiar algo manualmente cada tiempo, ¿verdad?). Con todo ese tipo de cosas, está creando algo que encapsula todo lo que necesita, para que pueda implementarse de forma aislada. Por lo tanto, puede hacer cosas como activar un nuevo nodo e implementarlo de la misma manera que lo haría en un nodo existente, etc.

Hay un montón de ventajas, como estoy seguro de que ya sabe, sobre el uso de la carga anterior a través de FTP.

De todos modos, esto es todo por cierto. Creo que en última instancia, como ya he mencionado, en mi opinión, todo esto se reduce; ¿Quieren los mantenedores de Helm habilitar este otro caso de uso o hacer que sea más difícil para las personas usarlo de esta manera? Al final, no es _realmente_ una gran diferencia de ninguna manera. Para mí, sería bueno no tener que empaquetar nuestro gráfico interno, que rara vez cambia, en cada compilación solo para configurar una versión de la aplicación, que nuevamente solo se usa para mostrar la versión actual en una lista. Para las aplicaciones propias, seré honesto, me he preguntado si Helm es el enfoque correcto de todos modos.

Una imagen de Docker no está empaquetada en un gráfico de Helm

De hecho, desearía que fuera así. Pero ahora no es así. Mi visión es, K8s será / debería ser una plataforma, que incorporará Helm (por lo que no habrá Helm) como API para instalar paquetes: necesitará empaquetar sus cosas en el archivo e instalarlo. De vuelta a la simplicidad de los archivos deb, pero con el aislamiento adecuado y los recursos k8s como ciudadanos de primera clase.

Un archivo .deb es un archivo AR
Puedes extraerlo y mirar el contenido.
y en última instancia son algunos metadatos
y algunos archivos

Como ... ¡un paquete de Helm!

Si tiene ... un .deb donde va el .deb y descarga el software para instalar como parte del proceso de instalación del archivo .deb ...
Eso es como instalar un instalador. ...

Sí, sería como un instalador que tiene un instalador adentro. ¿Gracioso, verdad? Usaría un artefacto si es posible , si fuera suficiente para configurar la instancia de la aplicación. Pero tenemos diferentes software, diferentes fuentes de verdad, a veces incluso es útil tener múltiples fuentes.

• Brew tiene YAML como paquete, pero obtiene binarios del almacenamiento remoto
• Emerge (gentoo) tiene ebuild como definición, que descarga incluso clones de git

Debian intenta empaquetar todo dentro. Y es lo correcto, si es posible. Pero para probar mi punto, los metapaquetes servirán. Has escuchado sobre eso? Es un paquete que instala algunos otros paquetes. ¿No es un paquete?

Pero, por favor, no se pierda el punto principal: ¡no importa ! Incluso el paquete vacío, que solo tiene una referencia dentro, es un paquete. ¿Quizás aceptaría otro término, instalador?

Lo que digo es que, al igual que Helm, los scripts proporcionados para instalar software a través de Brew son solo eso: scripts
Las aplicaciones se crean, empaquetan y distribuyen por separado y se extraen mediante esos scripts.

Y todos tenemos la misma canalización: crear una imagen de Docker.

estamos tratando de decidir si se debe agregar o no un indicador --app-version a helm install | upgrade para facilitar un caso de uso común.

Esa es una clave. Pero, ¿cómo podemos decidirnos? Deberíamos hacer dos preguntas:

• ¿Es posible? sí
• ¿Es lo correcto hacer? ¿Sí? ¿No?

Si hay personas haciendo algo, ¿significa que es algo bueno? Para avanzar, debemos cuestionar todo.

Disculpas, no tengo claro qué quieres decir con esto. ¿Qué es desactualizado / complejo / más difícil de administrar?

dejemos que se proyecte en Brew, ya que Brew está muy cerca de Helm y ya se utiliza ampliamente y con éxito. Puede proyectar en Gentroo Ebuilds o deb, la imagen no cambiará.

• Anticuado. ¿Cuándo fue la última vez que tuvo que instalar MySQL / PSQL manualmente? ¿Por qué nos hemos alejado de él? Estas razones, amigo.
• Complejo. Este es uno de los "por qué": necesita configurar la infraestructura de forma independiente, necesita saber cuál funciona mejor con qué versiones de software. A veces, necesitará personalizar la infraestructura para ejecutar cierta versión de software. ¿Por qué molestarse? ¿Por qué no delega toda la pregunta?
• Más difícil de manejar. Deberá administrar tanto la infraestructura como las versiones de la aplicación cuando solo pueda tener un artefacto. ¿Por qué hacer tu vida más difícil?

Lo siento, un poco vago en este momento para describir todos los casos de uso, como retrocesos limpios, actualizaciones elegantes, de todos modos, estas son las principales bonificaciones.

Bueno, de nuevo, la diferencia es básicamente que todas esas cosas que mencionaste están intrínsecamente vinculadas.

No siempre. Por ejemplo, la imagen de la ventana acoplable podría tener SSR BE y una referencia a CDN.

Dockerfile, así que no estoy seguro de qué se trata ese punto, pero a menudo usará el mismo Dockerfile sin cambiarlo para crear nuevas versiones de imágenes (quiero decir, ¿por qué molestarse con la automatización si tuviera que cambiar algo manualmente cada vez, verdad?).

Ese es el punto. Incluso cuando no se cambia Dockerfile, se crea una nueva imagen. Si su código fuente no se cambia, pero Dockerfile sí, crea una nueva imagen. Entonces, en pocas palabras, Dockerfile también es un paquete. Lo mismo ocurre con Helm. ¿No te parece?

Con todo ese tipo de cosas, está creando algo que encapsula todo lo que necesita, para que pueda implementarse de forma aislada. Por lo tanto, puede hacer cosas como activar un nuevo nodo e implementarlo de la misma manera que lo haría en un nodo existente, etc.

Pero resulta que la imagen de la ventana acoplable no es suficiente para ejecutar una aplicación. Necesitamos una instancia de configuración, necesitamos definiciones de servicio. ¿Por qué no empaquetarlo todo?

Al final, no es realmente una gran diferencia de ninguna manera.

Yo creo que lo es. Tal vez no sea mucho del trato en la base de código, pero estancará la evolución de la contenedorización.

Una imagen de Docker no está empaquetada en un gráfico de Helm

La imagen en sí no está empaquetada, pero la referencia (leída como: pin) sí lo está. Claro, podemos ser pedantes y quedar atrapados en si la imagen literal de tamaño variable (de MB a GB) está incluida o no en el artefacto de helm package (spoiler: no lo es), pero la esencia de la declaración "Una versión dada del código de una aplicación está incluida en un paquete de helm" sigue siendo fundamentalmente correcta. Si quieres o no quedar atrapado en el cómo es irrelevante.

Volviendo a la tierra de los ejemplos, digamos que tiene una aplicación que ha versionado internamente como 1.9.9 ejecuta en un gráfico con una versión de 1.2.5 . Para que no haya confusión, la imagen de Docker sha para el contenedor de la aplicación es fakeshaA .

Su equipo decide que en la versión 2.0.0 de su aplicación habrá una versión del sistema de archivos local de un archivo al que solía hacer referencia a través de HTTP. La razón de esto no es importante, pero la consecuencia para usted es bastante severa. Ahora necesita pv y pvc para sus implementaciones para que estos archivos ahora locales no se pierdan entre actualizaciones. Al ver la necesidad, continúe y actualice su gráfico de Helm para tener este pv y pvc para que el cambio a 2.0.0 no sea muy perturbador.

Antes de cambiar el gráfico, tiene Artifact A vincula la versión de la aplicación 1.9.9 a la versión de infraestructura 1.2.5 . Ahora cambia el gráfico ... _su gráfico de Helm ahora es v. 1.3.0 _ y producirá un artefacto que vincula 1.9.9 con la versión de infraestructura 1.3.0 . A esto lo llamaremos Artifact B

Cuando la implementación del código para 2.0.0 se active con la imagen de Docker sha fakeShaB , creará otro artefacto que vincule 2.0.0 a la versión infra 1.3.0 . Esto es Artifact C

Ahora digamos que resulta que hay un problema que no comprende completamente con la versión 2.0.0 y tiene que revertir. Retrocede usando Artifact B ... pero esto no resuelve el problema, por lo que retrocede nuevamente a Artifact A y el problema está resuelto.

El único problema con el que se encuentra es si el Registro de Docker al que hacen referencia sus artefactos todavía tiene la imagen a la que se hace referencia en esos artefactos.

Pase lo que pase, todavía tiene un vínculo entre una versión de una aplicación y una versión de infraestructura . Este es el propósito de Helm. Argumentar lo contrario es una locura.

@iorlas :

Dejemos de lado las comparaciones .deb . Creo que solo nos estamos desviando.

No siempre. Por ejemplo, la imagen de la ventana acoplable podría tener SSR BE y una referencia a CDN.

Eso es muy cierto. Sin embargo, más sobre eso más adelante.

Ese es el punto. Incluso cuando no se cambia Dockerfile, se crea una nueva imagen. Si su código fuente no se cambia, pero Dockerfile sí, crea una nueva imagen. Entonces, en pocas palabras, Dockerfile también es un paquete. Lo mismo ocurre con Helm. ¿No te parece?

Lo hace, pero eso se debe a que el producto al final de ese proceso de compilación (es decir, una imagen de Docker) depende de _ambos_ el Dockerfile y de lo que está colocando en él. Una imagen no puede existir sin esos dos componentes.

Por otro lado, un gráfico de Helm puede existir incluso antes de que se construya una aplicación, literalmente, antes de que se escriba una sola línea de código. Podría construir uno imaginario que no se instalaría, pero no obstante, Helm Chart podría existir por completo sin nada más. Como dije, esto sería inútil, pero solo estoy tratando de ilustrar mi punto de que no están vinculados en absoluto.

Mi punto aquí, y cómo se relaciona con este problema en particular, es que los gráficos de Helm no siempre están intrínsecamente vinculados a las aplicaciones que implementa el gráfico. No creo que sea una afirmación audaz, sucede, ya es un hecho. Lo estoy haciendo ahora mismo con aplicaciones de producción, también hay otros que han comentado sobre este tema. Entonces, como dije antes, todo esto se reduce a; ¿Quieren los mantenedores de Helm habilitar este caso de uso, o no? No hay nada más que eso.

Pero resulta que la imagen de la ventana acoplable no es suficiente para ejecutar una aplicación. Necesitamos una instancia de configuración, necesitamos definiciones de servicio. ¿Por qué no empaquetarlo todo?

De hecho, desearía que fuera así. Pero ahora no es así.

Si este fuera el caso, y un Helm Chart realmente empaquetaba todo lo que implementó (mencionaste CDN anteriormente, pero no lo estás implementando en Kubernetes entonces, por lo que aún no iría en tu Chart), entonces creo que esta conversación no estaría sucediendo. Su gráfico de Helm _ estaría_ intrínsecamente vinculado a la versión de la aplicación que se está implementando, al igual que la creación de una imagen de Docker. Para crear un gráfico de Helm en ese escenario, se le pedirá que lo reconstruya cuando cambie su aplicación, momento en el que no hay duda. No podrías usar Helm de la forma en que lo estoy usando hoy, sería mucho más claro de esa manera.

Sin embargo, esa no es la realidad. No es así como funciona Helm, y no sé si alguna vez terminará siendo realmente. Pero nunca digas nunca, ¿verdad?

@jrkarnes :

La imagen en sí no está empaquetada, pero la referencia (leída como: pin) sí lo está.

Claro, pero un caso de uso común es usar valores para anular este valor. Lo he usado con gráficos de terceros y propios. No sería una opción si no fuera algo que la gente usa.

Claro, podemos ser pedantes y quedar atrapados en si la imagen literal de tamaño variable (de MB a GB) está incluida o no en el paquete artifact of helm (spoiler: no lo es),

No creo que estemos siendo pedantes en nada; como ya ha señalado, sería incorrecto de hecho decir que la imagen de Docker está empaquetada dentro de Helm Chart "construido".

"Una versión determinada del código de una aplicación está incluida en un paquete de helm" sigue siendo fundamentalmente correcta.

Pero no realmente, como mi primer punto argumentaría en contra. Puede cambiar lo que se está implementando. Demonios, puedes cambiar la mayoría de gráficos para ejecutar la imagen hello-world si quieres. Eso sería inútil, pero demuestra muy bien mi punto: el Helm Chart no está vinculado a su aplicación. Hay una _ expectativa_ de que lo usará con la imagen correcta, y probablemente de manera predeterminada lo hará, pero ciertamente no _ tiene que_ - y de ninguna manera_ el código de la aplicación está incluido en un Helm Chart, empaquetado de otra manera.

Volviendo a la tierra de los ejemplos, [...] y el problema está resuelto.

Ha hecho que parezca que esto no es posible sin usar Helm en lo que aparentemente es actualmente la forma prevista. Pero en realidad, solo puede tener 2 versiones del gráfico (es decir, sus dos versiones de infraestructura) y 3 versiones de su aplicación. Si desea revertir, hágalo, puede elegir fácilmente qué Gráfico e imágenes desea implementar. Ejecute Helm con su gráfico, establezca sus valores en consecuencia para la imagen y estará listo.

Pase lo que pase, todavía tiene un vínculo entre una versión de una aplicación y una versión de infraestructura. Este es el propósito de Helm. Argumentar lo contrario es una locura.

Creo que discutir (idealmente discutir) cómo las cosas podrían cambiar a menudo conduce a mejorar las cosas. No creo que el "propósito" de Helm sea vincular un gráfico y una versión de la aplicación. Creo que su propósito es hacer que sea más fácil y seguro implementar aplicaciones en un clúster de Kubernetes, mientras mantiene sus manifiestos de Kubernetes SECOS y reutilizables. En ninguna parte necesita que un gráfico y una versión de la aplicación estén estrictamente vinculados (al igual que en la realidad en este momento, no es necesario que lo estén).

Entonces, nuevamente, como le dije a @iorlas , la pregunta es, ¿debería Helm adaptarse? ¿Cuál es la razón para no habilitar este caso de uso? Si la razón es simplemente "porque no lo hace actualmente", entonces esa es una razón bastante pobre si me preguntas. Nada de esta discusión hasta ahora parece haber respondido a esta pregunta.

... el producto al final de ese proceso de compilación (es decir, una imagen de Docker) depende tanto del Dockerfile como de lo que está colocando en él. ... Una imagen no puede existir sin esos dos componentes.

Entonces ... el paquete Helm necesita la versión Chart y la aplicación (= imagen de Docker) y no puede existir sin ella.

un gráfico de Helm puede existir incluso antes de que se cree una aplicación, literalmente, antes de que se escriba una sola línea de código. ... el Helm Chart podría existir completamente sin nada más. Como dije, esto sería inútil.

Lo curioso es que, en un proyecto, solíamos usar imágenes de stub docker para crear un prototipo de arquitectura. Literalmente usamos Gráficos sin escribir una sola línea de código. Además, siempre es un caso viable tener un gráfico que consta solo de subgráficos.

Entonces, mi hipótesis es : el paquete Helm es casi inútil sin una imagen de Docker. La imagen de Docker es casi inútil sin un código fuente. La diferencia es un nivel de abstracción. Ambas cosas son objetos similares a paquetes .

pero solo intento ilustrar mi punto de que no están vinculados en absoluto.

¡Sí, sí! Eso es realmente bueno, tenemos personas listas para discutir todo en detalle. Sin usted, sin proyecciones y afirmaciones, no ganaremos la vida en el futuro 😃

No creo que sea una afirmación audaz, sucede, ya es un hecho. ... Entonces, como dije antes, todo esto se reduce a; ¿Quieren los mantenedores de Helm habilitar este caso de uso, o no? No hay nada más que eso.

Hecho. Para realizar y aceptar dicho cambio, debe evaluarse: ¿ es lo correcto ?

Dejame contarte una historia. Martini era un gran marco web muy utilizado. La razón no fue la falta de horas para invertir, la razón no fueron algunas travesuras con las licencias. Entonces, la única forma de hacer que el futuro sea más brillante era desaprobar el marco completo, enojar a algunos, dejar algunos proyectos huérfanos y obligar a algunos a reevaluar las cosas que hacen.

Entonces, no estoy en contra de este enfoque. Veo cómo puede vivir (vea mi propuesta con helm run ). Pero aunque tenemos la oportunidad de hacer una intervención y, posiblemente, arreglar toda la industria mientras no es demasiado tarde, evaluaría cada uso, discutiría las desventajas y los problemas.

Para crear un gráfico de timón en ese escenario, se le pedirá que lo reconstruya cuando cambie su aplicación

Sip. Incluso ahora mismo podría ser un caso. Tenemos una canalización en la que, en lugar de push , estamos haciendo save / load de la imagen de la ventana acoplable. Y funciona bastante bien. No me apetece ahora mismo, pero fundamentalmente es mucho más limpio. El problema es que los K8 aún necesitarán el registro de la ventana acoplable remota como un bus para transferir la imagen de la ventana acoplable "de inicio".

Reduzcamos nuestro enfoque, chicos

Su gráfico de Helm estaría intrínsecamente vinculado a la versión de la aplicación que se está implementando, al igual que crear una imagen de Docker.

Esta es una diferencia clave aquí. Y @seeruk lo clavó. Y podemos concentrarnos en eso. Déjame parafrasearlo en hechos:

1. La imagen de Docker no está vinculada con el paquete Helm. Solo referencia a él.
2. Esto da la oportunidad de liberar estos caminos de forma independiente.

Preguntas clave:

1. ¿Cuáles son los riesgos del enfoque independiente? (es decir, qué pasa si algunos devops lo usan, qué argumentos diremos en su contra)
2. ¿Cómo lo resuelve el enfoque de empaquetado?
3. ¿Cuánto cuesta?
4. ¿Cómo vemos el futuro de la contenerización en esta pregunta en particular?

@seeruk :

Entonces, nuevamente, como le dije a @iorlas , la pregunta es, ¿debería Helm adaptarse? ¿Cuál es la razón para no habilitar este caso de uso? Si la razón es simplemente "porque no lo hace actualmente", entonces esa es una razón bastante pobre si me preguntas. Nada de esta discusión hasta ahora parece haber respondido a esta pregunta.

Haces muchas aclaraciones y puntos importantes. Personalmente, creo que Helm debería adaptarse. CI / CD es el futuro de cómo se construirá el software y, honestamente, con premios como --atomic helm ya se está volviendo más flexible como una herramienta de implementación confiable. Sin embargo, este problema es bastante antiguo, así que creo que fusionar las relaciones públicas no es "el siguiente paso" en el proceso.

¿Sería factible crear un complemento, digamos helm-ci-cd para esta característica particular de --app-version ( @jrkarnes probablemente pueda hablar con este como colaborador de relaciones públicas)? Creo que las necesidades de la comunidad para sacar a Tiller solo se reconocieron realmente después de que despegó el complemento. Hay varios otros problemas con Helm que se pasan por alto fácilmente y que pueden ser otros buenos candidatos para helm-ci-cd mire la dualidad install/ upgrade que nosotros CI / CD ppl ya hemos unificado a través de la envoltura.

Incluso si el cambio --app-version no es un valor agregado directo para los usuarios finales que intentan instalar una aplicación k8s sin tener que mirar los archivos de plantilla (lo cual, por cierto, nunca ha funcionado para debido a la necesidad de agregar políticas de red para cumplir con mi infraestructura de trabajo k8s) el usuario final todavía está obteniendo más valor porque la persona que construyó ese gráfico tuvo más facilidad para hacerlo debido a las características de helm ci / cd que hacen que la construcción sea estable y software confiable más fácil.

Acabamos de leer Chart.yaml con groovy, luego configuramos la versión de la aplicación y sobrescribimos el archivo durante el tiempo de implementación. Luego haz la actualización del timón. Sería bueno si fuera parte de Helm, pero no contaría con él.

Encontré esto a través de Google'ing. El mismo barco, en realidad.

Si verison: es la versión del gráfico, eso implica que esta versión cambia cuando cambian los YAML del gráfico. Dado que un gráfico es una plantilla con valores configurables, es seguro asumir que puede usar el Gráfico 1.3 para implementar aplicaciones de múltiples versiones, 1.2, 1.3, 1.6, 1.8, etc., sin modificar los archivos YAML del Gráfico.

Ahora viene en appVersion: codificado dentro de Chart.yaml, lo que le obliga a editar un archivo de gráfico para actualizar (y reflejar) la versión de la aplicación implementada.

Definitivamente existe la necesidad de una opción CLI --app-version que podamos usar dentro de las plantillas de gráficos para hacer referencia a la versión de la _aplicación_ para implementar diferentes versiones con el mismo gráfico version: 1.3.0 .

@seeruk

No creo que el "propósito" de Helm sea vincular un gráfico y una versión de la aplicación. Creo que su propósito es hacer que sea más fácil y seguro implementar aplicaciones en un clúster de Kubernetes, mientras mantiene sus manifiestos de Kubernetes SECOS y reutilizables.

Este es nuestro punto de discusión y no creo que ninguno de nosotros convenza al otro. A veces, en un entorno profesional, está bien tener diferencias irreconciliables cuando se trata de una cuestión de opinión. Ciertamente no estoy de acuerdo con todo lo que dice Stallman y si nos metiéramos en las trincheras sobre todo lo que él y yo estamos en desacuerdo, moriríamos antes de llegar a un consenso.

Lo dije más adelante en la discusión y creo que vale la pena repetirlo:

[...] Supongo que helm solo implementa realmente paquetes. Parece ser la única cosa semánticamente correcta que puede decir; sin embargo, el argumento sobre cómo se distribuyen estos paquetes parece ser la causa fundamental de este debate en la práctica. Específicamente, "¿actualizar o cambiar la versión de la aplicación constituye un nuevo paquete?"

Un gráfico de timón de primera parte (me gusta usar MySQL, así que seguiré usándolo) sin configuración debería instalar un recurso en un clúster como el creador del gráfico lo describió y pretendió . Mirando el gráfico real para mysql, hay dos propiedades que son configurables que involucran al motor mysql real:

• image (predeterminado mysql )
• imageTag (predeterminado 5.7.14 )

Luego, en su archivo Chart.yaml :

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

Tenga en cuenta que appVersion y el valor predeterminado imageTag no coinciden . Si ejecuto helm list , obtendré un informe de que la "versión de la aplicación" (leer; versión del motor) es un estado _que no refleja la versión real de la aplicación que está instalada en el clúster_.

En ninguna parte necesita que un gráfico y una versión de la aplicación estén estrictamente vinculados (al igual que en la realidad en este momento, no es necesario que lo estén).

Esto es correcto; y en mi opinión, un defecto de diseño.

Entonces, nuevamente, como le dije a @iorlas , la pregunta es, ¿debería Helm adaptarse?

Si. Abordaré algunas sugerencias en un momento.

@IRobL

¿Sería factible crear un complemento, digamos helm-ci-cd para esta característica particular de la versión de la aplicación ( @jrkarnes probablemente pueda hablar con este como un colaborador de relaciones públicas)?

Responde a su propia pregunta con:

Incluso si el cambio --app-version no es un valor agregado directo para los usuarios finales que intentan instalar una aplicación k8s sin tener que mirar los archivos de plantilla, el usuario final aún obtiene más valor porque la persona que construyó ese gráfico fue más fácil hacerlo debido a las características de helm ci / cd que facilitan la creación de software estable y confiable.

Si tenemos que hacerlo como un complemento para que la función sea correcta, entonces abogaría por ese enfoque; sin embargo, creo que está abordando el problema equivocado. Como le dije antes a @seeruk , creo que el hecho de que appVersion sea ​​una propiedad intrínseca en el archivo Chart.yaml inmutable es un defecto de diseño. appVersion es una propiedad de image que se está instalando en el clúster a través del gráfico, y se deriva de alguna manera de la imagen a la que se hace referencia con su tag .

Al pensar en un complemento helm-ci , ¿qué otras características o complementos esperaría que estuvieran allí? No creo que simplemente alternar las propiedades appVersion de las inmutables Chart.yaml sea ​​un valor agregado suficiente para justificar ser un complemento.

@IRobL y @seeruk juntos:

Creo que nuestras opiniones divergentes provienen de quién consideramos que es el usuario final más común de helm. Si se supone que el usuario final es alguien que no va a realizar mucha configuración o profundizar en las plantillas, entonces helm ls puede no ser particularmente útil y el punto es discutible.

Sin embargo ... si está usando helm como herramienta administrativa y asistente para administrar un clúster O si está utilizando Helm en un contexto más de CI / CD, entonces el cambio --appVersion termina siendo mucho más más útil y, por lo tanto, un punto de preocupación (y configuración),

En un mundo perfecto, diría que appVersion debería ser una propiedad derivada y provenir de los metadatos de la imagen de la ventana acoplable; esto no es factible para Helm, ergo, la falta de contención.

A lo que dije sobre

Si. Abordaré algunas sugerencias en un momento ...
... al pensar en un complemento helm-ci , ¿qué otras características o complementos esperaría que estuvieran allí?

Tengo una lista personal que podría ser un buen punto de partida:

• Ejecutar helm en el modo CICD no compararía _sólo_ el estado de los paquetes lanzados anteriormente con lo que se está aplicando actualmente. . En su lugar, cada implementación de una versión aplicaría por completo todos los manifiestos con plantilla cuando se ejecuta upgrade .
• helm-cicd debería ajustar los comandos base de Kubernetes. No puedo contar la cantidad de veces que he intentado ejecutar helm describe o helm logs .
• helm-cicd debería permitirme ver cuáles son los resultados de los comandos cuando los ejecuta un usuario diferente. Si usamos RBAC, me gustaría ver qué sucede cuando un usuario no autorizado intenta hacer algo.
• helm-cicd debería poder descomponer un espacio de nombres en una colección de manifiestos para editarlos más tarde.
• helm-cicd debería poder _trasplantar_ una versión en un espacio de nombres.

Esos son los más importantes ... pero discutir un complemento helm-ci completo está fuera del alcance de este PR / Problema (actualmente).

Leo todo lo que escriben y aprecio el discurso. Espero sus respuestas.

Estoy bastante ocupado con mi tiempo en este momento, pero quiero corregirlo en algunos puntos. @jrkarnes

Creo que el hecho de que appVersion sea una propiedad intrínseca en el archivo inmutable Chart.yaml es un defecto de diseño

No lo es. Cuando algo se hace de esta manera y no de otra, siempre hay una razón, aunque sea salvaje . En este caso, es la ideología que defiendo: un paquete = una compilación, gráfico = plantilla para las compilaciones, paquete = aplicación + infra.

Helm está diseñado en torno a esta ideología, para tratar K8s como sistema operativo y el paquete como instalador / actualizador de su aplicación. Tiene algunos problemas, a veces parece demasiado, pero ciertamente es un futuro.

_¿Por qué creo que está diseñado así? El mismo helm list está configurado para mostrar las versiones actuales de los paquetes instalados.

De acuerdo, tenemos muchos gráficos (públicos como mysql y locales, como probablemente los tenga) que no están diseñados para crear un paquete cada vez que aparece una nueva versión. Y admiro esta necesidad, ya que la migración a una solución de alto nivel requiere un tiempo. Además, alguien necesita compilar paquetes y sería difícil convencer a los encargados de mantenimiento de mysql de que creen un paquete Helm para cada compilación.

Con el gráfico MySQL hay un problema adicional. Tiene razón, sería mejor ver la versión de MySQL instalada en helm list , pero es solo una parte de la versión, ya que también hay una etiqueta de imagen, que probablemente sea parte de la versión aquí.

Entonces, nuevamente, como le dije a @iorlas , la pregunta es, ¿debería Helm adaptarse?
Si. Abordaré algunas sugerencias en un momento.

Nuevamente, hubo una propuesta para agregar helm run , que es lo que todos están buscando. Está diseñado para usar Chart como paquete al instante, lo que permite proporcionar versiones de la aplicación y todo.

En un mundo perfecto, diría que appVersion debería ser una propiedad derivada y provenir de metadatos de imágenes de Docker; esto no es factible para Helm, ergo, la falta de contención.

Estás viendo la imagen de Docker como un producto final, como el último paquete, que es la última fuente de verdad. No lo es. Cuando no tiene nada más que una imagen de Docker, puede ser engañado para que crea que es su software. Cuando estás escribiendo un módulo en tu código, te engañan para creer que este módulo es tu software.

El problema es que no lo es. Es solo una parte, un artefacto. Desde productos pequeños a grandes, tendrá muchos artefactos unidos. A veces, pasará versiones en el archivo de la ventana acoplable dentro del proceso de compilación, a veces tendrá un ConfigMap, que une varios artefactos. Y no tendrá un archivo de ventana acoplable que lo tendrá todo.

Tengo una lista personal que podría ser un buen punto de partida.

Creo que tiene muchas sugerencias, pero se siente más vivo como una bifurcación de Helm , más bien como un complemento salvaje. Yo diría que no tiene nada que ver con CI de CD exclusivamente. Yo diría que no se debe construir tal bifurcación / complemento, sino discutir y encontrar las soluciones adecuadas. Nadie necesita 3 horquillas Helm, considerando que la comunidad actual no es tan grande en este momento.

¡Atención por favor!

De acuerdo, tenemos muchos pensamientos allí y allá. Creo que el mejor escenario sería tener:

• Posibilidad de cambiar la versión de la aplicación, sin necesidad de crear paquetes primero
• Posibilidad de ver la versión adecuada de la aplicación en helm ls
• Permita que cualquier API (como el operador de Helm) especifique / actualice la versión de la aplicación sin estado intermedio

Tenemos dos enfoques proporcionados:

1. helm install se crea para instalar un paquete. También admite la instalación del gráfico, pero es limitado. Simplifiquemos helm install y dejemos que cumpla su propósito: instalar paquetes. En segundo lugar, agreguemos helm run , cuya intención es proporcionar un flujo simplificado: combine helm package y helm run , proporcione los argumentos de ambos comandos, pero filtre los que no tienen sentido en tal caso .
2. Agregue app-version en helm install cmd. Inflará esta API y ocultará la idea de usar paquetes, ocultará (como lo hace ahora) la ideología de usar paquetes como instaladores, lo que tiene total sentido al menos para algunos, si no la mayoría, de los proyectos.

¿Podemos acordar que estos dos enfoques resolverán todas las luchas que tenemos ahora?

Un complemento es una solución para una característica que falta y que los desarrolladores principales no quieren admitir o no tienen tiempo para hacerlo, por lo que no me importaría si es un complemento.

Helm está diseñado en torno a esta ideología, para tratar K8s como sistema operativo y el paquete como instalador / actualizador de su aplicación.

Oooh. Lo entiendo. Un [paquete] de gráfico de helm está destinado a ser un "rpm" [por decir] para Kubernetes. No es la impresión que tuve: Helm usa gráficos para implementar una aplicación. El gráfico / paquete es la aplicación "formateada para k8s".

Estoy bien con eso. Tiene sentido: ahora necesitamos actualizar nuestro servidor de compilación para actualizar la versión de la aplicación a medida que construimos nuevos contenedores:

• Contenedor de compilación: etiqueta "v1.2"
• Actualice Chart.yaml - appVersion: "v1.2" --- Veo que ya hay un comando helm package --app-version .
• Gráfico de paquete: helm package --app-version v1.2 => paquete [gráfico] -v1.2.tgz (es decir, un "paquete [gráfico] -v1.2.rpm")
• Implementar el paquete usando servidores de implementación, helm install package [gráfico] -v1.2 (por ejemplo, apt install [email protected])

Ahora, ¿estoy equivocado en la comprensión de algo de esto? Si package-v1.2 no es appVersion v1.2, ¿por qué no? ¿No sería esa la intención? por ejemplo, rpm es la versión de la aplicación, no el paquete (Gráfico).

Editar:

Si package-v1.2 no es appVersion v1.2, ¿por qué no? ¿No sería esa la intención?

Ahora veo por qué la gente comenta que Chart.version y Chart.appVersion están al unísono. Los argumentos pueden ir en ambos sentidos aquí ... una aplicación con una compilación de "gráfico" estable, esperaría que package-v1.2 cambie sus números de versión. Pero también podría argumentar que package-v1.2 sería el número de versión de Chart, cuando cambien los archivos yaml.

¿Cómo gestiona una versión estable de Chart (1.2), diferenciándose de una versión creciente de la aplicación (1.6)? ¿ package-[version] será 1.2? o 1.6? Supongamos que implementa una versión de Chart 1.2 pero la appVersion cambió en el empaque: 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

:(

.... Muy confuso.

Un [paquete] de gráfico de helm está destinado a ser un "rpm" [per-say] para Kubernetes

¡Exactamente! Pero a veces se siente demasiado estricto o demasiado complicado, aquí es donde se necesita un atajo.

Ahora, ¿estoy equivocado en la comprensión de algo de esto? Si package-v1.2 no es appVersion v1.2, ¿por qué no? ¿No sería esa la intención? por ejemplo, rpm es la versión de la aplicación, no el paquete (Gráfico).

Este es un problema para otra discusión, pero actualmente el paquete llevará el nombre de la versión del gráfico, no de la versión de la aplicación. No sé la razón, siento que debería ser al revés. Creo que es un problema histórico, pero en mi opinión, como en la tuya, debería ser package-{app-version}.tgz .

Según mis mensajes anteriores, hay 4 componentes para la versión:

• Gráfico
• Aplicación
• Paquete
• Liberar

Es un dolor de cabeza versionar todas estas cosas de forma independiente, pero así es como funciona en este momento. Con una excepción: el paquete tiene una versión posterior a la versión del gráfico.

Si elegimos una ideología para empaquetar la aplicación, la versión de la aplicación tendría mucho sentido, ya que el mismo proceso produce tanto la aplicación como la imagen y el paquete. Entonces, cuando vayamos al paso de entrega, será obvio cómo se llaman los archivos, qué archivo instalar. Ahora mismo tenemos que codificar el nombre del paquete en las canalizaciones> _ <

@iorlas

Estás viendo la imagen de Docker como un producto final, como el último paquete, que es la última fuente de verdad. No lo es. Cuando no tiene nada más que una imagen de Docker, puede ser engañado para que crea que es su software. Cuando estás escribiendo un módulo en tu código, te engañan para creer que este módulo es tu software.

Me tomó un par de semanas pensar en esta afirmación y estoy 100% de acuerdo con usted. Además, ahora entiendo de dónde se origina nuestra diferencia de opiniones ...

Sigo una filosofía de desarrollo e implementación según la cual debería construir un sistema a partir de componentes pequeños que hacen un conjunto de cosas increíblemente bien (piense en UNIX); sin embargo, los sistemas modernos pueden tratar una "aplicación" como una agrupación de estas pequeñas herramientas. ¿Cómo se supone que debe marcar la "versión" de una aplicación cuando depende no solo del artefacto de la ventana acoplable, sino también de los otros subcomponentes (que también pueden ser artefactos de la ventana acoplable)? No es una respuesta tan sencilla cuando empiezas a lanzar este tipo de acoplamiento.

Responder a esta pregunta está mucho más allá del alcance de este problema / solicitud. Para volver a la raíz del problema, me gustaría hacer una diferenciación entre install y run . Sobre la base de la semántica, install solo debería operar en paquetes, y run debería "ejecutar" helm a través del proceso de generación de plantillas y aplicarlas _sin mantener el estado_.

Si bien muchas veces deberíamos usar helm template para ver cómo se implementará un gráfico prospectivo, es muy útil verlo suceder vi-ca-vi run que tiene un El doble propósito de ser una estrella en las tuberías de desarrollo (donde no necesariamente queremos mantener un paquete porque no tiene valor si la velocidad es muy alta).

Con el gráfico MySQL hay un problema adicional. Tiene razón, sería mejor ver la versión de MySQL instalada en la lista de helm, pero es solo una parte de la versión, ya que también hay una etiqueta de imagen, que probablemente sea parte de la versión aquí.

Como dije, en un universo perfecto, la versión de un objeto instalado sería introspectada. Sin embargo, esto me da una idea.

Si tenemos en cuenta lo que dije al principio sobre cómo se implementan los gráficos, ¿qué pasaría si tuviéramos la capacidad de desplegar todos los subcomponentes con una bandera en helm describe ? Eso no soluciona la necesidad de especificar la versión de la aplicación, pero deja más claro exactamente qué está instalado (que es parte de la fuerza impulsora detrás de querer ajustar la versión de la aplicación con una bandera).

Leo todos los comentarios y no tengo una opinión totalmente calificada al respecto.

Llegué aquí porque mi empresa mantiene un repositorio privado de Helm y el 90% de nuestros gráficos son principalmente una implementación que tiene una especificación de contenedor. En estos casos, si pudiéramos usar appVersion para listar la etiqueta de la imagen, evitaríamos duplicar una variable y podríamos ver esta versión corriendo helm version .

Después de leer este hilo, me parece que esto sería conveniente, aunque realmente bueno que usaría si alguna vez se fusionara.

Como se solicitó, incluiré mi última respuesta del hilo anterior para que otros la vean.

Mmm. Aquí es donde las cosas comienzan a contradecirse cuando comienzas a vincular appVersion a una etiqueta de Docker (una asociación lógica). Aquí es donde tenemos problemas, es decir, el escenario de desarrollo que mencioné anteriormente. Dado que version debe ser un SemVer, simplemente no podemos usar etiquetas de Docker como un gráfico version .

¿Cómo creamos una diferencia de versión visual para los desarrolladores cuando appVersion no es evidente en las listas?

Debido a cómo funciona k8s con las aplicaciones de TI: en un mundo de desarrollo, ha habido alguna forma de permitir versiones de etiquetas en todos los ámbitos.

No podía hacer cosas como SemVer en términos de los operadores ~ o ^, porque la versión estaba puramente ordenada, sin semántica.

¿Por qué no? Hacemos esto todo el tiempo con php composer . Podemos usar SemVer o podemos usar versiones de cadenas que simplemente se analizan o ignoran en el esquema de control de versiones, es decir, si version no es un número SemVer, no lo incluya en ~ y ^ coincidencia de patrones.

Ya que está citando mi comentario sobre el número 7299 ,

Para los paquetes .deb y .rpm, la cadena de versión se divide de formas específicas (mediante guiones), pero no tienen un significado semántico como "Esto es compatible con API con eso", por lo que no puede generar una expresión como "Dar me la última versión compatible con API "o" Dame la última versión con una API sin cambios ", como puedes con SemVer.

Recuerdo que tanto Debian como RedHat usaron alias de paquetes para lograr esos casos de uso (y compatibilidad ABI) generalmente basados ​​en números de versión. Esto permitió un comportamiento razonablemente consistente usando solo nombres de paquetes y comparaciones solo de pedidos.

Sobre el tema general, la forma en que usamos los gráficos de Helm para nuestro producto es para empaquetar nuestros diversos servicios. Sin embargo, las imágenes de Docker son un mero artefacto y su denominación depende de la versión del servicio, para la cual hemos adoptado SemVer porque ofrecen API.

Nuestra canalización de CI convierte repositorios git de código y scripts relacionados, y produce gráficos de Helm que se pueden instalar y que hacen referencia a imágenes de Docker. Las etiquetas de las imágenes de Docker no son interesantes para nuestros usuarios. Luego etiquetamos con el git SHA de donde provienen, y luego volvemos a etiquetar las imágenes utilizadas en un lanzamiento. El principal beneficio de volver a etiquetar es que sabemos que nunca debemos quitar la etiqueta, mientras que podemos quitar la etiqueta de las versiones de git-SHA después de un período corto.

Así que estoy bastante contento con la forma en que Helm trabaja para nosotros, porque version contiene la versión exacta de nuestro software, y appVersion contiene lo mismo pero como una cadena, y nadie mira en nuestro repositorio de Docker.

Estoy un poco menos contento con la forma en que se versionan los gráficos en https://github.com/helm/charts/ , ya que allí se versiona el gráfico , no el software, lo que lleva a un gráfico menor ocasional version de un gráfico de la versión de las cosas que contiene.

Tenemos un problema similar con el gráfico estable / prometheus-operator , en nuestra página interna "Bibliotecas y artefactos consumidos externamente". Eso contiene un montón de piezas de software diferentes, por lo que la pregunta "¿En qué versión estamos?" y particularmente "¿Es seguro actualizar?" son mucho más difíciles de responder que para Agones, cuyas versiones de la misma manera que lo hacemos nosotros.

@jrkarnes

Si tenemos en cuenta lo que dije al principio sobre cómo se implementan los gráficos, ¿qué pasaría si tuviéramos la capacidad de desplegar todos los subcomponentes con una bandera en el timón para describir? Eso no soluciona la necesidad de especificar la versión de la aplicación, pero deja más claro exactamente qué está instalado (que es parte de la fuerza impulsora detrás de querer ajustar la versión de la aplicación con una bandera).

Absolutamente me encantaría ver eso. Hay una solicitud de función relacionada en # 6932, por ejemplo.

Habiendo retrocedido la discusión, la idea de que appVersion está relacionada con los metadatos de la imagen de Docker definitivamente no se ajusta a nuestro caso de uso, como lo hacen al menos algunos de nuestros gráficos (los que nuestros usuarios tratan principalmente) no contienen imágenes de Docker, ya que son en su mayoría hosts para recursos compartidos (por ejemplo, claves públicas JWT, values.yaml ) más un requirements.yaml para extraer otros gráficos.

la idea de que appVersion está relacionada con los metadatos de imágenes de Docker definitivamente no se ajusta a nuestro caso de uso, ya que al menos algunos de nuestros gráficos

No estoy diciendo que ese fuera el uso previsto. Simplemente dije que es una asociación lógica. Todavía estás usando appVersion como un "contenedor lógico" de tus yamls internos.

Todavía no sé cómo bloquear version en SemVer tiene algún beneficio. ¿Podría Helm simplemente analizar-probar version (y appVersion ) y continuar desde allí?

Supongo que mi punto fue que no estamos usando appVersion en absoluto, generalmente no está presente en nuestro Chart.yaml, y cuando está presente, es idéntico a version .

El beneficio de bloquear version en SemVer es que puede usar los diversos operadores SemVer en él y analizarlo de manera confiable para producir pedidos y coincidencias mediante la instalación.

Los sistemas de empaquetado RPM y DEB tienen lo mismo, excepto que sus sistemas de control de versiones usan una sintaxis diferente, pero siguen siendo una sintaxis restringida por razones de análisis semántico. También tienen una semántica diferente que les importa.

Dado cómo se ejecutó el repositorio de helm / charts, siento que un solo campo version con una versión de estilo DEB o RPM hubiera sido una mejor opción que SemVer más appVersion string. Sin embargo, ese es un barco completamente diferente, ya navegado. Y habiendo sido un proveedor y un empaquetador de Debian en mi juventud, agradezco no tener que hacer malabares con "¿Cuál de los números de versión se debe agregar aquí?" en nuestros paquetes " version es la única verdad".

El problema con "a veces es SemVer" es que SemVer se parece mucho al analizador-indistinguible de algo que podría escribir a mano o encontrar en otro lugar, como una versión del paquete Debian que no tiene una época, con resultados desastrosamente confusos. .

Hola. No hay novedades sobre esta función.

Después de leer todos los comentarios, puedo ver que sería de gran ayuda.

De hecho, en nuestra empresa, como obtuvimos varias aplicaciones que usaban las mismas tecnologías y se implementan de la misma manera, tenemos un gráfico para diferentes aplicaciones para evitar duplicaciones.
Empaquetamos un nuevo gráfico solo cuando hay cambios de infraestructura.
Y es solo cuando actualizamos o instalamos una versión que aplicamos valores específicos como etiqueta, variables env ...

Consideramos que el gráfico de helm empaquetado es la capa de abstracción que representa los recursos de Kubernetes y la estructura esperada para un tipo de aplicaciones y solo durante la implementación decimos "ok, quiero que este tipo de aplicación se implemente en ese entorno con estos valores específicos".

Como la lista de timones debería mostrar información de la versión, deberíamos poder ver la versión de la aplicación implementada dentro de esta versión.

Dejé el comentario en un problema similar https://github.com/helm/helm/issues/7517
¿Podemos agregar la capacidad de anular esto en values.yaml?
Luego obtenemos la opción de línea de comando gratis --set

Si intentamos usar Helm para cualquier aplicación, esto es una mierda. Nadie utiliza el control de versiones semántico para aplicaciones de producción.

Estoy de acuerdo. Actualmente estamos bloqueados por usar Chart Museum para gráficos basados ​​en _aplicaciones_ inmutables. Chart version! = Versión de la aplicación, por lo que es imposible que lo publiquemos a través de Chart Museum.

Leí un montón (no todo) de la discusión anterior, lo siento si estoy repitiendo algunos puntos / puntos de vista. Estoy tratando de dar una respuesta más considerada.

Me gusta ver appVersion cuando hago un helm ls y cambiar conceptualmente de .Values.image.tag fue bueno, PERO no poder configurarlo en el momento de la implementación es un obstáculo real y es algo que he tenido volver a.

Estoy firmemente en que (gráfico) version es la versión del gráfico y appVersion es la etiqueta de la ventana acoplable. En nuestro proceso de CI, la etiqueta de la ventana acoplable también es una etiqueta de git.
También tenemos varios microservicios y tenemos el deseo de mantener las cosas lo más SECAS posible. Tenemos gráficos genéricos en un repositorio de gráficos local porque la gran mayoría de las aplicaciones java-springboot son las mismas. La mayor parte de las aplicaciones de Tomcat son las mismas (pero diferentes de las de Springboot). Enjuague y repita para otras tecnologías. Luego tenemos valores ambientales a medida que la implementación se abre paso a través de varios entornos.
Cada uno de estos microservicios luego hace uso del gráfico genérico a través de CI / CD
eg helm upgrade release-name private-repo/generic-chart --values <environment>.yaml --set image.tag=<docker tag from build step> --namespace <environment> --install Preferiría usar .Chart.AppVersion lugar de .Values.image.tag pero DEBO poder implementar de una manera que sea eficiente para nuestra Org.

Si hago un helm ls , tengo CHART y APP VERSION por lo que toda la versión del gráfico debe coincidir con la versión de la aplicación. Continuar por esa ruta solo alienará a la gente y en algún momento el proyecto se bifurcará porque esa mentalidad es demasiado estricta y no es lo que mucha gente busca. También está comenzando a tomar la ruta de "Eliminemos image.* , nameOverride & fullnameOverride . Image. * Se puede codificar en deployment.yaml, etc." por razones MUY similares.

Un último punto es que muchos gráficos públicos no coincidirán exactamente con la versión del contenedor de la ventana acoplable que utilizan. Eche un vistazo a los contenedores docker más conocidos, por ejemplo, alpine o nginx, donde las versiones principales y secundarias son etiquetas móviles y solo las versiones de parche no funcionan. Tener un mapeo 1: 1 para cada versión de parche presenta una sobrecarga bastante significativa con poco o ningún beneficio.
No es raro que los entornos de producción no puedan actualizar a la última versión por una multitud de razones. Ni siquiera hable con la mayoría de los lugares sobre versiones rodantes en producción.

El resultado de todo lo anterior plantea la pregunta "¿Por qué Helm puede utilizar un repositorio de gráficos?".
No poder sobrescribir appVersion en el momento de la instalación / actualización significa que ya necesita descargar y desempaquetar el gráfico, editar appVersion por instalación / actualización, o también podría empaquetar los contenedores Docker necesarios en el gráfico.
La excepción es cuando se lleva a cabo una instalación completamente estándar, y ya hay mucho debate en torno a la generación automática de contraseñas y cosas por el estilo.
Sé que los últimos párrafos parecían como si me estuviera yendo por un agujero de conejo y me pintara a mí mismo en una esquina, pero eso ES donde "appVersion es la etiqueta de la ventana acoplable Y no puede configurar appVersion a través de la línea de comando o valores" nos lleva.

@timothyclarke : Lo que podría querer hacer, para el caso de uso helm upgrade que describió aquí, es helm package primero, lo que le permite configurar --version y --app-version , y luego puede helm install el tarball, y mantenerlo como un artefacto CI, lo que aumenta su reproducibilidad para la instalación, ya que no necesitará ningún parámetro --set agregado. A eso es a lo que nos hemos trasladado, aunque sin el aspecto de "gráfico genérico", ya que nuestros gráficos no son genéricos.

También es una buena oportunidad para agregar metadatos de compilación al Version , con algo como +g<shortCommitSHA> .

Según # 7517, eso me permitió eliminar un montón de llamadas sed que estaban reescribiendo image.tag antes de instalarlas en nuestro grupo de pruebas de CI, y luego nuevamente cuando se empaquetaran más tarde.

Este enfoque podría resolver los problemas que la mayoría de las personas han encontrado aquí, si están creando sus propios gráficos y, en particular, si están instalando desde la fuente del gráfico en su pago. Realmente no ayuda si necesitan esta funcionalidad para un gráfico proveniente de un repositorio, pero creo que ese es un problema diferente al que la mayoría de la gente está enfrentando.

Para mí, el riesgo de anular una versión de la aplicación (o versión) en el momento de la instalación es que no es tan claramente visible para otra persona que intenta recrear el gráfico, que esto se hizo. A menos que de alguna manera se haya pirateado el soporte de valores, no estará allí cuando se extraiga la configuración actual del gráfico usando helm get values -o yaml , por lo que se convierte en _una cosa más_ que hace que la implementación de su gráfico en vivo sea diferente de lo que obtiene con helm install <some way to specify a particular package> --values <values from helm get values> , por ejemplo, al intentar reproducir un problema visto en producción en una configuración de prueba.

Para mí, el riesgo de anular una versión de la aplicación (o versión) en el momento de la instalación es que no es tan claramente visible para otra persona que intenta recrear el gráfico, que esto se hizo. A menos que de alguna manera se haya pirateado el soporte de valores, no estará allí cuando se extraiga la configuración actual del gráfico usando helm get values -o yaml

Le diste al clavo. Esto debería tener bee en values.yml desde el primer día.

Si bien entiendo los argumentos filosóficos en contra de esta característica, la práctica de campo muestra que ayudaría mucho a las personas, incluidos nosotros.

Hay muchos gráficos en la naturaleza que le permiten configurar la versión de la aplicación a través de values.yml , específicamente porque no se puede configurar aquí.

No estoy seguro de si eso se ha discutido (hice un rápido CTRL + F y no pude encontrar ningún rastro), pero ¿qué hay de eliminar appVersion todos juntos como una solución alternativa? Me parece que evitaría toda la confusión.

En este momento, appVersion se trata como una especie de valor "especial". Supongo que está ahí para proporcionar visibilidad, por ejemplo, puedo tener la versión de gráfico 123.5.6 de Prometheus, pero tendrá appVersion: 2.17.1, así que sé qué versión de parche de seguridad tiene y qué características de Prometheus esperar y puede buscarlo usando helm ls .

Supongo que podría proporcionarse de alguna manera diferente. ¿Quizás a través de etiquetas de lanzamiento? O tal vez jsonPath consulta sobre todas las versiones, similar a lo que es posible con kubectl por ejemplo:

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

Luego, el soporte de eso se cambiaría a las mejores prácticas, en lugar de ser aplicado por helm . También se podría peinar.

Por otro lado, podría ser que muchas personas confíen en la implementación existente de appVersion , que también debe tenerse en cuenta.

¿Quizás dar un paso atrás y comprender por qué se ha agregado exactamente appVersion ayudaría a resolver este problema?

@bokysan Anteriormente estaba en values.yaml se movió a Chart.yaml Supongo que para todo el helm ls muestra tanto el gráfico como la etiqueta de la ventana acoplable en lugar de tener que ejecutar un comando como como
kubectl get deployment <release name> -o jsonpath='{.spec.template.spec.containers[0].image}'

@TBBle Abordaría cada uno de tus puntos, pero haría que esta publicación sea tan larga como la anterior. Creo que todo este problema se debe a que alguien decide que un gráfico genérico no es un caso de uso válido únicamente al mirar los gráficos en el repositorio público.

Toda la premisa de appVersion fracasa tan pronto como necesita comenzar a usar initContainers y sidecars. Para dar un ejemplo del mundo real, uno de los proyectos que actualmente necesito administrar tiene nginx con un sidecar php. Las etiquetas nginx y php no cambian con frecuencia. El contenedor / versión de php es muy importante para los desarrolladores que escriben el código. El contenedor que cambia con más frecuencia es el initContainer que proporciona el contenido.
¿Pongo appVersion en el initContainer , en el php contenedor o es nginx , y al elegir solo uno de estos, qué información se ha perdido?

Si es importante para sus usuarios, entonces debería ser la versión PHP, ¿no? Eso es lo que estás anunciando. También puedes pegar los tres en tu appVersion, después de todo, es un campo de texto libre.

Si desea forzar la etiqueta de imagen de contenedor appVersion ==, entonces lo encontrará desafiante con gráficos no triviales, es decir, gráficos con más de un contenedor o sin contenedores. Sin embargo, ese no es realmente el punto, o sería imageVersion . Si está empaquetando una sola aplicación upstream, use su versión. Si está creando un paquete de varias aplicaciones ascendentes, elija una, por ejemplo, prometheus-operator's chart, o ignore appVersion, ya que es un campo opcional.

Si la fuente de su gráfico es _ parte de_ la aplicación, por ejemplo, Agones, simplemente deje appVersion blanco, o cópielo de version si tiene herramientas que dependen de él.

Ninguna de estas cosas necesita ser una decisión de helm install . Como mencioné anteriormente, helm package llega lo suficientemente tarde para todos los flujos de trabajo, excepto "cambiar una versión ascendente diferente en el momento de la instalación para un gráfico de terceros" y eso debería estar en --values o --set como todas las demás acciones de "cambiar X en el momento de la instalación".

Honestamente, la característica real que falta es probablemente "pasar appVersion a tpl ", por lo que puede hacer que se lea desde .Values.image.tag o lo que sea que funcione para usted.

Si desea forzar appVersion == etiqueta de imagen de contenedor

Entonces probablemente estemos en https://github.com/helm/helm/issues/7517 De ahí tal vez de donde proviene todo esto.

No entiendo en absoluto esta discusión. ¿Por qué no dar a las personas la opción de usar la versión de la aplicación de la manera que consideren más adecuada para ellos es un gran problema?

En una forma actual para mí, será mejor no tener este APP VERSION en absoluto. Solo está trayendo confusión a la gente de nuestro proyecto. Tenemos> 80 servicios que utilizan el mismo gráfico de timón y, como no es posible cambiar fácilmente este APP VERSION en el helm upgrade -i ... , veo que todas nuestras aplicaciones se quedarán para siempre con 1.0 aquí. Y no planeo volver a empaquetar el gráfico ya empaquetado para simplemente cambiar la versión de la aplicación. ¿Por qué debería complicar mi IC para que se ajuste a su diseño?

También veo que solo necesito decirles a todos que no usen helm list ya que será algo que no les será útil. Para comprobar qué versión de nuestras aplicaciones tienen, necesitarán usar algo más.

Era optimista al comienzo de la lectura de esta conversación, pero después de ir hasta el final viendo cómo discuten esto y cómo luchan para obligar a los usuarios a tener su forma de pensar, perdí la esperanza ahora :(.

Tener dos salidas diferentes "CHART (versión)" y "VERSIÓN DE APLICACIÓN" en helm list , helm history y similares es muy útil y evita la necesidad de profundizar en las opciones de la línea de comandos y el análisis de salida para obtener los hechos más importantes.

Si "GRÁFICO (versión)" y "VERSIÓN DE LA APLICACIÓN" están vinculados en el momento de la compilación ("paquete de timón"), todo el beneficio de tener dos valores diferentes se pierde un poco. Crear un gráfico y actualizar la VERSIÓN DE LA APLICACIÓN sin incrementar / actualizar la VERSIÓN DEL GRÁFICO resultará en un gran problema, ya que la misma VERSIÓN DEL GRÁFICO le dará resultados muy diferentes. : - <

Entonces, por ahora, nos vemos obligados a construir el paquete con cada lanzamiento e incrementar "GRÁFICO (versión)" y "VERSIÓN DE LA APLICACIÓN" en sincronización para no encontrarnos en una situación loca o poco clara.

Como acabo de aprender, podríamos eliminar "VERSIÓN DE APLICACIÓN", ya que es opcional y usar algún valor personalizado y usarlo en lugar de {{Chart.appVersion}} para nuestra imagen ... pero luego helm list ser mucho menos informativo. : - <

Desde la perspectiva de los usuarios (desarrolladores):

• capacidad de establecer alguna propiedad / bandera / valor de la versión en el momento de la
• capacidad de ver esa propiedad de versión / bandera / valor en la lista de timón / salida del historial con la etiqueta "Versión XX"

¿Alguna posibilidad de que podamos hacer eso?

Si "GRÁFICO (versión)" y "VERSIÓN DE LA APLICACIÓN" están vinculados en el momento de la compilación ("paquete de timón"), todo el beneficio de tener dos valores diferentes se pierde un poco.

Creo que este es el quid de la desalineación. La ventaja de la versión de la aplicación tal como la uso, y como parece ser la intención de la configuración actual, es que conoce la versión de una aplicación empaquetada _ para esa versión de gráfico_, porque la versión de gráfico es la versión de todo el gráfico, no la versión de las plantillas en el gráfico. Odiaría tener todas las declaraciones como "Requerimos la versión ~ XY del gráfico de Helm" para requerir "Oh, y no te metas con la AppVersion" agregada al final.

Este beneficio se pierde de la versión de la aplicación (y la versión real de la aplicación) se cambia en el momento de la instalación, porque ahora la versión del gráfico no le dice qué aplicación está usando y pierde la capacidad de usar SemVer para asegurarse, por ejemplo, tiene la versión más reciente pero compatible con API.

Para el caso de uso que describe appVersion sea ​​una plantilla que apunte a una entrada de valores haría que helm list hiciera lo que se desea, siempre que el gráfico admita tener su La versión de la aplicación (probablemente una etiqueta de contenedor) cambió en el momento de la instalación, a través de --set o --values como cualquier otra opción de configuración "cambiado en el momento de la instalación".

Aquí donde tuve un problema con AppVersion .

Estamos utilizando tanto la versión de lanzamiento como AppVersions.

Para configurarlos ahora, tengo que llamar al helm package explícitamente de antemano de helm upgrade --install para crear un archivo tar local con ambas versiones configuradas.

Ahora estoy agregando el soporte helm-secrets , y ...
¡Y su envoltorio no puede funcionar con helm package !

¿Y ahora qué?
¿Eliminar el soporte y el flujo de todas nuestras versiones?
¿Soltar usando secretos?
¿Algunas ideas?

En realidad, es más un problema para el helm-secrets , pero está relacionado con la habilidad --set app-version discutida aquí también, porque si pudiera usarlo de esta manera, no necesito llamar al helm package en absoluto.

UPD Oh, espera ... todavía puedo usar helm secrets upgrade chart.tgz -f secrets.yaml ...
Bueno.
Pero aún así, +1 para agregar el --set app-version .

¿Y ahora qué?
¿Eliminar el soporte y el flujo de todas nuestras versiones?
¿Soltar usando secretos?
¿Algunas ideas?

Creamos dos paquetes: un paquete helm con solo los gráficos, sin los valores de env y el archivo de secretos. Cambiamos el nombre de este paquete a chart-{app-version}.tgz ya que chart-version no significa nada para nosotros, ni chart-version es compatible con nuestra sintaxis de versión de aplicación. Las actualizaciones de nuestra aplicación incluyen cualquier posible actualización de gráficos (el mismo repositorio, usando git tagging).

Luego tenemos un segundo tgz que es específico del entorno, chart-{app-version}-{env}.tgz que incluye el gráfico tgz, los valores yaml y el archivo de secretos cifrados. Este archivo también incluye un "package.yaml" que contiene valores como la etiqueta, la aplicación y el nombre del entorno para que nuestros scripts automatizados se implementen usando helm-secrets .

Estamos acostumbrados a identificar las versiones de nuestras aplicaciones, o la mayoría de ellas, con un número de versión semántica. Luego use este número en la VERSIÓN DE LA APLICACIÓN para identificarlo fácilmente en la lista helm history para reversiones u otras operaciones.
Como el sistema no permite inyectarlo automáticamente en el tiempo de implementación, ejecutamos este simple comando automáticamente en nuestra canalización de CI / CD antes del comando de implementación:

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

Es complicado, pero funciona como se esperaba.

@bvis
El problema con su solución alternativa es que debe editar el gráfico en su canalización de CI / CD.
Si usa un repositorio de gráficos centralizado, entonces se verá obligado a helm pull repo/chart --untar

¿Algún progreso adicional con la inyección programática de Chart.yaml / appVersion? ¿Existen soluciones alternativas? Daría un tremendo impulso a CI / CD Helm.

@jakovistuk, por lo que puedo decir, los gráficos que usan appVersion para mostrar la versión del contenedor lo hacen directamente a través de Chart.yaml, como se ve en nginx-ingress / Chart.yaml, por ejemplo ...

No he pensado mucho en este problema durante bastante tiempo, por lo que esta puede ser una pregunta realmente tonta, pero ¿hay alguna manera de usar Helm CLI para anular appVersion?

Parece que mucha gente aquí está pidiendo una forma de anular el campo 'appVersion'. La intención / solicitud original en este número es permitir —app-version como reemplazo de —version, por lo que un usuario podría ejecutar 'helm fetch —app-version = v0.15.0' y Helm averiguaría cuál es la última versión del gráfico más

En nuestro proyecto / gráfico (administrador de certificados) queremos dejar lo más claro posible a los usuarios finales qué versión están instalando, por lo que permitirles instalar por versión de aplicación en lugar de versión de

Dicho esto, este problema se abrió hace 2 años, y desde entonces hemos optado por mantener estos dos números de versión sincronizados / bloqueados. Después de un par de años haciendo esto, ha sido sorprendentemente fácil y sin dolor, aunque los usuarios a veces tienen que esperar un par de semanas para una nueva versión oficial si se realizan cambios en nuestros manifiestos de implementación.

Dada la antigüedad de este problema, su duración, la gran variedad de puertas de funciones ligeramente diferentes y los cambios en el proyecto Helm desde entonces (Helm 3, gráficos OCI, etc.), no creo que este problema esté en un buen estado para ser impulsado hacia adelante como una solicitud de función en su forma actual. Voy a cerrar este problema, pero cualquier otra persona que tenga una solicitud de función similar es mejor abrir un nuevo problema y vincular a cualquier otro comentario relevante sobre este problema para proporcionar evidencia. ¡Con suerte, eso funcionará mejor para el proceso de clasificación del equipo de Helm, de modo que sus solicitudes puedan obtener la visibilidad que necesitan!

También creo que este tipo de funcionalidad podría implementarse, y probablemente sea mejor, como una herramienta externa o envoltorio
Helm, especialmente cuando se tienen en cuenta los cambios de OCI que creo que harían que esto sea más complicado de implementar.

Hasta que esto se resuelva (o no) Así es como resolví esto en mi CI / CD (GitLab):

empaquetar el gráfico con la versión de la aplicación y luego implementarlo.
Sé que la versión Chart no está destinada a ser la misma que la appVersion, pero en nuestro caso está bien como solución.

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

Si establece su image.tag en {{ .Chart.AppVersion }} entonces no necesitará --set durante la instalación, ya será correcto. Esto también funciona muy bien para las compilaciones automáticas, cuando sus imágenes de Docker están etiquetadas con SHA1, por lo que AppVersion coincide con la etiqueta de imagen de Docker, y la versión es un SemVer de compilación automática.

No hay problema con que Version sea la misma que AppVersion si su AppVersion resulta ser SemVer.

Para los paquetes producidos por mi equipo, nos estamos moviendo hacia cosas que buscan AppVersion, por ejemplo, image.tag, por defecto en Version si AppVersion no está configurado. No es una gran diferencia, solo un argumento menos para helm package para lanzamientos etiquetados, pero solo tiene sentido si su gráfico está construido a partir del mismo SCM que lo que está empaquetando.

@TBBle que no funcionará si está utilizando un sub-gráfico para configurar su etiqueta de imagen

¿Quiere decir que image.tag está en un subgráfico, pero está intentando utilizar la versión de un gráfico principal? Si es así, sí, eso es muy incómodo y no será fácil de manejar. Acabo de rebotar exactamente este diseño en los gráficos de Helm de https://github.com/googleforgames/open-match/ . Sugiero volver a colocar los sub-gráficos en cuestión en el gráfico principal en este caso.

Los gráficos deben ser unidades utilizables / aisladas de forma independiente, sin depender de los comportamientos de los gráficos de los padres para funcionar. El subchart tiene su propia versión, _ esa_ es la que deberían usar sus imágenes, de lo contrario, ¿por qué es un subchart?

En el caso de Open Match, los subgráficos parecen usarse para que XXX.enable se pueda usar como un atajo en values.yaml para deshabilitar un montón de cosas a la vez, pero luego introduce un montón de problemas estructurales como este. . Todos los subgráficos de Open Match hacen un uso intensivo del gráfico principal denominado templates, y también tienen una versión local de 0.0.0-dev , por lo que ya hay dos códigos-huele que algo no está bien estructurado.

O quizás he entendido mal la observación que estás haciendo.

@haimari Desafortunadamente, no funciona (¿se relaciona con https://github.com/helm/helm/issues/6921?):

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

Pero esto funciona:

> 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

e incluso esto (pero parece sucio):

> 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

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

Creo que la solución de @haimari como está solo funciona porque usan etiquetas compatibles con semver en su canal de CI (es decir, este será un ejemplo para una ejecución de trabajo para versiones etiquetadas, no para cada confirmación)

@ a0s : generalmente sugiero:

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

Y luego haga que el valor de la etiqueta de la imagen de su contenedor sea algo así como {{ Values.image.tag | default .Chart.AppVersion | default .Chart.Version , para que no necesite cambiarlo sobre la marcha, como lo hace

En sus ejemplos, tiene lo que parecen ser dos versiones diferentes de git, ¿es así? ¿Es uno para la imagen del contenedor y otro para el gráfico?

Con SemVer, realmente no puede poner un SHA de confirmación de git en la parte significativa de semver, porque semver implica ordenar, y los SHA de confirmación de git no se pueden ordenar.

Por lo tanto, querrá usar una versión como 0.0.1-alpha.<build-id>+g<gitcommitsha> donde <build-id> es algo así como la tubería o la identificación del trabajo de su sistema de CI, por lo que siempre aumentará su compromiso con su proyecto. De esa manera, siempre obtendrá la última versión cuando la solicite.

En SemVer, usar - significa que es una versión preliminar de esa versión, por lo que 0.0.1-<anything> se encuentra entre las versiones 0.0.0 y 0.0.1. La parte después de + es la información de compilación, y se ignora para la clasificación, por lo que es un buen lugar para colocar SHA de git o nombres de sucursales u otra información de seguimiento no clasificable.

Entonces, con lo que ha usado aquí, 0-3454e5 parecerá ser más reciente que la siguiente confirmación, si su SHA comienza con 2 , por ejemplo, 0-2764e1 .

En sus ejemplos, tiene lo que parecen ser dos versiones diferentes de git, ¿es así? ¿Es uno para la imagen del contenedor y otro para el gráfico?

Sí, la aplicación y el gráfico: hay dos software independientes.

De esa manera, siempre obtendrá la última versión cuando la solicite.

¿Qué pasa si no quiero (y ni siquiera puedo imaginar) pedir lo último?

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

Esta cadena (después de la interpolación) parece demasiado larga para caber en una columna de salida estándar helm list :)

Siempre sé qué versión (sha hash) de la aplicación quiero instalar (pásala con --set args). Y siempre sé qué versión del gráfico uso (como lo describió usaré git checkout chart && helm pack && helm upgrade .tar.gz localmente en mi ci / cd)

¿Qué puede salir mal?
1) Un error durante el helm upgrade . Ok, corregiré el error e intentaré de nuevo (con otro compromiso sha de la aplicación - 99%) (o usando --atomic lugar)
2) Reversión manual: helm rollback <RELEASE_NAME> o implementación previa de confirmación a través de CI / CD.

¿Qué me extraño?

PD: Para ser honesto, quiero usar la parte sha corta en la versión y la versión de la aplicación solo con fines informativos (durante helm list )

Si es solo para fines informativos, va después de + en un SemVer, no de - . Si a usted _nunca_ le importa ordenar lanzamientos o distribuir gráficos de Helm a cualquier persona, y su gráfico o aplicación aún no son SemVer'd, entonces 0+g<commitsha> es un SemVer válido (equivalente a 0.0.0).

Esto es lo que hacen los gráficos autoconstruidos Helm de Open Match, por ejemplo; todos son actualmente 0.0.0-dev , y hemos empezado a pensar en hacer esos 0.0.0-dev+g<commitsha> para que, si estás mirando lo que has instalado, al menos puedas decir _cuál_ compilación maestra tienes.