Gerir uma versão do Helm
Como usar funções em um modelo Helm
A linguagem de modelos do Helm define funções que utiliza para transformar valores do ficheiro values.yaml. A sintaxe de uma função segue a estrutura {{ functionName arg1 arg2 ... }}. Vamos examinar a função quote como um exemplo para ver a sintaxe em utilização.
A função quote coloca entre aspas um valor para indicar a utilização de um string. Digamos que você defina o seguinte values.yaml arquivo:
apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
enabled: true
Decide que pretende utilizar o valor ingress.enabled como um booleano para determinar se deve ser gerado um manifesto de entrada. Para utilizar o valor enabled como um booleano, referencie o valor com {{ .Values.ingress.enabled }}.
Mais tarde, decide apresentar o campo como uma cadeia no ficheiro 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 apresentar um valor como cadeia, utilize {{ quote .Values.ingress.enabled }} para fazer referência ao valor booleano enquanto cadeia.
Como usar pipelines em um modelo Helm
Utilize pipelines quando mais do que uma função precisar de agir sobre um valor. Um pipeline permite-lhe enviar um valor, ou o resultado de uma função, para outra função. Por exemplo, pode reescrever a função quote acima como {{ .Values.ingress.enabled | quote }}. Repare que | indica que o valor é enviado para a função quote.
Aqui está outro exemplo. Digamos que você queira converter um valor em maiúsculas e envolvê-lo entre aspas. Pode escrever a instrução como {{ .Values.ingress.enabled | upper | quote }}. Repare que o valor é processado pela função upper e, em seguida, pela função quote.
A linguagem de modelos inclui mais de 60 funções que lhe permitem expor, procurar e transformar valores e objetos em modelos.
Como usar o controle de fluxo condicional em um modelo Helm
O controlo de fluxos condicional permite-lhe decidir a estrutura ou os dados incluídos no ficheiro de manifesto gerado. Por exemplo, talvez você queira incluir valores diferentes com base no destino ou controle de implantação se um arquivo de manifesto for gerado.
O if / else bloco é 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 if instrução:
{{ 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 ficheiros de modelo são analisados e avaliados sequencialmente pela linguagem de modelos de cima para baixo. No exemplo anterior, o mecanismo de modelo só gera o conteúdo do arquivo de manifesto se o .Values.ingress.enabled valor 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. A sintaxe faz com que o motor do modelo inclua uma linha nova para a linha da instrução if. Se você deixar o conteúdo do arquivo anterior como está, notará linhas vazias em seu YAML e o arquivo de manifesto de entrada será gerado.
O 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 do espaço em branco indesejado, pode reescrever o ficheiro da seguinte forma:
{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{- end }}
Repare na utilização do caráter - como parte da sequência de início {{- e de fim -}} da instrução. O caráter - instrui o analisador para remover carateres 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 caráter de nova linha.
Como iterar através de uma coleção de valores em um modelo Helm
O YAML permite-lhe definir coleções de itens e utilizar itens individuais como valores nos seus modelos. É possível aceder aos itens numa coleção com um indexador. No entanto, a linguagem de modelos do Helm suporta a iteração de uma coleção de valores com o operador range.
Digamos que você defina uma lista de valores em seu values.yaml arquivo 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: /
Irá utilizar o operador de intervalo para permitir que o motor do modelo itere através do .Values.ingress.extraHosts. O trecho de código a seguir mostra um exemplo condensado usando o range operador:
{{- 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-lhe limitar o âmbito das variáveis num modelo.
Lembre-se de que o . usado em um modelo Helm faz referência ao escopo atual. Por exemplo, o .Values instrui o motor do modelo para encontrar o objeto dos valores no âmbito atual. Digamos que você esteja usando o arquivo anterior para criar um arquivo de manifesto values.yaml do mapa de configuração:
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
Em vez de aceder a cada valor de caminho do item com {{ .Values.ingress.extraHosts.path }}, pode utilizar a ação with. O trecho de código a seguir mostra um exemplo usando o operador para gerar um arquivo de manifesto range 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 âmbito de valores para a matriz .Values.ingress.extraHosts.
A ação with restringe o âmbito. Não pode aceder a outros objetos a partir do âmbito principal. Digamos que você também queira acessar o {{ .Release.Name }} do gráfico no with bloco de código. Para aceder aos objetos principais, precisa de indicar o âmbito de raiz ao utilizar o caráter $ ou reescrever o 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 }}
Nota
Existem várias construções disponíveis na linguagem de modelos do Helm para o fluxo de controlo. A unidade de resumo deste módulo inclui uma secção com ligações 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 a aplicação principal e faz parte da versão instalada.
Pode criar um subgráfico com o comando helm create, ao especificar a localização do novo gráfico na pasta /charts, ou utilizar o comando helm dependency. Lembre-se de que a /charts pasta pode conter subgráficos implantados como parte da versão do gráfico principal.
O comando helm dependency permite-lhe gerir as dependências incluídas a partir de um repositório Helm. O comando utiliza metadados definidos na secção dependencies do ficheiro 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 values.yaml arquivo 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
Assim que os metadados da dependência estiverem definidos, execute o comando helm dependency build para obter o gráfico empacotado tar. O comando build do gráfico transfere 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
Lembre-se de que uma dependência de gráfico não está limitada a outros aplicativos. 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 a atualização de versões existentes como um delta de todas as alterações que se aplicam ao gráfico e às respetivas 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 Chart.yaml arquivo para refletir a nova versão do aplicativo:
- Atualiza a imagem do 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 e
linux-v2odockerTagvalor da versão do gráfico no0.2.0arquivo de valores do gráfico.
Aqui está um exemplo do arquivo atualizado values.yaml :
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 helm upgrade comando 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 é implementado novamente.
Quando a atualização for concluída, você poderá revisar o histórico de implantação da versão usando o helm history comando 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
Repare no campo revision no resultado. O Helm monitoriza as informações de todas as versões efetuadas para um gráfico Helm. Quando instala uma nova versão de um gráfico Helm, a contagem da revisão aumenta um valor 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 uma versão do Helm
O Helm permite a reversão de uma versão do Helm existente 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.
Pode utilizar o comando helm rollback para reverter para uma revisão de versão do Helm específica. Este comando utiliza dos 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 helm rollback comando 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 helm history comando 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 descubra um bug no aplicativo Web de rastreamento de drones e precise 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 helm history comando.
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
Repare que o campo da descrição mostra o número de revisão da reversão para facilitar o controlo de alterações.