Helm: Proporcione un medio para configurar .Chart.AppVersion durante la instalación o actualización sin editar Chart.yaml

Para mayor claridad, #3555 fue cerrado por el OP (ref https://github.com/helm/helm/issues/3555#issuecomment-633187773) con el siguiente comentario:

"Parece que mucha gente aquí está pidiendo una forma de anular el campo 'appVersion'. La intención/solicitud original en este problema es permitir —app-version como reemplazo de —version, para que un usuario pueda ejecutar ' helm fetch —app-version=v0.15.0' y Helm averiguaría qué última versión del gráfico especificó v0.15.0 como appVersion y lo recuperaría.

En nuestro proyecto/gráfico (cert-manager) 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 gráfico sería una experiencia de instalación mucho más natural.

Dicho esto, este problema se abrió hace 2 años y, desde entonces, hemos optado por mantener ambos números de versión sincronizados/bloqueados. Después de un par de años haciendo esto, ha sido sorprendentemente fácil y sencillo, 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 longitud, la gran variedad de puertas de características 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 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 que abra un nuevo problema y enlace a cualquier otro comentario relevante en este problema para proporcionar evidencia. ¡Ojalá eso funcione mejor para el proceso de clasificación del equipo de Helm para 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 un contenedor
Helm, especialmente cuando se tienen en cuenta los cambios de OCI que creo que harían que esto fuera más complicado de implementar".

es feo pero funciona, aunque me encantaría una bandera incorporada en el timón

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

Ojalá fuera más como....

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

@loa Su sugerencia no sigue lo siguiente del título (y es el punto completo de esto "

sin editar Chart.yaml

@timothyclarke Solo quería aclarar el caso de uso.

Actualmente sin la capacidad de cambiar appVersion en la actualización, el resultado de helm history es:

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

Idealmente corriendo

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

Daría como resultado un helm history más fácil de usar, como el que se muestra a continuación. Eso muestra que el gráfico no ha cambiado, pero la aplicación tuvo nuevos lanzamientos.

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

¿Este caso de uso encaja con el proceso de timón?

Idealmente, ¿la versión de la aplicación proporcionada a través de la línea de comandos también estaría disponible en las plantillas ( $.AppVersion )?

Esto permitiría agregarlo a los metadatos de la configuración de kubernetes.

Esto sería súper útil. Comente sobre el tema de la "versión de la aplicación", es decir, qué es una aplicación y cómo define la versión cuando hay más de una imagen acoplable en la "aplicación", etc., cómo automatizar la actualización en CI/CD. Paso por alto estos problemas definiendo 2 versiones:

1. la versión del gráfico: representa la _fuente_ de la plantilla;
   
   
   
   • si la fuente de la plantilla cambia, la versión del gráfico debería cambiar; fuente de plantilla significa la carpeta de plantillas, Chart.yaml, valores predeterminados.yaml, helmignore, notas, etc.
   
   
   • No guardo el gráfico de timón en el repositorio de gráficos porque el gráfico está disponible en git en cualquier momento y se puede instalar a través de la instalación de timón.
   
   
2. la versión de instalación: valor único basado en la combinación de todos los valores utilizados en la instalación, es decir, después de fusionar todos los archivos de valores (incluidos los secretos descifrados) y los valores predeterminados del gráfico y del conjunto. Determino esto a través de un MD5 o un SHA256 basado en el conjunto final de valores.

Dado que helm no tiene un concepto de versión de instalación, uso la versión de la aplicación para mantener el archivo md5.

Esto hace que interprete lo que está instalado:

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

Ahora es bastante obvio que las revisiones 1 y 3 son exactamente la misma instalación: la misma fuente de gráfico y el mismo árbol final de valores.

Si alguien está interesado en probar esto, https://github.com/schollii/sandals/blob/master/helm.py proporciona un par de funciones útiles para esto. Actualmente obtengo el hash a través de una ejecución en seco para obtener los valores combinados, y tengo que copiar el gráfico en una carpeta temporal para editar la versión de la aplicación en Chart.yaml (o usar la solución de empaquetado, ya que es compatible con --app-version ). Así que --app-version para la instalación sería increíble. También me gustaría implementar algo como --app-version-is-md5 que haría innecesaria una ejecución en seco, pero eso estará en otro número (#8453).

Uso esto antes de cada instalación cuando no estoy usando una etiqueta git yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_SHORT_SHA"

Cuando uso una etiqueta, actualizo la revisión en el proceso ci. Uso esto antes de cada instalación yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_TAG"
A continuación, envíe el Chart.yaml actualizado al control de versiones.

Usando gitlab ci

Sé que hay mucha gente a la que le gusta configurar la versión de la aplicación justo antes de publicar un gráfico. Pero realmente no queremos publicar un gráfico, especialmente cuando todavía estamos probando los cambios que acabamos de hacer. instalar o actualizar a un entorno de desarrollo es el caso de uso principal de esta función.

@woodcockjosh , no estoy seguro de que este problema esté relacionado con la versión del gráfico, sino más bien con la versión de la aplicación legible por humanos (appVersion) que se implementó usando el gráfico.

Diría que el caso de uso principal de la función es más para dar a los diseñadores de gráficos, administradores de servidores y desarrolladores la capacidad de:

1. Vea fácilmente la versión (no la versión del gráfico) de la aplicación que se implementa. Donde la aplicación es el código y todas las dependencias necesarias. Nota: no creo que appVersion sea un valor válido para desinstalar, revertir o buscar versiones.
2. (deseo personal) Exponer el valor del gráfico para que el mantenedor del gráfico, a su discreción, pueda determinar si desea utilizar la versión de la aplicación en el momento de la instalación/actualización. El ejemplo sería agregarlo a los metadatos de la implementación de Kubernetes

Al cubrir los dos casos de uso anteriores, en mi opinión, le permitiría a helm no opinar sobre cómo se realiza la implementación y el uso de los gráficos de helm.

la versión de instalación: valor único basado en la combinación de todos los valores utilizados en la instalación, es decir, después de fusionar todos los archivos de valores (incluidos los secretos descifrados) y los valores predeterminados del gráfico y del conjunto. Determino esto a través de un MD5 o un SHA256 basado en el conjunto final de valores.

@schollii Me gusta la idea de una versión de instancia, pero como creador e implementador de gráficos de timón donde trabajo, todavía me gustaría una versión de aplicación legible por humanos que sea independiente de la versión de instancia. La razón por la que están separados es
la versión de instalación no sería única si solo cambiara el código de la aplicación y no el gráfico y/o los valores aplicados al gráfico.

@rcampbel sí, por supuesto, queremos ver la versión de la aplicación que está instalada. Sin embargo, lo que digo es que las circunstancias en las que desearía tener una versión diferente para appVersion que la que está en Chart.yaml es si ese gráfico le pertenece y está implementando una versión de nivel de desarrollo de la aplicación. Si no era una versión de nivel de desarrollo, podría mantener el número de versión de la aplicación dentro de Chart.yaml y hacer que los usuarios finales del gráfico usen esa versión de la aplicación como la versión predeterminada de la aplicación.

Si estoy desarrollando nuevos microservicios, por ejemplo, no quiero empaquetar y cargar un nuevo gráfico de helm en un repositorio de helm cada vez que quiero probar una versión implementada de mi aplicación. Pero también me gustaría ver la versión o el ID de confirmación que se implementa para cada lanzamiento, por lo que queremos anular la versión de la aplicación para los lanzamientos de desarrollo, pero probablemente no para los lanzamientos de producción.

Sin embargo, lo que digo es que las circunstancias en las que desearía tener una versión diferente para appVersion que la que está en Chart.yaml es si ese gráfico le pertenece y está implementando una versión de nivel de desarrollo de la aplicación. Si no era una versión de nivel de desarrollo, simplemente podría mantener el número de versión de la aplicación dentro de Chart.yaml y hacer que los usuarios finales del gráfico usen esa versión de la aplicación como la versión predeterminada de la aplicación.

Esta es exactamente la razón por la que helm no debe opinar sobre cómo se realiza la implementación y el uso de los gráficos de helm.
Helm no debe preocuparse por la estrategia de implementación a nivel local y más allá, eso depende del flujo de trabajo del equipo/proyecto. Pero esto se está desviando de la función que se solicita, permitir que se configure .Chart.AppVersion en el momento de la instalación/actualización sin actualizar Chart.yaml

No quiero empaquetar y cargar un nuevo gráfico de helm en un repositorio de helm cada vez que quiero probar una versión implementada de mi aplicación.

Por lo que puedo decir, helm ya no tiene opinión sobre esto, ya que tiene los medios para hacer exactamente esto cuando llama a helm upgrade

El argumento del gráfico puede ser: una referencia de gráfico ('example/mariadb'), una ruta a un directorio de gráficos, un gráfico empaquetado o una URL completa. ~ https://helm.sh/docs/helm/helm_upgrade/

@woodcockjosh Hay muchos casos de uso y, como afirma @rcampbel , el timón no debe opinar sobre esto y permitir que las personas trabajen a su manera.
Si sigo la lógica "debería publicarse en el gráfico" (hasta el extremo), ¿por qué helm tiene el indicador --set o --values , -f y, de hecho, por qué tiene un archivo de values.yaml ? Todo lo proporcionado por las banderas son anulaciones de tiempo de implementación que deberían haber estado en el gráfico publicado. Sé que es malo poner secretos en un gráfico, pero si esa fuera la única razón, entonces el argumento debería ser --secrets lugar de --values .

En mi situación, implementamos varias aplicaciones que usan el mismo gráfico. Estas aplicaciones se promocionan a través de entornos que utilizan un método de CI/CD. Las aplicaciones utilizan el indicador --values para proporcionar una configuración específica de la aplicación y del entorno (por lo general, detalles de ingreso y fuente de datos). Si estuviera publicando un nuevo gráfico para cada versión de la aplicación para cada entorno, estaría creando cientos o miles de versiones de gráficos por semana. En la mayoría de los casos, las únicas diferencias serían la versión de la aplicación. Entonces me veo obligado a cambiar la versión del gráfico. Para mí, los requisitos introducidos por todo este párrafo, si bien son lógicos con una cosa que desencadena otra, son una locura.

Como el .Chart.appVersion no funciona para nosotros, hemos vuelto a un .Chart.appVersion estático y estamos usando .Values.image.tag (Esta no es una invitación para reabrir ese debate)

Estaba seguro de que appVersion era el camino a seguir con respecto a la versión de la aplicación después de leer la documentación, hasta leer todos estos casos de uso válidos.

Para los usuarios de un paquete de gráficos es más fácil cambiar image.tag , implica modificar solo los valores, el gráfico puede vivir en otro lugar. Pero al usar image.tag no obtienes información sobre la versión del paquete cuando haces helm history <release>

También me di cuenta de que helm package <chart> generará un archivo tar con Chart.version . Si solo desea distribuir una nueva versión de su aplicación y se usa appVersion , se espera que también aumente version ; de lo contrario, sobrescribirá el archivo anterior. Si appVersion y version son diferentes, es más difícil calcular el impulso de servidor correcto con herramientas automáticas para version (supongamos que appVersion se modifica en función de los mensajes de confirmación ). ¿Cómo lo lidian ustedes?

Solo necesitamos algo que sea una versión real de la aplicación que podamos ver al enumerar los gráficos implementados.

Cuando tengo un gráfico de timón que se crea para implementar mi microservicio estándar, me gustaría elegir durante la implementación qué versión de la aplicación tiene este microservicio durante la implementación. Actualmente, todos mis servicios tienen siempre la versión 1.0.0 de la aplicación y no estoy usando helm para verificar qué versión de la aplicación tengo, porque hacerlo posible con los métodos actuales (reempaquetar el gráfico) hará que mi vida sea un infierno.

Simplemente, permítanos decidir cómo usaremos este parámetro. Si esto no es posible debido a razones técnicas, infórmenos por qué.

Prefiero no usar "sed" como se menciona en 8194
Hasta que esto se resuelva (o no) Así es como resolví esto en mi CI/CD (GitLab):

Empaquete el gráfico con la versión de la aplicación y luego impleméntelo.
Sé que la versión de gráfico no pretende ser la misma que la versión de la aplicación, pero en nuestro caso está bien como solución alternativa.

Además, no es necesario cargarlo en un repositorio de helm, pero es posible usar los artefactos de CI resultantes (chart.tgz)

Entonces, si empaquetar primero no es un problema, y ​​necesita una solución para hoy , puede usar algo como esto.

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

En la salida ahora tengo las versiones disponibles.

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

@haimari
Gracias por el fragmento, para cualquiera que busque, hay otro ejemplo anterior en esta banda de rodadura https://github.com/helm/helm/issues/8194#issuecomment -635879040 que logra el mismo resultado.

Sin embargo, el problema en cuestión es que volver a empaquetar el gráfico no es deseable y los mantenedores del timón están forzando esa opinión y forma de trabajar. Esta solicitud es que el timón sea menos obstinado y permita que el timón se use de una manera que se adapte mejor a otras partes de la comunidad.
Este problema y https://github.com/helm/helm/issues/3555 han explorado las diferencias entre .Chart.version y .Chart.appVersion , específicamente cómo la mayoría de los gráficos públicos vinculan appVersion a se lanza la etiqueta del contenedor que ha obligado a cambiar la versión del gráfico simplemente porque hay una nueva versión de una aplicación. Si bien esa podría ser una buena suposición para la mayoría de las cartas públicas, la suposición no es válida para una cantidad significativa de cartas privadas. De ahí esta solicitud a los mantenedores del timón para que dejen de imponer ese enfoque a la comunidad.

ps Su fragmento de código implica una versión de gráfico por versión/por entorno que luego reemplazaría la necesidad de configurar image.repository y image.tag . Esperaría un paso después del reempaquetado para publicar el gráfico en un repositorio de helm en caso de que necesite volver a implementar, consulte https://github.com/helm/helm/issues/8194#issuecomment -658715462 arriba que explora ese conejo agujero

@haimari
Gracias por el fragmento, para cualquiera que busque, hay otro ejemplo anterior en esta banda de rodadura #8194 (comentario) que logra el mismo resultado.

Sin embargo, el problema en cuestión es que volver a empaquetar el gráfico no es deseable y los mantenedores del timón están forzando esa opinión y forma de trabajar. Esta solicitud es que el timón sea menos obstinado y permita que el timón se use de una manera que se adapte mejor a otras partes de la comunidad.
Este número y el #3555 han explorado las diferencias entre .Chart.version y .Chart.appVersion , específicamente cómo la mayoría de los gráficos públicos vinculan appVersion a la etiqueta del contenedor, lo que ha obligado a cambiar la versión del gráfico simplemente porque se lanza una nueva versión de una aplicación. Si bien esa podría ser una buena suposición para la mayoría de las cartas públicas, la suposición no es válida para una cantidad significativa de cartas privadas. De ahí esta solicitud a los mantenedores del timón para que dejen de imponer ese enfoque a la comunidad.

ps Su fragmento de código implica una versión de gráfico por versión/por entorno que luego reemplazaría la necesidad de configurar image.repository y image.tag . Esperaría un paso después del reempaquetado para publicar el gráfico en un repositorio de helm en caso de que necesite volver a implementar, consulte el n . ° 8194 (comentario) arriba que explora ese agujero de conejo

@timothyclarke Gracias por la información.

1. Esta no es una práctica recomendada, sino una solución alternativa para _"Proporcionar un medio para configurar .Chart.AppVersion durante la instalación o actualización sin editar Chart.yaml"_
2. No es necesario enviar el gráfico a un repositorio. Esto funciona con varios clústeres de k8 directamente desde Gitlab.
3. Proporciona todo lo que necesito para tener lanzamientos:

Los image.repository y image.tag se configuran de todos modos exactamente de la misma manera en la canalización,
así que incluso sin la línea de empaquetado, esta es la forma de usar helm de gitlab.

la variable CI_COMMIT_TAG contiene la etiqueta de versión actual de la canalización que se ejecuta.
Por lo tanto, siempre podemos retroceder a la versión anterior directamente desde la canalización de CI con un solo clic.

Mi empresa tiene nuestro gráfico de timón desacoplado de las etiquetas del contenedor. No hay absolutamente ninguna necesidad de volver a empaquetar el gráfico para cada construcción de contenedor.

La ausencia de la opción para configurar appVersion (y por lo tanto tenerla siempre configurada con el mismo valor) durante la instalación es una gran deficiencia en nuestro proceso de implementación. Es realmente molesto que nuestros usuarios no puedan ver las versiones de la aplicación haciendo "lista de timón".

Tener la capacidad de usar algo como "helm install... --app-version v1.2.3" agregaría mucho valor al uso de Helm en nuestro caso.

Mi propuesta sería desaprobar appVersion y enumerar chart version y container tag al hacer helm list o helm history <name> .
Helm no debe intentar proporcionar la versión real de la aplicación dentro del contenedor, debe proporcionar lo que tiene a mano, la etiqueta y la versión del gráfico, aquí algunos ejemplos:

| GRÁFICO | ETIQUETA PARA CONTENEDOR |
| ----- | ----- |
| 0.1.0 | 0.3.0 |
| 0.1.0 | 0.4.0 |

En el ejemplo anterior, podemos inferir que el gráfico se está reutilizando para diferentes etiquetas.

| GRÁFICO | ETIQUETA PARA CONTENEDOR |
| ----- | ----- |
| 0.3.0 | 0.3.0 |
| 0.4.0 | 0.4.0 |

En el ejemplo anterior, podríamos inferir que el gráfico comparte la misma versión que la etiqueta.

La principal desventaja de appVersion parece ser que requiere que el paquete se vuelva a publicar, incluso si el gráfico no ha cambiado, pero sí el código dentro del contenedor. Mientras tanto, la etiqueta del contenedor se puede proporcionar a través de values.yaml y no necesita volver a publicarse.

Alternativas

Creo que lo más simple sería enumerar la etiqueta del contenedor al hacer helm list o helm history , pero sería extraño tener un appVersion dando vueltas. Esto al menos, daría algo de información extra, y la gente podría ignorar appVersion .

Otra solución, en lugar de desaprobar appVersion , podría moverse a values.yaml , de esta manera se separaría del Gráfico, evitando múltiples publicaciones.

¿Pensamientos?

@Woile, ¿qué

@Woile, ¿qué

Tiene razón, considerando ese caso de uso también (lo siento, estaba pensando en mis casos de uso), creo que mover appVersion al values.yaml mejoraría la situación.

• helm list y helm history podrían seguir siendo los mismos
• puedes tener más de un contenedor
• no es necesario volver a publicar cada vez, pero puede hacerlo si desea mantener sincronizados Chart y appVersion .

¿Qué me estoy perdiendo?

Mi preferencia sería permitir controlar appVersion explícitamente. Puede ser igual a las etiquetas de los contenedores, o puede ser necesario configurarlo en un valor diferente (por ejemplo, mi secuencia de comandos de instalación busca un repositorio/espacio de nombres/etiqueta de un contenedor dado y luego aplica una expresión regular para transformarlos en un contenedor fácil de usar). formato para mostrar la versión de la aplicación)

@woodcockjosh @Woile
Mis $0.02. El concepto de appVersion es bueno desde el punto de vista de helm ls . La implementación es el problema que me gustaría ver corregido. Tener múltiples etiquetas/versiones en appVersion debería estar bien, por ejemplo, appVersion: nginx-1.16.0-php-7.5

Observo que helm 3.2.4 tiene {{ .Values.image.tag | default .Chart.AppVersion }} por lo que permite ese tipo de desconexión

La posibilidad de seleccionar appVersion durante la instalación/actualización sería el enfoque preferido. No tiene sentido cambiar la versión del gráfico cada vez que cambia la versión de la aplicación, ya que el gráfico en sí no cambia. La progresión lineal del control de versiones tampoco siempre es aplicable, especialmente para aplicaciones de contenedores múltiples que se implementan en diferentes entornos con diferentes combinaciones de versiones de contenedores. La sugerencia de usar la misma appVersion y chartVersion también es mala porque obliga a appVersion a ser compatible con semVer. semVer no es el santo grial del control de versiones y appVersion debe ser libre de usar cualquier esquema de control de versiones que sea más apropiado para la aplicación.

@bacongobbler ¿ Este comentario significa que helm planea implementar tal bandera?

Creo que la introducción de app-version (en la opción de línea de comando) y appVersion (en Chart.yaml) proporciona una buena manera de ver la versión de una aplicación implementada con una instancia de gráfico. Pero esto también genera muchas preguntas y prácticas diferentes que deben aclararse.

• El objetivo de helm (gráfico) es empaquetar e instalar recursos en un clúster de kubernetes (para una aplicación).
• La versión de la aplicación solo se puede proporcionar en la fase del paquete, por lo que esta información se convierte en parte del gráfico.
• Almacenado en un repositorio de helm (como un artefacto java o python), el gráfico se vuelve inmutable. Por lo tanto, la versión de la aplicación nunca debe anularse.
• Por otro lado, durante la fase de instalación o actualización, los valores permiten anular cualquier valor del gráfico (para las personalizaciones del entorno), pero la versión de la aplicación no puede.
• Como podemos ver en muchos casos de uso, la versión real de la aplicación es la versión de la imagen proporcionada por image.tag durante la fase de instalación o actualización.

Mi conclusión

• Un gráfico paraguas se puede considerar como una agregación de múltiples gráficos (dependencias) que siguen el ciclo de vida adecuado
• Un gráfico general es el único caso en el que appVersion no está directamente vinculado a la imagen utilizada.
• Una aplicación siempre proporciona un gráfico donde, en muchos casos, la versión de la aplicación = etiqueta de imagen (por transitividad al código de la aplicación)
• La separación de la fuente entre el código de la aplicación y el código del gráfico solo presenta algunas dificultades en el cumplimiento entre la imagen de la ventana acoplable y el gráfico.
• El gráfico compartido, como un "gráfico de arranque de resorte", debe usarse siempre como una dependencia en el gráfico de la aplicación (incluso si su aplicación solo se compone de esta dependencia) ... ¡no implementa un gráfico compartido sino una aplicación!

mi elección actual

• un gráfico compartido solo produce un gráfico con su versión y la versión de la aplicación siempre está vacía (nunca se usa)
• un gráfico compartido nunca se usa directamente para hacer una implementación.
• un gráfico de aplicación (componente) siempre produce un gráfico adecuado, donde versión del gráfico = versión de la aplicación = etiqueta de imagen
• el seguimiento de un gráfico general es un ciclo de vida adecuado en el que la versión del gráfico representa la versión de la aplicación

Pregunta / Idea

No sé por qué se introdujo la versión de la aplicación (tal vez para cubrir el mal uso del gráfico compartido).
Creo que podría ser una buena idea eliminarlo e introducir la capacidad de configurar la etiqueta de la imagen en la fase del paquete sin usar una solución alternativa como sed o yq.

Tal vez una publicación demasiado larga, pero necesito algunos comentarios.

@grazius
Mi entendimiento de su publicación es que las banderas --set , -f y --values son malas y nunca deben usarse. Todas las implementaciones son inmutables y deben representarse en un gráfico, incluso si ese gráfico es poco más de values.yaml y el gráfico general es una dependencia. Este gráfico debe representarse en el momento de la compilación (de la aplicación) y publicarse en un repositorio de gráficos

En la situación anterior, ¿dónde está almacenando secretos o información confidencial similar? En todos los lugares en los que he trabajado, se han introducido a través de un archivo --values

Para algún contexto, mis implementaciones tienen efectivamente 3 elementos que se versionan de forma independiente

• Gráfico
• Solicitud
• (Entorno) Valores de configuración

Si cambio uno de esos, no debería verme obligado a reconstruir ninguno de los otros. Por lo general, uso varios entornos para que las aplicaciones se puedan probar antes de que se activen. Como tal implementación le gustaría chart-v1.0 application_build-50 config_non-prod-v1.3 con los archivos de configuración env almacenados gpg cifrados.
Mi plataforma de CI gestiona la creación, implementación y promoción de la aplicación a medida que la creación fluye desde el origen hasta la producción, pasando por las pruebas. Si necesitamos volver a implementar una versión histórica de la aplicación, volvemos a ejecutar esos trabajos.

Pregunta: ¿Por qué deberíamos vernos obligados a usar un repositorio de gráficos para almacenar el estado que mi plataforma de CI maneja de manera inmediata? Nunca deberíamos instalar nada de esto a mano.

@timothyclarke solo asegúrese de usar el complemento de secretos para que pueda usar archivos de valores cifrados

@timothyclarke Hola, gracias por este primer comentario ;)

• La ventaja de un repositorio (como pypi, maven central, dockerregistries for development) es que el artefacto generado se puede compartir y publicar (para helm es un tgz) con la seguridad de que es inmutable.
• Para valores por entorno (es otro tema) se pueden almacenar donde quieras (scm repo, solución dedicada como hashicorp para secretos, illumio para netpol, etc...).

Un gráfico proporciona valores predeterminados.yaml (inmutable para cada versión del gráfico) que los consumidores del gráfico pueden usar (o anular).
Para Chart.yaml también es una parte inmutable del gráfico... y el app-version está incluido.

En su caso, ¿qué se muestra en la lista de timón para la versión de la aplicación? 50?
En caso afirmativo, ¿cómo colocó la versión de la aplicación en el gráfico versión de la aplicación en su canalización?

@grazius

Un gráfico proporciona valores predeterminados.yaml (inmutable para cada versión del gráfico) que los consumidores del gráfico pueden usar (o anular).
Para Chart.yaml también es una parte inmutable del gráfico... y la versión de la aplicación está incluida.

Tal vez no entienda bien lo que está diciendo aquí, pero esto plantea la pregunta de ¿por qué tener una versión de la aplicación si es inmutable para cada versión del gráfico? Entonces, para cada cambio de versión de la aplicación, también tendría que haber un aumento en la versión del gráfico, incluso si no se realizó ningún otro cambio en el gráfico. Si es así, ¿por qué tener la versión del gráfico o la versión de la aplicación?

Creo que esto también va en contra de lo que se solicita: "Proporcione un medio para configurar .Chart.AppVersion durante la instalación o actualización sin editar Chart.yaml". Creo que lo que dijo @timothyclarke anteriormente en este chat resume las cosas bastante bien: https:/ /github.com/helm/helm/issues/8194#issuecomment -671331311

Creo que otra cosa importante a tener en cuenta es que no todos tienen control sobre el gráfico que se usa, pero pueden tener la capacidad de pasar la imagen que se usa y otros valores al gráfico en el momento de la implementación. En ese caso, ¿cómo sugeriría actualizar la versión de la aplicación que se implementa?

¡El mismo problema aquí!
Teniendo en cuenta el uso de la bandera --description como una solución para proporcionar alguna forma de mostrar la versión de la aplicación en el helm list 🤔

La versión de la aplicación es realmente necesaria cuando crea un gráfico general. Para el gráfico de componentes, creo que el interés de hacer evolucionar la versión del gráfico y la versión de la aplicación por separado es muy bajo.

¿Quizás el principal problema es que el tipo en Chart.yaml no es lo suficientemente preciso? No hay forma de diferenciar un gráfico general, compartido o de aplicación

@grazius Esa es una respuesta bastante obstinada.
Si bien puede ser aplicable para muchos proyectos de código abierto, no es tan aplicable a tantas compilaciones de código cerrado. Vuelva a revisar este hilo, incluidas todas las declaraciones y casos de uso realizados, ya que esta solicitud no es una solicitud para eliminar .Chart.AppVersion de la especificación de un gráfico. Ni siquiera es una solicitud para enmascarar APP VERSION de la salida de helm ls .
Este hilo es una solicitud para hacer que Chart.AppVersion configurable en el momento en que se usa un gráfico (sin tener que reconstruir o alterar el gráfico) para que el campo APP VERSION de helm ls no es engañoso.

Tal como está, actualmente diría que APP VERSION es un campo superfluo en helm ls y no debería ser visible para los comandos de tiempo de ejecución debido a la estrecha relación entre .Chart.AppVersion y .Chart.Version . helm inspect chart --version <.Chart.Version> <.Chart.Name> proporciona la misma información.
También extendería eso al uso de .Chart.AppVersion para ser usado como la etiqueta del contenedor, ya que son cosas ligeramente diferentes que se pueden versionar de forma independiente por razones válidas, pero actualmente están calzados en una sola cosa.
He tratado de mantener mis opiniones sobre ese vínculo fuera de esta solicitud, ya que los proyectos pueden tener razones completamente válidas para tal vínculo. Al no imponer el mismo proceso a todos los que usan helm, hacemos de helm una herramienta mejor y más inclusiva.
No creo que estos cambios solicitados disminuyan el timón o fuercen su uso a otros.

@bacongobbler ¿Puedes comentar sobre esto? Es una característica muy solicitada.

Es una característica muy solicitada.

Hola, @jasondamour , complemento de timón y escribir un HIP .

Hola, tal vez la mejor solución es proporcionar un argumento de versión de la aplicación de lanzamiento para el comando de instalación/actualización que, si está presente, anula la visualización de la versión de la aplicación cuando hacemos una lista de timón.