Enregistreur VHS dans les nuages - Architecture sur GCP

Une architecture très peu onéreuse en utilisant des services serverless, qui ne coûte absolument rien si inutilisée. Ça semble logique, mais pas toujours aussi évident.

Sans détour, un schéma donnant une vue à vol d’oiseau de l’architecture du système :

recorder-gcp.png

Automatisation des déploiements avec GitOps

J’utilise Bitbucket et Github pour mes repository Git, Github pour tout ce qui est public, et Bitbucket pour le privé. Le processus de déploiement est simple, dès qu’un tag est créé, et parce que les repositories sont synchronisés avec Source repo, ça déclenche un mécanisme utilisant Cloud Build.

CICD avec Cloud Build et Container Registry

Cloud Build utilise le code pour générer les container images et pousser celles-ci sur Container Registry et sur Cloud Run pour l'API.

API de contrôle qui roule sur Cloud Run

Pour lancer un enregistrement d’une émission, il suffit d’appeler l’API avec l’URL choisie et le système va ajouter la tâche dans la queue. Le tout tourne sous Cloud Run, une plateforme serverless permettant de créer une application simplement en ayant une image qui écoute sur le protocole HTTP. Si l’application n’est pas appelée, aucun coût n’est chargé, ce qui permet une économie énorme lorsqu’un système n’est pas utilisé de façon constante.

Un système de file d'attente (queue) sous Firestore

Comme le tiers gratuit de GCP est assez généreux avec Firestore, cette base de données nosql serverless est utilisée pour sauvegarder les paramêtres, et le plus important, les statuts des tâches en cours.

Preemptible VMs et Cloud Scheduler

Une fois que l’API a poussé les données sur Firestore, Cloud Scheduler s’occupe d’appeler le même API périodiquement afin de vérifier s’il y a des tâches à exécuter, et surtout, s’il y a des émissions à enregistrer. Si tel est les cas, l’API va s’occuper de lancer une nouvelle machine virtuelle. Ces machines virtuelles utilisent la classe préemptive, qui permet d’obtenir un prix grandement réduit, mais tout en acceptant que ces machines puissent être arrêtées à tout moment, donc sans garantie que l’enregistrement sera terminé. Le truc est de s’assurer qu’une nouvelle VM prend le relais à la suite d’un échec, et le tour est joué.