- Un truco para resolver los problemas de costo y complejidad al operar una base de datos para desarrollo y pruebas
- VPS, VM en la nube y servicios administrados generan costos continuos y cargos de almacenamiento
- La configuración es compleja y hay que pagar por los recursos incluso cuando no se usan
- Alternativa: operar una base de datos usando GitHub Actions y S3
- Ejecutar una base de datos temporal con GitHub Actions solo cuando se necesite
- Usar AWS S3 o almacenamiento compatible con S3 para guardar los datos de forma permanente
- Al terminar el workflow, los datos se conservan y el entorno de ejecución se elimina, lo que permite reducir costos
- Mediante tunneling, es posible exponer temporalmente la base de datos a acceso público desde internet
- Precauciones al usarlo
- Este método solo es adecuado para pruebas de integración de corto plazo, demos temporales y tareas simples de desarrollo
- No usar GitHub Actions indebidamente como plataforma de servicio de largo plazo
- Si se necesita hosting de base de datos continuo y de largo plazo, lo adecuado es configurar un Self-Hosted Runner o un servicio de base de datos aparte
- Hay que operarlo cumpliendo las políticas de uso de GitHub
Idea principal
- Aprovechar el entorno de cómputo temporal de GitHub Actions
- Ejecutar una base de datos compatible con MySQL solo cuando haga falta, como parte de un workflow de CI/CD o de pruebas
- Persistencia de datos mediante almacenamiento compatible con S3
- Guardar los datos en object storage como AWS S3 o Cloudflare R2
- Aunque el entorno temporal termine, los datos quedan almacenados de forma segura en el object storage
- Tunneling para acceso público
- Exponer temporalmente la base de datos a internet para pruebas o demos
- Adecuado para uso de corto plazo
- La base de datos funciona solo durante el tiempo de ejecución del workflow
- Al finalizar el workflow, los recursos temporales de cómputo se liberan y esto no reemplaza una solución de hosting permanente
- Si quieres usarlo totalmente gratis
- Considera servicios compatibles con S3 que ofrezcan nivel gratuito, como Cloudflare R2
Casos de uso
- Pruebas de integración en CI/CD: ejecutar realmente un entorno compatible con MySQL, probar y luego apagarlo
- Demos temporales: crear a corto plazo una instancia de base de datos que se pueda compartir rápidamente
- Trabajo de desarrollo de corto plazo: probar en un entorno de base de datos real sin mantenimiento continuo
- Casos de uso no recomendados:
- Hosting de base de datos de largo plazo
- Mantener siempre activo un endpoint público de base de datos
- Eludir las políticas de uso de GitHub Actions
- Importante: GitHub Actions no fue diseñado como plataforma de servicio continua, sino para CI/CD. Si necesitas hosting de base de datos de largo plazo, deberías considerar configurar un Self-Hosted Runner
13 comentarios
Parece un uso no intencional. Considero que, aunque sea técnicamente posible, se debería evitar usar deliberadamente métodos que no son recomendables.
Como está escrito como una “triquiñuela para resolver problemas de costo y complejidad al operar una base de datos para desarrollo y pruebas”, supongo que, si tienen sentido común, sabrán juzgarlo por su cuenta.
Pensando en la ley de Hyrum (https://www.hyrumslaw.com/),
creo que es un método que tarde o temprano a alguien se le podía ocurrir.
Pero, como dicen varios de ustedes, este tipo de mal uso termina trayendo inconvenientes aún mayores.
Aunque desaparezcan las GitHub Actions del plan gratuito de GitHub… ah… esto sí que era algo bueno…
No creo que sea abuso.
¿Cuánta carga le va a poner al servidor levantar una sola base de datos? Además, según el artículo, solo la levantan por un rato.
No parece adecuado que, en lugar de levantar una DB de prueba durante el proceso de CI, se retrase intencionalmente el workflow para convertirla en una DB hospedada. La definición de “un rato” también es ambigua.
¿Es "solo cuando se necesita como parte de un flujo de trabajo de CI/CD o de pruebas"?
Si es un usuario de pago, ¿no estaría bien? De todos modos, lo usaría dentro del límite de uso asignado.
Más allá de eso, se le cobraría.
https://docs.github.com/en/site-policy/…
No sé hasta dónde llega lo que se considera aceptable, pero en la documentación se indica que recomiendan usarlo solo con fines de prueba de programas mientras no se especifique si hay cobro o no. Y, por supuesto, GitHub tiene la facultad de suspender cuentas en caso de abuso del servicio.
Jajaja, está divertido. Me pregunto cuánto se podrá ahorrar con esto...
Es un abuso. Creo que usar recursos de esta manera desvía recursos que deberían destinarse a personas de buena fe y al código abierto, aumenta el costo de operar los servicios gratuitos que ofrece GitHub y al final ese costo termina trasladándose a todos.
Igual que cuando usaban Actions para minar criptomonedas, si este tipo de acciones aumentan, las políticas se irán endureciendo cada vez más.
Y para bloquear el tunneling tendrían que restringir el tráfico saliente, así que al final los usuarios comunes serán los cada vez más perjudicados.
Estoy de acuerdo.
Viendo los comentarios en Hacker News, hay críticas que dicen que esto en sí mismo es un abuso.
https://news.ycombinator.com/item?id=42397167
Es un texto que ya estaba publicado, y lo comparto una vez para que lo vean solo como un “ah, entonces esto se puede hacer”.