🕴🏾 ⬇️ 🐳 Um guia rápido para projetar gráficos no Helm 🔖 🌪️ 🤨

Unsplash de Frank Eiffert

Helm é uma ferramenta poderosa para aplicar, atualizar e gerenciar aplicativos no Kubernetes. A comunidade Helm cria muitos gráficos de código aberto. Você pode implantar Redis, Nginx ou Prometheus Operator com um único comando. E eles vêm com tudo que você precisa, como o Ingress.

A equipe Mail.ru Cloud Solutions traduziu um artigo que descreve uma maneira rápida de criar um gráfico básico, mostrando comandos úteis e compartilhando práticas recomendadas. Ele não se detém em aspectos da linguagem de templates Go, já que a maioria deles é abordada na documentação do Helm. Este tutorial fornece aspectos e ideias mais abstratos para melhorar seu fluxo de trabalho.

Criação de uma estrutura gráfica básica

Comece com um comando simples que criará um exemplo de estrutura de gráfico:

$ helm create basic
Creating basic
$ tree basic
basic/
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

Isso é tudo o que é preciso para criar um gráfico pronto para implantação. Este gráfico permite que você implante um aplicativo com todos os componentes necessários. Se você der uma olhada em values.yaml, verá que este aplicativo implantará o Nginx.

Expandir um gráfico é tão fácil quanto criar:

$ helm install basic

A equipe do template é sua melhor amiga

Imediatamente antes da instalação e após as alterações no gráfico, você deve verificar se tudo está sendo tratado corretamente nos modelos.

Para verificar o que exatamente será implantado no cluster, use o comando:

$ helm template basic

O comando produzirá cada YAML gerado por todos os modelos. Se você quiser ver apenas o resultado de um modelo, use:

$ helm template basic -x templates/service.yaml

O resultado será mais ou menos assim:

---
# Source: basic/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-basic
  labels:
    app.kubernetes.io/name: basic
    helm.sh/chart: basic-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: basic
    app.kubernetes.io/instance: release-name

Para testar um modelo com valores personalizados, use:

$ helm template basic -x templates/service.yaml -f \ mypath/tocustomvalues.yaml

O modelo gerado pode ser testado no cluster usando o comando:

$ helm install basic --dry-run --debug

LINT!

Antes de enviar para o repositório, você pode adicionar mais uma etapa para verificar claramente o código - linting (análise estatística):

$ helm lint basic/
==> Linting basic/
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, no failures

Helm trabalha com funções

Se você olhar para o diretório de modelos de gráfico, poderá ver _helpers.tpl. Aqui você pode adicionar suas funções, elas estarão disponíveis em todo o gráfico. Uma função de exemplo pode ter a seguinte aparência:

{{/*
Expand the name of the chart.
*/}}
{{- define "basic.name" -}} 
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}} 
{{- end -}}

O uso de uma função em um modelo é indicado por meio de uma função include:

app.kubernetes.io/name: {{ include "basic.name" . }}

Meta rótulos

Uma parte importante do Kubernetes é o uso correto dos rótulos. Isso é muito importante se você estiver usando o Helm para implantar vários manifestos. Para adicionar tags facilmente para encontrar recursos gerenciados pelo Helm, você pode usar suas próprias funções:

{{/*
Common labels
*/}}
{{- define "basic.labels" -}} 
app.kubernetes.io/name: {{ include "basic.name" . }}
helm.sh/chart: {{ include "basic.chart" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}

E agora é fácil adicionar algumas tags ao gráfico:

apiVersion: v1
kind: Service
metadata:
  name: {{ include "basic.fullname" . }}
  labels:
{{ include "basic.labels" . | indent 4 }}
...

Se você deseja encontrar serviços criados usando este gráfico, use o comando:

$ kubectl get svc -l helm.sh/chart=basic-0.1.0

Os comentários vão salvar você

Existem dois tipos de comentários:

# É um comentário simples que permanece no YML resultante após o processamento.
{{- / * ... * / -}} é um comentário descartado pelo mecanismo de modelagem.

# app files volume
        {{- /*
          App files are configmaps created by cloud-app-play-files chart.
          App files contains files specific for app and environment.
          App name should be same as in deployment of cloud-app-play-files chart.
        */ -}} 
        {{- if .Values.include.appDir }}
        - name: {{ $appName }}-files
          configMap:
            name: {{ $appName }}-files

A saída do modelo será assim:

       # app files volume
       - name: app-notification-files
         configMap:
           name: app-notification-files

Como você pode ver, o manifesto gerado contém apenas um comentário de tipo simples. Que tipo de usar é com você. Mas os comentários do modelo são úteis se você estiver definindo pipelines ou dependências mais complexas em YAML.

Também é importante lembrar que os comentários que começam com # também são analisados. Se você colocar um modelo Go em um comentário, ele será avaliado. Portanto, os comentários também podem ser modelos.

Certifique-se de manter a documentação

A documentação do gráfico é indispensável, especialmente se você deseja publicar um gráfico. A maneira mais fácil de criar e manter documentos é usar o pacote Golang denominado helm-docs . Com ele você pode gerar um README.md contendo tabelas de valores, versões e descrições de values.yaml e chart.yaml, ou usar outros arquivos personalizados.

^{Exemplo retirado de https://github.com/norwoodj/helm-docs}

Como você pode ver, adicionar o nome com - nos resultados dos comentários em uma linha da tabela. Além disso, a tabela contém informações adicionais, como descrição do gráfico, nome e versão. Helm-docs pode ser integrado a um pré-commit junto com o linting. É fácil fazer isso:

$ helm-docs
INFO[2020-07-23T15:30:38+02:00] Found Chart directories [.]                 
INFO[2020-07-23T15:30:38+02:00] Generating README Documentation for chart .

A magia dos subcharts

Quando seu gráfico se torna o monstro da arquitetura, é melhor dividir alguns dos componentes do gráfico em outros menores. Eles são chamados de subcharts ou gráficos filho.

Os subcharts são implantados ao mesmo tempo que o gráfico principal. Os valores dos subcharts podem ser fornecidos no mesmo arquivo values.yaml do gráfico principal. Você também pode conectá-los a partir do GitHub, mas para o artigo, criarei um subchart localmente.

Para começar com um novo subchart do qual depende o gráfico principal, crie um diretório de gráficos dentro da pasta do gráfico principal. Em seguida, crie um gráfico básico:

$ mkdir charts
$ cd charts
$ helm create subbasic

Para conectar um subchart, altere a definição do gráfico principal:

apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: basic
version: 0.1.0
dependencies:
  - name: subbasic

Agora, toda vez que o comando é lançado helm install, não apenas o gráfico principal é expandido, mas também o subchart. Para substituir o nome de referência do subchart ao implantar no serviço, adicione os seguintes comandos a values.yaml do gráfico principal:

subbasic:
 service:
   type: NodePort
 nameOverride: "jojo"

Agora execute o comando templatee veja a saída modificada do serviço do subchart. O tipo de serviço mudará junto com o nome:

---
# Source: basic/charts/subbasic/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-jojo
  labels:
    app.kubernetes.io/name: jojo
    helm.sh/chart: subbasic-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: jojo
    app.kubernetes.io/instance: release-name

Nota importante: os subcharts não podem obter valores de gráficos pais.

Momentos que muitas vezes são esquecidos

Mais alguns pontos:

Nomes de recursos - 63 caracteres no máximo.
Os nomes dos recursos só podem ser números, letras minúsculas, "-" ou ".".
Tamanho do gráfico - não mais do que 1 MB . Isso é especialmente importante se você estiver usando anexos de arquivo.
O gráfico tem uma função de análise .tpl.
Você pode especificar os recursos que permanecerão após o comando ter removido a implantação do gráfico helm delete.

Bom, isso é tudo!

Agora você pode escrever seu primeiro gráfico. Vale a pena mencionar o anexo de arquivos - os gráficos não são adequados para adicionar arquivos e salvar sua estrutura em diretórios. Mas na página de recomendação, você não encontrará informações sobre o que traçar e quais não.

Helm é uma ferramenta bastante jovem, mas com muito potencial. Não se esqueça de que linting, geração de documentação e até mesmo modelos de simulação em um cluster podem fazer parte do CI. O Helm Workflow já está disponível para GitHub .

Boa sorte!

O que mais ler:

Um guia rápido para projetar gráficos no Helm