Boas Práticas

As boas práticas aqui descritas são excertos das fontes pesquisadas, de forma a serem lidas por completo como uma lista de itens a validar.

Fontes

Leitura Obrigatória

Leituras Opcionais

Diretrizes

Ambiente de Desenvolvimento

  1. Usar 2FA/MFA para autenticação nas plataformas de desenvolvimento, sempre que houver: GitLab, GitHub etc.
  2. Recomendação de ferramenta: Visual Studio Code ou equivalente como Gitpod e outros.
  3. Extensões: GitLens, Indented Block HighLighting, Kubernetes, REST Client e Settings Sync.

Controle de versão

  1. Arquivos em YAML e validados e organizados por alguma ferramenta como YAML Lint.
  2. Todos os arquivos de configuração sob controle de versão.
  3. Uso de ramos para cada estágio do código: desenvolvimento (desenvolvimento), teste (testes), produção (master) e código fora de uso (abandonado).
  4. Os namespaces devem estar alinhados com os estágios de desenvolvimento, com especial cuidado na sequência: quando pronto o código para o próximo estágio, deve-se alterar primeiramente o namespace para depois mesclar (git merge) no ramo da próxima etapa.

Definição das imagens Docker

  1. Preferir sempre a menor imagem possível: Alpine, depois Debian Slim, depois os demais…
  2. Verificar se a instalação dos pacotes (apk, apt) irá gerar uma imagem muito grande, e daí considerar outra distribuição mais adequada/pronta.
  3. Criar um webhook no Docker Hub para criar/atualizar a imagem e salvar a URL no repositório privado de webhooks.
  4. Quando usado código de terceiro, preferir sempre a política de atualização deste. Quando houver dúvidas na política, fixar as imagens pelo número primário (major) e acompanhar regularmente (assinatura de email, changelog etc.) a publicação de novas versões. A leitura das modificações é importante por dois motivos: compatibilidade com a(s) versão(ões) anterior(es) e possível mudança nos parâmetros padrão de configuração.
  5. Quando houver uma atualização de versão, a política mais simples é a de encerrar os atuais pods e esperar o sistema (ReplicaSet) convergir para a quantidade de pods definida.
  6. Executar com usuário com o mínimo de privilégios, evitando ao máximo root.

Definição dos objetos Kubernetes

  1. Labels da aplicação: nome (app), tipo (type, como backend ou database), versão (vX.X.X), entre outros específicos por serviço/aplicação.
  2. O namespace deve estar incluído na definição do objeto, já que usamos vários repositórios (GitLab e GitHub).
  3. KISS: valores padrão são omitidos.
  4. Recursos: tanto recursos mínimos (resources) quanto limites (limits). Sempre. Se houver dúvida dos valores, pode executar uma primeira vez, observar os números no Grafana para executar novamente com os valores próximos da realidade.
  5. Sempre que possível, deve haver monitoramento constante da aplicação com livenessProbe. Para aplicações HTTP, obrigatório monitoramento, direto do protocolo. Para os demais serviços, teste TCP ou, no pior caso, comando a ser executado.

Ordem dos objetos K8s

  1. Volumes: Secret, ConfigMap, PersistentVolume;
  2. Associações de volumes: PersistentVolumeClaim;
  3. Ingresso: Ingress;
  4. Serviço: Service;
  5. Pods: Deployment, StatefulSet, DaemonSet.
  6. Tarefas: Job, CronJob.

Atualização de ambiente

  1. Ler changelog, sempre. Os valores padrão podem ser alterados, e portanto deve-se ter cuidado.