Migrar do Heroku para a Absam

[anapaulagomes]

A Absam (http://absam.io) está apoiando o nosso projeto! 🎉😍 Nessa issue vamos fazer um levantamento dos serviços que precisamos configurar, questões em aberto e como fazer a migração.

O que temos na infraestrutura atual e vamos precisar na próxima:

• [x] Python 3.8 (Docker ✔️)

• [x] Java (JRE) 8 ou maior para o Apache Tika (Docker ✔️)

• [x] Banco de dados: Postgres 11 (disponível via Cloud Database mas estamos rodando com 12.4 no Heroku e Docker)

• [x] Broker: RabbitMQ (Docker ✔️)

• [x] Deploy automático depois que os testes estão passando Não tem. Temos que implementar essa integração (ver mais abaixo).

• [x] Gerenciamento de logs (logentries) Bem simples mas temos sempre a flexibilidade de rodar um serviço de logs ou ter uma maneira de fazer o download deles.

• [x] Scheduler. Podemos usar um crontab mesmo (já que a máquina é Linux).

• [x] Backups. É possível fazer backups da máquina. O Postgres tem suporte ao pgadmin, por isso imagino que seja possível fazer backup de lá também (a confirmar).

• Deploys

A Absam ainda não tem suporte para deploys automatizados usando webhooks. Geralmente as pessoas clonam o repositório, com uma chave ssh com permissão leitura no servidor. Assim é possível fazer o pull da branch sem alterar o código diretamente. Essa instrução veio do suporte da Absam.

Uma boa ideia pode ser usar algo como o webhook combinado com Github webhooks + Github Actions.

Funcionalidades da Absam que podem ser interessantes:

• Startup scripts
• API (apenas para checar o status dos servidores e ligar/desligar/reiniciar)

Arquitetura proposta

À definir.

[gomex]

MInhas sugestões e perguntas:

• Python 3.8 3.7 (Cloud App): Usar a versão mais atualizada, mas deixar especifico dentro do Dockefile;
• Java (JRE) 8 ou maior - possível com Docker: Mesma coisa do python;
• Banco de dados: Postgres 11 (Cloud Database): A ideia seria usar um RDS? Não entendi aqui;
• Broker: RabbitMQ: Essa máquina será gerida por esse projeto tb? Caso positivo, precisamos pensar na automação dela tb;
• Deploy automático: Isso é tranquilo via github actions, precisamos apenas pensar no que validar antes de mandar automaticamente para produção. Podemos usar deploy baseado em branch para começar e depois evoluir para usar master apenas ;)
• Gerenciamento de logs (logentries) Bem simples mas temos sempre a flexibilidade de rodar um serviço de logs ou ter uma maneira de fazer o download deles. Concordo Scheduler (algo como crontab). Podemos usar um crontab mesmo (já que a máquina é Linux). Temos apenas que monitorar isso aqui, pois se o job falhar, precisamos saber. Backups. É possível fazer backups da máquina. O Postgres tem suporte ao pgadmin, por isso imagino que seja possível fazer backup de lá também (a confirmar). É possível fazer backup sim, meu conselho é usar esse factor aqui: https://12factor.net/admin-processes

[gomex]

Outra pergunta, esse servidor que hospedaremos o serviço, é apenas uma máquina, correto?

[gomex]

Sobre isso "API (apenas para checar o status dos servidores e ligar/desligar/reiniciar)" a minha sugestão é que a API tenha uma rota em seu código que retorne apenas HTTP code 200, pois usaremos isso como healthcheck.

[anapaulagomes]

Banco de dados: Postgres 11 (Cloud Database): A ideia seria usar um RDS? Não entendi aqui; Cloud Database é a nomenclatura da Absam. Eles oferecem o Postgres como serviço mesmo.

Broker: RabbitMQ: Essa máquina será gerida por esse projeto tb? Caso positivo, precisamos pensar na automação dela tb;

Isso. Teríamos que ver se colocamos numa máquina separada etc

Deploy automático: Isso é tranquilo via github actions, precisamos apenas pensar no que validar antes de mandar automaticamente para produção. Podemos usar deploy baseado em branch para começar e depois evoluir para usar master apenas ;)

Boa. Se os testes e os checks de migrations estiverem passando, tudo certo. Geralmente precisamos fazer coisas como atualizar as dependências e rodar as migrações no banco.

Outra pergunta, esse servidor que hospedaremos o serviço, é apenas uma máquina, correto?

Temos 500 reais de crédito pra usar. Podemos aplicar em máquinas diferentes (https://absam.io/cloud-server/planos-e-precos).

Sobre isso "API (apenas para checar o status dos servidores e ligar/desligar/reiniciar)" a minha sugestão é que a API tenha uma rota em seu código que retorne apenas HTTP code 200, pois usaremos isso como healthcheck.

Acho que o endpoint de status já serve.

@gomex, se quiser já dar uma olhada me manda teu email no telegram que eu te adiciono na nossa conta aí você pode dar uma olhadinha. O suporte deles é bem bom também, então dá pra tirar as dúvidas pelo chat.

[gomex]

Os próximos passos para se discutir e decidir são:

• Usaremos o DB que o provedor oferece como serviço? Precisamos avaliar
• Usaremos Swarm ou Docker puro lá no servidor? Eu não acho uma boa usar K8s por agora, pq o provedor não oferece isso gerenciado.
• Precisamos alterar o docker-compose para suportar o uso do Swarm ou Docker puro
• Precisamos escolher uma solução de proxy reverso para entrada do tráfego, pode ser o Traefik (https://docs.traefik.io/)

[anapaulagomes]

Checklist para migração:

• [x] Ter acesso aos logs facilitado para acompanhamento
• [x] Fazer backup de produção no Heroku
• [x] Configurar Sentry
• [x] Configurar credenciais do S3
• [x] Configurar bot do Telegram

[anapaulagomes]

Migração realizada com sucesso pelo time de infra liderado por @gomex! Parabéns pelo excelente trabalho! 🎉🏆👏🏽