- Une astuce pour résoudre les problèmes de coût et de complexité liés à l’exploitation d’une base de données pour le développement et les tests
- Les VPS, VM cloud et services managés entraînent des coûts récurrents et des frais de stockage
- La configuration est complexe et il faut payer les ressources même lorsqu’elles ne sont pas utilisées
- Alternative : exploiter une base de données avec GitHub Actions et S3
- Exécuter une base de données temporaire dans GitHub Actions uniquement quand c’est nécessaire
- Utiliser AWS S3 ou un stockage compatible S3 pour conserver les données de façon permanente
- À la fin du workflow, les données sont conservées et l’environnement d’exécution est supprimé, ce qui permet de réduire les coûts
- Grâce au tunneling, la base de données peut être rendue temporairement accessible publiquement depuis Internet
- Points d’attention à l’usage
- Cette approche ne convient qu’aux tests d’intégration de courte durée, aux démos temporaires et aux tâches de développement simples
- Ne pas détourner GitHub Actions en plateforme de service de longue durée
- Si un hébergement de base de données continu et de long terme est nécessaire, il est préférable de configurer un Self-Hosted Runner ou un service de base de données séparé
- L’exploitation doit respecter les règles d’utilisation de GitHub
Idée clé
- Exploiter l’environnement de calcul éphémère de GitHub Actions
- Exécuter une base de données compatible MySQL uniquement au moment nécessaire, dans le cadre d’un workflow CI/CD ou de test
- Conservation pérenne des données via un stockage compatible S3
- Stocker les données dans un stockage objet comme AWS S3 ou Cloudflare R2
- Même après l’arrêt de l’environnement temporaire, les données restent en sécurité dans le stockage objet
- Tunneling pour l’accès public
- Exposer temporairement la base de données à Internet pour des tests ou une démo
- Adapté aux usages de courte durée
- La base de données ne fonctionne que pendant la durée d’exécution du workflow
- Une fois le workflow terminé, les ressources de calcul temporaires sont libérées ; ce n’est pas une solution d’hébergement permanente
- Pour une utilisation entièrement gratuite
- Envisager un service compatible S3 avec offre gratuite, comme Cloudflare R2
Cas d’usage
- Tests d’intégration CI/CD : exécuter réellement un environnement compatible MySQL, lancer les tests puis l’arrêter
- Démo temporaire : créer rapidement une instance de base de données partageable sur une courte période
- Travail de développement ponctuel : tester dans un vrai environnement de base de données sans maintenance continue
- Cas d’usage non recommandés :
- Hébergement de base de données de long terme
- Maintien d’un endpoint de base de données public toujours actif
- Contournement des règles d’utilisation de GitHub Actions
- Important : GitHub Actions n’est pas une plateforme de service continue, mais a été conçu pour le CI/CD. Si vous avez besoin d’un hébergement de base de données à long terme, il faut envisager de configurer un Self-Hosted Runner
13 commentaires
Cela ressemble à un usage non intentionnel. Ce n’est pas parce que c’est techniquement possible qu’il faut volontairement utiliser une méthode non recommandée, et je pense qu’il vaut mieux s’en abstenir.
Puisqu’il est écrit « une astuce pour résoudre les problèmes de coût et de complexité liés à l’exploitation d’une base de données pour le développement et les tests », ceux qui ont du bon sens sauront sans doute en juger par eux-mêmes.
Si l’on pense à la loi de Hyrum (https://www.hyrumslaw.com/),
je me dis que c’est une méthode que quelqu’un finirait par imaginer un jour.
Mais, comme d’autres l’ont dit, ce type de mésusage finit par entraîner des désagréments encore plus importants.
Si GitHub Actions venait à disparaître du free tier de GitHub… ah… c’était donc quelque chose de bien…
Je ne pense pas que ce soit un abus.
Quel niveau de charge le lancement d’une seule base de données peut-il vraiment imposer à un serveur ? Et d’après l’article, ce n’est lancé que brièvement.
Dans le processus de CI, il ne s’agit même pas de lancer une base de données de test ; on retarde volontairement le workflow pour en faire une base de données hébergée, ce qui semble problématique. La définition de « brièvement » est aussi ambiguë.
« seulement quand c’est nécessaire dans le cadre d’un workflow CI/CD ou de test » ?
Pour les utilisateurs payants, ce ne serait pas acceptable ? Après tout, ils l’utiliseraient dans la limite du quota accordé.
Au-delà, ce serait facturé.
https://docs.github.com/en/site-policy/…
Je ne sais pas jusqu’où va la notion de « acceptable », mais la documentation précise qu’il est recommandé de l’utiliser uniquement à des fins de test de programmes, dans un contexte où la facturation n’est pas explicitement indiquée. Et bien sûr, GitHub se réserve le droit de suspendre un compte en cas d’abus du service.
Haha, c’est marrant. Je me demande combien on pourrait économiser avec ça...
C’est un abus. J’estime que ce type de comportement détourne des ressources qui devraient être utilisées au bénéfice de particuliers de bonne foi et de l’open source, augmente les coûts d’exploitation des services gratuits fournis par GitHub et finit, en conséquence, par être répercuté sur tout le monde.
Comme à l’époque où l’on faisait du minage de cryptomonnaies avec Actions, si ce genre de pratique se multiplie, les règles vont sans doute se durcir de plus en plus.
Pour bloquer le tunneling, il faudra restreindre le trafic sortant, donc au final ce sont surtout les utilisateurs ordinaires qui seront de plus en plus pénalisés.
Je suis d’accord.
En voyant les commentaires sur Hacker News, certains critiquent cela en disant que c’est en soi un abus.
https://news.ycombinator.com/item?id=42397167
Le texte est déjà public, donc je le partage juste pour montrer le genre de chose qu’il est possible de faire.