Gerir um lançamento do Helm
- 12 minutos
Como usar funções em um modelo Helm
A linguagem de modelo Helm define funções que você usa para transformar valores do values.yaml arquivo. A sintaxe de uma função segue a estrutura {{ functionName arg1 arg2 ... }} . Vamos olhar para a função quote como um exemplo para ver essa sintaxe em uso.
A função quote encapsula um valor entre aspas para indicar o uso de um string. Digamos que você defina o seguinte arquivo values.yaml:
apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
enabled: true
Você decide que deseja usar o valor ingress.enabled como um booleano ao determinar se um manifesto de entrada deve ser gerado. Para usar o valor enabled como booleano, faça referência ao valor usando {{ .Values.ingress.enabled }}.
Mais tarde, você decide exibir o campo como uma cadeia de caracteres no arquivo templates/Notes.txt. Como as regras de coerção de tipo YAML podem levar a bugs difíceis de encontrar em modelos, você decide seguir as orientações e ser explícito ao incluir cadeias de caracteres em seus modelos. Por exemplo, enabled: false não é igual a enabled: "false".
Para exibir o valor como uma cadeia de caracteres, use {{ quote .Values.ingress.enabled }} para fazer referência ao valor booleano como uma cadeia de caracteres.
Como usar pipelines num modelo de Helm
Você usa pipelines quando mais de uma função precisa agir sobre um valor. Um pipeline permite enviar um valor, ou o resultado de uma função, para outra função. Por exemplo, você pode reescrever a função quote acima como {{ .Values.ingress.enabled | quote }}. Observe como o | indica que o valor é enviado para a quote função.
Aqui está outro exemplo. Digamos que você queira converter um valor em maiúsculas e envolvê-lo entre aspas. Você pode escrever a declaração como {{ .Values.ingress.enabled | upper | quote }}. Observe como o valor é processado pela função upper e, em seguida, pela função quote.
A linguagem do modelo inclui mais de 60 funções que permitem expor, pesquisar e transformar valores e objetos em modelos.
Como usar o controle de fluxo condicional em um modelo Helm
O controle de fluxo condicional permite que você decida a estrutura ou os dados incluídos no arquivo de manifesto gerado. Por exemplo, talvez queira incluir valores diferentes com base no destino de implantação ou controlar se um ficheiro de manifesto é gerado.
O bloco if / else é uma estrutura de fluxo de controle e está em conformidade com o seguinte layout:
{{ if | pipeline | }}
# Do something
{{ else if | other pipeline | }}
# Do something else
{{ else }}
# Default case
{{ end }}
Digamos que você decida que o arquivo de manifesto de entrada para um gráfico só é criado em casos específicos. O exemplo a seguir mostra como fazer isso usando uma instrução if:
{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{ end }}
Lembre-se de que você pode usar espaços reservados para preencher metadados no modelo. Os arquivos de modelo são analisados e avaliados sequencialmente pelo idioma do modelo de cima para baixo. No exemplo anterior, o motor de template só gera o conteúdo do ficheiro de manifesto se o valor .Values.ingress.enabled for true.
Quando o mecanismo de modelo processa a instrução, ele remove o conteúdo declarado dentro da sintaxe {{ }} e deixa o espaço em branco restante. Esta sintaxe faz com que o motor de templates inclua uma nova linha para a instrução if. Se você deixar o conteúdo do arquivo anterior as-is, você notará linhas vazias em seu YAML e o arquivo de manifesto de entrada será gerado.
YAML dá significado ao espaço em branco. É por isso que guias, espaços e caracteres de nova linha são considerados importantes. Para corrigir o problema de espaço em branco indesejado, você pode reescrever o arquivo da seguinte maneira:
{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{- end }}
Observe o uso do caractere - como parte do início {{- e do final -}} da sequência da instrução. O caractere - instrui o analisador a remover caracteres de espaço em branco.
{{- remove o espaço em branco no início de uma linha e -}} no final de uma linha, incluindo o caractere de nova linha.
Como percorrer uma coleção de valores num modelo Helm
YAML permite que você defina coleções de itens e use itens individuais como valores em seus modelos. O acesso a itens em uma coleção é possível usando um indexador. No entanto, a linguagem de modelo Helm suporta a iteração de uma coleção de valores usando o operador range.
Digamos que você defina uma lista de valores em seu arquivo values.yaml para indicar hosts de entrada adicionais. Aqui está um exemplo dos valores:
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
Use o operador range para permitir que o mecanismo de modelo itere através do .Values.ingress.extraHosts. O trecho de código a seguir mostra um exemplo condensado usando o operador range:
{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
...
spec:
rules:
...
{{- range .Values.ingress.extraHosts }}
- host: {{ .name }}
http:
paths:
- path: {{ .path }}
...
{{- end }}
...
{{- end }}
Como controlar o escopo de valores em um modelo Helm
Quando você tem valores definidos com várias camadas de profundidade, sua sintaxe pode se tornar longa e complicada ao incluir esses valores em um modelo. A ação with permite limitar o escopo de variáveis em um modelo.
Lembre-se de que o . usado em um template Helm faz referência ao escopo atual. Por exemplo, o .Values instrui o mecanismo de modelo a localizar o objeto Values no escopo atual. Digamos que você esteja usando o arquivo values.yaml de anteriormente para criar um arquivo de manifesto do mapa de configuração:
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
Em vez de acessar o valor do caminho de cada item usando {{ .Values.ingress.extraHosts.path }}, você pode usar a ação with. O trecho de código a seguir mostra um exemplo usando o operador range para gerar um arquivo de manifesto do mapa de configuração:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- with .Values.ingress.extraHosts }}
hostname: {{ .name }}
path: {{ .path }}
{{ end }}
O {{- with .Values.ingress.extraHosts }} limita o escopo dos valores ao array .Values.ingress.extraHosts.
A ação with restringe o escopo. Não é possível aceder a outros objetos a partir do âmbito pai. Digamos que você também queira acessar o {{ .Release.Name }} do gráfico no bloco de código with. Para acessar objetos pai, você precisa indicar o escopo raiz usando o caractere $ ou reescrever seu código. Aqui está o código atualizado para mostrar como incluir objetos-pai usando o caractere $:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- with .Values.ingress.extraHosts }}
hostname: {{ .name }}
path: {{ .path }}
release: {{ $.Release.Name}}
{{ end }}
Observação
Há várias construções disponíveis na linguagem de modelo Helm para controlar o fluxo. A unidade de resumo deste módulo inclui uma seção com links para a documentação do Helm para saber mais.
Como Helm definir dependências de gráficos
Um gráfico permite a declaração de dependências para suportar o aplicativo principal e faz parte da versão instalada.
Você pode criar um subgráfico usando o comando helm create, especificando o local do novo gráfico na pasta /charts, ou usar o comando helm dependency. Lembre-se de que a pasta /charts pode conter subgráficos implantados como parte da versão do gráfico principal.
O comando helm dependency permite gerenciar dependências incluídas em um repositório Helm. O comando usa metadados definidos na seção dependencies do arquivo de valores do gráfico. Você especifica o nome, o número da versão e o repositório de onde instalar o subgráfico. Aqui está uma extração de um arquivo values.yaml que tem um gráfico MongoDB listado como uma dependência:
apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
...
dependencies:
- name: mongodb
version: 10.27.2
repository: https://marketplace.azurecr.io/helm/v1/repo
Depois que os metadados de dependência forem definidos, execute o comando helm dependency build para buscar o gráfico empacotado tar. O comando de construção de gráfico baixa o gráfico para a pasta charts/.
helm dependency build ./app-chart
Os subgráficos são gerenciados separadamente do gráfico principal e podem precisar de atualizações à medida que novas versões ficam disponíveis. O comando para atualizar subgráficos é helm dependency update. Este comando busca novas versões do subgráfico enquanto exclui pacotes desatualizados.
helm dependency update ./app-chart
Tenha em mente que uma dependência de diagrama não se limita a outras aplicações. Você pode decidir reutilizar a lógica de modelo em seus gráficos e criar uma dependência especificamente para gerenciar essa lógica como uma dependência de gráfico. Você terá um exemplo dessa estratégia no próximo exercício.
Como atualizar uma versão do Helm
O Helm permite atualizar versões existentes como um delta de todas as alterações que se aplicam ao gráfico e suas dependências.
Por exemplo, digamos que a equipe de desenvolvimento do exemplo webapp nesta unidade faça alterações de código que afetam apenas a funcionalidade do site. A equipe faz as seguintes atualizações no arquivo Chart.yaml para refletir a nova versão do aplicativo:
- Atualiza a imagem de contêiner do aplicativo Web e marca a imagem como
webapp: linux-v2ao enviar a imagem para o registro do contêiner. - Atualiza o valor
dockerTagparalinux-v2e o valor da versão do gráfico para0.2.0no arquivo de valores do gráfico.
Aqui está um exemplo do arquivo de values.yaml atualizado:
apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
type: application
version: 0.2.0
appVersion: 1.0.0
registry: "my-acr-registry.azurecr.io"
dockerTag: "linux-v2"
pullPolicy: "Always"
Em vez de desinstalar uma versão atual, use o comando helm upgrade para atualizar a versão Helm existente.
helm upgrade my-app ./app-chart
Lembre-se de que Helm gera um delta das alterações feitas no gráfico Helm quando você atualiza uma versão. Como tal, uma atualização do Helm apenas atualiza os componentes identificados no delta. No exemplo, apenas o site é reimplantado.
Quando a atualização for concluída, você poderá revisar o histórico de implantação da versão usando o comando helm history com o nome da versão.
helm history my-app
O comando history retorna vários campos que descrevem a versão, conforme mostrado na saída de exemplo a seguir:
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Mon Oct 11 17:25:33 2021 deployed aspnet-core-1.3.18 3.1.19 Install complete
Observe o campo revision no resultado. Helm rastreia as informações de todas as versões lançadas de um Helm chart. Quando você instala uma nova versão de um gráfico Helm, a contagem de revisões aumenta em um e as informações da nova versão correspondem a essa revisão.
Aqui está um exemplo do mesmo comando de histórico executado após uma nova versão de instalação do aplicativo Web:
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Mon Oct 11 17:25:33 2021 superseded aspnet-core-1.3.18 3.1.19 Install complete
2 Mon Oct 11 17:35:13 2021 deployed aspnet-core-1.3.18 3.1.19 Upgrade complete
Como reverter um release do Helm
O Helm permite a reversão de uma versão existente do Helm para uma versão instalada anteriormente. Lembre-se de anteriormente que Helm rastreia informações de lançamento de todos os lançamentos de um gráfico Helm.
Use o comando helm rollback para reverter para uma revisão de versão específica do Helm. Este comando usa dois parâmetros. O primeiro parâmetro identifica o nome da versão e o segundo identifica o número de revisão da versão.
helm rollback my-app 2
O comando helm rollback reverte a versão de lançamento do aplicativo para a revisão especificada e atualiza o histórico de versões do aplicativo. Uma execução subsequente do comando helm history mostra o número de revisão ativa mais recente como a entrada de versão mais recente.
Por exemplo, digamos que a equipe de desenvolvimento do exemplo webapp nesta unidade descobre um bug no aplicativo Web de rastreamento de drones e precisa reverter para uma versão anterior. Em vez de desinstalar a versão atual e instalar uma versão anterior, eles revertem para a versão de trabalho.
helm rollback my-app 1
Quando uma reversão for concluída, você poderá revisar o histórico de implantação usando o comando helm history.
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Mon Oct 11 17:25:33 2021 superseded aspnet-core-1.3.18 3.1.19 Install complete
2 Mon Oct 11 17:35:13 2021 superseded aspnet-core-1.3.18 3.1.19 Rolled back to 1
3 Mon Oct 11 17:38:13 2021 deployed aspnet-core-1.3.18 3.1.19 Upgrade complete
Observe como o campo de descrição mostra o número de revisão da reversão para facilitar o controle das alterações.