Exportando modelos nomeados reutilizáveis

Um pacote de biblioteca distribui seu conteúdo na forma de modelos nomeados. Você os escreve com define, exatamente como faria em qualquer arquivo _helpers.tpl.

Os nomes dos modelos são globais em um pacote e em suas dependências. Prefixe os seus com o nome da biblioteca, como common.labels, para evitar conflitos.

Os modelos de biblioteca ficam no diretório templates do pacote, em arquivos com um sublinhado inicial para que o Helm nunca os renderize como manifestos.

Um bloco define isolado não produz nada quando o pacote é renderizado. O modelo só emite texto quando outro pacote o inclui posteriormente.

Você pode definir um objeto inteiro do Kubernetes como um único modelo nomeado. Os consumidores então renderizam um Service completo com uma única chamada a include.

Dentro de um fragmento, o ponto é o que quer que o chamador forneça. Ler .Values e .Release permite que o seu modelo se adapte a cada pacote consumidor.

Como os fragmentos confiam na entrada que recebem, deixe um comentário informando o contexto necessário. Um consumidor que passe o ponto errado receberá erros confusos.

Divida a lógica em fragmentos pequenos e focados: um para nomes, um para rótulos e um para seletores. Peças pequenas podem ser compostas facilmente em muitos pacotes.

Envolva define e end em marcadores de hífen, como {{- e -}}, para que a saída da biblioteca não insira linhas em branco indesejadas no YAML do consumidor.

Definir um modelo o torna disponível, não ativo. Ele só contribui para a saída quando um pacote de aplicação o chama com include ou template.

Alguns fragmentos, como common.fullname e common.labels, formam o vocabulário compartilhado sobre o qual todo pacote da equipe pode ser construído.

Por que uma biblioteca deve prefixar os nomes de seus modelos, usando common.labels em vez de labels?

Você publica lógica reutilizável com define em arquivos com prefixo de sublinhado, cria um espaço de nomes para os nomes e confia no ponto do chamador para obter o contexto. 🧩