Declarando um tipo de gráfico de biblioteca

Todo pacote Helm declara um type em Chart.yaml. O padrão é application, mas existe um segundo tipo dedicado exclusivamente ao compartilhamento de lógica de modelos.

Defina type: library e o pacote deixará de ser algo que você instala. Ele se tornará uma caixa de ferramentas de modelos nomeados para reutilização por outros pacotes.

Um pacote de biblioteca não produz objetos do Kubernetes por conta própria. Ele apenas define modelos que os pacotes consumidores chamam durante a renderização.

Executar helm install em um pacote de biblioteca falha. Não há nada para implantar, então o Helm recusa o comando por definição.

Os arquivos na pasta templates de um pacote de biblioteca não são renderizados como manifestos. Eles devem apenas definir fragmentos, sem emitir YAML diretamente.

O Helm ignora arquivos em templates que começam com um sublinhado. Os arquivos de modelos de bibliotecas usam nomes como _deployment.tpl para não serem renderizados.

Os pacotes de biblioteca só existem com apiVersion: v2. Os pacotes v1 da era do Helm 2 nem sequer tinham o conceito de tipo de biblioteca.

Uma biblioteca ainda precisa de um campo version para que os consumidores possam fixar uma versão. Trate-a como um artefato de lançamento real, não como uma pasta solta.

Em vez de copiar o mesmo YAML de Deployment para dez pacotes, você o escreve uma vez em uma biblioteca e permite que todos os pacotes o utilizem.

O pacote bitnami/common, amplamente utilizado, é uma biblioteca. Centenas de pacotes dependem dele para obter auxiliares compartilhados de rótulos, nomes e imagens.

Um pacote de application implanta cargas de trabalho; um pacote de library apenas fornece modelos. O campo type determina qual dos dois o Helm considera que ele é.

Você definiu type: library em Chart.yaml. O que acontece quando executa helm install nele?

Um pacote type: library não renderiza nada e não pode ser instalado. Ele existe apenas para empacotar modelos nomeados que outros pacotes reutilizam. 📦