Ferramentas básicas

Antes de mais, eis as principais ferramentas que vamos utilizar:

• kubectl
• leme (segredos/difusão)
• sopas
• helmfile
• git

Para versionar facilmente as tuas configurações e acompanhar as nossas implementações, usamos helmfile que, tal como o docker compose, te permite declarar ambientes. É muito mais simples do que reescrever todos os comandos helm do zero (reespecificando o namespace, o ficheiro de valores, etc.)!

Arquitetura

Com o kubernetes, quando começas com um cluster “vazio”, existem basicamente apenas os pods utilizados para executar os nós, todos em namespaces kube-*.

Para organizar corretamente os nossos recursos, utilizaremos vários espaços de nomes, como reverse-proxy, monitoring, logging… Isto permitir-nos-á conceder facilmente direitos mais detalhados aos utilizadores ligados ao cluster.

Por isso, temos de começar por dividir as nossas configurações em vários repositórios git:

• Kubernetes Common:
  Permite a instanciação de elementos que devem ser únicos para todo o cluster. Estes incluem o painel de controlo do Kubernetes, o proxy inverso, a monitorização, etc.
• Kubernetes your-site deployments:
  Contém tudo o que precisas para implementar os diferentes ambientes do teu site. Se quiseres entregar uma nova versão do teu site, isso acontecerá através de um commit para este repositório.
• Frontend do Helm Chart:
  Define todos os componentes necessários para implementar o teu sítio. Estes podem ser deployments, services, secrets…
• Helm Chart xxx:
  Todos os teus outros gráficos personalizados, como um api ou outro…

O que é que te parece?

Kubernetes comum

Começamos com um ficheiro helmfile.yaml que irá conter a lista dos nossos lançamentos helm. e.g. :

liberta:
  - nome: traefik
  gráfico: traefik/traefik
  versão: x.x.x
  namespace: reverse-proxy
  segredos:
  - ./traefik.values.encrypted.yml

  - nome: cert-manager
  gráfico: jetstack/cert-manager
  versão: x.x.x
  namespace: reverse-proxy
  valores:
  - ./cert-manager.values.yml

cert-manager.yaml

crds:
  ativado: verdadeiro
  mantém: verdadeiro

Depois de termos configurado os nossos valores para as várias ferramentas, só nos resta executar o comando helmfile apply.

Por vezes é necessário incluir dados sensíveis em ficheiros de valor, como uma chave privada. Estes ficheiros podem, portanto, ser encriptados usando sops e helm secrets, o que permitirá ao helm desencriptar os ficheiros antes de os aplicar.

Implementações Kubernetes no teu local

Este ficheiro será diferente do comum, porque terá uma dimensão extra: o ambiente.

helmfile.yaml

ambientes:
  preprod: {}
  prod: {}

repositórios:
  - nome: ma-stack
  url: https://url-du-repo

liberta:
  - nome: frontend
  gráfico: ma-stack/frontend
  versão: 1.0.0
  namespace: "{{ .Environment.Name }}"
  segredos:
  - ./{{ .Environment.Name }}/frontend.values.encrypted.yaml

  - nome: api
  gráfico: ma-stack/api
  versão: 1.0.0
  espaço de nome: prod
  segredos:
  - ./prod/api.values.encrypted.yaml

  - nome: api
  gráfico: ma-stack/api
  versão: 2.0.0
  espaço de nome: preprod
  segredos:
  - ./preprod/api.values.encrypted.yaml

Adicionando a noção de ambiente a este helmfile significa que uma versão específica pode ser implementada para cada ambiente.

Neste exemplo, a versão 1.0.0 do gráfico frontend é implantada duas vezes: uma no ambiente prod e outra no ambiente preprod. A diferença pode estar no ficheiro de valores, que conterá definições diferentes consoante o ambiente de destino.
Por exemplo, nos ficheiros de valores, especificamos geralmente a etiqueta da imagem da doca implementada, o que, neste caso, significa que podem ser implementadas duas versões diferentes do site em cada ambiente.

Relativamente à API, esta tem uma nova versão do gráfico em pré-produção. Isto permite-te adicionar um novo elemento kubernetes, como um novo service ou qualquer outra coisa… É por isso que é uma boa ideia extrair o gráfico do teu front-end/api para outro repositório.

Depois de tudo isto, podemos aplicar esta configuração com helmfile apply e ela entrega todas as modificações necessárias em todos os ambientes!

O que vais fazer a seguir?

Com esta distribuição entre diferentes projectos, resta apenas implementar o CD.
A implementação da configuração pode assim ser automática e os nossos repositórios serão a fonte de verdade para o estado do teu cluster.
Na tua cadeia de integração, a atualização de uma aplicação consistirá em fazer o commit nestes repositórios.