O documento discute a experiência da empresa Konker em orquestrar containers Docker usando Mesos e Marathon, sem usar DC/OS. Eles enfrentaram desafios técnicos em sua arquitetura inicial e migraram para microsserviços e containers para melhorar a disponibilidade, escalabilidade e desempenho. Algumas decisões como Mesos e Marathon funcionaram bem, enquanto outras como falta de gestão de segredos e ferramentas oficiais do DC/OS apresentaram problemas.

1. Aprendizados
Orquestrando Docker com Mesos+Marathon,
sem DC/OS
André Rocha (andre@konkerlabs.com)
Wellington Mariusso (wmariusso@konkerlabs.com)

2. Agenda
● Sobre a Konker
● Nossos Desafios Técnicos
● Por que Mesos/Marathon?
● O que deu certo?
● O que não deu tão certo assim…
● O que vem pela frente!

3. Konker
● Startup brasileira de 18 meses, focada em tecnologia para IoT
● Desenvolvendo uma plataforma IoT OpenSource
(https://github.com/KonkerLabs/konker-platform)
● Proposta: modelo baseado em Platform as a Service
○ Altamente disponível
○ Suportando grandes volumes
○ Fácil de usar!

4. Desafios Técnicos de um IoT PaaS
● Altíssima disponibilidade
● Workload misto (ingestão de dados, batches operacionais, analítico)
● Possibilidade de execução em nuvem ou On Premises
● Operação enxuta (somos uma startup!)
● Escalável
● Capaz de suportar grandes volumes de clients e dados
● Multi-tenant
● Multi-idioma

5. Como todo
produto novo...
● Começamos com um MVP - alvo
para Out/2016.
● Foco em validar o modelo
● Arquitetura mais simples possível: o
grande monolito

6. Dificuldades com MVP
● A arquitetura inicial não atendia nossos requisitos:
● Estrutura monolítica
○ Deploys grandes
○ Builds complexos
● Datastore começando a apresentar dificuldades
● Inelástico
● Disponibilidade não-ótima (Failover)

7. Repensando Arquitetura
● Migrar para uma estrutura de microsserviços
● Containerizar para simplificar
● Mudança para Datastores mais robustos
● Redundância de Serviços e Load Balancing

8. ● rolling updates de containers
● canary releases
● load balancing
● service discovery
● configuration management
● health monitoring / self healing
● built-in central logging
A wishlist para o novo ambiente
● Distribuição segura de secrets
● Separação de visibilidade (público,
privado, gerenciado)
● update do cluster (não dos
containers) sem downtime
● suporte multi-az / multi-datacenter /
datacenter aware
● multi-user / segurança
Fundamental! Nice to Have...

9. Resultado:
Principais razões:
● Maturidade (na época)
● Capacidade de usar o mesmo ambiente para workload misto
(Transacional + Data Intensive)
Mas vamos com Baby Steps! :) - Sem DC/OS

11. O que deu certo?
Orquestrar docker é realmente simples
● mesos agent e docker instalado
● mesos-agent -- containerizers=docker,mesos
* É possível usar Kubernetes para pools mais complexas

12. O que deu certo?
Operar os serviços é realmente muito simples
PUT https://{marathon
host}:{marathon
port}/v2/apps/{group}/{app}
{
“instances”: {desired value}
}

13. O que deu certo?
O modelo de implantação é hibrido e se adapta bem a Cloud
https://www.draw.io/#G0B_byvJyk9fHXUGVnbzV6U2RtRm8

14. O que deu certo?
Troubleshooting via dashboard rica e intuitiva

15. O que deu certo?
Mesos Agent barato

16. O que deu certo?
Isolamento/Compartilhamento de recursos

17. O que deu certo?
Service Discovery/Registration

18. O que deu certo?
Api’s ricas e completas permitem integração de ferramental ‘out of the box’

19. O que deu errado
Falta de gestão de secrets nativa (estamos testando o Vault)

20. O que deu errado
Troubleshooting de deploy complexo

21. O que deu errado
Estado do marathon não persistente

22. O que deu errado
Marathon LB sensível a erros na configuração da camada de serviço

23. O que deu errado
SSL / TLS ( sem wildcard )

24. O que deu errado
Tuning de healthy entre Marathon e Marathon-LB

25. O que deu errado
Ferramental / suporte oficial do DC/OS fez falta

26. O que mudamos até agora
- Pelo menos 3 nós para cada serviço
- Masters recebem apenas serviços do próprio ecossistema do mesos
- Amazon ELB na borda
- Saltstack orquestra implantação de nós, serviços e configurações básicas do cluster
- ELK + Grafana + ElasticAlert (Yelp) para log e monitoria e Chatops
- Route53 + Mesos-DNS
- Ci integrado ao Marathon
- Conciliação de distribuição de recursos nos nós de mesos via mesos groups

27. O que mudamos?
Monitoria, Consolidação de Logs, Chatops para alertas

28. O que mudamos?
Agrupamento de recursos

29. Pŕoximos passos
● Zabbix para monitoria e manutenção de eventos de falha
● Vault + Vault-Gatekeeper-Mesos (já em teste) para gestão de secrets
● Plugin de gestão de volumes integrado ao EBS
● Atualização da versão do mesos e do marathon (com suporte a pods)
● kafka + Graylog?
● Autoscaling?

30. MIGRAR PARA DC/OS ?