- Uma gambiarra para resolver problemas de custo e complexidade ao operar um banco de dados para desenvolvimento e testes
- VPS, VMs em nuvem, serviços gerenciados etc. geram custos contínuos e taxas de armazenamento
- A configuração é complexa e você acaba pagando por recursos mesmo quando não os está usando
- Alternativa: operar o banco de dados usando GitHub Actions e S3
- Executar um banco de dados temporário com GitHub Actions apenas quando necessário
- Usar AWS S3 ou armazenamento compatível com S3 para persistir os dados
- Ao final do workflow, os dados são mantidos e o ambiente de execução é removido, permitindo reduzir custos
- Por meio de tunelamento, é possível expor temporariamente o banco de dados para acesso público pela internet
- Cuidados ao usar
- Essa abordagem é adequada apenas para testes de integração de curto prazo, demos temporárias e tarefas simples de desenvolvimento
- Não abuse do GitHub Actions como plataforma de serviço de longo prazo
- Se você precisa de hospedagem de banco de dados contínua e de longo prazo, o mais adequado é configurar um Self-Hosted Runner ou um serviço de banco de dados separado
- A operação deve seguir as políticas de uso do GitHub
Ideia principal
- Aproveitar o ambiente de computação temporário do GitHub Actions
- Executar um banco de dados compatível com MySQL apenas quando necessário, como parte de um workflow de CI/CD ou de testes
- Persistência de dados com armazenamento compatível com S3
- Armazenar os dados em object storage como AWS S3 ou Cloudflare R2
- Mesmo que o ambiente temporário seja encerrado, os dados permanecem armazenados com segurança no object storage
- Tunelamento para acesso público
- Expor temporariamente o banco de dados na internet para testes ou demonstrações
- Adequado para uso de curto prazo
- O banco de dados funciona apenas durante o tempo de execução do workflow
- Após o término do workflow, os recursos temporários de computação são liberados, e isso não é uma solução de hospedagem permanente
- Para usar totalmente de graça
- Considere serviços compatíveis com S3 que ofereçam camada gratuita, como o Cloudflare R2
Casos de uso
- Testes de integração em CI/CD: executar de fato um ambiente compatível com MySQL, testar e depois encerrar
- Demos temporárias: criar rapidamente uma instância de banco de dados compartilhável para uso de curto prazo
- Tarefas de desenvolvimento de curto prazo: testar em um ambiente real de banco de dados sem manutenção contínua
- Casos de uso não recomendados:
- Hospedagem de banco de dados de longo prazo
- Manter um endpoint público de banco de dados sempre ativo
- Contornar as políticas de uso do GitHub Actions
- Importante: o GitHub Actions não foi projetado como plataforma de serviço contínuo, e sim para CI/CD. Se você precisa de hospedagem de banco de dados de longo prazo, considere configurar um Self-Hosted Runner
13 comentários
Parece um uso não intencional. Só porque algo é tecnicamente possível não significa que seja recomendável usar deliberadamente um método que não é indicado.
Como está escrito
"uma gambiarra para resolver problemas de custo e complexidade ao operar um banco de dados para desenvolvimento e testes", imagino que quem tiver bom senso saberá julgar por si mesmo.Pensando na Lei de Hyrum (https://www.hyrumslaw.com/),
acho que é um método que alguém poderia acabar imaginando algum dia.
Mas, como outras pessoas aqui estão dizendo, esse tipo de mau uso acaba trazendo problemas ainda maiores.
Mesmo que o GitHub Actions desapareça no plano gratuito do GitHub… ah… então isso é que era algo bom…
Não acho que isso seja abuso.
Quanto de carga subir um único banco de dados realmente causaria no servidor? E, segundo o texto, é só subir por um instante mesmo.
No processo de CI, não se trata apenas de subir um banco de dados de teste; parece haver um problema em intencionalmente atrasar o workflow para transformá-lo em um banco de dados hospedado. A definição de “por um instante” também é ambígua.
"Mas isso é "somente quando for necessário como parte de um fluxo de trabalho de CI/CD ou de testes", não é?"
Se for usuário pago, não estaria tudo bem? Afinal, usaria isso dentro da cota disponibilizada.
Acima disso, haveria cobrança.
https://docs.github.com/en/site-policy/…
Não sei exatamente até onde vai o que é considerado aceitável, mas a documentação afirma que recomenda o uso apenas para fins de teste de programas, já que não há indicação explícita sobre cobrança. E, claro, o GitHub tem o direito de encerrar a conta em caso de abuso do serviço.
kkk, interessante. Quanto será que dá para economizar fazendo isso..
Isso é abuso. Acho que, na medida dos recursos consumidos por esse tipo de conduta, estão sendo desviados recursos que deveriam ser usados por indivíduos bem-intencionados e pelo open source, além de aumentar o custo de operação dos serviços gratuitos oferecidos pelo GitHub, o que no fim acaba sendo repassado para todos.
Assim como na época em que usavam o Actions para minerar criptomoedas, se esse tipo de prática aumentar, as políticas vão ficando cada vez mais rígidas.
Para bloquear o tunelamento, seria preciso restringir o tráfego de saída, então no fim quem vai ficando cada vez mais prejudicado são os usuários comuns.
Concordo.
Nos comentários do Hacker News, há críticas dizendo que isso em si já é um abuso.
https://news.ycombinator.com/item?id=42397167
Como o texto já é público, estou compartilhando só para mostrar o nível de “nossa, então isso é possível?”.