Helm: Forneça um meio de configurar .Chart.AppVersion durante a instalação ou atualização sem editar Chart.yaml

Para maior clareza, #3555 foi fechado pelo OP (ref https://github.com/helm/helm/issues/3555#issuecomment-633187773) com o seguinte comentário:

"Parece que muitas pessoas aqui estão pedindo uma maneira de substituir o campo 'appVersion'. A intenção/solicitação original neste problema é permitir —app-version como um substituto para —version, para que um usuário possa executar ' helm fetch —app-version=v0.15.0' e o Helm descobriria qual versão do gráfico mais recente especificou v0.15.0 como uma appVersion e buscaria isso.

Em nosso projeto/gráfico (cert-manager), queremos deixar o mais claro possível para os usuários finais qual versão eles estão instalando, portanto, permitir que eles instalem por versão do aplicativo em vez da versão do gráfico seria uma experiência de instalação muito mais natural.

Dito isso, esse problema foi aberto há 2 anos e, desde então, optamos por manter esses dois números de versão em sincronia/bloqueio. Depois de alguns anos fazendo isso, tem sido surpreendentemente fácil e indolor, embora os usuários às vezes precisem esperar algumas semanas por um novo lançamento oficial se houver alterações feitas em nossos manifestos de implantação.

Dada a idade desse problema, seu comprimento, a enorme variedade de portas de recursos ligeiramente diferentes e as mudanças no projeto Helm desde então (Helm 3, gráficos OCI etc.), não acho que esse problema esteja em bom estado para ser encaminhado como uma solicitação de recurso em sua forma atual. Vou encerrar este problema, mas qualquer outra pessoa que tenha uma solicitação de recurso semelhante é melhor abrir um novo problema e vincular a quaisquer outros comentários relevantes neste problema para fornecer evidências. Espero que isso funcione melhor para o processo de triagem da equipe do Helm, para que suas solicitações possam obter a visibilidade de que precisam!

Eu também acho que esse tipo de funcionalidade poderia ser, e provavelmente é melhor, implementado como uma ferramenta externa ou wrapper ao redor
Helm, especialmente ao levar em conta as mudanças da OCI, que acho que tornariam isso mais complicado de implementar."

é feio, mas funciona, adoraria uma bandeira embutida no leme embora

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

gostaria que fosse mais assim....

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

@loa Sua sugestão não segue o seguinte do título (e é o ponto principal disso"

sem editar Chart.yaml

@timothyclarke Eu só queria esclarecer o caso de uso.

Atualmente sem a capacidade de alterar appVersion na atualização, o resultado de helm history é:

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 em execução

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

Isso resultaria em um helm history mais amigável, como o abaixo. Isso mostra que o gráfico não mudou, mas o aplicativo teve novos lançamentos.

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 se encaixa com o processo de leme?

Idealmente, a versão do aplicativo fornecida via linha de comando também estaria disponível nos modelos ( $.AppVersion )?

Isso permitiria que ele fosse adicionado aos metadados da configuração do kubernetes.

Isso seria super útil. Observação sobre o tópico "versão do aplicativo", ou seja, o que é um aplicativo e como você define a versão quando há mais de uma imagem docker no "aplicativo", etc., como automatizar a atualização no CI/CD. Eu ignoro esses problemas definindo 2 versões:

1. a versão do gráfico: representa o _source_ para o modelo;
   
   
   
   • se a fonte do modelo for alterada, a versão do gráfico deverá ser alterada; fonte de modelo significa a pasta de modelos, Chart.yaml, valores padrão.yaml, helmignore, notas, etc.
   
   
   • Eu não armazeno o gráfico do leme no repositório de gráficos porque o gráfico está disponível no git a qualquer momento e pode ser instalado via instalação do leme
   
   
2. a versão de instalação: valor único baseado na combinação de todos os valores usados ​​na instalação, ou seja, após mesclar todos os arquivos de valores (incluindo os secretos descriptografados) e os valores padrão do conjunto e do gráfico. Eu determino isso por meio de um MD5 ou SHA256 com base no conjunto final de valores.

Como o leme não tem um conceito de versão de instalação, uso a versão do app para guardar o md5.

Isso faz com que ele interprete o 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

Agora é bastante óbvio que as revisões 1 e 3 são exatamente a mesma instalação: mesma fonte de gráfico e mesma árvore final de valores.

Se alguém estiver interessado em experimentar isso, https://github.com/schollii/sandals/blob/master/helm.py fornece algumas funções úteis para isso. Atualmente, recebo o hash por meio de uma execução a seco para obter os valores mesclados e tenho que copiar o gráfico para uma pasta temporária para editar a versão do aplicativo em Chart.yaml (ou usar a solução alternativa de empacotamento, pois suporta --app-version ). Então --app-version para instalar seria incrível. Eu também gostaria de implementar algo como --app-version-is-md5 que tornaria um teste desnecessário, mas isso estará em outra edição (#8453).

Eu uso isso antes de cada instalação quando não estou usando uma tag git yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_SHORT_SHA"

Quando eu uso uma tag eu atualizo a revisão no processo ci eu uso isso antes de cada instalação yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_TAG"
Em seguida, confirme o Chart.yaml atualizado para o controle de versão.

Usando o gitlab ci

Eu sei que muitas pessoas gostam de definir a versão do aplicativo antes de publicar um gráfico. Mas realmente não queremos publicar um gráfico, especialmente quando ainda estamos testando as alterações que acabamos de fazer. instalar ou atualizar para um ambiente de desenvolvimento é o principal caso de uso para esse recurso.

@woodcockjosh , não tenho certeza de que esse problema esteja na versão do gráfico, mas mais na versão do aplicativo legível por humanos (appVersion) que foi implantada usando o gráfico.

Eu diria que o principal caso de uso do recurso é mais dar aos designers de gráficos, administradores de servidores e desenvolvedores a capacidade de:

1. Veja facilmente a versão (não a versão do gráfico) do aplicativo implantado. Onde a aplicação é o código e todas as dependências necessárias. Observação: não acho que appVersion seja um valor válido para ser usado para desinstalar, reverter ou pesquisar versões.
2. (desejo pessoal) Para expor o valor ao gráfico para que o mantenedor do gráfico, a seu critério, possa determinar se deseja usar a versão do app no ​​momento da instalação/atualização. Exemplo seria adicioná-lo aos metadados da implantação do Kubernetes

Ao cobrir os dois casos de uso acima, IMO, permitiria que o leme ficasse sem opinião sobre como a implementação e o uso dos gráficos do leme são feitos.

a versão de instalação: valor único baseado na combinação de todos os valores usados ​​na instalação, ou seja, após mesclar todos os arquivos de valores (incluindo os secretos descriptografados) e os valores padrão do conjunto e do gráfico. Eu determino isso por meio de um MD5 ou SHA256 com base no conjunto final de valores.

@schollii Eu gosto da ideia de uma versão de instância, mas como criador e implementador de gráficos de leme onde trabalho, ainda gostaria de uma versão de aplicativo legível por humanos que seja separada da versão de instância. A razão para eles serem separados é
a versão de instalação não seria única se apenas o código do aplicativo fosse alterado e não o gráfico e/ou valores aplicados ao gráfico.

@rcampbel sim claro que queremos ver a versão do aplicativo que está instalado. O que estou dizendo é que as circunstâncias em que você deseja ter uma versão diferente para appVersion daquela que está em Chart.yaml é se esse gráfico pertence a você e você está implantando uma versão de nível de desenvolvimento de a aplicação. Se não fosse a versão de nível de desenvolvimento, você poderia apenas manter o número da versão do aplicativo dentro de Chart.yaml e fazer com que os usuários finais do gráfico usem essa versão do aplicativo como a versão padrão do aplicativo.

Se estou desenvolvendo novos microsserviços, por exemplo, não quero empacotar e carregar um novo gráfico de leme em um repositório de leme sempre que quiser testar uma versão implantada do meu aplicativo. Mas eu também gostaria de ver a versão ou o id de confirmação que é implantado para cada versão, e é por isso que queremos substituir o appVersion para versões de desenvolvimento, mas provavelmente não para versões de produção.

O que estou dizendo, porém, é que as circunstâncias em que você gostaria de ter uma versão diferente para appVersion daquela que está no Chart.yaml é se esse gráfico pertencer a você e você estiver implantando uma versão de nível de desenvolvimento do aplicativo. Se não fosse a versão de nível de desenvolvimento, você poderia apenas manter o número da versão do aplicativo dentro do Chart.yaml e fazer com que os usuários finais do gráfico usem essa versão do aplicativo como a versão padrão do aplicativo.

É exatamente por isso que o leme não deve opinar sobre como a implementação e o uso dos gráficos do leme são feitos.
O Helm não deve se preocupar com a estratégia de implantação local e além, isto é, para o fluxo de trabalho da equipe/projeto descobrir. Mas isso está fugindo do recurso que está sendo solicitado, permita que .Chart.AppVersion seja definido no momento da instalação/atualização sem atualizar Chart.yaml

Não quero empacotar e fazer upload de um novo gráfico de leme para um repositório de leme sempre que quiser testar uma versão implantada do meu aplicativo

Pelo que posso dizer, o leme já não tem opinião sobre isso, pois tem os meios para fazer exatamente isso ao chamar helm upgrade

O argumento do gráfico pode ser: uma referência de gráfico('exemplo/mariadb'), um caminho para um diretório de gráfico, um gráfico empacotado ou uma URL totalmente qualificada. ~ https://helm.sh/docs/helm/helm_upgrade/

@woodcockjosh Existem muitos casos de uso e, como @rcampbel afirma, o leme deve permanecer sem opinião sobre isso e permitir que as pessoas trabalhem à sua maneira.
Se eu seguir a lógica "deveria ser publicado no gráfico" (ao extremo), por que o leme tem o sinalizador --set ou --values , -f e, por isso, um arquivo values.yaml ? Tudo fornecido pelos sinalizadores são substituições de tempo de implantação que deveriam estar no gráfico publicado. Eu sei que é ruim colocar segredos em um gráfico, mas se esse fosse o único motivo, o argumento deveria ser --secrets vez de --values .

Na minha situação, implantamos vários aplicativos que usam o mesmo gráfico. Esses aplicativos são promovidos por meio de ambientes usando um método CI/CD. Os aplicativos usam o sinalizador --values para fornecer configuração específica do aplicativo e do ambiente (geralmente detalhes de entrada e fonte de dados). Se eu estivesse publicando um novo gráfico para cada versão de aplicativo para cada ambiente, estaria criando centenas a milhares de versões de gráfico por semana. Na maioria dos casos, as únicas diferenças seriam a versão do aplicativo. Eu sou então forçado a aumentar a versão do gráfico. Para mim, os requisitos introduzidos por todo este parágrafo, embora lógicos com uma coisa desencadeando outra, são loucos.

Como o .Chart.appVersion não está funcionando para nós, revertemos para um .Chart.appVersion estático e estamos usando .Values.image.tag (este não é um convite para reabrir esse debate)

Eu tinha certeza que appVersion era o caminho a seguir em relação à versão do aplicativo depois de ler a documentação, até ler todos esses casos de uso válidos.

Para usuários de um pacote de gráficos é mais fácil aumentar image.tag , isso implica em modificar apenas os valores, o gráfico pode ficar em outro lugar. Mas usando image.tag você não obtém informações sobre a versão do pacote ao fazer helm history <release>

Eu notei também que helm package <chart> irá gerar um arquivo tar com o Chart.version . Se você quiser apenas distribuir uma nova versão do seu aplicativo e for usado appVersion , espera-se que você também aumente version , caso contrário, você substituirá o arquivo anterior. Se appVersion e version forem diferentes, é mais difícil calcular o aumento semver correto com ferramentas automáticas para version (suponha que appVersion seja aumentado com base nas mensagens de confirmação ). Como vocês lidam com isso?

Só precisamos de algo que seja uma versão real do aplicativo que possamos ver ao listar os gráficos implantados.

Quando tenho um gráfico de leme criado para implantar meu microsserviço padrão, gostaria de escolher durante a implantação qual versão do aplicativo esse microsserviço tem durante a implantação. Atualmente, todos os meus serviços têm appVersion 1.0.0 para sempre e não estou usando helm para verificar qual versão do aplicativo eu tenho - porque tornar isso possível com os métodos atuais (reempacotar o gráfico) tornará minha vida um inferno.

Apenas, por favor, deixe-nos decidir como usaremos este parâmetro. Se isso não for possível devido a alguns motivos técnicos, informe-nos o motivo.

Eu prefiro não usar "sed" como mencionado em 8194
Até que isso seja resolvido (ou não) Aqui está como eu resolvi isso no meu CI/CD (GitLab):

Empacote o gráfico com a versão do aplicativo e implante-o.
Eu sei que a versão do Chart não deve ser a mesma que a appVersion, mas no nosso caso é uma solução alternativa.

Além disso, não há necessidade de fazer upload para um repositório de leme, mas é possível usar os artefatos de CI resultantes (chart.tgz)

Portanto, se a embalagem primeiro não for um problema e você precisar de uma solução alternativa para hoje , poderá usar algo assim.

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

Na saída agora tenho as versões disponíveis.

 $ 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
Obrigado pelo snippet, para quem procura, há outro exemplo anterior neste passo https://github.com/helm/helm/issues/8194#issuecomment -635879040 que atinge o mesmo resultado.

Esta questão em mãos, no entanto, é que reempacotar o gráfico é indesejável e os mantenedores do leme estão forçando essa opinião e maneira de trabalhar. Este pedido é que o leme seja menos opinativo e permita que o leme seja usado de uma maneira que melhor se adapte a outras partes da comunidade.
Esta edição e https://github.com/helm/helm/issues/3555 explorou as diferenças entre .Chart.version e .Chart.appVersion , especificamente como a maioria dos gráficos públicos vincula appVersion a a tag de contêiner que forçou a alteração da versão do gráfico simplesmente porque uma nova versão de um aplicativo foi lançada. Embora isso possa ser uma boa suposição para a maior parte dos gráficos públicos, a suposição não é válida para um número significativo de gráficos privados. Daí este pedido aos mantenedores do leme para que parem de forçar essa abordagem na comunidade.

ps Seu trecho de código implica uma versão do gráfico por versão / por ambiente que substituiria a necessidade de definir image.repository e image.tag . Eu esperaria um passo após o reempacotamento para publicar o gráfico em um repositório de leme no caso de você precisar reimplantar, consulte https://github.com/helm/helm/issues/8194#issuecomment -658715462 acima, que explora esse coelho buraco

@haimari
Obrigado pelo trecho, para quem procura, há outro exemplo anterior neste passo # 8194 (comentário) que atinge o mesmo resultado.

Esta questão em mãos, no entanto, é que reempacotar o gráfico é indesejável e os mantenedores do leme estão forçando essa opinião e maneira de trabalhar. Este pedido é que o leme seja menos opinativo e permita que o leme seja usado de uma maneira que melhor se adapte a outras partes da comunidade.
Esta edição e a nº 3555 exploraram as diferenças entre .Chart.version e .Chart.appVersion , especificamente como a maioria dos gráficos públicos vincula appVersion à tag de contêiner que forçou a versão do gráfico a mudar simplesmente porque há uma nova versão de um aplicativo é lançado. Embora isso possa ser uma boa suposição para a maior parte dos gráficos públicos, a suposição não é válida para um número significativo de gráficos privados. Daí este pedido aos mantenedores do leme para que parem de forçar essa abordagem na comunidade.

ps Seu trecho de código implica uma versão do gráfico por versão / por ambiente que substituiria a necessidade de definir image.repository e image.tag . Eu esperaria um passo após o reempacotamento para publicar o gráfico em um repositório de leme no caso de você precisar reimplantar, veja # 8194 (comentário) acima, que explora a toca do coelho

@timothyclarke Obrigado pela informação.

1. Esta não é uma prática recomendada, mas uma solução alternativa para _"Fornecer um meio de definir .Chart.AppVersion durante a instalação ou atualização sem editar Chart.yaml"_
2. Não há necessidade de enviar o gráfico para um repositório, isso funciona com vários clusters k8s diretamente do Gitlab.
3. Ele fornece tudo o que eu preciso para ter lançamentos:

Os image.repository e image.tag são definidos exatamente da mesma maneira no pipeline,
então mesmo sem a linha de embalagem, essa é a maneira de usar o leme do gitlab.

a variável CI_COMMIT_TAG contém a tag de versão atual do pipeline executado.
Assim, sempre podemos reverter para a versão anterior diretamente do pipeline de CI com um clique.

Minha empresa tem nosso gráfico de leme desacoplado das tags de contêiner. Não há absolutamente nenhuma necessidade de reempacotar o gráfico para cada compilação de contêiner.

A ausência da opção de definir appVersion (e, portanto, sempre defini-lo com o mesmo valor) durante a instalação é uma grande deficiência em nosso processo de implantação. É realmente irritante que nossos usuários não possam ver as versões do aplicativo fazendo "lista de leme"

Ter a capacidade de usar algo como "instalação do helm ... --app-version v1.2.3" agregaria muito valor ao uso do Helm em nosso caso.

Minha proposta seria descontinuar appVersion e listar chart version e container tag ao fazer helm list ou helm history <name> .
O Helm não deve tentar fornecer a versão real do aplicativo dentro do container, ele deve fornecer o que tem em mãos, a tag e a versão do gráfico, aqui alguns exemplos:

| GRÁFICO | ETIQUETA DE RECIPIENTE |
| ----- | ----- |
| 0.1.0 | 0.3.0 |
| 0.1.0 | 0.4.0 |

No exemplo acima podemos inferir que o gráfico está sendo reutilizado para diferentes tags

| GRÁFICO | ETIQUETA DE RECIPIENTE |
| ----- | ----- |
| 0.3.0 | 0.3.0 |
| 0.4.0 | 0.4.0 |

No exemplo acima, poderíamos inferir que o gráfico compartilha a mesma versão que a tag.

A principal desvantagem do appVersion parece ser que ele requer que o pacote seja republicado, mesmo que o gráfico não tenha mudado, mas o código dentro do container sim. Enquanto isso, a tag do container pode ser fornecida por meio de values.yaml e não precisa ser republicada.

Alternativas

O mais simples eu acho que seria listar a tag do container ao fazer helm list ou helm history , mas seria estranho ter um appVersion por aí. Isso, pelo menos, daria algumas informações extras, e as pessoas poderiam ignorar appVersion .

Outra solução, em vez de descontinuar appVersion , poderia ser movido para o values.yaml , desta forma seria desanexado do gráfico, evitando várias republicações.

Pensamentos?

@Woile e se seu aplicativo tiver mais de 1 contêiner?

@Woile e se seu aplicativo tiver mais de 1 contêiner?

Você está certo, considerando esse caso de uso também (desculpe, eu estava pensando sobre meus casos de uso), acho que mover appVersion para o values.yaml melhoraria a situação.

• helm list e helm history podem permanecer os mesmos
• você pode ter mais de um recipiente
• você não precisa republicar todas as vezes, mas pode se quiser manter Chart e appVersion em sincronia.

o que estou perdendo?

Minha preferência seria permitir controlar appVersion explicitamente. Pode ser igual a tags de contêiner(es), ou pode precisar ser definido com um valor diferente (por exemplo, meu script de instalação procura um determinado repositório/espaço de nomes/tag de contêiner e, em seguida, aplica um regex para transformá-los em um amigável formato para exibir a versão do aplicativo)

@woodcockjosh @Woile
Meus $ 0,02. O conceito de appVersion é bom do ponto de vista helm ls . A implementação é o problema que eu gostaria de ver corrigido. Ter várias tags / versões em appVersion deve ser bom, por exemplo, appVersion: nginx-1.16.0-php-7.5

Observo que o leme 3.2.4 tem {{ .Values.image.tag | default .Chart.AppVersion }} então permite esse tipo de desconexão

A capacidade de selecionar appVersion durante a instalação/atualização seria a abordagem mais preferida. Não faz sentido aumentar a versão do gráfico toda vez que appVersion muda, pois o gráfico em si não é alterado. A progressão linear do controle de versão também nem sempre é aplicável - especialmente para aplicativos de vários contêineres implantados em diferentes ambientes com diferentes combinações de versões de contêiner. A sugestão de usar o mesmo appVersion e chartVersion também é ruim porque isso força appVersion a ser semVer compatível. semVer não é o santo graal do versionamento e o appVersion deve ser livre para usar qualquer esquema de versionamento que seja mais apropriado para o aplicativo.

@bacongobbler Este comentário significa que o leme planeja implementar esse sinalizador?

Acho que a introdução de app-version (na opção de linha de comando) e appVersion (em Chart.yaml) fornece efetivamente uma boa maneira de ver a versão de um aplicativo implantado com uma instância de gráfico. Mas isso também gera muitas questões e práticas diferentes que precisam ser esclarecidas.

• O objetivo do helm (chart) é empacotar e instalar recursos em um cluster kubernetes (para um aplicativo).
• A versão do aplicativo só pode ser fornecida na fase do pacote, então essas informações passam a fazer parte do gráfico.
• Armazenado em um repositório helm (como um artefato java ou python), o gráfico se torna imutável. Portanto, a versão do aplicativo nunca deve ser substituída.
• Por outro lado, durante a fase de instalação ou atualização, os valores permitem substituir quaisquer valores do gráfico (para personalizações do ambiente), mas o appVersion não pode.
• Como podemos ver em muitos casos de uso, a versão real do aplicativo é a versão da imagem fornecida por image.tag durante a fase de instalação ou atualização

Minha conclusão

• Um gráfico guarda-chuva pode ser considerado como uma agregação de vários gráficos (dependências) que seguem seu ciclo de vida adequado
• Um gráfico guarda-chuva é o único caso em que o appVersion não está diretamente vinculado à imagem usada.
• Um aplicativo sempre fornece um gráfico onde, em muitos casos, a tag app-version = image (portanto, por transitividade ao código do aplicativo)
• A separação da fonte entre o código do aplicativo e o código do gráfico apenas apresenta algumas dificuldades na conformidade entre a imagem do docker e o gráfico.
• Gráfico compartilhado como um "gráfico de inicialização de mola" precisa ser sempre usado como uma dependência no gráfico do aplicativo (Mesmo que seu aplicativo seja composto apenas dessa dependência) ... você não implanta um gráfico compartilhado, mas um aplicativo!

Minha escolha atual

• um gráfico compartilhado só produz um gráfico com sua versão e a versão do aplicativo está sempre vazia (nunca usada)
• um gráfico compartilhado nunca é usado diretamente para fazer uma implantação.
• um gráfico de aplicativo (componente) sempre produz um gráfico adequado, em que versão do gráfico = versão do aplicativo = tag de imagem
• um gráfico guarda-chuva é o ciclo de vida adequado, onde a versão do gráfico representa a versão do aplicativo

Pergunta / Ideia

Eu não sei por que a versão do aplicativo foi introduzida (talvez para cobrir o mau uso do gráfico compartilhado).
Acho que pode ser uma boa ideia removê-lo e introduzir a capacidade de definir a tag de imagem na fase do pacote sem usar soluções alternativas como sed ou yq.

Talvez um post muito longo, mas eu preciso de alguns feedbacks

@grazius
Meu entendimento do seu post é que os sinalizadores --set , -f e --values são ruins e nunca devem ser usados. Todas as implantações são imutáveis ​​e devem ser renderizadas em um gráfico, mesmo que esse gráfico seja pouco mais que values.yaml e o gráfico guarda-chuva como uma dependência. Este gráfico deve ser renderizado no tempo de compilação (aplicativo) e publicado em um repositório de gráficos

Na situação acima, onde você está armazenando segredos ou informações confidenciais semelhantes? Em todos os lugares em que trabalhei, eles foram alimentados por meio de um arquivo --values

Para algum contexto, minhas implantações têm efetivamente 3 elementos que são versionados de forma independente

• Gráfico
• Aplicativo
• (Ambiente) Valores de configuração

Se eu mudar um desses, não devo ser forçado a reconstruir nenhum dos outros. Normalmente estou usando vários ambientes para que os aplicativos possam ser testados antes de serem _live_. Como tal implantação gostaria de chart-v1.0 application_build-50 config_non-prod-v1.3 com os arquivos de configuração env armazenados gpg criptografados.
Minha plataforma de CI está gerenciando a compilação, implantação e promoção do aplicativo à medida que a compilação flui da origem até o teste e a produção. Se precisarmos reimplantar uma versão histórica do aplicativo, reexecutaremos esses trabalhos.

Pergunta: Por que devemos ser forçados a usar um repositório de gráficos para armazenar o estado que minha plataforma de CI processa imediatamente? Nunca devemos instalar nada disso manualmente

@timothyclarke apenas certifique-se de usar o plugin de segredos para que você possa usar arquivos de valores criptografados

@timothyclarke Olá, obrigado por este primeiro feedback ;)

• A vantagem de um repositório (como pypi, maven central, docker registries for development) é que o artefato gerado pode ser compartilhado e publicado (para helm é um tgz) com a garantia de que é imutável.
• Para valores por ambiente (é outro assunto) eles podem ser armazenados onde você quiser (scm repo, solução dedicada como hashicorp para segredos, illumio para netpol, etc...).

Um gráfico fornece valores padrão.yaml (imutáveis ​​para cada versão do gráfico) que podem ser usados ​​(ou substituídos) pelos consumidores do gráfico.
Para o Chart.yaml também é uma parte imutável do gráfico ... e o app-version está incluído.

No seu caso, o que é exibido na lista de leme para a versão do aplicativo? 50?
Se sim, como você colocou a versão do aplicativo no gráfico app-version em seu pipeline?

@grazius

Um gráfico fornece valores padrão.yaml (imutáveis ​​para cada versão do gráfico) que podem ser usados ​​(ou substituídos) pelos consumidores do gráfico.
Para o Chart.yaml, também é uma parte imutável do gráfico ... e a versão do aplicativo está incluída.

Talvez eu esteja entendendo mal o que você está dizendo aqui, mas isso levanta a questão de por que ter uma versão de aplicativo se ela é imutável para cada versão do gráfico? Então, para cada mudança de versão do aplicativo, também teria que haver um aumento na versão do gráfico, mesmo que nenhuma outra alteração fosse feita no gráfico? Em caso afirmativo, por que ter a versão do gráfico ou a versão do aplicativo?

Acho que isso também vai contra o que está sendo solicitado, "Fornecer um meio de configurar .Chart.AppVersion durante a instalação ou atualização sem editar Chart.yaml" Acredito que o que @timothyclarke disse anteriormente neste bate-papo resume as coisas muito bem: https:/ /github.com/helm/helm/issues/8194#issuecomment -671331311

Acho que outra coisa importante a ter em mente é que nem todos têm controle sobre o gráfico que está sendo usado, mas podem ter a capacidade de passar a imagem que está sendo usada e outros valores para o gráfico no momento da implantação. Nesse caso, como você sugeriria atualizar a versão do aplicativo implantada?

A mesma questão aqui!
Considerando o uso do sinalizador --description como uma solução alternativa para fornecer alguma maneira de mostrar a versão do aplicativo no helm list 🤔

A versão do aplicativo é realmente necessária quando você cria um gráfico guarda-chuva. Para o gráfico de componentes, o interesse de fazer evoluir a versão do gráfico e a versão do aplicativo separadamente é muito baixo, eu acho.

Talvez o principal problema seja que o tipo no Chart.yaml não é preciso o suficiente? Não há como diferenciar um guarda-chuva, um gráfico compartilhado ou de aplicativos

@grazius Essa é uma resposta bastante opinativa.
Embora possa ser aplicável a muitos projetos de código aberto, não é tão aplicável a tantas compilações de código fechado. Por favor, reveja este tópico incluindo todas as várias declarações e casos de uso feitos, pois esta solicitação não é uma solicitação para remover .Chart.AppVersion da especificação de um gráfico. Não é nem mesmo uma solicitação para mascarar APP VERSION da saída de helm ls .
Este segmento é um pedido para tornar Chart.AppVersion configurável no momento em que um gráfico é usado (sem ter que reconstruir ou alterar o gráfico) para que o campo APP VERSION de helm ls não é enganoso.

Atualmente, eu argumentaria que APP VERSION é um campo supérfluo em helm ls e não deve ser visível para comandos de tempo de execução devido ao quão próximo .Chart.AppVersion está vinculado a .Chart.Version . helm inspect chart --version <.Chart.Version> <.Chart.Name> fornece a mesma informação.
Eu também estenderia isso para o uso de .Chart.AppVersion para ser usado como a tag do contêiner, pois todas são coisas ligeiramente diferentes que podem ser versionadas independentemente por razões válidas, mas atualmente são encaixadas em uma única coisa.
Tentei manter minhas opiniões sobre essa vinculação fora desta solicitação, pois os projetos podem ter razões inteiramente válidas para tal vinculação. Ao não forçar o mesmo processo a todos que usam o leme, tornamos o leme uma ferramenta melhor e mais inclusiva.
Eu não acho que essas mudanças solicitadas diminuam o leme ou forcem seu uso para outros.

@bacongobbler Você pode comentar sobre isso? É um recurso altamente solicitado

É um recurso altamente solicitado

Olá, @jasondamour - obrigado pelo seu interesse! Duas boas opções: criar um plugin helm e escrever um HIP .

Oi, talvez a melhor solução seja fornecer um argumento release-app-version para o comando install/upgrade que, se presente, substitui a exibição da versão do aplicativo quando fazemos uma lista de leme.?