Trilha Containers How we figured out we had a SRE team at - O caminho para o uso de Kubernetes no Governo Federal

1. Projeto Estaleiro - O
caminho para o uso de
Kubernetes no Governo
Federal

2. XaaS e a fábrica de salsichas

3. ● XaaS - Qualquer coisa como serviço
● IaaS - Entra especificação, sai máquina
● PaaS - Entra código, sai app server rodando
● Por trás de qualquer coisa as a Service, existe um motor de
orquestração decidindo onde, quando e como o serviço será
provisionado
Alguns conceitos

4. Container é apenas um
processo em execução no
Sistema Operacional
Containers

6. Container é apenas uma aplicação
rodando em um servidor e expondo
seus serviços em uma porta
qualquer
Containers

8. SERPRO e a fábrica de aviões

9. ● +- 5 mil Servidores
● Mainframes
● Muitos e muitos serviços críticos
● Muitas e muitas tecnologias
● Muitas questões: Agilidade em entrega, performance das
aplicações, segurança, diversas configurações necessárias
SERPRO e a fábrica de aviões

10. ● Durante o dia: Troca de um dos motores
○ Avião desbalanceado!! Problema em vôo !!
● Desenvolvimento: O avião está com problemas!!!
○ Troca aquela peça lá e vê se resolve.
● Comandante do vôo: Emergência declarada. Checklist XPTO
para pouso de emergência!!
SERPRO e a fábrica de aviões

12. Nós construímos o barco
que leva o seu container
Projeto Estaleiro

13. Projeto Estaleiro

14. ● Docker - Engine para execução de containers
○ Um orquestrador, que recebe especificação e cria
mecanismos de isolamento de processos no servidor
● Kubernetes
○ Um orquestrador de containers :)
○ E outras coisas a mais ;)
Nosso Foco

15. Projeto Estaleiro

16. ● Integrações com o mundo tradicional
○ Bancos proprietários, Mainframe, SFTP…
● Aplicações antigas no novo mundo
○ Armazenamento local de arquivos
○ Aplicações com persistência de sessão - Ex.: JSF
○ Aplicações em linguagens não suportadas - Ex.: .NET
E os problemas do mundo real ?

17. ● Boas práticas de desenvolvimento para aplicações cloud native.
● Aplicável aos desenvolvedores de soluções para o novo mundo.
● Aplicável aos engenheiros de operação dessas aplicações
● Aplicável também à infraestrutura desses serviços
○ CoreOS - Cloudinit, log driver remoto, etc
12 Factors

18. ● Códigos no GIT
● Do GIT a publicação só ocorre via CI
● Gitlab tem um plugin de publicação no Kubernetes
● Para o Projeto Estaleiro - API própria, com CLI própria usada
nos Runners
● github.com/estaleiro/12factors
Factor 1 - Code Base

19. Factor 1 - Code Base

20. ● PaaS - Para cada plataforma, existe a possibilidade de
declaração de dependências
● Imagem final construída à partir de dependências + a aplicação
em si - Source to Image
● Não fazemos a compilação da aplicação, logo aplicações Java
devem utilizar Maven, Gradle, etc.
Factor 2 - Dependências

21. ● Mesma imagem, diferentes configurações
● Para cada ambiente, integrações diferentes (mas a mesma
imagem)
● Kubernetes: Objeto de deployment
○ Especificar a imagem, usar as configurações definidas em
variáveis de ambiente
Factor 3 - Configurações

22. apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: app-katz-dev
spec:
replicas: 1
template:
metadata:
labels:
app: app-katz-dev
spec:
containers:
- name: app-katz
image: rpkatz/app-katz
ports:
- containerPort: 8080
env:
- name: MENSAGEM
value: "Olá! Esse é o ambiente de desenvolvimento"
Factor 3 - Configurações

23. Factor 3 - Configurações
Demonstração

24. ● Toda integração deve estar declarada
● Como forçar?
Factor 4 - Attached Resources / Serviços de apoio

26. ● Toda integração deve estar declarada
● Como forçar?
○ Regras de firewall na saída
○ Calico - Stack de rede para o Kubernetes
○ Necessário declarar integrações como anotação, para que
as regras sejam abertas!
● Documentação de integrações:
Factor 4 - Attached Resources / Serviços de apoio

27. ● Existe um container base para cada plataforma
● O processo de publicação cria um novo container com a
imagem base (jboss, php, python) + dependências + aplicação
compilada (Factor 2)
● Nova imagem: projeto/aplicacao:versao
● Essa versão pode (e deve) ser usada em todo o ciclo de vida do
ambiente
Factor 5 - Build, Release, Run

28. ● Se você armazena estado, como sua aplicação será escalável?
● Ahm, mas eu preciso de afinidade de sessão...
Factor 6 - Processos stateless

30. ● Se você armazena estado, como sua aplicação será escalável?
● Ahm, mas eu preciso de afinidade de sessão…
● Mas eu preciso MUITO de afinidade de sessão…
● https://github.com/kubernetes/ingress/pull/258
● Mas...por sua conta e risco, veja o problema a seguir...
Factor 6 - Processos stateless

31. Factor 6 - Processos stateless
Demonstração

32. ● Além do PR no Ingress, outras abordagens para tratar esse
fator:
○ Redis como plataforma, para controle de sessão (inclusive
para .NET Core!)
○ Evitar usar abordagens que dependem de sessão (apps com
JSF)
Factor 6 - Processos stateless

33. ● A aplicação tem sua própria porta e não depende de um
serviço/plataforma externa para isso.
● Cada aplicação / deployment isolada, com sua própria porta
● Bom: Apps Java com Jetty, Apps Go com seu HTTP Server,
.NET Core com sua porta, Apps J2EE com Wildfly Swarm
● Não tão bom... Usar Wildfly completo, Apache + PHP, etc
● Para esse, ainda não temos uma solução em uso :(
Factor 7 - Port Binding

34. ● App de demonstração dessa palestra:
func main() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", logRequest(http.DefaultServeMux))
}
● Código completo em http://github.com/Estaleiro/12factors
Factor 7 - Port Binding

35. ● A aplicação deve estar preparada para concorrência e
elasticidade
● Kubernetes permite o crescimento horizontal, conforme uso de
CPU, e as aplicações devem estar preparadas para isso!
○ Horizontal Pod Autoscaling (HPA)
Factor 8 - Concorrência e Elasticidade

36. Factor 8 - Concorrência e elasticidade

37. ● Container morreu? Cria de novo!
○ Morre rápido, sobe rápido
● SRE Book (Google) - Manter 100% de disponibilidade é MUITO
CARO! - É mais barato manter a disponibilidade de 99.999% e
assumir que as coisas podem (e vão!) falhar.
● Deployment Health Check
● Ex.: Aplicação (em produção) morre 400x por semana e tem 0
incidentes!
Factor 9 - Descartabilidade

38. apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: app-katz-dev
spec:
replicas: 1
template:
spec:
containers:
- name: app-katz
image: rpkatz/app-katz
livenessProbe:
httpGet:
path: /factor9
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
ports:
- containerPort: 80
Factor 9 - Descartabilidade

39. Factor 9 - Descartabilidade
Demonstração

40. ● “No meu ambiente funciona!”
● Solução: O cluster K8S é o mesmo, de Dev a Prod
● Mesma build, diferentes diretivas
○ Pode rodar na sua estação se quiser!
Factor 10 - Paridade Dev/Prod

41. ● Graylog!!!
● Em toda engine Docker, subimos ela com o Gelf Log Driver
● Graylog extrai e trata campos, gera alertas baseados em
comportamento
● Tratamento de erros: Aplicação deve fazer
● Erros e stack traces == Inferno
○ Solução: Sentry
Factor 11 - Logs e fluxos de evento

42. ● Mesma base de código, container diferente para isso
● Pode ser por exemplo um ‘Short running’ Container que suba,
execute as tarefas administrativas e finalize, mas com a mesma
base de código.
● Ex.: Carga de um banco de dados
● Kubernetes Jobs para isso
○ Ou ainda um kubectl exec em algum container, e algum
comando especial (não é o ideal!)
Factor 12 - Processos Administrativos

43. ● OS DOIS!!!
● Flexibilidade - Demandas não aderentes ao 12 Factor tem valor,
geram conhecimento (e código!) e devem ser tratadas
● Ex.: Discussão de evolução de plataformas de produção do
Wildfly para aplicações auto contidas (Factor 7)
● Risco x Valor - Containers não são (e nem tem como ser)
solução para tudo, mas não devemos desistir tão facilmente.
Você quer ter razão ou ser feliz??

44. ● https://12factor.net/pt_br/
● https://github.com/gomex/docker-para-desenvolvedores
● https://docs.gitlab.com/ce/user/project/integrations/kubernetes.ht
ml
● Kubernetes Docs
Referências

45. Dúvidas?
Agradecemos pela atenção.
Ricardo Pchevuzinske Katz
ricardo.katz@serpro.gov.br
@katzsp
github.com/Estaleiro