quarta-feira, 15 de janeiro de 2020

Como fazer rollback de uma aplicação que roda no kubernetes

Como fazer rollback de deployments no kubernetes

Sempre falo bastante sobre estrategias de CI/CD, uso do Auto DevOps do gitlab e como o kubernetes é legal. Mas, o que muito ocorre e pouco se fala, é: O que fazer quando da ruim e preciso fazer rollback rapidão?
Eu achei um artigo bem detalhado e que explica tudo muito bem, mas para aqueles que pulam para a flag verde no stackoverflow, vou resumir colocando os passos para operar um rollback de um deployment no kubernetes.

Bora lá

Vou partir da premissa que você já usa o kubectx e o kubens (por favor!) e também que nosso deployment possui o nome "app".

Seguem os passos:

# "acessar" o cluster
kubectx [cluster]

# "acessar" o namespace
kubens [namespace]

# verificar os deployments do namespace 
kubectl get deployments

# verifica a revisão (versão) do deployment que quero operar um rollback
kubectl describe deployment/app | grep deployment.kubernetes.io/revision:

# verificar o histórico de revisões (versões) do deployment que desejo fazer rollback
kubectl rollout history deployment/app

# faço rollback pra revisão que desejo
kubectl rollout undo deployment/app --to-revision=25

# acompanho e aguardo os pods e o deployment ficarem disponíveis
kubectl get deployments,pods

# verifico se a revisão foi alterada (vai incrementar)
kubectl describe deployment/app | grep deployment.kubernetes.io/revision:


terça-feira, 7 de janeiro de 2020

Configurando auto escalonamento usando gitlab com Auto DevOps

Como usar o helm requests e limits com Auto DevOps do Gitlab

Já falei bastante aqui no blog sobre o Auto DevOps. O que poderíamos fazer para permitir que nossas aplicações (que já fazem uso de todas as praticas dos 12 fatores, rodam na nuvem em clusters de orquestração de container, possuem capacidade de tolerância a falha) possam chegar ao próximo passo e escalar de forma inteligente ainda fazendo uso do Auto DevOps?
- Agora é o momento de fazer com que nossa aplicação use apenas o recurso que ela realmente necessita e deixe o resto para quem quiser usar ou para eventuais sobrecargas que exijam "auto escalonamento" :)



Para aqueles que usam o auto DevOps do gitlab e já perceberam que nem tudo é configurável, apresento-lhes a variável HELM_UPGRADE_EXTRA_ARGS do .gitlab-ci.yaml. Essa varável nos permite apontar um arquivo para modificar outros valores dos nossos arquivos yaml gerados pelo Auto DevOps. E um desses valores (que vou falar aqui), é o resources.

Para usa-la, basta inclui-la em variables no .gitlab-ci.yaml:
variables:
  - HELM_UPGRADE_EXTRA_ARGS: "--values helm-values.yaml"
*percebam que passei o nome de um arquivo depois de "--values"

Certo, seguem os passos:
- Junto ao arquivo .gitlab-ci.yaml, vamos criar um arquivo chamado: helm-values.yaml
- Dentro do arquivo helm-values.yaml, vamos incluir as informações de resources (recurso que minha aplicação tem disponível para trabalhar e o limite acima disso).

Dentro do helm-values.yaml:
resources:
  requests:
    memory: "150Mi"
    cpu: "50m"
  limits:
    memory: "195Mi"
    cpu: "65m"
*para encher linguiça, vou apenas deixar aqui a explicação e sugiro que você leia antes de brincar com requests e limits: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container

Outra forma de configurar o upgrade helm

É possível usar um nome e path padrão. Se usado, o gitlab entende e não precisamos colocar a variável no .gitlab-ci.yaml. para isso, basta criar o arquivo helm: .gitlab/auto-deploy-values.yaml com o mesmo conteúdo do a helm-values.yaml mencionado acima.

Variável criada e arquivo helm preparado

Faremos o deploy via Auto DevOps e dessa forma, possibilitamos nosso cluster escalar nossa aplicação caso ela atinga determinadas métricas (podendo crescer ou diminuir) de acordo com a demanda.

Para configurar o auto scale no seu objeto deployment, faça o seguinte:
- kubectx [nome do cluster]
- kubens [nome do namespace]
- kubectl get deployment
*aqui irá listar seus deployments
- kubectl autoscale deployment [nome do deployment] --min=1 --max=3 --cpu-percent=85
*min, max e cpu são apenas exemplos. Você pode configurar de acordo com sua necessidade.

É isso o/ flwss

Ref:. https://gitlab.com/gitlab-org/gitlab-foss/issues/65497